I'm trying to "clone" my company's SharePoint installation in order to run some experiments. The system is run on a virtual machine, but for some reason the VM will only work in the system were it is currently located, it won't boot in any other. I'm working to find an answer to that problem, but in the meanwhile I still need to clone the SP installation.

I have access to all the databases (which I also copied using SQL Server Management Tools to another machine) so my question is if there is a way to install a new SP 2010 installation and point it to the databases I already have copied.

EDIT: To clarify my question, I need to move the whole farm, not just the content DB. I could accept losing some information, but databases like the Managed Metadata cannot be lost.


4 Answers 4


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"


  • 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


  • @lozzi, If I'm getting the article right, the strategy they use is simply aliasing the DB connections. My problem is that I have no Sharepoint server at all. I need to install a new server that will connect to the old databases.
    – Carlos G.
    Commented Nov 8, 2011 at 22:12
  • my bad, i power read it. To my previous question, are you targeting just the sites? or do you want the entire farm moved? Commented Nov 9, 2011 at 1:48
  • The entire farm
    – Carlos G.
    Commented Nov 9, 2011 at 13:02
  • Ok, this might be tricky. Moving an entire farm might be be possible, as a cold move (just copy and move). You can install new servers into a farm and deactivte old ones, basically moving it along, but with a copy it'll be a lot more complex. I can't seem to find much about it online. I'd guess you'd have to attack it: 1) copy databases 2) install SP farm 3) as you configure, specify the copied databases for your services (i'm guessing it'll attach to existing ones). 4) you may have to run some commands to rename the farm servers after the fact? Commented Nov 9, 2011 at 13:13

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.

  • Can the same strategy work for Service Applications DBs and the Configuration DB?. My intention is to have an exact copy of our current system
    – Carlos G.
    Commented Nov 8, 2011 at 22:10

You need to install SharePoint on the machine, which also needs SQL Server installed (can be Express) into which you have restored your content database. Once you have the SharePoint bits installed you can run the SharePoint Configuration Wizard and create a new SharePoint farm. Then create a Web Application. Within the new web application create a new site collection, but instead of letting it create a new database, give it the name of the database you restored into SQL Server.

I tend to do this kind of thing using the Central Administration UI, but you can also use PowerShell. You probably need to find a good blog or MSDN article about each of those steps if you haven't done it before. If you want more than just the content database it gets more complicated. I would not bother trying to restore the configuration database - just let the wizard create a new one.

  • How about the Service Applications DB?
    – Carlos G.
    Commented Nov 9, 2011 at 13:05
  • Generally this is possible, though more complicated. The precise steps will depend on the service app.
    – SPDoctor
    Commented Nov 9, 2011 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.