当我在工作站上运行 gpupdate 时出现以下错误。
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.
跑步gpresult /h
给予The user does not have RSoP data
查看事件日志,我可以看到与 gpupdate 相关的错误代码为 49 无效凭据。但是,当我使用 ldp.exe 测试 ldap bind 时,凭据工作正常。
有人见过这样的问题吗?我正绞尽脑汁想弄清楚发生了什么事。
答案1
我自己修复了这个问题。结果发现本地机器帐户缓存了错误的凭据,这些凭据(正确地)失败了。感谢@greg-askew 为我指明了正确的方向。对于任何偶然发现这个问题并寻求解决方案的人:
- 从以下位置下载 PsExec(sysinternals 的一部分)https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
- 从提升的命令提示符运行
PsExec.exe -i -s cmd.exe
(这将在本地计算机帐户上下文中打开另一个命令窗口)。 - 从该窗口运行
rundll32.exe keymgr.dll, KRShowKeyMgr
(这将打开一个带有缓存凭据列表的 GUI)。 - 在该 GUI 中,删除所有可疑的凭据(在我的情况下,凭据以我的 PDC 命名)。如果您的 PDC 只有一个记录,则更改凭据足以解决问题。
从缓存中删除凭据后,它立即开始再次工作。
答案2
即使在 2022 年,此错误仍可能发生。为了修复它,我从域中移除了 PC,然后将其重新加入域,问题就解决了。对我来说,这似乎比下载 PsExec 并按照所有必需的步骤更容易。只是觉得有另一种答案可能会对某些人有益。我确实看到 Greg Askew 在另一个答案的评论中提出了同样的修复建议。