6

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.

TheGentleman
  • 291
  • 1
  • 2
  • 8
  • `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
  • `Look in the details tab for error code and description.` Excuse me for pointing out the terribly unobvious but...LOOK IN THE DETAILS TAB OF WHAT?!? WHERE IS THE DETAILS TAB?!? IN WHAT APPLICATION?!? ON WHAT MACHINE?!? They're going to have to be a lot more specific here and stop treating us all like *we're* the idiots for not knowing... – Justa Guy Dec 17 '22 at 11:36
  • @JustaGuy - not sure why you're commenting on a 6 year old question, but as the original asker I'd point out that you are referencing a comment not an answer. Comments don't need to meet the same standards for clarity as an answer; and regardless, the application referenced in the question is explicitly the event log which is the application that is being referenced and I would argue would be clear to the average person who would have seen this error message (again, in the windows event log) – TheGentleman Dec 19 '22 at 16:48

2 Answers2

12

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.

PeterFnet
  • 107
  • 5
TheGentleman
  • 291
  • 1
  • 2
  • 8
  • 1
    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: https://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
  • 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 '21 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. – Evan Anderson Jan 21 '22 at 03:52
0

Even in 2022 this error can still occur. To fix it, I removed the PC from the domain, and then rejoined it to the domain, and the problem was fixed. It seemed easier to me than downloading PsExec and following all the required steps. Just thought having an alternative answer may be a benefit to some folks. I do see Greg Askew suggested this same fix in his comment on the other answer.

Joe Gayetty
  • 133
  • 5