DirectAccess Reconnect Regression: KIR and December 2022 Fix

Microsoft has confirmed that installing the October 18, 2022 out‑of‑band update KB5019509 — and certain cumulative updates that followed — can leave enterprise endpoints unable to reconnect to DirectAccess after a temporary network interruption or when switching Wi‑Fi networks, and the company has responded with a Known Issue Rollback (KIR), Group Policy remediation guidance, and later cumulative updates to permanently resolve the problem.

Background​

DirectAccess is a legacy, enterprise‑grade remote access technology that provides seamless, always‑on connectivity for domain‑joined Windows clients to reach corporate resources without the user manually initiating a VPN. It relies on complex network transition technologies (IPv6 transition, IP‑HTTPS, IPsec) and certificate‑based authentication, so small changes in the networking stack or authentication flows can have outsized effects on reconnection logic.
In mid‑October and November 2022 Microsoft shipped a series of updates (notably KB5019509 and related October/November cumulative updates) that later surfaced a regression: after a brief network outage or when clients roam between wireless access points, some DirectAccess clients remained in a perpetual “Connecting” state and failed to reestablish the tunnel. Microsoft acknowledged the behavior, offered a simple restart workaround for affected endpoints, and published a Known Issue Rollback (KIR) for enterprise-managed systems while issuing December 13, 2022 cumulative updates that contained a permanent fix.
This article reviews what happened, who was affected, what administrators should do now, and the operational and security trade‑offs of the mitigation strategies Microsoft provided.

---

What Microsoft said and how the issue manifested​

• The problem: After installing KB5019509 or later updates, some Windows devices could not reconnect to DirectAccess after temporarily losing network connectivity or when transitioning between Wi‑Fi networks or access points.
• Scope: The issue primarily impacted domain‑joined devices using DirectAccess to access corporate network resources. Consumer devices or devices not configured to use DirectAccess were not affected. Other remote access modalities — conventional VPN (RAS) and Always On VPN (AOVPN) — were reported as unaffected by this regression.
• Immediate mitigation: Microsoft advised affected users that a full reboot of the endpoint would usually restore DirectAccess connectivity temporarily. For enterprise environments, Microsoft released KIR policy definition packages that administrators could deploy via Group Policy or Intune to disable the code path that caused the regression until a proper fix was available.
• Permanent fix: Microsoft released December 13, 2022 cumulative updates for the affected OS families which included a resolution for the DirectAccess reconnection issue; once those updates were installed, the KIR is no longer needed.

These facts are reflected in the update release notes and guidance published by Microsoft, and they match multiple independent administrator reports from the field that documented “Connecting”‑state behavior and the subsequent KIR and December patch resolution.

---

Who was affected — operating systems and updates​

The regression was tied to a family of October/November 2022 updates and surfaced across:

• Windows 11 (22H2 and earlier servicing branches) — examples include KB5018427 and KB5019509.
• Windows 10 (various 20H2/21H1/21H2/22H2 builds) — affected by KB5018482, KB5019959 and earlier November releases.
• Windows Server 2022 — corresponding server updates were included in the set of affected KBs.

Microsoft’s response listed specific KBs associated with the issue and the KIR activations for each OS build. In practice this meant that the problem was most visible in enterprise estates where DirectAccess was still in use. DirectAccess is less common in modern deployments (many organizations have migrated to Always On VPN or SASE models), but some large enterprises and legacy setups still rely on it — amplifying the operational impact.

---

Why this was serious for admins​

DirectAccess is designed to be invisible to users: once configured, domain‑joined devices should have continuous access to intranet resources. A persistent “Connecting” state breaks not only ad hoc remote access to file shares and management services, but it can also:

• Block remote management and patching workflows that depend on the tunnel.
• Prevent certificate auto‑enrollment or other PKI operations that assume network reachability.
• Interfere with corporate telemetry collection and endpoint monitoring.
• Create support‑heavy interruptions for users who must reboot devices or call IT every time the tunnel fails to reconnect.

For organizations that still use DirectAccess, the regression increased helpdesk tickets and elevated risk on roaming laptops — exactly the devices that are most likely to encounter transient network disruptions.

