ConfigMgr SQL WSUS

Upgrading ConfigMgr Infrastructure – Tips and Gotchas

Anthony J. Fontanez

I’ve recently worked through a number of different situations involving upgrading ConfigMgr infrastructure away from older version of Windows Server and SQL Server. In this post, I don’t plan on covering specific processes in detail (there’s already many docs and other blogs out there, some of which I will link to). Instead, I will be going over what options there are for different situations and their pros and cons, as well as some issues that I have run into, and how to best resolve them.

Site Server OS Upgrade Options

There are three options for upgrading a site server to Server 2019+:

  • In-Place Upgrade (IPU)
  • Site Recovery
  • Site Server High Availability (HA)

I personally prefer the IPU and Site Recovery options. IPU tends to be the quickest path forward to a newer OS, and my first choice. Site Recovery is a good alternative to IPU when the current site server is just plain old and has a bunch of junk on it, and you want to start “fresh” for the most part. Site Recovery is also the alternative if an IPU somehow goes off the rails (which is not something I’ve encountered, but always good to have in your back pocket). Remember, VM snapshots are NOT a supported recovery mechanism in ConfigMgr!

That brings us to Site Server HA. It’s an awesome feature. I know others that have used it to migrate to a newer site server. It’s the only option that allows you to rename your site server (yes, that’s can actually be a hard requirement for some folks, usually due to moving to a new datacenter or Azure). However, it can be a lot of extra work, both pre and post upgrade, if you don’t intend to keep HA around. For example:

  • SQL must be remote – for small to medium sized sites, this means you are likely spinning up a new server to move SQL to temporarily. Don’t forget about other ConfigMgr-related databases, these will need to be moved as well – SUSDB, SSRS, and Data Warehouse.
  • The content library must also be remote – this can be a lot of data to move, which can time consuming.
  • The site server cannot also have the Distribution Point role installed on it – this is a pre-req to moving the content library.
  • The Service Connection Point (SCP) will also need to be moved elsewhere – easy enough role to move, but yet another thing to consider.
  • You may also need to consider other important roles such as the Management Point and Software Update point. If you only have one of each, you’ll need to move them as well, and moving a SUP the “correct” way involves sharing the SUSDB and WSUS content. If the current SUP is using WID, that’s yet another issue to contend with.
  • If you don’t plan on keeping HA, you will effectively be doing all of the above work twice, along with potentially creating temporary servers along the way. It’s just not worth it in my opinion.
  • I’m also of the opinion that site server HA is best coupled with SQL Always On (if keeping HA), which also makes administration and management of your environment more complicated. Take a good long look at what your business requirements are to determine if you really need it. Usually, just having multiple instances of other important roles (such as MPs/DPs/SUPs) and a documented site backup and recovery process is “good enough”.

In general, my go-to process is to first update SQL to the latest available SP/CU, then upgrade the OS to 2019, and finally upgrading SQL to 2019.

Site Server OS In-Place Upgrade Tips/Gotchas

Primary Microsoft Documentation: Upgrade on-premises infrastructure that supports Configuration Manager

In-Place Upgrade is my go-to preference in the majority of situations. It has the lowest amount of prep work, usually the easiest to complete, and you still have the site recovery option in the rare chance that things just don’t go well. There are some key items about this process that I do want to make note of and expand on, based on my experiences. This is not meant to include everything in the above link; please refer to that for a complete list of tasks.

Windows Management Framework 5.1 Removal

Windows Management Framework 5.1 MUST be uninstalled from Server 2012 R2 prior to OS upgrade, if it was previously installed. Note that this is not a default update/feature, it would have been installed/deployed administratively if present. Server 2012 R2 comes with WMF 4.0 by default.

The docs linked above make mention of this, but don’t exactly go over why. After digging through a failed lab upgrade, scouring docs/blogs, and consulting peers, I found this: Configuration Manager task sequence doesn’t continue after an in-place upgrade to Windows 10. Ignore the fact it mentions client operating systems, the key information is listed in the Cause section:

“WMF 5.1 installs a Windows 10 version of the WMIMigrationPlugin.dll file in the C:\Windows\System32\migration directory. This DLL is responsible for migrating the WMI repository during the in-place upgrade. However, the Windows 10 version of the WMIMigrationPlugin.dll file is incompatible with Windows 7 and Windows 8.1. Therefore, the migration of the WMI repository fails during the in-place upgrade. This results in the WMI repository becoming corrupted, and the task sequence can’t continue in the new (Windows 10) OS.”

If you are even remotely familiar with ConfigMgr, you know that it relies heavily on WMI, especially the site server. Rebuilding WMI is not something you want to be doing there. Also note the following information mentioned later in the above link:

