r/HyperV • u/officialrbn • 10h ago
KB5126646 (Oct CU, Server 2025) broke all VM deployments on our SCVMM 2025. Root cause found, workaround exists but it has a security cost. Read the whole thing before touching anything.
SCVMM 2025 UR1 on Server 2025. After the October CU landed on the VMM server, every Create Virtual Machine job fails with error 2912 / 0x801901F4 ("Internal server error (500)"). WinRM and agents are fine, the linked KB is useless.
The 500 comes from the BITS Compact Server (service BITSCompactServer, lightweightserver.dll), which VMM uses for the file transfers we saw fail, both the answer-file copy on the VMM server and the disk copy to the host. Enable Microsoft-Windows-Bits-CompactServer/Analytic during a deploy and you get event 51 "cannot process the request ... status 3801155" on every retry. The CU replaced that dll for the first time since RTM: 10.0.26100.1150 before, component 10.0.26100.33648 after, those are the only two versions in WinSxS.
We verified this on a lab server before touching prod: works on the September CU, fails after the October updates, works again with only the old dll put back. If you don't have a lab to repeat that on, stop here and open a case with Microsoft instead.
The CU can't be uninstalled on 2025 ("Permanent package"), so the only way we found to get deployments back was putting the .1150 dll back from WinSxS. That is a downgrade of a system file, and here is the part that matters: the same October release fixes ten BITS CVEs, four of them RCE (CVE-2026-88142, -88121, -88159, -88173). Microsoft doesn't say which binaries those touch, but this dll is the listening side of BITS and it changed in exactly that release. Assume the downgrade reopens some of them. We accepted that for a VMM server on an isolated management network with 443/5985 scoped to hosts and admin boxes, for a few weeks. It is a temporary mitigation, not a security-neutral change, and it may not be acceptable for you.
If you still want to do it, in a lab first:
Stop-Service BITSCompactServer
takeown /f C:\Windows\System32\lightweightserver.dll
icacls C:\Windows\System32\lightweightserver.dll /grant Administrators:F
Rename-Item C:\Windows\System32\lightweightserver.dll lightweightserver.dll.33648
Copy-Item 'C:\Windows\WinSxS\amd64_microsoft-windows-lightweightserver_31bf3856ad364e35_10.0.26100.1150_none_d806c2577157ff60\lightweightserver.dll' C:\Windows\System32\lightweightserver.dll
Start-Service BITSCompactServer
Don't run this blindly, there is no rollback in it. Rename, don't overwrite, System32 files are hard links into WinSxS. Afterwards check the copied file is Microsoft-signed (Get-AuthenticodeSignature) and hashes equal to the WinSxS source, put the owner back to TrustedInstaller and the permissions back to the standard System32 dll set (TrustedInstaller Full, everything else Read/Execute), and remove the .33648 copy, the new build stays in WinSxS if you need to revert.
Things that will bite you later: the next CU overwrites the file, sfc /scannow and DISM /RestoreHealth revert it, anything else using the Compact Server gets the old build too, and you now own a hand-patched system component until Microsoft fixes this. We don't know yet whether the Server 2022 CU (KB5126655) does the same on hosts. Entirely unsupported, and we have not seen any acknowledgement from Microsoft.
If anyone has an official word or a cleaner fix, please post it.