---

Known Issue Rollback (KIR): what it is and how it works​

Microsoft’s Known Issue Rollback is a targeted mechanism to disable a specific code change introduced by a Windows update without uninstalling the update itself. Key operational characteristics:

• KIRs are intended for non‑security regressions. Microsoft restricts KIR use to nonsecurity fixes, because rolling back a security fix could open a vulnerability.
• For consumer and unmanaged devices, Microsoft can deliver KIR activations automatically via Windows Update infrastructure; end users typically need only reboot for the rollback to apply.
• For enterprise‑managed devices, Microsoft supplies a KIR policy definition (.msi that installs ADMX/ADML templates) which administrators can deploy via Group Policy (GPO) or ingest into Intune via ADMX ingestion. The GPO effectively disables the problematic feature/fix until Microsoft ships a corrected update.
• KIR policy definitions are temporary; once Microsoft certifies a proper hotfix or cumulative update that addresses the root cause, administrators should remove the KIR policy and install the corrected update.

KIR is a pragmatic compromise: it reduces immediate operational pain without forcing a full uninstall of the update nor exposing endpoints to security regressions.

---

Workarounds and fixes: step‑by‑step options for admins​

The remediation choices fall into three practical paths. Each organization should choose based on scale, urgency, and management tooling.

• Immediate, low‑effort option — restart affected endpoints
• Most users reported that a simple reboot restored DirectAccess connectivity.
• This is useful for small numbers of machines or temporary relief while rolling a broader action.
• Enterprise mitigation — deploy the KIR via Group Policy or Intune
• Download the KIR policy definition MSI for the specific OS build Microsoft published.
• Install the MSI on the machine used to author Group Policy (or extract ADMX and copy to the central store).
• Create a GPO and follow the steps to enable the KIR activation:
• Create a GPO targeted at the affected OS build (use a WMI filter that matches the specific build/version if necessary).
• In the GPO editor navigate to Computer Configuration → Administrative Templates → KB <KBID> Issue <XXX> Rollback → Windows <version> and set the policy to Disabled (the exact naming is provided by the ADMX you installed).
• Link the GPO, force a gpupdate on test machines, and restart clients to apply the rollback.
• For Intune, extract the ADMX from the MSI and use ADMX ingestion with the OMA‑URI method to deploy the KIR activation to managed devices.
• Permanent fix — apply Microsoft’s December 13, 2022 cumulative updates
• Microsoft released cumulative updates on December 13, 2022 that included a fix for the DirectAccess reconnection bug; installing the appropriate CU for your OS family (for example, the December CU for Windows 11 and corresponding Windows 10 CUs) resolves the issue permanently.
• Once the CU is installed and validated, remove the KIR policy and reboot devices to return them to normal update posture.

Administrators should prefer the permanent fix path when possible, but the KIR is an invaluable stopgap if the CU rollout is constrained by change windows or application compatibility testing.

---

Detection and troubleshooting: how to tell which clients are impacted​

Identifying symptoms and confirming the problem quickly cuts helpdesk load. Recommended diagnostics:

• Observe client UI: DirectAccess client in the system tray or the Network Connectivity Assistant remaining in a persistent Connecting state after network disruptions.
• Run command‑line checks on suspect clients:
• netsh interface httpstunnel show interface — look for failures to connect to the IP‑HTTPS server and Last Error Code : 0x57 or similar error text.
• Get-NetIPHttpsState (PowerShell) — returns IP‑HTTPS state and can show failed interface status.
• Get-DAClientExperienceConfiguration (PowerShell) — verifies whether DirectAccess client settings were applied.
• Check Event Viewer:
• Application and System logs for RasClient or IPHTTPS related error events and timestamps coinciding with network blips.
• Network Connectivity Assistant and DirectAccess client logs often show useful diagnostic details for reconnection failures.
• Use Remote Monitoring/Management tools to query endpoints for installed KBs (e.g., inventory queries for specific KB IDs) and correlate those with support‑ticket spikes to identify the impacted population.

These checks let admins prioritize remediation (for example, prioritizing laptop fleets used for critical remote work).

---

Security and operational trade‑offs​

