Wi-Fi issues are easily the most common — and most maddening — tickets in any IT helpdesk queue. If you've spent more than a week on a helpdesk, you know the drill: random disconnections, glacial speeds, 802.1X authentication failures that produce the world's least helpful error messages, and now WPA3 compatibility headaches on top of everything else.
I've put together this guide to give you a structured diagnostic workflow, from that first "my Wi-Fi isn't working" call all the way through advanced packet-level analysis. Every command here is tested on Windows 11 24H2/25H2 and Windows Server 2025, with notes for macOS Sequoia where it makes sense.
Initial Triage: The 5-Minute Diagnostic Checklist
Before you start digging through logs, run through this quick checklist to figure out which layer is actually broken. Most Wi-Fi tickets fall into one of four buckets: adapter/driver, authentication, infrastructure, or RF/signal.
Step 1: Confirm the Scope
- Single user or multiple? If several people on the same floor are reporting issues at once, look at the access point or upstream switch first — not the client.
- One SSID or all SSIDs? If the user can connect to the guest network but not the corporate SSID, the problem is almost certainly authentication or certificate-related.
- Wi-Fi only or all network? Have the user plug in an Ethernet cable for 10 minutes. If wired is also broken, don't waste time on wireless — the issue is upstream (DHCP, DNS, or the switch port).
Step 2: Pull the Quick Status
Open an elevated PowerShell or Command Prompt and run:
netsh wlan show interfaces
This one command shows the connected SSID, BSSID (which AP the client is talking to), radio type (802.11ax, 802.11be), channel, signal strength percentage, receive/transmit rate, and authentication type. Grab this output — it's your baseline for every single Wi-Fi ticket.
Step 3: Check the Driver
netsh wlan show drivers
Verify the driver version and date, then cross-reference with the latest from Intel, Realtek, MediaTek, or Qualcomm. You'd be surprised how often an outdated driver is the root cause of Wi-Fi disconnections — especially on Windows 11 24H2, where several driver-breaking updates shipped in late 2025.
Fixing Wi-Fi That Keeps Disconnecting on Windows 11
This is hands-down the most common Wi-Fi ticket in 2026. Windows 11 24H2 introduced driver compatibility changes that cause intermittent disconnections on Intel AX200/AX201/AX210/AX211 and MediaTek MT7921/MT7922 chipsets. Here's the fix sequence that actually works.
Disable Wi-Fi Power Management
Windows is really aggressive about power-managing the wireless adapter, especially on laptops. This is the number-one cause of random disconnections after sleep or during idle periods.
- Open Device Manager > Network adapters.
- Right-click your Wi-Fi adapter > Properties > Power Management tab.
- Uncheck "Allow the computer to turn off this device to save power."
- While you're there, go to the Advanced tab and set Power Save Mode (or Roaming Aggressiveness) to Maximum Performance.
To deploy this at scale via PowerShell:
# Disable Wi-Fi adapter power management on all wireless NICs
Get-NetAdapter -Name "Wi-Fi*" | ForEach-Object {
$adapterName = $_.Name
# Disable OS-level power management
powercfg /setdcvalueindex SCHEME_CURRENT SUB_NONE CONNECTIVITY_IN_STANDBY 1
powercfg /setacvalueindex SCHEME_CURRENT SUB_NONE CONNECTIVITY_IN_STANDBY 1
powercfg /setactive SCHEME_CURRENT
Write-Host "Power management updated for $adapterName"
}
Update or Roll Back the Driver
If the disconnections started right after a Windows Update or driver update:
- Open Device Manager > Wi-Fi adapter > Properties > Driver tab.
- Click Roll Back Driver if the option's available.
- If Roll Back is grayed out, download the previous driver version from the vendor and install it manually.
For Intel adapters specifically, download drivers directly from Intel rather than relying on Windows Update. The Intel Wi-Fi driver version 23.80.x and later resolves most Windows 11 24H2 disconnection issues. Honestly, this single step fixes about half the tickets I see.
Reset the Network Stack
If power management and driver changes don't help, it's time to reset the full network stack:
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns
Restart the machine after running these. This clears corrupt Winsock catalog entries and resets TCP/IP parameters to defaults.
Verify WLAN AutoConfig Service
Get-Service WlanSvc | Select-Object Name, Status, StartType
If the service isn't running or isn't set to Automatic, fix it:
Set-Service -Name WlanSvc -StartupType Automatic
Start-Service WlanSvc
802.1X Authentication Failure Troubleshooting
So, let's talk about 802.1X. These are easily the most complex Wi-Fi tickets you'll handle, because they involve the client supplicant, the access point (authenticator), and the RADIUS server (authentication server) all working in concert. A failure at any point in that chain breaks the connection — and the error messages rarely tell you which link failed.
Identify the Authentication Method
Before you start troubleshooting, confirm which EAP method your environment uses:
- PEAP-MSCHAPv2 — Username/password-based. Most common in small to mid-size environments.
- EAP-TLS — Certificate-based. The gold standard for security, but it requires PKI infrastructure.
- TEAP — Tunnel EAP. Can authenticate both user and machine simultaneously. It's a newer method that's gaining traction.
Check the WLAN-AutoConfig Event Log
The first place to look for 802.1X failures:
# Pull the last 20 WLAN-AutoConfig events
Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" -MaxEvents 20 |
Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
Key event IDs to watch for:
- Event 8001 — Successfully connected to a wireless network.
- Event 8002 — Failed to connect. The Message field has the reason code.
- Event 8003 — Disconnected from a wireless network.
- Event 11004 — Wireless security failed. This is your primary 802.1X failure event.
- Event 11005 — Wireless security succeeded.
Check NPS/RADIUS Server Logs
On your NPS (Network Policy Server), authentication events show up in the Windows Security event log:
# On the NPS server — query recent RADIUS authentication events
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=6272 or EventID=6273]]" -MaxEvents 20 |
Format-Table TimeCreated, Id, Message -Wrap
- Event 6272 — NPS granted access.
- Event 6273 — NPS denied access. The Reason Code field tells you exactly why (and it's actually useful, unlike most Windows error messages).
Common 802.1X Failure Scenarios and Fixes
Certificate Trust Issues
If the client doesn't trust the RADIUS server certificate, authentication fails silently. Verify that the root CA certificate is deployed to all clients via Group Policy:
# Check if the root CA cert is in the Trusted Root store
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*YourCA*" }
Deploy the certificate via GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
Credential Guard Blocking MSCHAPv2
Here's one that trips up a lot of teams. Windows 11 with Credential Guard enabled will block PEAP-MSCHAPv2 authentication entirely, because MSCHAPv2 uses NTLM-derived credentials that Credential Guard protects. If your environment uses PEAP-MSCHAPv2, you've got two options:
- Migrate to EAP-TLS (certificate-based) — the recommended long-term fix.
- Disable Credential Guard for the Wi-Fi adapter via GPO — a tactical workaround: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security > set Credential Guard to Disabled.
KB5058411 Breaking 802.1X (Known Issue)
After installing Windows 11 update KB5058411, some clients fail during the PEAP Phase 2 MSCHAPv2 handshake. The client establishes the TLS tunnel but never sends the inner EAP-Response. Fun times. The fix:
- Uninstall the update:
wusa /uninstall /kb:5058411 /quiet /norestart - Check for a superseding update from Microsoft that resolves the regression.
- If no fix is available, block the update temporarily via WSUS or Intune update policies.
Deploying Wireless Settings via Group Policy
Manual configuration of 802.1X on every client doesn't scale. Use Group Policy to push wireless profiles to all domain-joined machines.
Create a Wireless Network Policy
- Open Group Policy Management Editor.
- Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies.
- Right-click > Create A New Wireless Network Policy for Windows Vista and Later Releases.
- Name the policy and add an Infrastructure profile.
- On the Connection tab, enter your SSID and check Connect automatically when in range.
- On the Security tab, set Authentication to WPA2-Enterprise or WPA3-Enterprise, select the EAP method, and configure the server certificate validation settings.
Configure Authentication Mode
Under the Security tab, set Authentication Mode to User or Computer authentication. This ensures the machine authenticates when no user is logged in (important for startup scripts, GPO processing, and SCCM tasks) and re-authenticates with user credentials at logon.
Export and Import XML Profiles
Some advanced settings aren't exposed in the GPO editor UI. To work around this, export the profile to XML, edit it, and re-import:
# Export a wireless profile to XML
netsh wlan export profile name="CorpWiFi" folder=C:\Temp
# Import a wireless profile from XML (after editing)
netsh wlan add profile filename="C:\Temp\Wi-Fi-CorpWiFi.xml" user=all
WPA3 Transition: What Helpdesks Need to Know
WPA3 isn't optional anymore — it's mandatory for any SSID operating in the 6 GHz band, and Microsoft is pushing WPA3-Enterprise support hard in Windows 11 25H2. Here's what tends to break during the transition and how to deal with it.
WPA2/WPA3 Mixed Mode (Transition Mode)
Most enterprises should deploy in WPA2/WPA3-Enterprise mixed mode during the transition. This lets WPA3-capable clients negotiate WPA3 while older clients fall back to WPA2. Configure this on your wireless controller — the exact setting varies by vendor (Cisco, Aruba, Meraki, etc.).
Common WPA3 Issues
- Older NICs don't support WPA3. Check adapter support with
netsh wlan show drivers— look under "Authentication and cipher supported in infrastructure mode" for WPA3-Enterprise or WPA3-Personal. - Protected Management Frames (PMF). WPA3 mandates PMF. If your APs or clients don't support PMF, the connection will fail. Verify PMF is enabled on the AP and not blocked by the client driver.
- Inconsistent cipher negotiation. Some clients negotiate AES-CCMP-128 while others expect GCMP-256 for WPA3-Enterprise. Make sure your RADIUS server and APs support both cipher suites during transition.
Checking WPA3 Capability on Windows 11
netsh wlan show drivers | findstr /i "WPA3"
If the output doesn't list WPA3-Enterprise, the adapter or driver doesn't support it. Update the driver first; if it's still unsupported, the hardware needs to be replaced.
Wi-Fi 6E and Wi-Fi 7: New Challenges for the Helpdesk
Wi-Fi 7 (802.11be) access points are now the default enterprise purchase in 2026, and Wi-Fi 6E (6 GHz) is the primary capacity layer in modern deployments. Both bring some genuinely new troubleshooting headaches.
6 GHz Band Issues
- Shorter range. 6 GHz signals attenuate faster than 5 GHz. Users who were fine at their desk on 5 GHz may lose connectivity on 6 GHz from the same spot. A dedicated 6 GHz site survey is essential — don't just assume your existing AP placement will work.
- WPA3 mandatory. Legacy security modes (WPA2-Enterprise, WPA2-Personal) simply can't be used on 6 GHz. If a client doesn't support WPA3, it can't connect to the 6 GHz SSID at all.
- AFC (Automated Frequency Coordination). Standard-power 6 GHz operation requires AFC approval from the FCC. Indoor low-power mode works without AFC, but standard-power deployments (outdoor, warehouse, campus) need an AFC-enabled controller.
Multi-Link Operation (MLO) Troubleshooting
Wi-Fi 7's MLO lets a client send and receive on multiple bands simultaneously. Sounds great on paper. In practice, MLO implementations vary wildly across vendors, and you'll run into unexpected behavior:
- Clients connecting on fewer links than expected. Verify the MLO mode (STR, NSTR, eMLSR) supported by both AP and client.
- Intermittent throughput drops. If one link experiences interference, the aggregate throughput can tank. Use the AP controller dashboard to monitor per-link statistics.
- Windows 11 25H2 required. WPA3-Enterprise with Wi-Fi 7 MLO only works on Windows 11 25H2 and later. Earlier versions fall back to single-link mode silently.
Driver Issues on Wi-Fi 7
The Wi-Fi 7 driver ecosystem is still maturing (to put it diplomatically). Known issues in 2026:
- Intel BE200/BE202 drivers need version 24.40.x or later for stable MLO.
- Windows 11 24H2 broke Wi-Fi 7 drivers for several Intel and MediaTek chipsets — upgrade to 25H2 or install out-of-band driver updates from the vendor.
- Apple devices (iPhone 16 series) have known Wi-Fi 7 connectivity quirks that randomly fall back to Wi-Fi 6 speeds. No fix from Apple as of early 2026 — just document it as a known issue for your team.
Generating a Full Wi-Fi Diagnostic Report
When you need the full picture of a client's wireless health, this command is your best friend:
netsh wlan show wlanreport
It creates an HTML report at C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html covering the last 3 days of wireless activity. The report includes:
- Connection sessions — every connect/disconnect event with timestamps and reason codes.
- Error events — highlighted in red circles on the timeline chart (very visual, very helpful).
- Adapter information — driver version, capabilities, and supported radio types.
- Network profile output — stored profiles and their configuration.
- IP configuration — current DHCP lease, DNS servers, and gateway.
Want a longer reporting window? Say, 7 days:
netsh wlan show wlanreport duration=168
For deeper packet-level analysis, capture WLAN events with PowerShell:
# Start a WLAN event trace
New-NetEventSession -Name WifiDiag -CaptureMode SaveToFile -LocalFilePath C:\Temp\wifi-trace.etl
Add-NetEventProvider -Name "Microsoft-Windows-WLAN-AutoConfig" -SessionName WifiDiag
Start-NetEventSession -Name WifiDiag
# ... reproduce the issue ...
# Stop the capture
Stop-NetEventSession -Name WifiDiag
Remove-NetEventSession -Name WifiDiag
macOS Sequoia Wireless Diagnostics
Got macOS clients in your environment? Here's how to troubleshoot them:
- Hold Option and click the Wi-Fi icon in the menu bar to see detailed connection info (RSSI, noise, channel, PHY mode, MCS index).
- Open Wireless Diagnostics (Spotlight search) for a guided troubleshooting workflow.
- Use Terminal for command-line diagnostics:
# Show current Wi-Fi status on macOS
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
# Scan for available networks
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s
# Generate a Wi-Fi diagnostic report
sudo wdutil diagnose
Escalation Checklist: When to Involve Network Engineering
Not every Wi-Fi ticket should stay at the helpdesk. Know when to escalate:
- Multiple users on the same AP are experiencing simultaneous failures — this points to an AP hardware issue, uplink switch problem, or RADIUS server outage.
- The WLAN report shows frequent channel changes or high retry rates — that suggests RF interference requiring a proper site survey.
- 802.1X failures appear on the RADIUS server for valid credentials and valid certificates — could be an NPS policy misconfiguration or a certificate chain issue on the server side.
- Users report consistent problems in specific physical locations — time for an RF heat map and possibly additional AP placement.
- Wi-Fi 7 MLO or 6 GHz-specific issues that persist after driver updates — these likely need firmware updates on the APs or controller-level config changes that are beyond helpdesk scope.
Frequently Asked Questions
Why does my Wi-Fi keep disconnecting on Windows 11 after an update?
Windows 11 24H2 and certain cumulative updates (notably KB5058411) introduced driver compatibility issues affecting Intel and MediaTek wireless adapters. The most effective fix is to disable Wi-Fi power management in Device Manager, update to the latest vendor-specific driver (not the Windows Update version), and reset the network stack with netsh winsock reset and netsh int ip reset.
How do I troubleshoot 802.1X Wi-Fi authentication failures?
Start with the WLAN-AutoConfig operational log on the client (Event Viewer > Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig). Look for Event ID 11004 (security failure). Then check your NPS/RADIUS server for Event ID 6273 (access denied) — it includes a Reason Code explaining what went wrong. Common culprits: expired certificates, untrusted root CAs, Credential Guard blocking MSCHAPv2, and mismatched EAP method configurations.
Does WPA3 work with all Wi-Fi adapters on Windows 11?
Nope. WPA3 requires both hardware and driver support. Run netsh wlan show drivers and check the "Authentication and cipher supported in infrastructure mode" section. If WPA3-Enterprise isn't listed, update the driver first. If it's still absent, the adapter hardware doesn't support WPA3 and needs to be replaced. The good news: most adapters shipped after 2021 (Wi-Fi 6 and later) do support it.
What's the difference between Wi-Fi 6E and Wi-Fi 7 for enterprise?
Wi-Fi 6E (802.11ax) extends Wi-Fi 6 into the 6 GHz band, giving you more channels and less interference. Wi-Fi 7 (802.11be) adds Multi-Link Operation (MLO) for simultaneous multi-band connections, 320 MHz channel width, and 4096-QAM modulation. For helpdesks, the practical difference is that Wi-Fi 7 introduces MLO-related troubleshooting complexity — clients may behave differently depending on which links are active, and driver maturity varies a lot across vendors.
How can I remotely diagnose a user's Wi-Fi issue?
Run netsh wlan show wlanreport via your remote management tool (SCCM, Intune, or remote PowerShell) to generate the WLAN diagnostic report on the user's machine. The report gets saved as an HTML file you can retrieve and review. For real-time diagnostics, netsh wlan show interfaces gives you the current connection state, signal strength, and authentication type — no need to rely on the user's description of what's happening.