Why Wi-Fi Adapters Sleep Through Support Calls

#Current Method: Chasing Ghosts in the Wi-Fi Logs

Most service desks learn about a sleeping Wi-Fi adapter only after a user reports a dropped VPN session, a stalled Teams call, or an intermittent ‘no internet’ banner. The ticket lands with almost nothing to diagnose from: the adapter has usually re-associated by the time anyone looks, and the underlying cause — the operating system suspending the network adapter to save power — leaves no obvious trace in the symptom the user actually reports. Support technicians are left reconstructing the incident from WLAN-AutoConfig event logs, DHCP

This reactive model has three structural weaknesses. First, the trigger condition — the operating system deciding the adapter is idle and can be powered down — is invisible until after the disconnect has already happened, so the evidence trail is always retrospective. Second, log correlation is manual and inconsistent between technicians, so similar incidents get triaged differently depending on who picks up the ticket. Third, because the root cause sits in a power-management policy rather than a network fault, standard network diagnostics (ping, DNS checks, driver reinstalls) rarely resolve anything, and the ticket is frequently closed as ‘intermittent, self-resolved’ without a fix being applied at all.

The organisational assumption behind the current method is that Wi-Fi reliability is primarily a network-layer problem. In environments where devices are managed through Microsoft Intune, that assumption is frequently wrong: the adapter itself is healthy, but the device’s power plan is allowed to suspend it, and no telemetry loop exists to catch the state change before the user notices.

#Improved Workflow: Catching the Drop Before the User Notices

The proactive alternative treats adapter sleep as a detectable device state rather than a symptom to be chased after the fact. Intune’s proactive remediation capability (device-side detection-and-remediation script pairs run on a schedule under the SYSTEM context) is used to poll the adapter’s power-management state directly, rather than waiting for a user-visible symptom. If the detection script finds that the adapter is configured to allow the OS to power it down, a remediation script corrects the configuration and records the action, closing the loop without a ticket ever being raised.

Each step in this workflow exists for a specific reason. Detection runs first because remediation without detection risks resetting settings on devices where the sleep behaviour is intentional (for example, devices on battery power with a deliberately conservative policy). Remediation is scoped narrowly to the specific power-management property rather than reapplying an entire power plan, because broad changes are harder to reason about and harder to roll back. Logging of remediation outcomes exists because Intune’s built-in reporting shows success/failure counts but not device-level trend history, and trend history is what turns a one-off fix into a measurable reduction in ticket volume.

The trade-off being accepted is scheduling frequency versus device load: proactive remediations typically run on a recurring schedule (commonly daily), so detection is not instantaneous. This workflow reduces the window between fault and correction from days (until a user complains) to hours, not to zero.

#Implementation

#

Step 1: Building the Detection Query

The detection script should check the specific adapter power-management property that allows Windows to power off the device to save power, rather than querying the entire power plan. Using the NetAdapter PowerShell module keeps the check narrow and auditable.

1$adapter = Get-NetAdapter | Where-Object { $_.InterfaceDescription -match 'Wireless|Wi-Fi' -and $_.Status -eq 'Up' }
2if ($adapter) {
3    $pm = Get-NetAdapterPowerManagement -Name $adapter.Name
4    if ($pm.AllowComputerToTurnOffDevice -eq 'Enabled') {
5        Write-Output 'NonCompliant: adapter allows OS sleep'
6        exit 1
7    }
8}
9Write-Output 'Compliant'
10exit 0

This detection logic is illustrative and has not been validated against a specific Windows build or OEM driver stack in this article; teams must confirm the property name and default value on their own hardware baseline before relying on it, because some OEM power-management utilities expose overlapping controls that can mask or override this setting.

#

Step 2: The Proactive Remediation Script

The remediation script should change only the property flagged by detection, and should write a local, timestamped record of the change so the action is auditable independently of Intune’s own reporting.

1$adapter = Get-NetAdapter | Where-Object { $_.InterfaceDescription -match 'Wireless|Wi-Fi' -and $_.Status -eq 'Up' }
2if ($adapter) {
3    Set-NetAdapterPowerManagement -Name $adapter.Name -AllowComputerToTurnOffDevice Disabled
4    "$(Get-Date -Format o) Remediated $($adapter.Name)" | Out-File -Append 'C:ProgramDataOpsPlaybookwifi-remediation.log'
5}

This script is also illustrative and untested outside a lab context; validate the property write succeeds and persists across a reboot on your specific hardware and driver version before packaging it into an Intune proactive remediation policy.

#

