Step by Step Guide to Perform SCCM ConfigMgr Server Hardware Migration

This is the post which you want to refer before performing any kind of SCCM/ConfigMgr server migration. Follow the steps one by one and make sure your SCCM server hardware migration is hassle free !

2
Advertisement
Moving SCCM/ConfigMgr server from one hardware to another is common scenario in enterprise world. There could be several reason for this kind of SCCM/ConfigMgr server hardware migrations. Server OS upgrade is one of the most common scenario. Yes, SCCM CB 1606 and later versions supports in place upgrade of server OS. However I’ve seen that most of our server teams don’t want to perform in place OS upgrade.
I have completed similar kind of migration activities many times in my career. It’s very important to follow these steps when we need to perform migration or server hardware changes of your SCCM server. I’m not covering SQL migration in this post. In this scenario, SQL is on remote box. If the SQL is on the same box then things will be bit more easy. I’ve divided the migration process into 5 phases:-
  1. Pre SCCM Migration Activities
  2. Start of SCCM Migration Activities – Downtime starts from here
  3. SCCM Installation activities on new server
  4. SCCM/ConfigMgr Recovery/Restore activities
  5. Post SCCM/ConfigMgr Repair/Recovery activities
 
Pre SCCM Migration Activities
  • Create new servers with new names – check whether the SCCM version which you are going to install supports OS version of the servers
  • Make sure new servers are created in same VLAN – This will make life much more easy
  • Make sure the Drive letters of newly provisioned servers are same as existing servers
  • Request for storage extension if you want to keep 3 or 4 copies SCCM full backup on the new server
  • Document the SMS Groups and security settings of existing servers and configurations of SCCM console
  • SCCM Site backup and store remotely (confirm success) – Probably a day before actual migration schedule
  • 4-5 days before actual SCCM server migration, replicate all the Data SCCM Package folders, drivers etc (all data except those are NOT covered as part of SCCM Full backup) to Newly provisioned server
  • Make sure the copy of SCCM source files and pre-requisites are already copied to new SCCM servers
  • Perform differential copy of Data SCCM Package folders, drivers etc to Newly provisioned servers (may be couple of hours before depending on the size of data)
  • Document current servers AD membership inc groups OU etc, also current IP information
  • Remove remote site system roles like SUP/RP. Make sure site system details have been removed from SCCM console.
  • Take couple of extra Site backup copy and store it on newly provisioned SCCM server
  • Take Snapshot of existing SCCM servers (include the drive where SCCM is installed)
 
Start of SCCM Migration Activities - Downtime starts from here
  • Remove existing SCCM servers from domain ensuring you know local admin account details
  • Shutdown existing SCCM servers
  • Rename existing SCCM servers in Vcenter or HyperV to .old
  • Rename new SCCM server in Vcenter/HyperV to existing SCCM server names
  • Delete existing SCCM servers from AD
  • Take new SCCM/ConfigMgr servers off domain and reboot ensuring you have local admin account details
  • Log onto new SCCM/ConfigMgr servers using local admin account
  • Change IPs of new SCCM servers to reflect old SCCM server IP details
  • Change new SCCM servers names to existing SCCM server name and reboot
  • Log on to new SCCM servers as local admin account
  • Add new SCCM servers to domain and reboot
  • Verify OU, System Management Access and AD membership information of new SCCM/ConfigMgr servers. Reboot if you have made any changes above
  • Storage migrate any back end storage in vmware/HyperV to ensure that vmdk files and vmx/VHDX files are named correctly
  • Take full backup of Remote SQL Database (confirm success)
  • Archive this SQL backup so the old server can be re-instated as a backout plan if site not working correctly
  • Delete SCCM Databases (SCCM and SUSDB) from remote SQL server
  • Delete SQL logins for existing SCCM computer objects using SQL management studio

SCCM Installation activities on new server
  • Make sure all security permissions and security groups/computers are added back to the new SCCM servers
  • Install WSUS admin console
  • Install WAIK 2.0 (SCCM 2007) or ADK (SCCM 2012 or CB) depending on the version of SCCM
  • Install all the pre requisites like IIS, Bits  etc…on new servers
  • Install WSUS on remote WSUS server
  • Install SCCM/ConfigMgr Software on new SCCM server – Make sure you install exactly the same version of existing SCCM server. For SCCM CB versions, source files are part of SCCM Full backup
  • Make sure that everything works fine after the installation of SCCM/ConfigMgr on new servers
  • Take a copy of the SRVACCT folder from the new installation (<Install Path>\Microsoft Configuration Manager\SRVAcct) N.B. this is a hidden folder
  • Re populate the local SMS group memberships as they were (not all site roles may be installed so repeat the task at the end)
  • Take Snapshot of the servers pre-site recovery
 
SCCM/ConfigMgr Recovery/Restore activities
  • Make sure the servers are restarted
  • Restore/attach databases (SCCM and SUSDB) from backup (use SQL to restore if it is a remote SQL box)
  • Run the SCCM/ConfigMgr site REPAIR wizard. Select the check box “Do not restore database” to skip the DB restoration
  • Make sure you have started the REPAIR wizard with administrator access. Also, provide the exact path of SCCM full backup folder
  • Stop the SCCM services and copy the previously archived SRVACCCT folder back over
  • Start SCCM services and monitor the sitecomp.log as components re-install
  • Once sitecomp.log complete perform a site reset to repair file and registry permissions
  • Install SCCM RP
  • Install SCCM SUP on remote server
 
Post SCCM/ConfigMgr Repair/Recovery activities
  • Make sure all the packages source including classic package and software update packages are restore with same share names and permissions
  • Repopulate the local security groups on SCCM servers
  • Check the sender.log to make sure that the restores SCCM servers are able to communicate with child primary sites. Some case we need to delete the addresses from SCCM console and recreate it
  • Make sure all the accounts with passwords in SCCM console have been removed and recreated
  • Create a new package/Collection and make sure that the package/collection is getting replicated to downstream servers
  • Start new WSUS Sync and check whether it works fine or not. You may need to wait for hours and hours before completing the WSUS sync
  • Make sure the replication of old packages and OSD related packages are getting replicated Ok or not

2 COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here