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

I recently added a second site system server to my lab environment, in order to migrate all of the client-facing ConfigMgr roles off the primary site server. After successfully moving the Management Point and Distribution Point roles, I turned my attention to the Software Update Point. I knew this process was going to be a bit more complicated than just adding new roles and dropping old roles, but I ended up running into a bug in one of the SQL scripts included with WSUS in Server 2022.

For reference, both of my site system servers are running Server 2022, build 20348.350. The ConfigMgr site is running 2107 with the latest hotfix. The first SUP was installed using SQL, but with a local content directory, so my first task was to move the content to a fileshare so the second SUP could utilize it. Easy enough:

WsusUtil.exe MoveContent "\\ad.domain.tld\Shares\WSUSContent" "%TEMP%\WSUS_MoveContent.log"

The next task was to run WSUS postinstall on the new server before adding the SUP role, usually also a simple task. Until this appeared in the postinstall log (yes, “Swtching” is a typo directly from the log 😂):

Well that’s interesting. I double-check both server patch levels and they indeed match (20348.350). I try rebooting the server and running postinstall again, and no dice. Moving backwards in the log, I find that it’s running a SQL script included with WSUS (C:\Program Files\Update Services\Database\VersionCheck.sql):

Time to hop into SQL Management Studio. First thing I look at is the tbSchemaVersion table:

Interesting, the build number is 20348.51 and VersionCheck.sql is expecting 20348.11. Looking at another SQL script included with WSUS, UpdateSchemaVersion.sql, I find 20348.51 referenced again:

At this point, I’m pretty sure there is a typo in VersionCheck.sql. To confirm my suspicion, I spun up a Server 2019 VM, installed SQL 2019 + LCU, and installed WSUS (I know I’ve set up multiple SUPs on Server 2019 with a shared database and content directory in the past without issue). Lo and behold…

So on the Server 2019 host, it’s referencing 17763.107 in both scripts, and just to triple-check, I ran the same SQL query against the SUSDB database:

Looks like they all match! So now, to fix things on the new Server 2022 VM so I can finish installing my new SUP, I updated line 3 of VersionCheck.sql to the following:

DECLARE @scriptMinorVersion int = (51)

Note, in order to make this change, you will need to temporally take ownership of the file and assign yourself NTFS privileges to it. This can be completed by doing the following:

  1. Change the owner of VersionCheck.sql from “NT Service\TrustedInstall” to yourself.
  2. Grant yourself full control NTFS permissions.
  3. Edit and save the file.
  4. Remove your NTFS permissions
  5. Change the owner back to “NT Service\TrustedInstall”

After completing the above, I reran the postinstall command and it completed successfully! Hooray!

Leave a Reply