There are four principal considerations administrators must weigh:

• Security posture vs. availability: KIRs are limited to nonsecurity fixes, which means deploying a KIR typically does not reintroduce a security vulnerability. Nonetheless, disabling a nonsecurity improvement can remove a benign fix or performance improvement; teams should consider the functional impact and remove KIRs once a validated hotfix is available.
• Support overhead: For organizations without centralized GPO or Intune coverage, repeatedly asking users to reboot is an unsustainable support burden. The KIR GPO approach centralizes the remediation and reduces tickets.
• Update cadence: Patching to the December cumulative fix is the recommended long‑term action, but some environments require lengthy testing windows. In that scenario, keep the KIR temporarily and expeditiously schedule CU deployment.
• Migration planning: For organizations still using DirectAccess, this incident underscores the fragility of aging remote access architectures. Evaluating migration paths to modern alternatives (Always On VPN, Entra Private Access, or vendor SASE solutions) reduces exposure to future Windows client networking regressions and simplifies roaming device management.

---

Operational checklist for Windows admins​

• Inventory: Query your fleet for the presence of the October/November 2022 KBs and for devices configured for DirectAccess.
• Detect: Use the diagnostic commands above on symptomatic machines to confirm the “Connecting”‑state and error codes.
• Short term:
• For isolated cases, advise users to reboot.
• For widespread impact, download and deploy the KIR MSI for the matching OS, configure GPOs or Intune ADMX ingestion, and enforce a restart.
• Long term: Schedule and deploy the December 13, 2022 cumulative updates (appropriate KBs for each Windows version). Once validated, remove KIR policies and confirm clients update and reboot.
• Monitor: After remediation, monitor for reoccurrence, and validate recovery on roaming devices and Wi‑Fi handoffs.
• Review: Consider moving away from DirectAccess if practical and budget allows, as the ecosystem and Microsoft guidance increasingly favor modern VPN and zero‑trust access solutions.

---

What we still do not know — flagged uncertainties​

• Root cause details: Microsoft’s public communications and update notes documented the symptom and the fix availability but did not provide a detailed root‑cause analysis of the underlying change that regressed the DirectAccess reconnection logic. The exact code path or network stack interaction that caused the failure was not described in Microsoft’s high‑level guidance. Organizations that require forensic detail will need to work with Microsoft support or consult logs and packet captures in an open SR.
• Scope of field impact: Administrator reports indicate the issue affected a significant number of managed devices in some enterprises, but there is no authoritative public count of affected endpoints. Field reports and community threads are consistent with at‑scale operational impact in larger estates but are anecdotal and should be interpreted accordingly.
• Regressions after fixes: Some administrators reported intermittent reappearance of DirectAccess reconnection problems after later monthly CUs in early 2023 during pilot rollouts. These reports were community‑sourced and situational; they underscore the need for staged testing and telemetry collection when removing temporary mitigations like KIR.

Where claims or implications cannot be verified from Microsoft’s technical notes or reproducible diagnostics, this account flags them as anecdotal and recommends direct telemetry and testing in your environment.

---

Lessons for Windows update strategy and remote access architecture​

• Test updates in representative pilot rings before broad deployment, especially in environments with specialized networking like DirectAccess.
• Maintain a documented KIR and rapid rollback plan: KIR is a sanctioned Microsoft mitigation — learn to use the MSI/ADMX process and maintain a small playbook for activation and deactivation.
• Monitor user experience for roaming and connectivity issues with synthetic checks that simulate access point transitions and temporary network blackouts.
• Reevaluate long‑term remote access strategy: DirectAccess was a powerful solution but is now legacy; modern enterprises should plan migration paths to Always On VPN, conditional access with device posture enforcement, or cloud‑native zero‑trust access platforms to reduce dependency on older IPv6‑over‑IPv4 tunneling mechanisms.
• Keep security and availability balanced: a temporary KIR is acceptable when an urgent regression affects availability, but it must be a short‑lived, controlled measure rather than a permanent workaround.

---

Conclusion​

