If the "stale" policy cache is already there, it is unchanged by any kind of gpupdate or attempts to use MMC for requesting certificates of any kind. If the policy cache is not present (because I deleted it), it is not recreated either.

However, if I copy the policy cache file from a computer with identical certificate-related permissions and paste it into the cache location, MMC works on the formerly problematic computer. What I don't know is whether that copied-in cache will still go "stale" or start being properly updated at normal intervals.

Other items related to this issue:
- the server having this problem is the Registration Authority server, running the following services: NDES, CEP, CES.
- The NDES and CES services run under a domain user account which is properly delegated. CEP runs under the ApplicationPoolIdentity
- The policy cache file still doesn't exist at C:\ProgramData\Microsoft\Windows\X509Enrollment\
- running "certutil -credstore *" yields "ACCESS_DENIED"
- running "certutil -Policy" results in "ERROR_FILE_NOT_FOUND C:\ProgramData\Microsoft\Windows\X509Enrollment\12065efb6f422680fb327405097fa95818d
- IIS log has the following typical entry for the problematic server: "2021-12-01 18:00:11 172.16.xx.xx POST /ADPolicyProvider_CEP_Kerberos/service.svc/CEP - 443 - 172.16.xx.xx MS-WebServices/1.0 - 401 2 5 0 Keep-Alive - - - " where the IP address is the registration authority server trying to connect to itself and the CEP service
- The workstations that are having the same policy cache problem have an IIS log identical (except for IP address)
- A server that connects to CEP successfully and maintains a current policy cache shows IIS logs such as: "2021-11-22 15:16:10 172.16.xx.xx POST /ADPolicyProvider_CEP_Kerberos/service.svc/CEP - 443 MAHTS\AUTH-0$ 172.16.yy.yy MS-WebServices/1.0 - 200 0 0 359 Keep-Alive - " where the 172.16.xx.xx is the IP address of the Registration Authority hosting CES/CEP and 172.16.yy.yy is the IP of the server that successfully connected.

• copying a policy cache file from a working computer into the problematic computer will "fix" it. MMC cert snap in works, and certutil queries show good results. However, the policy cache file will be deleted the next day and enrollment policy is broken again.
  

• The servers are running Windows Server 2012; the workstations Windows 10 1607.

I've checked the GPO and here's the stats:

• The Policy is applied at the domain level
  

• rsop and gpresult on the problematic server show the policy being applied
  

• deleting the enrollment policy registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\PolicyServers\ then running "gpupdate /force" results in the registry key being re-created

  
  
  
  

That's the one thing I haven't checked, since I haven't noticed any GPO application problems before. I will try that next. Thanks!