Copyright from: www.cdh.com
Have you ever found yourself in the situation where you wished you had named your SharePoint server differently? Renaming that server isn’t exactly straight forward. You can’t simply rename the machine and call it good. SharePoint contains many references to the name of your machine throughout it’s database, and all of these must be changed as well. Luckily, Microsoft has provided us with a handy PowerShell cmdlet called Rename-SPServer to make most of these changes. There’s more to it than just this command, however, so I’m going to go through all of the steps that I have a lot of success with.
In a nutshell, we’re going to first rename the server in SharePoint’s eyes using PowerShell, then actually rename the machine itself, fix a few things neither of those two steps updated for us, and run an upgrade command. And we should be doing all of this as the Farm Account to ensure we don’t run into any permission issues performing these steps.
If this is a 2013 server, we’re also going to have to contend with the Distributed Cache service. The first time I tried to rename a 2013 server I had a bear of a time with this service still having references to the old server name and not working properly. There is a specific order these steps have to go in, otherwise you can end up with trouble.
In detail, here are the steps that I take:
1. Log into the server as the Farm Account.
2. Open SharePoint Management Shell (PowerShell).
3. If this is SharePoint 2013, execute the command:
Remove-SPDistributedCacheServiceInstance
We need to remove this before the server is renamed. Doing this out of order I was running into many difficulties getting this service working again, and getting it to forget the old name of the server.
4. Next, execute the command:
Rename-SPServer -Identity “[old_server_name_here]” -Name “[new_server_name_here]“
You will probably see an “Object not set to an instance of an object” error message, this is normal, the farm was renamed.
5. Now rename the actual Windows server itself to the same name you gave the Rename-SPServer command. These must match, otherwise you’re going to end up with SharePoint Management Shell windows that say nothing but “Farm not found”.
6. Reboot the server.
7. Log back in as the Farm Account and open the SharePoint Management Shell(PowerShell) back up again.
8. Execute the command:
New-SPAlternateURL -WebApplication http://[old_server_name]:[central_admin_port]
-Url http://[new_server_name]:[central_admin_port] -Zone Default
The Rename-SPServer cmdlet doesn’t rename the alternate access mapping for Central admin for you… it doesn’t touch any of the alternate access mappings. You’ll need to repeat this command for every Web Application you may have that is simply the old servers name on different ports.
9. Now open up a regular ole’ command prompt and execute the following:
psconfig.exe -cmd upgrade -inplace b2b -wait -force
This will take a while. You also may get an error saying the User Profile Synchronization service failed to start, which is fine. You’ll need to go start that manually via Central Admin afterwards.
10. If this is a SharePoint 2013 server, let’s head back to SharePoint Management Shell and resurrect the Distributed Cache Service by executing the command:
Add-SPDistributedCacheServiceInstance
Now let’s head to Central admin to fix a few things there.
11. Investigate the User Profile Synchronization Service. It was most likely stopped by the upgrade above and will need to be started again. I have ran into a rare instance where it reported that it was Started, but ended up finding that it actually wasn’t provisioned. If you find this to be the case, just go to the service and see that it is running normally. Kick off an incremental to make sure. Stop and Start the service again if you run into any issues.
12. Finally, let’s head to the Search Service Application to update the Content Sources and any Crawl Rules you may have. If you have any sources or rules that reference the name of the old server, these too will need to be updated with the new server name.
After all of this you may also want refresh your Health Analyzer list, the one that drives that little yellow or red bar across the top of Central Admin telling you that it has detected some issues. If you don’t have one of these displayed, AWESOME! It’s rare to find a farm that doesn’t have something in there. If you have any issues in there they’ll most likely be reporting these issues had occurred on the old server name. Once the rule runs again later on it’ll start saying the issue exists on both the old and new server names. It doesn’t hurt anything to leave it like this, but I like to go through and clean out that entire list and let it start fresh again with the new server name.
If you don’t want to wait for all of those rules to run again over time, you can force them all on the spot with the following command in the SharePoint Management Shell:
Get-SPTimerJob | where {$_.Title -like “Health Analysis Job*”} | Start-SPTimerJob
