Sharepoint - Configure a new SharePoint install with existing databases

Note: This is the database restore process we follow, if you want to recreate the farm just do your SharePoint install and configure as you need then overwrite the databases created with the production versions. It's how we populate new installs when we create local SP vm's for development and test use.

We do this on a monthly basis, and while this is edited to remove the customized steps we need due to external database dependencies, the general steps are there. This also includes a few steps we found when dealing with Managed Metadata that we also move around.

Note: Email should be turned off before a Content Database restore, to assure that any uncompleted Workflows do not send email unnecessarily.

When updating a SharePoint Content Database we do both the Content and Managed_Metadata as these items need to be kept in Sync for the Taxonomy on the content to remain in sync.

In addition, for User Profile Data the following Databases are restored:

• User_Profile_Service_Application_ProfileDB
• User_Profile_Service_Application_SocialDB
• User_Profile_Service_Application_SyncDB

Create a SQL Server backup of the source content database, or grab one of the nightly backup files, we typically use backups due to the size

Copy the backup file to the target machine In the Sharepoint 2010 Management Shell execute the following commands: Get-SPContentDatabase - to make sure you know which database to dismount Dismount-SPContentDatabase "" where is the existing content database shown from the previous command

Note: When the Mount-SPContentDatabase command is used it will relink the Term Store to the Content and that is necessary for successfully moving the Managed Metadata database. To prepare for that turn off the Managed Metadata Web Service on ALL machines in the Farm

Restore the database in the target SQL Server using SQL Management tools to import the backups over the existing databases

Remount the Content DB Mount-SPContentDatabase "" -DatabaseServer "" -WebApplication "http://sitename"

where:

• is the restored backup
• is the target machine name
• is the root site

If the Managed Metadata Database has been updated turn the Service back on ALL machines in the Farm

With the Content Database reattached update the Metadata Database to point it to the Web Application in the new environment, from the SharePoint PowerShell Administrator app run: Set-SPMetadataServiceApplication -Identity "" -HubUri "" -SyndicationErrorReportEnabled

To verify that this has updated select the Managed Metadata Service from the Service Application list and select Properties, the properties page will note the Content Type Hub at the bottom of the page.

Because the Metadata database brings down permissions from Production as well run the following update statement in SQL Manager to reset the Administrator account for the Metadata Service Proxy

update [Managed_Metadata_Service].[dbo].[ECMPermission] set PrincipalName = '<LOCAL>' where PrincipalName =  '<PROD>'

With the updates to the User Profile databases the User Profile My Sites settings need to be updated, the My Site Host setting needs to be set to the proper environment URL to allow the Edit Profile link to point to the current environment. Sometimes this gets changed to the production value. Verify the Term Store Administration list is set properly, this will carry over the accounts from the database it was restored from so if you want to use this and have the right access check the accounts and adjust them as necessary.

Email should be turned on as the last step.

yes, you can use your existing databases. Content databases are easiest, farm databases might be a little trickier as your server name is different. Check out http://technet.microsoft.com/en-us/library/cc512725.aspx, this walks through moving databases to a new server, but the same techniques should work for what you're looking for

HTH

What you're probably easiest doing (and I think what you may mean), is to stand up a new installation of SharePoint somewhere (on a VM or something, just a completely separate farm), and attach the content databases from your live environment to your own, new farm.

You can attach the content database using the Mount-SPSContentDatabase powershell cmdlet.