I wrote a blog post on how to move SQL Server instances from one cluster to another cluster late last year and found myself needing to move a SharePoint instance from a standalone Hyper-V machine to our bare-metal physical database cluster. The main difference between the last instance move and this instance move is that the SERVER\INSTANCE_NAME would change this time around rather than staying the same but just moving to a different home. If the SERVER\INSTANCE_NAME didn’t need to change – things would have been easier. I started by referencing my old post and let the journey begin:
There are two main ways that you can move SharePoint databases, the easy network alias method where you really don’t tell SharePoint that you are moving the databases (that you have to then live with for ever) or the real way in which you do tell SharePoint that you have moved the databases and that it is aware of what you did. The main process for following both of these methods can be found in this KB article, but it is never as easy as following their steps. I believe the key to success on this move is to keep the old instance up and running while you perform the changes – then you can stop the SQL Server services on the old instance to test, pay attention to this below. DO NOT start hacking the registry in a brute force method to just make it work
https://technet.microsoft.com/en-us/library/cc512725.aspx
To get started, I followed a lot of my own steps in my previous blog post with I will leave out here and only cover the important steps:
- Make the SharePoint instance unavailable to your users – I did this through my load balancers, but you want to make sure that no one is changing the database in case you need to roll back or they are not working with the database after you already made backups of it.
- Just to be sure, I also stopped IIS and all related SharePoint services on my web front ends
- Making sure that all my SQL users from the old instance have been moved over to the new instance, follow this KB article to help you out: http://support.microsoft.com/kb/918992 (this is a bit on an art as you need to modify the file before you execute it, you may have old users, be referring to default databases that don’t exist yet, etc.)
- I run a script that puts all the databases in to Simple recovery, shrinks them and the log files and then I back up ALL the databases in my old SharePoint 2013 instance (SQL Server 2012). This makes the file copy to the new server go much faster.
- Copy the backup files to the new instance on the cluster (SQL Server 2014) and run the restore scripts (as seen in my last post).
- Once the databases are restored on the new instance and you can test access to the new instance with the same user that SharePoint will try to access them with from the SharePoint web front ends (use osql to test if you need to), you are ready to move on to the SharePoint related steps – because up to this point, you have not really touched SharePoint.
- On the SharePoint server, open the SharePoint 2013 Management Shell and run the following command to pipe all your databases out to a text file: Get-spdatabase | Out-File C:\databases.txt
-
Once you have the text file with all of the SharePoint databases in it, you want to use that file to build a script that makes all the changes for you in a single pass. Take a single line like this and replicate this process for each line in the databases.txt file (the GUID is the only thing that you are really keeping from each source line):
StateService_fee01336… 04d5b4bc-5341-4388-a870-7922a01928fe Microsoft.Offi…
And convert it to this:
$db = get-spdatabase -identity 04d5b4bc-5341-4388-a870-7922a01928fe
$db.ChangeDatabaseInstance(“<YourNewServer\InstanceNameHere”)
$db.Update()
Write-Host $db.DatabaseConnectionString
![]()
![]()
-
Once you have the file created/converted, then you can either test one database or run the entire file. Here is an example of testing a single database and confirming that the new SERVER\INSTANCE_NAME has indeed been changed. Make sure you have followed these rules to this point; No manual registry changes AND the old database instance is still online and accessible!
![]()
- The next step is to make ONE SINGLE registry change, update the SERVER\INSTANCE_NAME at this ONE location with the new one you used above:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure\ConfigDB]
-
Now that the heavy lifting is done, follow these steps to wrap it all up and test it.
- Close all SharePoint 2013 Management Shells that are currently open
- Stop the SQL Server services on the OLD instance that you are moving away from (or shut he machine down for now – and hopefully for good)
-
Open a new SharePoint 2013 Management Shell and run the following command: Get-spdatabase
- If you see the following results, you know it is connected to the new database instance and everything should work fine
- If you see a bunch of red errors, something is wrong and it can’t connect to the new database instance
-
Now you can either restart IIS and all the related SharePoint 2013 services on your web front ends, or just reboot them (my suggestion is to reboot them) and wait for the system to come back online
![]()
If you have any issues, first check your database connectivity to the old and new instances while you are running the power shell commands. You can very easily roll the entire process back by simply putting your old instance name in the power shell commands and re-running them to point everything back to your old instance and updating the one item in the registry and rebooting your web front ends.
It is really not a complicate process, but the KB article doesn’t cover all the bases. You should be comfortable with SQL Server, SharePoint and Power Shell in order to get through this without too much heartache.
Good Luck!
-Eric Niemiec