The KB5019509‑era regression that left some DirectAccess clients unable to reconnect after transient network interruptions was an unwelcome reminder of how delicate legacy remote access mechanics can be when the underlying OS networking stack is updated. Microsoft’s triage model — public acknowledgment, Known Issue Rollback for enterprise control, and a December cumulative update to permanently fix the issue — followed a reasonable path: immediate relief, controlled enterprise mitigation, and a definitive patch.
For administrators, the practical response is straightforward: inventory and detect impacted devices, deploy the KIR if needed to stop the bleeding, then validate and install the December 13, 2022 cumulative update that contains the fix. Longer term, the incident should be used as momentum to reduce reliance on aging DirectAccess architectures and to strengthen update testing and rollout processes so that future regressions produce fewer disruptions to remote workers and critical IT services.

---

Source: BetaNews Microsoft warns of Direct Access connectivity issues after installing KB5019509 update

 

[ChatGPT]

Microsoft has warned that a recent update branch that includes KB5019509 can cause enterprise endpoints using DirectAccess to get stuck in a perpetual “Connecting…” state after a temporary network interruption or when roaming between Wi‑Fi access points, and the company has issued mitigation guidance including a Known Issue Rollback (KIR) and an enterprise Group Policy workaround while advising a simple reboot as a short‑term fix.

Background​

DirectAccess is a legacy Microsoft remote‑access technology that provides always‑on, seamless connectivity for domain‑joined Windows clients to corporate intranet resources without requiring users to manually initiate a VPN connection. It relies on IPv6 transition technologies, IP‑HTTPS tunneling, IPsec, and certificate‑based authentication—components that tightly couple the Windows networking stack with authentication and name resolution. Because of those dependencies, comparatively small changes in the networking stack or related subsystems can produce outsized effects on connection and reconnection logic.
The issue first surfaced in the October/November 2022 update wave, where a family of updates that included KB5019509 (and sibling KBs such as KB5018427, KB5018482, KB5018483, KB5018485 among others) was tied to a regression: after a brief network outage or roaming event, some DirectAccess clients would fail to reestablish their tunnel and remain stuck in a “Connecting” state until the machine was rebooted. Microsoft publicly acknowledged the behaviour and moved to mitigate impact through a Known Issue Rollback (KIR) and guidance for managed environments.

---

What happened: the observable symptom and scope​

Symptom, in plain terms​

• Devices with DirectAccess configured could initially connect after installing the update, but if network connectivity dropped briefly (for example, a Wi‑Fi handoff) the DirectAccess client would switch to a permanent Connecting state and not recover on its own.
• A complete system restart generally resolved the condition temporarily, but the issue could recur on subsequent network interruptions.

Systems and configurations affected​

• The regression primarily affected domain‑joined, enterprise devices that rely on DirectAccess. Consumer devices or corporate devices not configured to use DirectAccess were not reported as affected in Microsoft’s advisory.
• Reports and field investigations showed the problem surfaced across multiple Windows servicing branches where the related KBs were applied (Windows 10/11 client builds and corresponding server updates in some environments). The issue had a disproportionate operational effect because many enterprises still have roaming laptops that rely on DirectAccess for remote management and access.

What did not appear to be affected​

• Microsoft and independent reporting stressed that other remote access solutions — conventional VPN (RAS) and Always On VPN (AOVPN) — were not affected by this particular regression. That distinction matters operationally because it allowed organizations that had migrated away from DirectAccess to avoid the disruption.

---

Why the update caused problems: technical sketch​

DirectAccess depends on several interacting subsystems: the Windows networking stack (IPv6 transition technologies and IP‑HTTPS), IPsec policies, certificate validation, the IP Helper service, and DNS/Name Resolution Policy Table (NRPT) configuration pushed by Group Policy. In environments using DirectAccess, the client’s ability to recover from transient link‑layer changes depends on robust reconnection logic across those layers.
The October/November 2022 update set apparently changed a networking-related code path that interfered with the reconnection logic. Community and vendor reports pointed to issues such as services (for example, IP Helper) failing to restart cleanly after network changes, or link/ARP handling differences on virtual/transition interfaces that prevented the DirectAccess tunnel from negotiating correctly after a network hiccup. Microsoft’s public notes did not fully disclose a line‑by‑line root cause in the update text; rather, the company documented the observed symptom and applied the KIR to revert the specific behavior that caused the regression.
Because DirectAccess uses IPv6 transition mechanisms (often carrying IPv6 over IPv4 via IP‑HTTPS), small timing or stack changes can easily leave the client stuck waiting for a response or a service handshake that never completes. Administrators reported that restarting certain services did not consistently recover the tunnel, and a full reboot was the reliable temporary corrective action.

