I'm troubleshooting a Windows 11 domain environment where gpupdate succeeds normally, but gpupdate /force fails for both computer and user policy whenever the client is connected over Wi‑Fi. The same devices succeed immediately when connected to Ethernet, and this affects wireless clients from multiple manufacturers and images.
The environment has one AD domain with two current functional-level domain controllers. Wi‑Fi clients are bridged onto 10.0.80.0/24, wired clients use 10.0.90.0/24, and the DCs are on 10.0.140.0/24, with a FortiGate handling inter-VLAN routing. Wireless access points use a bridged WLAN with client isolation and filtering disabled.
The error is "Windows could not resolve the computer name" and "Windows could not resolve the user name." Group Policy logs show error 0x5 and MyGetUserName failing with access denied after only about 15–31 ms. During a failed wireless run, the client contacts the endpoint mapper on TCP 135 and receives successful responses for the DRSUAPI UUID every time, but never opens a connection to the returned dynamic RPC port. There is also no Kerberos, LDAP, SMB, or dynamic RPC traffic at all. A wired run completes the expected sequence through RPC, LDAP, SMB, and Kerberos.
The client can resolve and query the domain, enumerate SYSVOL, read GPT.INI, resolve SIDs, locate a DC with nltest, establish the secure channel, and connect to ports 88, 135, 389, and 445. Time synchronization, MTU, host firewalls, FortiGate policies, dynamic RPC rules, client isolation, wireless filtering, and machine diversity have all been checked. Both interfaces report DomainAuthenticated and otherwise appear equivalent.
What could cause Windows to receive a valid DRSUAPI endpoint from the endpoint mapper and then abandon the connection locally with error 0x5, specifically on Wi‑Fi? Could an incomplete AD Sites and Services subnet definition, reverse-DNS or Kerberos issue, or interface-specific name-resolution behavior explain the absence of any Kerberos attempt even though the relevant ports are reachable?
3 Answers
A stale or incorrect PTR record could contribute to Kerberos or identity lookups, especially if the wireless address range was added differently from the wired ranges. I’d compare forward and reverse DNS results, DC discovery, and the selected network interface side by side during successful and failed runs.
Since the endpoint mapper succeeds but the dynamic RPC connection never starts, this looks more like a local Windows decision than a firewall drop. Compare the interface metrics, binding order, DNS suffixes, routes, and any wireless-specific security or policy settings. Also check whether a policy or WLAN configuration is replacing connection settings instead of merely updating them.
The first things I’d recheck are DNS behavior and AD Sites and Services. Make sure the wireless subnet is explicitly mapped to the correct site and that Wi‑Fi clients use only the internal AD DNS servers, including correct forward and reverse records. A client can pass basic connectivity tests while still getting different DC or site-selection behavior during Group Policy processing.
The clients do resolve the internal DCs and nltest returns a valid DC with the expected site flags, but I’ll verify the subnet objects and reverse lookups specifically for the wireless range.