There are two common scenarios where an organization may need to change the Operating System instance for a System Center Configuration Manager (ConfigMgr/SCCM) site server:
- Hardware swap out
- Operating System upgrade((As of ConfigMgr Current Branch 1702, Windows Server 2008 and 2008 R2 are no longer supported for site servers; see Supported operating systems for System Center Configuration Manager site system servers for details.))
Because of a few fixed limitations within ConfigMgr, this swap out is non-trivial. These main limitations are:
- You cannot change the name of a site server.
- You cannot change the domain of a site server.
- You cannot change the volume layout of a site server.((You can change physical drives all you want as long as the same [logical] drive letters are available to ConfigMgr. This is also not explicitly true because if you really know what you are doing, some changes are actually possible. And no, mapped drives don’t work — if you have to ask why you probably shouldn’t be doing anything described in this post. Not being mean, just saying that if you can’t do addition, you aren’t going to be able to do calculus.))
Note that of course you can technically change these, but ConfigMgr won’t work anymore.
So, what are the options for these two scenarios?
- Migration to a new site
- In-place OS upgrade (only applicable to the OS upgrade scenario and not the hardware swap-out scenario)
- Site backup and restore
Migration to a new site
Migration seems to be for some reason the default choice most folks make yet it’s the worst option of the three for these two scenarios. Migrations are great to get away from that crazy old ConfigMgr 2007 site or to get rid of that evil CAS; however, they are the worst choice for our two scenarios because:
- They are also complete re-installs.
- Clients must be re-deployed.
- Some configuration will always have to be re-done including Client Settings which cannot be migrated using the migration tools.
- Distribution point migration is cumbersome and lengthy at best and is compounded by the number of DPs and their connectivity.
- Can’t migrate secondary sites.
- Any hard-references to site codes, system names, IDs, or other names won’t be valid after the migration.
- Other things like content and custom reports are not handled by the migration tools.
The above list isn’t comprehensive but it certainly contains the top items that should easily [hopefully] dissuade you from considering this the best choice.
Most folks state that performing a migration also gives them the chance to “clean up” the environment. Well, that’s just a plain garbage reason. If you want to clean up the environment, then clean it up. You can do it without a migration in an even more controlled manner.
In-place OS upgrade
(As noted in the list above, this option isn’t applicable in hardware refresh scenarios.)
In-place OS upgrade is the preferred option of the ConfigMgr product team. As long as you upgrade to ConfigMgr CB 1606 or 1610 first, then pretty much any in-place OS upgrade path is fully supported by both Windows and ConfigMgr. There are some complications with built-in components like WSUS though because if you are going from Windows Server 2008 or 2008 R2 to Server 2012, 2012 R2, or 2016, then the WSUS version is also updated and this will break things. Jorgen covers this process pretty well in his post: ConfigMgr CB 1602 Server 2008 R2 in-place upgrade to 2012 R2.
In-place OS upgrades have a stigma attached to them though. Traditionally, everyone was quite scared of them and probably for good reason. Prior to Windows installations being image based, the Windows installer had a lot of work to do. Since Windows Vista and Windows Server 2008 though, the setup process is image based and generally much more reliable. That doesn’t make the process perfect though and so folks are still, understandably averse to doing this.
Site backup and restore
Site backup and restore is not a server backup and restore, it is a [su_highlight]site[/su_highlight] backup and restore per the official documentation. It is perfectly supported to restore a site to a completely new system (it would be really dumb if it wasn’t) and it’s perfectly supported for that new system to have a different operating system on it — for the OS upgrade scenario, this would be a newer operating system version of course. You still need to address WSUS version differences, but it requires much less effort in general than a migration. Additionally, this is completely transparent to other site systems in the environment as well as the clients. One last major benefit is that it gives you a chance to actually test and run through the site restore procedures because if you can’t restore something, then your backups are useless.
Here’s a comparison of the three methods:
| Migration | In-place OS Upgrade | Site Restore | |
|---|---|---|---|
| Fully Supported | Yes | Yes | Yes |
| Preserves all configurations | No | Yes | Yes |
| Re-installation of site roles | All | Some | Some |
| Redeployment or reconfiguration of clients | Yes | No | No |
| Downtime required | No | Yes | Yes |
| Easy fallback | Yes | No | Yes |
| Requires new hardware or virtual machine | Yes | No | Depends* |
| Shared DPs or content re-distribution across WAN | Yes | No | No |
| Involves “risky” OS in-place upgrade | No | Yes | Yes |
* A site restore can be performed to the same hardware that’s had it’s OS updated via a wipe and load. This eliminates the easy fallback path and is a bit scary, but it works the same way.
In the next post, I’ll be posting a complete list of steps that I follow for performing a site backup and restore for either scenario.
A New Hope
A lot of folks will read the above and ask why there isn’t an easier way, a way to just “transfer” the site server functionality directly to a new system without performing any of the above. Well, the best answer currently is “it is what it is”. There is a new method being worked on though and was recently presented at MMS 2017: site server high availability. This, of course,e is not designed for our scenarios explicitly, but it will work while accomplishing our goals for either scenario and in a much more streamlined fashion. Basically, you stand-up a fail-over site server in the same primary site. From there, you simply fail over operations to this new server and decommission the old server. This new high availability feature set doesn’t handle the database though so that will still need to handled separately.
Unfortunately, this feature hasn’t even hit a technical preview yet so there’s no telling when it will hit a production build or what limitations and nuances will exist. For today we are limited to the above three options.
Hi,
I’ve gone trough all of these options.
In place upgrade
– I would not really recommend this
Migration
– Lots of work, have done it just because something with the 2007 migration had gone wrong and we were left with some unrecoverable errors in the database. Not a show stopper but we had to manually edit the database from time to time in order to make things work so I preferred to have a “clean” start but took the sane option of migrating instead of recreating everything from scratch. I can tell you now it was the right choice…
Backup and restore on new server (same name, same partition labels, moved the site DB to a standalone SQL server)
– Did it for the 2012R2 upgrade. We first upgraded the site to 2012R2, moved the DB on a temporary server, backed the site up, spun up new 2012R2 servers (previously we had 2008R2), restored on the new server, moved the database to the new SQL server, moved all DP’s and Siste systems to new servers.
Everything went very smooth, some minor problems with the SQL server.
Backup and restore is definitely the way to go in my opinion, especially if you have a very large environment.
Very nice article! At the time I did not make a thorough analyse as you did, but the backup and restore seemed the best option without much thought back then.
does the backup/restore work with different server, same name ( different object SID)?
Yes. ConfigMgr doesn’t care about or use the computer object’s SID (it probably doesn’t even know what it is just like most applications); however, to maintain any security permissions previously assigned to the computer object (if you or whoever set up ConfigMgr) was short-sighted and didn’t use a security group to assign those permissions, it may be easier to reuse the same computer object.