Recently, I came across an issue in which a Secondary Site Server experienced unrecoverable hardware failure. After the server was rebuilt, the old site was deleted with PreInst.exe /DELSITE and a new Secondary Site was created, I had to start re-adding all of the servers that were members of the failed Seconday Site.
For simplification, we’ll say the site code of the crashed Secondary Site is OLD and the site code of the newly created Secondary Site is NEW. (Gotta love convenient three-letter words when it comes to SCCM!)
After adding the Site Systems and installing some component roles, I noticed ID 1048 in the Site Status error logs. Error 1048 states: “SMS Site Component Manager detected that site system \\SERVERNAME is currently in use by SMS site OLD.”
OLD had been deleted but the Site Systems could not be removed before deletion, so they were, in effect, orphaned. SCCM should attempt to remove Site Systems in such a state after 7 days. I was under the gun a bit and needed to get the NEW Site Systems working as soon as possible. Here’s what I did…
EDITING THE DATABASE DIRECTLY IS NOT SUPPORTED BY MICROSOFT. USE AT YOUR OWN RISK!
I had some remnants of OLD sitting around in the Sites_DATA table. I ran these two commands to get rid of them:
SELECT * INTO Sites_DATA_Backup FROM Sites_DATA
This created a backup of the current table (just in case).
DELETE FROM Sites_DATA WHERE SiteCode = 'OLD'
Now, it was time to get some Secondary Site Systems moved over to the NEW site. Because the OLD Secondary Site Server had crashed without providing the opportunity to cleanly remove the Site Systems, every role and configuration was nearly intact on the servers… but configured for OLD instead of NEW. After moving the Site Systems to NEW and adding component roles, I watched the sitecomp.log on NEW Secondary Site Server and saw:
Server is already part of SMS site OLD.
Server installation failed and will be retried in the next polling cycle.
To get everything moved over, you need to change some registry settings on the Secondary Site System. Kudos to this post for pointing out the specific keys. The data below reflects a 64-bit system and a few more keys that were appropriate to my situation considering I created a new Secondary Site code.
Step One: Stop the SMS Agent Host and SMS_EXECUTIVE services on the Secondary Site System.
Step Two: BACKUP THE SMS REGISTRY KEY BEFORE EDITING.
Step Three: MAKE SURE YOU BACKED UP THE SMS REGISTRY KEY.
Step Four: SERIOUSLY. IT DOESN’T TAKE VERY LONG TO BACK IT UP.
Step Five: Look at the following keys on your new Secondary Site Server and copy/paste the necessary settings to the Secondary Site System.
“Site Install Map File Path”
(Look for any keys that point to the old UNC path of the retired Secondary Site Server.)
Step Six: Continue through the list of components under SMS Server Role and change pertinent site code information from the old one to the new one. After making a solid pass through the keys, I would go back to the top of the SMS key and do a Find command to see if you missed any instances of your old site code.
Step Seven: Once all registry entries have been changed, start the SMS Agent Host and SMS_EXECUTIVE services on the Secondary Site System again.
Step Eight: Restart the SMS_SITE_COMPONENT_MANAGER service on the new Secondary Site Server and watch the Sitecomp.log file. You should see the Secondary Site Server begin installing roles on the Secondary Site System.