It’s become very popular to run SharePoint 2010 in a virtualized environment, especially for development purposes. As a result, many systems administrators are taking snapshots and cloning existing SharePoint servers. That’s great from an IT administrative perspective. It allows you to quickly recover if something goes wrong or you need to add processing power.
The darker side of the cloning process is what happens when you put that cloned server on the same network as the server it was cloned from. The IT administrator will have to rename the server or Windows will get very upset, this much is obvious. Unfortunately, even after you’ve renamed the server, SharePoint continues to keep on chugging thinking it’s the original server. The configuration settings for the SharePoint Configuration Database are stored locally on the server along with the server name so simply changing the server’s name in Windows doesn’t cut it.
I recently had this happen at a client and it results in some incredibly weird behavior, especially since we weren’t aware of the cloned server at first. The long and short of it is that anything that relies on more than one timer job is going to behave erratically because SharePoint assigns timer jobs by server name. Since you have two servers with the same name, your process could end up running on either one! Timer jobs are the single most important aspect of SharePoint and all service applications are built on top of them.
In my situation, search and user profiles were completely shredded. We had custom timer jobs that we could not debug on the original because they were running on the clone server! The clone was a mindless zombie that kept screwing up the SharePoint Best Practices Analyzer and didn’t appear in the list of Servers in this Farm. We discovered it when we saw different IP addresses in the ULS logs.
How do you correct this? There’s a PowerShell cmdlet called Rename-SPServer that you can use or there’s STSADM if you’re old school. I won’t go into all the details here because there’s a great blog post about it over at Decentrix written by the BIAnalytix Team that you should check out if you find yourself in this situation.