---

Microsoft’s response (acknowledgement, KIR, and guidance)​

Microsoft’s public actions followed a typical triage pattern for non‑security regressions:

• Acknowledge the issue and document the symptom in the affected update’s KB/known‑issues notes.
• Deploy a Known Issue Rollback (KIR) activation to neutralize the problematic code path on consumer/non‑managed devices via Windows Update. For enterprise‑managed devices, Microsoft supplied a downloadable KIR policy package (an MSI that installs ADMX/ADML templates) which administrators could deploy via Group Policy or Intune to apply the rollback immediately.
• Recommend a short‑term workaround: a system reboot often re‑establishes DirectAccess connectivity until the KIR or permanent fix is applied.

The KIR approach allowed Microsoft to disable only the specific change that caused the regression without uninstalling the entire cumulative update (which could expose devices to other residual issues or security regressions). For many organizations this was a practical compromise: mitigate the availability issue while preserving other security and bug fixes from the update.

Enterprise deployment detail (practical steps)​

• Download the KIR MSI that corresponds to the affected OS build and install it on the Group Policy management host, or extract the ADMX files for Intune ADMX ingestion.
• Create and link a Group Policy Object (GPO) targeted to affected OUs or use a WMI filter keyed to the problematic builds if selective targeting is needed.
• Force a gpupdate, then reboot client devices to apply the KIR. Microsoft emphasized removing the KIR after installing the permanent fix distributed in subsequent cumulative updates.

---

Workarounds and remediation options​

Administrators had three practical choices, listed here from the least to most structural:

• Reboot the affected endpoints
• The simplest, fastest workaround was to reboot the client device; a restart typically restored the DirectAccess tunnel temporarily. This was useful for isolated incidents or when a rapid helpdesk remedy was needed.
• Deploy the Known Issue Rollback (enterprise route)
• For managed fleets experiencing widespread impact, deploy the KIR policy via Group Policy or Intune to neutralize the offending change while preserving the rest of the update package. This approach is fast, targeted, and Microsoft‑managed.
• Install the permanent fix (recommended long term)
• Microsoft later released cumulative updates that permanently addressed the reconnection regression. After validating those fixes in a pilot ring, administrators should remove any temporary KIR policies and install the corrected cumulative updates across the estate. Community reporting and Microsoft guidance both recommend moving to this state as the definitive remediation.

Troubleshooting checklist for admins​

• Inventory endpoints that use DirectAccess and identify which KBs are installed.
• Use event logs and DirectAccess client diagnostics to confirm the “Connecting”‑state and gather service error conditions (for example, IP Helper or the DirectAccess connectivity assistant events).
• Pilot the KIR on a small cohort before broad deployment, verify reconnection behaviour across roaming scenarios, and then expand to production OUs.
• After applying the permanent CU that contains the fix, remove the KIR policy and confirm normal update/connection behaviour.

---

Operational impact: why this mattered​

DirectAccess is intended to be invisible—physical users and helpdesks expect endpoints to maintain connectivity without intervention. When the reconnect path fails:

• Remote management, patch deployment, telemetry, and PKI enrollment can be disrupted for roaming laptops.
• Helpdesk tickets multiply because end users frequently need a reboot to recover access.
• Enterprise automation and monitoring workflows that depend on persistent tunnels can fail or show false negatives, complicating troubleshooting during incidents.

For organizations still relying on DirectAccess—often larger enterprises with legacy VPN architectures—the regression was particularly costly in support hours and increased operational risks during peak change windows.

---

Critical analysis: strengths and weaknesses of Microsoft’s approach​

What Microsoft did well​

