7

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.

Improve this question
5
  • 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?
    – TheGentleman
    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
  • 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, 2022 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, 2022 at 16:48

2 Answers 2

Reset to default
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). If you have only one record with your PDC, changing the credentials is enough to solve the issue.

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

Improve this answer
6
  • 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, 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.
    – Evan Anderson
    Jan 21, 2022 at 3: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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .