Group Policy Event ID 1053 / 1055: “Windows could not resolve the user name” (name resolution failure)

A domain-joined PC is not picking up its policies. Drive maps are missing, a security setting never arrived, or software is not deploying. You run gpupdate /force and it complains. In Event Viewer, under Windows Logs, System, there is a Group Policy error like this:

Event ID 1053 (source GroupPolicy)
The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one or more of the following:
1. Name Resolution failure on the current domain controller.
2. Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

The details tab carries a domain controller name and an error code. The code is the clue that tells you which of several different problems you have.

Applies to: Windows 10, Windows 11 and Windows Server machines that are members of an Active Directory domain. Commands run in an elevated Command Prompt or PowerShell window (right-click, Run as administrator). The DC-side steps need a domain administrator on a domain controller.

What is going on

Before Windows can apply Group Policy it has to find a domain controller (DC) and then talk to it over LDAP (the directory query protocol). Finding one is done through DNS. The PC asks DNS for a special kind of record called an SRV record, in the form _ldap._tcp.<domain>, which lists the domain controllers. If the PC cannot do that lookup, it cannot find AD, and Group Policy processing stops.

There are several Group Policy events that look alike, so it is worth reading the right one. This is what Microsoft documents for them:

• 1053: “Windows could not resolve the user name.” It is logged when the user side of policy processing cannot resolve the account against the domain controller. Microsoft lists two causes: name resolution failure on the current DC, or Active Directory replication latency (an account created on another DC has not replicated to this one).
• 1055: the computer-side event of the same kind. It often appears at startup. Microsoft documents it appearing straight after NETLOGON Event ID 5719 (the PC could not reach any domain controller) on machines that start before the network is ready, and followed by a success event once the network comes up.
• 1030: Windows could not retrieve the list of Group Policy objects. It points to name resolution or network connectivity to a DC, and Microsoft suggests checking that the LDAP ports are open.
• 1058: Windows could not read a file (gpt.ini) from the domain controller’s SYSVOL share. That is a share or replication problem, not a lookup problem.
• 1006: the LDAP bind failed (could not authenticate to the DC). Error code 258 (timeout) in this event suggests the DNS configuration is wrong.
• 1129: no network connectivity to a DC, for example LDAP port 389 blocked.
• 1097: Windows could not determine the computer account. Microsoft says to check the clock. A difference of more than five minutes can stop the computer from authenticating. See Kerberos clock skew.
• NETLOGON 5719: the PC could not reach any domain controller when it started.

The common thread for 1053, 1055 and 1030 is name resolution. A PC whose DNS points somewhere that knows nothing about your domain (a home router, an ISP, a public resolver) will fail exactly like this. That is why it often shows up after VPN use or when a laptop comes back to the office.

Diagnosis

1. Read the error code on the event

Open the event, go to the Details tab and note the domain controller name and the decimal error code. For Event 1053 Microsoft maps the codes like this:

• 1355: the specified domain either does not exist or could not be contacted. A DNS fault or bad DNS configuration. Use nslookup to confirm you can resolve the domain controllers.
• 525: the specified user does not exist. Can mean wrong permissions on the organizational unit (OU). Users and computers need read access to the OU that holds their objects.
• 5: access denied. May mean a password changed while the user was signed in, or replication delay after a password change.
• 1727: the remote procedure call failed. A firewall in the way (Windows Firewall or a third-party one).
• 14: not enough storage available. Look for other memory problems in the System log.

To pull the recent events from PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; Id=1030,1053,1055,1058} -MaxEvents 10 |
  Format-List TimeCreated, Id, Message

2. Check which DNS servers the PC is using

ipconfig /all

Find the adapter that is actually in use and read its DNS Servers lines. On a domain member these must be DNS servers that can resolve the SRV records and host names for your AD forest, usually your domain controllers or DNS servers that forward to them. Microsoft calls out the most common mistake directly: client computers using DNS servers that belong to the internet service provider. A home router address (such as 192.168.1.1) counts too. The same applies to the secondary server: a public resolver in the second slot is used by Windows whenever the first one is slow, and it cannot answer for your domain.

3. Prove that the PC can (or cannot) find a domain controller

nltest /dsgetdc:<domain name> /force
nslookup <domain name>
nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain name>

• nltest /dsgetdc runs the same discovery Windows does, asks DNS for the DCs and contacts them. /force skips the cache and goes to DNS. Success prints a DC name, address and site. Failure with error 1355 matches the Event 1053 code above.
• nslookup <domain name> should return the addresses of domain controllers. If it does not, or returns an address that is not a DC, the domain’s own (same as parent) A records are the thing to check on the DNS server.
• nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain name> should list one or more records with port = 389 and a DC host name. Microsoft documents this lookup as the way to verify that a DC has registered its locator records. An empty answer means either the PC is asking the wrong DNS server, or the DNS server has no records.

Now ask the DNS server you should be using directly, by adding its address to the end of the command. This separates a client problem from a server problem:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain name> <IP address of a DC or AD DNS server>

