I ran the following command on a Server 2012 R2 running WSUS:
DISM.exe /Online /Cleanup-image /Restorehealth
It failed with error 0x800F0906
Various posts online tell you that the solution for that error is to rename C:\Windows\SoftwareDistribution\Download and C:\Windows\System32\catroot2 then reboot. When I did that, I broke my WSUS installation and started getting errors like these:
Log Name: Application
Source: MSSQL$MICROSOFT##WID
Event ID: 18456
Task Category: Logon
Level: Information
Keywords: Classic,Audit Failure
User: NETWORK SERVICE
Description:
Login failed for user ‘NT AUTHORITY\NETWORK SERVICE’. Reason: Failed to open the explicitly specified database ‘SUSDB’. [CLIENT: <named pipe>]
Some research took me back to KB3159706. My Installed Updates doesn’t list that update, but my hunch is that it is included in a later cumulative update. So I applied (or re-applied) the “postinstall” task described in KB3159706, which I blogged about here. That got WSUS working again.
Fortunately, I stumbled across this article on repairing a .NET Framework 3.5 installation error. For 0x800F0906, it advises setting group policy to tell WSUS that it’s okay to download repair sources directly from Windows Update, which makes sense:
So I updated my WSUS group policy to enable Computer Configuration > Policies > Administrative Templates > System > Specify settings for optional component installation and component repair:
After that, DISM was able to complete successfully.
THANK YOU!!
thank you i didn’t know this group policy parameter !
Nope, doesn’t work. I’ve had this GP enabled or years and every single time I try to run RestoreHealth I get a not found error and I’m told to point to the source. Then of course pointing to a WIM file does no good what so ever because the files it needs are most likely from updates that are far beyond the WIM file and no such updated ISO source exists. I’ve been able to remove said machine from the domain and then repair it. That would of course only work for a very narrow field of servers. For example, I’m guessing removing an Exchange server from the domain would be bad. Very bad. But a print server? Sure. And it works. Rejoin and all is well. So WSUS is 100% the problem here. Right now I’m stuck because it’s my AD server that’s got an issue and can’t repair itself. I might have to temporarily remove WSUS from GP.
@Justin, you sound pretty familiar with Group Policy, so I assume you’ve confirmed that this GP is applied to the server in question?
I wonder if, rather than messing with Group Policy overrides/exceptions, you could just go into that server’s registry and temporarily remove the GP policy link that points to your WSUS server, quick do the DISM, then let the registry revert on the next gpupdate. I don’t have any WSUS left to check, but it looks like that would be
HKLM:Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer
See https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsUpdate::CorpWuURL