5

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.

3
  • 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, 2016 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? Oct 28, 2016 at 18:39
  • 2
    It's failing too bind using the computer credentials, not your user credentials.
    – Greg Askew
    Oct 28, 2016 at 19:41

1 Answer 1

10

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://docs.microsoft.com/en-us/sysinternals/downloads/psexec
  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.

6
  • 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, 2016 at 22:33
  • It made my day!!!
    – Alex G
    Nov 27, 2017 at 19:35
  • correct url: docs.microsoft.com/en-us/sysinternals/downloads/psexec
    – LPChip
    Mar 21, 2019 at 10:16
  • 1
    For me it was in the hosts file. I had many server entries including the domain controller like: IP single_label_server_name fully_qualified_domain_name. I removed the single label portion from that line and that fixed it. Go figure.
    – Roman
    Sep 17, 2021 at 18:08
  • 1
    Bravo. It's rare that I see an error in Windows that I haven't seen before. Today was one of those days. I didn't expect this to actually work, but my frustration level was high and I decided I'd give it a shot anyway. To my astonishment it actually worked. I'd love to know what I did to work the machine into this state (so I don't do it again), but I'm happy it's working. Jan 21 at 3:52

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