“There is currently no fix for this issue in the Windows 8.1 cumulative updates.”

Recall that Windows 8.1 = Windows Server 2012 R2. This means that even if your 2012 R2 site server is fully up to date, the WMF issue is sitting there dormant, and the only way to resolve it pre-upgrade is to remove WMF 5.1

If you are unable to remove WMF 5.1 (usually due to using dism in the past to clean up the WinSxs folder), you will need to import the task sequence linked in the docs for review and utilize the scripts in it, as there are a number of steps in it that will attempt to revert the DLL file from previous versions. If you are unable to resolve this, you should move directly to doing a Site Recovery instead of IPU.

WSUS Removal

WSUS doesn’t really need to be uninstalled prior to OS upgrade. The docs linked above mention that WSUS should be uninstalled (if present) prior to OS upgrade, and this is the Microsoft supported path.

I prefer to avoid doing this as before removing WSUS, the SUP role should be removed, and removing your only SUP can cause some interesting side effects for endpoints that had their software updates managed by ConfigMgr.

In my experience, the underlying WSUS version will upgrade fine during the OS upgrade process, similar to other Windows features like IIS. You will need to run postinstall via wsusutil in order to upgrade the SUSDB schema, but you would need to do even if you removed and reinstalled WSUS.

  • Performing a WSUS postinstall (WsusUtil.exe is located in C:\Program Files\Update Services\Tools\):
    • WsusUtil.exe postinstall SQL_INSTANCE_NAME=SQLSERVER.domain.com CONTENT_DIR=X:\WSUS
  • Verifying the SUSDB schema version:
    • SELECT * FROM [SUSDB].[dbo].[tbSchemaVersion]
SUSDB schema version after postinstall

Other Pre-Upgrade Tips

  • Install all available Windows Updates pre-upgrade, but don’t bother upgrading .NET just yet, as it will revert to 4.7 post-upgrade anyway. Upgrade it to 4.8 afterwards.
  • Install any available SQL SP/CU to ensure that the version of SQL you are running is supported. If you are currently still on SQL 2012, ensuring it is at SP4 is critical, as SP4 is the only build of SQL 2012 that is supported by Server 2019.
  • If your site server is currently running 2012 (non-R2), you cannot upgrade directly to 2019. You will need to “double hop” upgrade through 2012 R2 first.
  • If you have remote Software Update Points, also plan to upgrade those at or around the same time, to ensure the management components installed on the site server match the WSUS version on the remote SUPs. Temporarily disable the sync schedule, and re-enable it after all upgrades are complete, to ensure there are no issues.
  • Finally, run a site backup and verify site/component status is all green, before beginning the OS upgrade. I know this sounds pretty obvious, but it’s still good to mention!

Post-Upgrade Tips

  • Check/enable relevant services (some won’t be started or will be disabled), and restart the server to verify they start as expected.
  • Run a site reset to verify all ConfigMgr file/registry permissions are applied correctly. Once the site reset is complete, monitor all status messages, it will take a bit of time before things kick back into gear (you’ll know things are good once there is a time jump in status messages and everything begins to be processed again).
  • Upgrade .NET to 4.8 and install all available Windows updates.
  • Remove SMBv1 components if still present, as you likely don’t need them.
  • Don’t forget to activate Windows if necessary!
  • Install Edge so you don’t need to use IE anymore! (👀Morten)

Site Recovery Tips/Gotchas

If you plan on using the Site Recovery method, this does give make dealing with SQL a bit easier.

  • You can move directly to a newer version of SQL at the same time (SQL 2019 CU5 minimum, latest CU recommended).
  • You can easily restructure how SQL is laid out if desired (DB file location, log file location, etc.).

Make sure to also inventory what is installed on the current site server, and plan on reinstalling/reconfiguring things as needed. Things like external tools/utilities, 3rd party patching tools, etc., will need to be dealt with. If you have any scripts/scheduled tasks configured on the old server, make sure to carry those over as well.

Pre-Recovery Tips

  • Prepare the new server with a temporary ahead of time with site/role pre-reqs, but don’t install SQL until after taking over the hostname of the current site server. Renaming a SQL server has never gone well for me.
  • Now is a good time to switch away from running SQL as SYSTEM if that is the current configuration. Using a (group) Managed Service Account with limited permissions to run SQL is always a good idea. The MSA/gMSA should only need to be granted “Log on as a service” and “Lock pages in memory” user rights assignments.
  • Remove the Reporting Services Point role if currently installed on the site server, and reinstall it afterwards.
  • Copy the content library over to the new server to avoid needing it to be rebuilt afterwards.
  • Run a site backup just before starting recovery to ensure you have the most recent state to run setup from.
  • Stop the site and disable ConfigMgr/SQL services if planning on leaving the old server running during recovery.
  • Ensure that the new SQL instance is prepared correctly – there are things that are performed automatically during site installation that do not occur during recovery/maintenance.
  • Make sure to grant the new site server computer object access to the System Management container in AD, and remove the old object’s access.

