UPDATE: 2024-12-11
This issue was resolved in the 2024-11 CU for Server 2022 (https://support.microsoft.com/en-us/topic/november-12-2024-kb5046616-os-build-20348-2849-817737a3-4027-485e-ba0d-e97ad4378047). If you made the change below in the past, you will need to revert it, otherwise, the CU will fail to install due to a hash mismatch when it checks VersionCheck.sql.
Original Post:
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 😂):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
2021-11-22 00:17:18 Install type is: UnsupportedFuture 2021-11-22 00:17:18 DB is a higher version than the config scripts 2021-11-22 00:17:18 Swtching DB to multi-user mode...... 2021-11-22 00:17:18 Finished setting multi-user mode 2021-11-22 00:17:18 Ensuring SUSDB is set to Multi-User Mode ... 2021-11-22 00:17:18 Disposing Connection 2021-11-22 00:17:18 Clearing Connection Pools 2021-11-22 00:17:18 Microsoft.UpdateServices.Administration.CommandException: The schema version of the database is from a newer version of WSUS than currently installed. You must either patch your WSUS server to at least that version or drop the database. at Microsoft.UpdateServices.Administration.ConfigureDB.CheckForUnsupportedVersion(DBInstallType installType, Boolean dbExists) at Microsoft.UpdateServices.Administration.ConfigureDB.ConnectToDB() at Microsoft.UpdateServices.Administration.ConfigureDB.Configure() at Microsoft.UpdateServices.Administration.ConfigureDB.Run(String instanceName, Action`1 logWriter, Boolean contentLocal) at Microsoft.UpdateServices.Administration.PostInstall.Run() at Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments) |
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):
|
1 2 3 4 5 6 7 |
2021-11-22 00:17:15 Checking to see if database exists... 2021-11-22 00:17:15 Database exists 2021-11-22 00:17:15 Switching database to single user mode... 2021-11-22 00:17:18 Loading install type query... 2021-11-22 00:17:18 DECLARE @currentDBVersion int DECLARE @scriptMajorVersion int = (20348) DECLARE @scriptMinorVersion int = (11) |
Time to hop into SQL Management Studio. First thing I look at is the tbSchemaVersion table:
|
1 2 3 4 5 6 7 8 |
USE SUSDB; SELECT * FROM tbSchemaVersion; ID ComponentName BuildNumber SchemaVersion 1 CoreDB 20348.51 1333526579 2 PublishingDB 20348.51 20399 3 ServiceAdminDB 20348.51 20399 4 TroubleShooterDB 20348.51 20399 |
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:
|
1 2 3 4 5 6 |
UpdateSchemaVersion.sql (lines 15-18) SET @coreDBschemaVersion = (20348 * 65536 + 51) SET @publishingDBschemaVersion = (20348 + 51) SET @serviceAdminDBschemaVersion = (20348 + 51) SET @troubleShooterDBschemaVersion = (20348 + 51) |
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…
|
1 2 3 4 5 6 7 8 9 10 11 |
VersionCheck.sql (lines 2-3) DECLARE @scriptMajorVersion int = (17763) DECLARE @scriptMinorVersion int = (107) UpdateSchemaVersion.sql (lines 15-18) SET @coreDBschemaVersion = (17763 * 65536 + 107) SET @publishingDBschemaVersion = (17763 + 107) SET @serviceAdminDBschemaVersion = (17763 + 107) SET @troubleShooterDBschemaVersion = (17763 + 107) |
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:
|
1 2 3 4 5 6 7 8 |
USE SUSDB; SELECT * FROM tbSchemaVersion; ID ComponentName BuildNumber SchemaVersion 1 CoreDB 17763.107 1164116075 2 PublishingDB 17763.107 17870 3 ServiceAdminDB 17763.107 17870 4 TroubleShooterDB 17763.107 17870 |
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:
- Change the owner of VersionCheck.sql from “NT Service\TrustedInstaller” to yourself.
- Grant yourself full control NTFS permissions.
- Edit and save the file.
- Remove your NTFS permissions
- Change the owner back to “NT Service\TrustedInstaller”
After completing the above, I reran the postinstall command and it completed successfully! Hooray!
excellent post! got my lab issue squared away in no time.
Woohoo, Thank you, Thank you for sharing this.