Step 3: Wiring the Logging Loop for Zero-Touch Evidence

Intune’s proactive remediation reporting provides device-level success/failure counts, but sustained trend analysis usually requires the local log file (written above) to be collected into a central store, for example via a Log Analytics custom log ingestion or an existing endpoint logging pipeline already in use by the organisation. The specific ingestion mechanism (webhook, agent-based log forwarding, or scheduled export) depends on what logging infrastructure is already approved and in place; this article does not assume a specific product for that step because no verified configuration for it was supplied.

#

Step 4: Validation Loop and Ticket Suppression Logic

Before this pair is assigned broadly, run it against a small pilot ring and compare detection results with a manual check on the same devices. Ticket suppression — automatically annotating or closing related tickets when remediation succeeds — should only be introduced once the detection/remediation pair has a demonstrated low false-positive rate in the pilot ring; suppressing tickets on an unproven detection script risks masking genuine hardware faults.

#Guardrails

• Scope the remediation script to change only the single power-management property being targeted; do not reapply an entire power plan or driver configuration.
• Assign the proactive remediation policy to a pilot Azure AD group first, and expand only after a defined observation period with clean results.
• Run detection and remediation scripts with the least privilege the SYSTEM context allows; do not embed credentials or broaden scope beyond the local device.
• Keep a written record of the pre-remediation adapter power-management state on pilot devices so the original configuration is known, not assumed.
• Treat any change to laptop power management as a trade-off against battery life on unmanaged mobility patterns, and disclose this trade-off to the pilot group.

#Validation

• Confirm the detection script correctly flags a deliberately misconfigured test device and correctly passes a compliant one.
• Confirm the remediation script’s change persists after a reboot and after a driver update, since some drivers reset power settings on update.
• Cross-check the Intune proactive remediation report’s success/failure counts against the local remediation log for at least one full scheduled cycle.
• Compare service desk Wi-Fi drop ticket volume for the pilot group against a comparable control group over the same period, not against historical volume alone.

#Common Mistakes

• Deploying remediation to all devices before the pilot ring has produced a stable false-positive rate.
• Assuming the detection property name and default are identical across OEMs and driver versions without checking.
• Suppressing service desk tickets automatically before remediation success has been independently validated.
• Treating a successful remediation report as proof that the underlying disconnect symptom is resolved, without checking the WLAN-AutoConfig event log for continued disconnect events on the same device.

#Recovery

1. Disable or unassign the proactive remediation policy from the affected Azure AD group in Intune to stop further script executions.
2. On affected devices, run Set-NetAdapterPowerManagement -AllowComputerToTurnOffDevice Enabled only if the pre-remediation record confirms that was the original state; otherwise restore the recorded original value.
3. Review the local remediation log and the Intune proactive remediation report together to identify which devices were changed and when.
4. Reopen or flag for review any service desk tickets that were auto-suppressed during the affected period.
5. Confirm on a sample of reverted devices that adapter behaviour has returned to its pre-remediation state before re-expanding the pilot ring.

#Measurable Outcome: Measuring the Deflection

Establish a baseline before deployment: the count of Wi-Fi-related drop tickets per week for the pilot population over at least two prior weeks. The success signal is a sustained reduction in that ticket count for the pilot group relative to a comparable control group, measured over a period long enough to smooth out normal weekly variation (a minimum of four weeks is a reasonable starting point, subject to local ticket volume). The measurement method should combine the service desk ticketing system’s category/tag for Wi-Fi drops with the Intune proactive remediation success/failure report, so a reduction in tickets can be checked against a corresponding rise in successful remediations rather than assumed. Review the comparison at a fixed cadence (for example, monthly) and use a defined threshold — such as a sustained percentage reduction in tickets against the control group — as the decision point for expanding beyond the pilot ring. No production deflection percentage or return-on-investment figure is asserted here, because no verified production measurement was supplied for this article; any such figure must be generated from the organisation’s own baseline and control-group comparison.

#Checklist

• Detection script scoped to a single, named power-management property, tested against known-compliant and known-noncompliant devices.
• Remediation script scoped to the same single property, with a local audit log of every change.
• Pilot Azure AD group defined, with pre-remediation adapter state recorded for each pilot device.
• Logging path from local remediation log to a central store confirmed and owned by an existing, approved logging pipeline.
• Ticket suppression logic withheld until false-positive rate from the pilot ring is known and acceptable.
• Rollback procedure tested on at least one pilot device before wider assignment.
• Baseline ticket count and control group defined before expanding beyond the pilot ring.