4

When I run gpupdate on my workstations I get the following error.

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Running gpresult /h gives The user does not have RSoP data

Looking in the event log, I can see associated with the gpupdate an error code 49 Invalid Credentials. However, when I test ldap bind using ldp.exe the credentials work fine.

Has anyone seen an issue like this? I'm pulling my hair out trying to figure out what is going on.

  • Look in the details tab for error code and description. Also, what would your user credentials have to do with the computer policy not applying? – Greg Askew Oct 28 '16 at 18:37
  • ...Error code 49... In order for group policy to apply the machine has to bind to ldap on a domain controller. Error code 49 is invalid credential, I'm not sure I understand your question? – TheGentleman Oct 28 '16 at 18:39
  • 2
    It's failing too bind using the computer credentials, not your user credentials. – Greg Askew Oct 28 '16 at 19:41
6

I was able to fix this myself. It turns out that the local machine accounts had cached bad credentials that were (correctly) failing. Thanks to @greg-askew for pointing me in the right direction. For anyone who stumbles on this looking for a solution:

  1. Download PsExec (part of sysinternals) from https://technet.microsoft.com/en-us/sysinternals/pxexec.aspx
  2. From an elevated command prompt run PsExec.exe -i -s cmd.exe (This will open another command window in the Local Machine account context).
  3. From that window, run rundll32.exe keymgr.dll, KRShowKeyMgr (That will open a gui with a list of cached credentials).
  4. In that gui, delete any credentials that look suspicious (In my case the credentials were named after my PDC).

After deleting the credentials from the cache, it immediately started working again.

| improve this answer | |
  • Excellent find, I would not have thought of that. I would probably have removed/rejoined it to the domain. Also good self initiative, quite rare on ServerFault these days. – Greg Askew Oct 29 '16 at 22:33
  • It made my day!!! – Alex G Nov 27 '17 at 19:35
  • correct url: docs.microsoft.com/en-us/sysinternals/downloads/psexec – LPChip Mar 21 '19 at 10:16
  • Just had this exact issue and this fix has worked! TVM! :) – Rawns May 15 '19 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.