Post-Recovery Tips

  • Once site recovery is complete, you may have other ConfigMgr roles that were utilizing the old SQL server. These all need to be handled differently:
  • If you were previously running the ConfigMgr client on the site server, reinstall it at this point.

SQL Server In-Place Upgrade Tips/Gotchas

Upgrading SQL to 2019 is a mostly straightforward task, however, there’s a few items that can trip things up depending on what version you are currently running. Specifically, SSRS became a separate component in 2016, and SSMS in 2017. This just means that a few tasks need to be performed in a specific order to successfully upgrade a ConfigMgr SQL server to SQL 2019.

One important note: SQL 2019 does not support Server 2012 R2, and SQL 2012 must be at SP4 to support Server 2019, so if you are in the situation of running SQL 2012 on Server 2012 R2, you will need to ensure SQL 2012 is running SP4, then upgrade the OS to 2019, and then finally, you can proceed to upgrade SQL to 2019.

Additionally, if you make use of the BitLocker Management feature of ConfigMgr, review the following docs to ensure the encryption certificate is rotated correctly: https://learn.microsoft.com/mem/configmgr/protect/deploy-use/bitlocker/encrypt-recovery-data#manage-the-encryption-certificate-on-sql-server-upgrade

Pre-Upgrade Tips

  • Backup any custom reports as a precaution.
  • Remove the Reporting Service Point role from your site before messing with SSRS.
  • Export the encryption key via SSRS Configuration Manager before removing SSRS.
    • The SSRS databases are reusable, but without the encryption key, some saved items will need to be recreated, such as schedules with saved credentials.
  • Modify the existing SQL installation and remove all SSRS and management tools components, leaving only the database engine.

Upgrade & SSRS Reinstallation Tips

  • Upgrade the SQL instance to 2019 and latest CU.
  • Install the latest version of SSMS.
    • Pro-Tip – This is a great way to keep the SQL native client up to date, as SSMS includes this (a somewhat newer version than what you can download standalone I’ve found), plus it’s just useful to have installed on your site server.
  • Install and configure standalone SSRS, reusing the existing databases, and import the encryption key.
    • This is also a good opportunity to “upgrade” to Power BI Report Server, if desired (and have licensing for it). PBIRS can utilize the same databases that SSRS used, but they will be converted in the process and cannot be reverted to SSRS later.
  • Depending on what version of SQL you upgraded from, you may encounter the following error when attempting to import the encryption key backup due to the old instance still existing in the database.
SSRS Scale-Out Error
State of Keys table after first attempting to import the encryption key backup
  • Clicking OK does not appear to actually resolve the issue, however, you can with the following query:
    • DELETE FROM [ReportServer].[dbo].[Keys] WHERE InstanceName = 'MSSQLSERVER'
    • This only seems to occur when upgrading from SQL 2014.

Post-Upgrade Tips

  • Reinstall the Reporting Services Point role.
    • Any custom reports should still exist as they travel with the database, but if any issues occur, just reimport the RDL files.
  • Raise the compatibility level of the site database to 150 (2019).
    • This may be undesirable in some circumstances, depending on site/database size.
    • SSRS databases can also have their compatibility levels raised.
  • Be aware that upgrading SQL will not relocate database files; if your previous instance was configured to use default file paths, the files will remain in a folder with a name including the old SQL instance name.

Conclusion

All in all, it’s not too bad of a process to get a ConfigMgr site upgraded to Server 2019 and SQL 2019, and you’ll be in a much better state. ConfigMgr will drop support for Server 2012 R2 when it goes end of life next year, and SQL 2012 is already end of life. Once all of your upgrades are complete, you can even in-place upgrade the OS again to get to Server 2022 if desired!

Related Posts

ConfigMgr OSD

Domain Join Hardening Changes (KB5020276) – Workaround

Anthony J. Fontanez
ConfigMgr SQL WSUS

ConfigMgr, Multiple SUPs, Server 2022, and “The schema version of the database is from a newer version of WSUS”

Anthony J. Fontanez

5 thoughts on “Upgrading ConfigMgr Infrastructure – Tips and Gotchas”

  1. Excellent real-world guide. Can I ask is WMF 4.0 a problem or is it just WMF 5.1?

    Reply

  2. After Upgrading the SCCM Console wont open again. Any Ideas? Thanks an Regards

    Reply

Leave a Reply