If this works but the earlier query did not, the PC is pointed at the wrong DNS server (client fault). If it fails here too, the DNS server does not hold the records (server fault, see the fix below).

4. Does it only fail at startup or when the VPN connects?

If the sequence in the System log is NETLOGON 5719, then GroupPolicy 1055, then a success event a little later, the problem is timing. Windows tried to process policy before the network was usable, found no DC, and succeeded on the next background refresh. Microsoft documents this pattern for client startup. On VPN, remember that policy cannot apply until the tunnel is up and the VPN hands out the corporate DNS servers (check with ipconfig /all while connected).

Root cause

The client could not resolve a name needed to locate or use a domain controller. Most often its DNS settings point at a server that does not host the Active Directory zones. Less often, the DNS server has no SRV records for the DCs because they failed to register, or the network is not ready when policy runs at startup. For Event 1053 specifically, a newly created account that has not replicated yet is the other documented cause.

The fix

Do not delete or recreate GPOs. A broken lookup does not damage the policy objects. Making changes on a domain controller (restarting Netlogon, editing DNS) affects every client that uses it, so do it deliberately and one DC at a time.

Step 1: point the PC at the right DNS servers

Use your network’s correct AD DNS servers. For many PCs, fix it where they get it: the DHCP scope’s DNS option, or the VPN connection profile. For a single PC with a static address, open the adapter’s IPv4 properties and set the preferred and alternate DNS servers to your internal DNS servers, with no public or ISP resolver in either slot. You can also view current values from PowerShell:

Get-DnsClientServerAddress -AddressFamily IPv4

Step 2: refresh the DNS cache and registration, then retry

ipconfig /flushdns
ipconfig /registerdns
gpupdate /force

Microsoft’s own Group Policy guidance for this kind of failure tells you to flush and re-register DNS. /flushdns clears cached answers, including cached failures. /registerdns re-registers the PC’s own address with DNS. Neither changes which server is asked, so Step 1 comes first.

Step 3: if the DNS server itself has no SRV records

Domain controllers register their locator records through the Netlogon service. On the DC that should own the missing records, run this from an elevated prompt as a domain administrator:

net stop netlogon && net start netlogon
ipconfig /flushdns
ipconfig /registerdns
dcdiag /test:dns /v

This is the procedure Microsoft documents for registering DNS records manually. Wait a few minutes, repeat the SRV lookup from step 3 of the diagnosis, and read the dcdiag output for DNS warnings. A DC with dynamic updates disabled on its zone, or one that points to the wrong DNS server itself, will keep failing until that is corrected.

Step 4: if it is only a startup timing issue

For PCs that hit 5719 then 1055 at boot and recover by themselves, Microsoft documents a delay setting: the Startup policy processing wait time policy (Computer Configuration, Policies, Administrative Templates, System, Group Policy), which sets the registry value GpNetworkStartTimeoutPolicyValue. The Microsoft example uses 60 seconds. Windows checks the connection every two seconds and moves on as soon as it is up, but if the PC is truly offline it waits the whole time, so do not set it higher than you need. It is a workaround for slow networks at boot. It does not fix a wrong DNS server.

If the code was something else

• Event 1053 right after creating an account or resetting a password: wait for Active Directory replication, or check replication health between domain controllers.
• Code 1727 or an Event 1129: test ports to the DC (LDAP 389, plus Kerberos 88, SMB 445 and the RPC ports) and check any firewall between the PC and the DC.
• Event 1058: check you can open \\<DC name>\SYSVOL\<domain>\Policies\{GUID}\gpt.ini as the affected computer. The event gives the exact path.

Verification

nltest /dsgetdc:<domain name> /force
gpupdate /force
gpresult /r

nltest should now return a DC. gpupdate /force should finish with “Computer Policy update has completed successfully” and “User Policy update has completed successfully”. gpresult /r lists the policy objects that applied. For a fuller report use gpresult /h %Temp%\gp.html and open it in a browser. In Event Viewer, Applications and Services Logs, Microsoft, Windows, GroupPolicy, Operational shows each processing run. Group Policy logs a success event once it manages to process. Give a startup problem one reboot and check there is no new 5719 and 1055 pair.

Notes

• Event IDs 1053 and 1055 are the “could not resolve” pair for user and computer. Do not assume 1053 is about the computer. If you only see 1053, the problem is in the user’s processing.
• DNS, time and the secure channel share causes. If the PC finds a DC but sign-in still fails, check the clock (Kerberos clock skew) and the computer account password (trust relationship failed) next.
• Microsoft says domain-joined computers must have proper name resolution and network connectivity to a DC to discover new Group Policy objects. That is true for every domain member, including servers and VMs.
• Pages this article was checked against on Microsoft Learn: “Applying Group Policy troubleshooting guidance”, “Windows 7 Clients intermittently fail to apply group policy at startup” (applies to all supported Windows client versions), “How to verify that SRV DNS records have been created for a domain controller”, “Troubleshoot domain controller location issues in Windows” and the Nltest reference.

Still failing? Post the event ID, the error code from the Details tab, and the output of ipconfig /all and nltest /dsgetdc:<domain> /force (blank out anything private) in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.