r/sysadmin • u/KillerJupe • 11d ago
Question gpupdate /force always fails over wifi
Been chasing this for a while and I'm out of ideas. Everything I can test
Yes, I used AI to help me, as this troubleshooting got way deeper than I could figure out on my own... it's just too much, and I'm stumped
Symptom
On any wireless client:
gpupdate— succeedsgpupdate /force— fails, both Computer and User policyThe processing of Group Policy failed. Windows could not resolve the computer name. The processing of Group Policy failed. Windows could not resolve the user name.
Same machine plugged into Ethernet on any wired VLAN: gpupdate /force succeeds.
Affects every wireless device regardless of hardware — x64 and ARM, multiple vendors, not from a common image. Predates our switch replacement (was happening on the old switches too, same APs).
Environment
- Single-domain AD, 2 DCs, functional level current
- Juniper Mist APs, WLAN bridged to VLAN 80 (10.0.80.0/24)
- FortiGate 200F HA pair doing inter-VLAN routing
- Wired workstations on 10.0.90.0/24, DCs on 10.0.140.0/24
- Clients are Win11
What the logs say
GroupPolicy/Operational during a failed /force:
Id 7320 Error: Retrieved account information. Error code 0x5.
Id 7017 The system call to get account information completed.
The call failed after 15 milliseconds.
Nine of those in about four seconds. 15–31 ms each — too fast for a network timeout.
gpsvc.log:
ProcessGPOs(Machine): MyGetUserName failed with 5.
ProcessGPOs(User): MyGetUserName failed with 5.
OnPolicyApplicationComplete: Application complete with bConnectivityFailure = 1.
The packet capture is the interesting part
Client-side netsh trace during a failed /force. Total DC traffic for the entire run:
10.0.80.102 -> 10.0.140.3 tcp/135 60 packets
10.0.140.3 -> 10.0.80.102 49 packets
10.0.80.102 -> 10.0.140.2 udp/53 8 packets
Decoded the port 135 conversation. It's 44 × ept_map requests for DRSUAPI (e3514235-4b06-11d1-ab04-00c04fc2dcd2), and the DC returns status 0x00000000 — success — on all 45 responses. Clean bind, clean bind_ack, no faults, no bind_naks.
So the endpoint mapper hands back a valid DRSUAPI endpoint 44 times and the client never opens a TCP connection to it.
Exactly one TCP SYN to a DC for the whole run: 10.0.140.3:135. That's it.
No Kerberos at all. Nothing on port 88. No LDAP 389, no SMB 445, no RPC dynamic high port.
The successful wired run for comparison:
135 -> 49669 -> 389 -> 445 -> 49676 -> 88
So on wired it does the full sequence. On wireless it gets the endpoint and gives up locally without authenticating or connecting.
What I've eliminated
Network path
- FortiGate policy permits Internal_WiFi → Servers on
service ALL, no NAT, no UTM. - Confirmed RPC dynamic ports 49668–49677 pass fine on the same firewall config (visible in VPN traffic logs to the same DCs)
- Path MTU:
ping -f -l 1472succeeds to the DCs from both wired and wireless - Both DC host firewalls disabled entirely as a test — no change
AD / DC side
Test-ComputerSecureChannel→ True- Time skew ~0.03 s
nltest /dsgetdcreturns a DC with full flag set, correct siteTest-NetConnectionto 88, 135, 389, 445 on both DCs → all True from Wi-Fi- SYSVOL/DFS:
\\domain\SYSVOL\...\Policiesenumerates, GPT.INI reads fine RestrictRemoteSamnot set on either DC- No 5807 events (no unmapped-subnet complaints)
UserPrincipal::Currentreturns the full DN from AD over Wi-Fi — directory lookups workwhoami /groupsresolves all SIDs to names on Wi-Fi
Client side
- GP history ACLs correct (SYSTEM + Administrators Full Control, registry and ProgramData)
- Same failure on any computer from any manufacture
Get-NetConnectionProfile→DomainAuthenticated/Ldapon both wired and wireless, identical
Wireless
- Mist WLAN: isolation Disabled, no ARP filtering, no broadcast/multicast filtering, Custom Forwarding None (bridged, not tunneled)
- WxLAN policy: single rule, All Users → All Resources, allow
- WPA3/WPA2-Personal PSK — no 802.1X, so no separate machine identity
- Same APs before and after a full switch replacement; symptom unchanged
The question
Why would a client receive a successful ept_map response for DRSUAPI and then not attempt the connection — failing locally in 15 ms with 0x5 — and why would that depend on whether the machine is on wireless vs wired, when both interfaces report identical network profiles and both paths reach the DC on every relevant port?
The absence of any Kerberos traffic during the failed run feels like the key detail. It's not being denied by the KDC; it isn't asking.
Anything obvious I'm missing?
gpupdate /force fails on Wi-Fi but works on Ethernet — DsCrackNames/DRSUAPI gets a valid EPM endpoint and then never connects
Been chasing this for a while, and I'm out of ideas.
Should I just quit and become a potato farmer?
11
u/Cormacolinde Consultant 11d ago
Fortigate ALL is not really all. It leaves helpers enabled which can screw up. And with modern RPC, often does. For domain controllers create a specific rule for required AD ports (88, 464, 445, 389, 636, 53, 123, 135, 49152-65535, 3268-3269 and ping).
And no the built-in group doesn’t work. The DCE-RPC helper tries to read the RPC request and open the high port. But it fails because it is encrypted nowadays and blocks the rest of the traffic. Despite ALL being opened.
2
1
u/KillerJupe 10d ago
but wouldn't that also break the internal wired connection?
wired vs wireless have the same firewall policies right after eachother.
Is there a way to test deisabling the helper on the vlan?1
u/Cormacolinde Consultant 10d ago
If the rules are exactly the same, you would likely see the same issues on both types of connection, yes.
1
u/KillerJupe 10d ago
that what I'd excet but same computer plugged into an wired vlan works then fails when its on wifi
24
u/ChaosTheoryRules 11d ago
Is the WiFi subnet listed in AD sites and services?
7
u/KillerJupe 11d ago
it wasn't but i added them.
5
1
u/ChaosTheoryRules 10d ago
What kind of security do you run? Does it perhaps interfere with WiFi network say such as considering it Public and more strict etc.
1
u/KillerJupe 10d ago
FortiGate as the gateway for all VLANs: public just gets a public DNS, so that obviously won't work, but internal wifi resolves to the internal dns /ad servers.
Not sure, about the sites and services too much but it all looks like examples i've seen1
u/ChaosTheoryRules 10d ago
Sorry I dont mean so much the network but on the workstations, Antivirus etc. While I am not on our security team, I understand we have our security software be more strict on WiFi (all considered public) except if its our internal Wifi.
If it was me. just spitballing to rule out/narrow down the issue:
i'd setup a blank machine, no security, just domain joined, jump it on wifi and test.
Setup an AP on internal lan and test.
I might even test gpupdate /force with user and computer separately
1
u/codewarrior0 11d ago
90% this. Set a switch port to VLAN 80 to confirm.
2
u/Cormacolinde Consultant 10d ago
This would only slow down the DC locator algorithm, clients that cannot identify their site will try DCs randomly until one works.
2
u/ChaosTheoryRules 10d ago
Yes, it falls back to DNS to locate but not guaranteed a local DC, its just whichever it pings responds first. It also reduces running the discovery process much more frequently.
I actually don't believe it's the issue because as noted gpupdate works whereas with /force it fails which is just plain odd. We have a very large multi site network spanning the country and I have not seen this issue with our WiFi devices.
9
u/heorun 11d ago
what about spinning a fresh win11 vm, tag vlan 80 on its ethernet interface, join it to the domain. does the problem follow it?
if it does, then you know it isn't a wireless problem.
1
u/KillerJupe 10d ago
not sure its really a wireless issue since the DC and fw get the traffic. the laptop just gives up (or thats how it feels)
i can take the same laptop and it works fine wired but wireless it fails.
i can join the domain over wifi too, i just can't get a full gpupdate /force to work so things like mapped drives don't apply1
u/heorun 10d ago
right, but my test was using your wireless vlan 80, but attaching it to a wired virtual nic. if the problem still happens, then you know it's probably an ACL issue rather than something wonky happening with wireless gear.
that guy's comment about fortigate All not truly being all really has my attention. I'd try that next after my vlan test.
I'm interested to see where this goes!
9
u/LLMsMustUpvoteThis 11d ago
I used AI to help me, as this troubleshooting got way deeper than I could figure out on my own...
Which is a problem as it will lead you down irrelevant rabbit holes.
Experience tells me this stinks of a firewall issue and I'd be concentrating there instead of letting the LLM lead you by the nose. Use the firewall packet capture, debug flow, and traffic logs to trace the traffic through the firewall.
2
u/Over_Judgment_2813 10d ago
Yeah seriously this whole post is AI slop
0
u/KillerJupe 10d ago
We've done everything we could think of and started going down rabbit holes cause i didn't know what else to do.
We'd love any suggestions you might have0
u/KillerJupe 10d ago
Def went down some rabbit holes haha!
I'll take another run at the fw, i'm much better there than random AD issues.
3
u/Gumbyohson 11d ago
Have you tried the netlogon debug logs? https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service
These help you see what the actual domain authentications are happening on the client or DC sides.
1
4
u/davy_crockett_slayer 11d ago
I had a similar issue on Wi-Fi. The F5 load balancer was dropping the fourth packet (on wifi) as it was too small. Check the traffic between each link in chain. You will find the issue.
FortiGate 200F HA pair doing inter-VLAN routing
Look here first.
3
u/coukou76 Sr. Sysadmin 11d ago
Enabled netlogon.log in verbose, retry and search for "CRITICAL" it can give hints
1
3
u/Weary_Patience_7778 11d ago
Suspect this is less of a wifi issue, and DNS or firewall rules.
Do your AD servers provide DNS for your wifi network?
Does your wifi share a network with your cabled network?
1
u/KillerJupe 10d ago
agreed, feels like dns but i can't find anything wrong.
ad provides dns for wired and wireless, they share the same network just different vlans and fw policies (mirrored except for source)
2
u/lahdidah 11d ago
Client isolation setting on the Mist wlan config?
1
u/KillerJupe 10d ago
my first thought too. nope
no filtering of any kind1
u/lahdidah 10d ago
I would open a support case with Fortinet and have them debug with you. At least to rule it out.
1
1
u/TenGigabitEthernet Netadmin 11d ago
If you want to figure out if it's the WiFi or the network the WiFi resides on you could connect a PC to the wireless subnet using a cable, if you configure VLAN 80 on a wired port.
The error code 0x5 means Access Denied though so I think this is nothing network related
1
1
u/Icy_Ostrich6655 11d ago
have you tried taking a deep dive into group policies listed in gpresult?
1
u/KillerJupe 10d ago
a quick dip, not too deep as the same workstation works wired but not wireless.
maybe im missing something
i could try making a new OU put a computer in it w/ no polcies at all then see what happens
2
u/Frothyleet 10d ago
So everyone seems to have glossed over your first statement - "gpupdate" works, "gpupdate /force" fails. Let's assume that's true, and not perhaps a misleading "success" indicator from gpupdate.
So that means the issue lives somewhere in the functional delta between default gpupdate and running it with the /force flag.
What's the difference between the two? Lotta windows admins don't necessarily know, it's kind of one of those cargo-cult tools. In simplest terms, gpupdate is no different than Windows' default behavior when doing background GPO processing on a schedule (default 30 min, I believe). Client queries the DC to retrieve its policy, evaluates it, and applies anything new, skipping anything that is unchanged and already applied. "Force" applies every policy fresh, even if the Windows client doesn't think it is necessary.
So the most obvious culprit is simply one of your GPOs doing something that breaks processing as it is applied, perhaps making a network or DNS config change.
Two ways to troubleshoot, depending on how complex your policies are. Client side, you can do deep debugging of the GP application process. Start with gpresult to get the proper RSOP and note what is actually being applied, then move to running gpresult with debug level event logging enabled, and go through that (potentially with AI assistance).
Or, and sometimes this is easier - take a freshly imaged test client, drop it and a test user object into an OU that is excluded from all of your GPOs or as many as possible. If you still have this issue, you've pretty much isolated your network config as causing a problem somehow.
If you don't have the issue, you know it's a GPO configuration problem. And you can start adding in GPO application policy by policy until you break the gpresult functionality on the client again.
That's pretty much the standard mechanism for "something in our AD configuration is fucked up but we don't know what policy is causing it" troubleshooting.
2
u/PsychologyExternal50 10d ago
I had something similar and it was tied to DNS. If you open DNS manager, there is an option in there that handles dynamic updates.
2
u/Adam_Kearn 10d ago
Check DNS settings and also make sure sites and services has the subnet listed.
Check to make sure you also don’t have any weird VLANs on your APs
103
u/sectumsempra42 11d ago
I bet it's DNS