• Quick acknowledgment and public documentation of the symptom reduced uncertainty and allowed admins to correlate local incidents with the vendor advisory.
• KIR is a pragmatic tool that avoids uninstalling the entire cumulative update while still reverting the specific change that caused the regression. This minimizes security trade‑offs versus a full rollback.
• Microsoft provided a deployable enterprise policy path (MSI/ADMX) suitable for Group Policy and Intune, which aligns with standard change control processes in managed environments.

Risks and limitations​

• The public guidance did not provide a fully transparent root‑cause breakdown in the KB notes; organizations seeking forensic-level details had to rely on telemetry, packet captures, or direct support engagements. This gap can slow remediation and forensic validation for sensitive environments.
• KIRs are temporary mitigations; leaving them in place long term risks missing critical security or quality updates if administrators fail to remove the KIR after the definitive fix is applied.
• The episode underscores the fragility of legacy features that depend on layered, low‑level networking. DirectAccess’ complex dependency graph makes it more fragile in the face of networking stack changes compared with modern zero‑trust or cloud‑forward remote access architectures.

---

Recommendations for Windows administrators and IT leaders​

• Inventory reliance on DirectAccess. If an organizational migration plan to Always On VPN, ZTNA, or cloud‑native access is feasible, accelerate it—DirectAccess is legacy and carries disproportionate operational risk when interacting with modern update cycles.
• Maintain a documented KIR playbook: know where to download the appropriate MSI/ADMX, keep a test GPO, and rehearse activation and rollback steps in a lab.
• Stage updates in pilot rings and test roaming scenarios (Wi‑Fi handoffs, VPN failover) before broad deployment. Synthetic checks that simulate wireless transitions can catch regressions early.
• Monitor Microsoft’s KB and update notes closely when deploying out‑of‑band or cumulative updates that touch networking components. Confirm that fixes are installed and KIRs removed as part of the post‑patch validation window.

---

Broader implications: what this says about updates and legacy features​

This episode is illustrative of a recurring theme in modern OS maintenance: incremental updates aimed at polishing user experience or improving subsystem security can inadvertently break complex, legacy feature sets that depend on precise network and authentication behaviours.

• Known Issue Rollback is an effective operational mechanism when used correctly; it demonstrates Microsoft’s ability to surgically revert changes without fully rolling back security updates.
• However, reliance on legacy technologies such as DirectAccess exposes organizations to disproportionate operational risk. The industry trend to move toward Always On VPN, conditional access, and zero‑trust architectures reduces exposure to such regressions and provides better long‑term maintainability.

---

What remained unclear and cautions for readers​

• Microsoft’s public notes and community reports did not enumerate an exact internal code change or single line of offending code; where that level of detail is required, organizations should escalate with Microsoft support and provide packet captures and targeted telemetry to aid forensic analysis. This article flags any such low‑level root‑cause claims as unverified unless corroborated by vendor diagnostic statements or direct SR outcomes.
• The field footprint (how many endpoints were affected globally) was not quantified in public disclosures. Community reports indicated significant pockets of impact but lacked a single authoritative count; treat anecdotal spread as operationally meaningful but not a precise metric.

---

Conclusion​

The KB5019509-era regression that interfered with DirectAccess re‑establishment after transient connectivity events was a high‑visibility reminder of how intertwined and fragile older remote access technologies can be when the operating system networking stack evolves. Microsoft’s response—public acknowledgment, a Known Issue Rollback for immediate mitigation, enterprise Group Policy guidance, and later cumulative updates as a permanent fix—was pragmatic and operationally sound. The practical takeaway for administrators is to treat KIR as a surgical, temporary tool, to validate permanent fixes in controlled pilot rings, and to accelerate transitions away from legacy remote access models where feasible. Inventory, test, and staged rollouts remain the best defenses against update regressions that can silently break critical connectivity for mobile and remote workers.

---

For administrators facing this regression now, prioritize: (1) inventory and detection, (2) KIR deployment for widespread impact, and (3) installation and validation of Microsoft’s permanent cumulative fixes followed by KIR removal—actions that together restore availability while maintaining update posture and security hygiene.

---

Source: BetaNews https://betanews.com/article/micros...ty-issues-after-installing-kb5019509-update/]