Overview
We had this issue on some virtual servers migrated from a "cloud" provider back to our internal data center. The root cause was permissions to the %SystemRoot%\System32\catroot2
folder. There were a number of differences between the permissions on that folder on a healthy server vs those on the migrated server. I believe the key one was that TrustedInstaller
didn't have full access
.
Additional Symptoms
Looking at the Application log in the event viewer, we saw a number of errors:
Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.
Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).
The clue is in the ESENT error's text; i.e. permissions issue accessing a file under the catroot2 folder.
Resolution
Give the Trusted Installer account full control to the catroot2 folder and its children.
In case that's not enough, for comparison, running icacls %systemroot%\system32\catroot2
on a healthy server gives this:
C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
NB: To add Trusted Installer, you'll need to search on the local computer accounts for nt service\trustedinstaller
.
After replacing permissions on catroot2
, ensure you click the replace permissions on child objects & containers
checkbox to ensure that child items have their permissions resolved also.
No reboot is required for the fix itself (though obviously, once updates start working again, you'll likely need to reboot for those).