Why does gpupdate /force fail only over Wi‑Fi while RPC and DNS appear healthy?

0
0
Asked By MellowCedar42 On

I'm troubleshooting a Windows 11 issue where gpupdate succeeds but gpupdate /force fails for both computer and user policy on every wireless client. The same machines succeed immediately when connected to Ethernet.

The error is that Windows cannot resolve the computer or user name. GroupPolicy/Operational logs show error 0x5, while gpsvc.log reports MyGetUserName failed with error 5 and marks the run as a connectivity failure. The failures happen within roughly 15–31 ms.

The environment has one AD domain with two current-level domain controllers. Wireless clients are bridged through Juniper Mist APs onto 10.0.80.0/24. Wired clients use 10.0.90.0/24, and the domain controllers are on 10.0.140.0/24. A FortiGate HA pair handles routing. The issue affects different Windows 11 devices, architectures, vendors, and images, and existed before a switch replacement.

A packet capture is especially unusual. During a failed wireless run, the client contacts a DC over TCP 135 and performs repeated endpoint-mapper requests for the DRSUAPI interface. The DC returns successful responses, including clean binds, but the client never opens a connection to the returned dynamic RPC endpoint. There is no Kerberos traffic on port 88, LDAP on 389, SMB on 445, or dynamic RPC connection. A wired run performs the expected sequence through RPC, LDAP, SMB, and Kerberos.

DNS resolves the internal domain controllers, nltest /dsgetdc finds a valid DC and site, Test-ComputerSecureChannel is true, time is synchronized, SYSVOL is readable, directory lookups and SID-to-name resolution work, and the relevant ports test successfully from Wi‑Fi. The firewall allows all traffic between the wireless and server networks, dynamic RPC ports have been observed working, MTU tests pass, and disabling the DC firewalls made no difference. Wireless isolation and filtering features are disabled, the WLAN is bridged, and both wired and wireless interfaces report DomainAuthenticated with LDAP connectivity.

Why would Windows receive a successful DRSUAPI endpoint from the endpoint mapper and then fail locally with error 5 without attempting the dynamic RPC connection or Kerberos authentication? What could make this behavior depend on the network interface when both interfaces appear to have the same profile and can reach the domain controllers?

4 Answers

Answered By CopperLime88 On

The wireless network may be applying a different policy or connection configuration than Ethernet. Check computer and user GPOs that affect WLAN profiles, network location, RPC, credential delegation, security providers, or interface binding. A policy that replaces rather than updates the wireless profile could also create a timing or identity issue during forced policy refreshes, even if normal SYSVOL access continues to work.

Answered By SilverMaple61 On

Error 5 is access denied, so the important clue may be a local Windows security or interface-specific decision rather than a blocked firewall port. Compare the effective security policy, Winsock state, interface metrics, DNS registration, and network-provider bindings while connected by Wi‑Fi and Ethernet. Capturing ETW events around gpsvc, Netlogon, RPC, and Kerberos may show which local API returns access denied before Windows ever sends the next packet.

Answered By OrbitingFox19 On

Verify that 10.0.80.0/24 is mapped to the correct AD site in Active Directory Sites and Services. An unmapped or incorrectly mapped wireless subnet can cause DC-selection and policy-processing differences even when nltest finds a domain controller. The absence of 5807 events does not completely rule out a site or subnet configuration problem, so it is worth confirming the exact subnet objects and site links.

Answered By QuietPine7 On

DNS is still worth checking carefully, especially the wireless adapter’s DNS suffix, search list, forward lookups, and reverse/PTR records. Make sure the client is using the internal domain DNS servers and that the wireless subnet does not produce a different name-resolution result. A stale PTR or inconsistent hostname resolution could explain why authentication never gets as far as Kerberos, although the successful directory tests make this less obvious.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.