Cloud

SharePoint 2010: Cloned SharePoint Server Zombie

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.

Microsoft - The Essential Guide to Microsoft Teams End-User Engagement
The Essential Guide to Microsoft Teams End-User Engagement

We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.

Get the Guide

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.

About the Author

Andrew Schwenker is a Sr. Technical Consultant within Perficient’s Microsoft National Business Unit East's SharePoint practice. Andrew has nearly 2 years of experience in consulting and has participated in projects that have touched nearly every aspect of SharePoint 2010. Andrew earned his Bachelor’s degree in Computer Science as well as Master’s degrees in Computer Science and Information Systems from Indiana University. He’s interested in creating winning solutions to generate business innovation using SharePoint. Prior to starting at Perficient, Andrew completed internships with General Electric, ExactTarget, and Great American Financial Resources. During his studies, he actively participated in Alpha Phi Omega National Service Fraternity and competed in the first annual Cluster Challenge at SC07 in Reno, NV. Andrew was a part of the dynamic PointBridge team that was acquired by Perficient.

More from this Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up