Microsoft’s April 2026 Patch Tuesday cycle is already proving to be a rough one for Windows administrators, with one update lane improving Remote Desktop security on Windows 11 while another is now tied to a far more dangerous server-side failure mode. The latest confirmed issue affects Windows Server domain controllers that combine Privileged Access Management with non-Global Catalog roles, where LSASS can crash during startup and trigger repeated reboots. That means the same month that brought fresh security hardening also introduced a new availability risk for identity infrastructure, and that is exactly the sort of trade-off Windows admins dread. (support.microsoft.com)
April 2026’s Windows servicing wave arrived as a familiar mix of security fixes, platform changes, and the occasional post-release surprise. Microsoft’s Windows 11 release notes for KB5083769 show the company pushing security improvements, a Remote Desktop phishing defense change, SMB over QUIC reliability work, and a fix for a prior Reset this PC issue. In other words, the update was not a single-purpose patch, but a broad monthly rollup carrying both security and quality changes. (support.microsoft.com)
On the server side, the picture is similar. Windows Server 2025’s KB5082063 and Windows Server 2022’s KB5082142 are both April 14, 2026 cumulative updates that roll in the latest security fixes and non-security changes from the prior month’s optional preview. Microsoft’s servicing model means these packages are meant to be routine, but the known-issues track record has become a central part of how IT teams judge whether a patch can be deployed immediately or needs staged rollout.
This matters because identity infrastructure is not an ordinary workload. Domain controllers sit at the center of authentication, authorization, and directory services, so even a narrow boot-time failure can cascade into a broad outage. When LSASS stops working on a DC, the server can fail to validate sign-ins, service tickets, and directory operations, which is why Microsoft’s own wording about repeated restarts should be treated as a critical availability event, not a cosmetic bug.
The specific combination Microsoft highlights is also telling. PAM is designed for tightly controlled privileged access in isolated Active Directory environments, and Microsoft’s own guidance around privileged access architecture has shifted over time toward more modern privileged access strategies for most organizations. Even so, many enterprises still run PAM-style forests or tier-0 isolation in regulated or legacy-heavy environments, which means the affected population may be smaller than the total Windows Server base, but the operational stakes are much higher.
The pattern is also not new. Microsoft has had to publish past LSASS-related fixes for domain controllers when servicing updates interacted badly with directory services. That history is important because it shows the latest April 2026 issue is less an isolated surprise and more part of a recurring class of problems: security updates colliding with the very authentication stack they are supposed to protect.
That distinction matters because it changes the operational response. A broad client-side reboot bug can often be quarantined to endpoints, but a domain-controller loop can strand multiple business services at once. In environments where DCs are also handling dependency-heavy services such as LDAP bind authentication, Kerberos ticket issuance, or application logons, the downstream failure surface becomes far larger than the number of servers directly patched.
Microsoft’s advisory language also emphasizes that the bug can be hit in more than one moment of the DC lifecycle. Some servers may fail immediately after patching and rebooting, while others may only surface the issue under early authentication load. That means a green reboot is not always a guarantee of safety; admins may need to watch startup behavior and event logs closely even when the machine appears to return online cleanly.
The important technical detail is not merely that LSASS crashed, but that it crashed during startup. Boot-time failures are especially painful in domain services because they can stop the machine before it fully advertises itself, synchronizes normally, or answers directory requests. In practice, that can create a chain reaction where one DC falls over, others absorb more traffic, and the whole environment becomes more fragile at exactly the moment administrators are trying to stabilize it.
That also helps explain why Microsoft is treating this as a support-mitigated issue rather than a simple uninstall-the-update recommendation. A DC that is stuck in a restart loop may not give admins many recovery windows, and a rollback may not be safe or immediate in every managed environment. So the company’s mitigation-first posture is consistent with the seriousness of the failure mode.
That is why this bug lands so badly. A feature that exists to protect the most sensitive systems is now part of the trigger path for a fault in the most sensitive servers. For administrators, that creates an uncomfortable paradox: the more serious your security architecture, the more likely you are to notice a deep integration issue before ordinary environments do. It is a reminder that security complexity can become availability complexity.
It also explains why the issue may not affect all customers equally. Many enterprises do not run PAM in the specific configuration Microsoft is describing, and many domain controllers are Global Catalog servers. But organizations that do use a non-GC/DC layout inside a PAM forest are often the very organizations that cannot afford a failed authentication tier. In those environments, the impact is disproportionate to the number of machines involved.
This is the kind of issue that tends to escape basic lab testing. A patch can appear stable on a GC-backed test domain while failing in a production topology where non-GC roles, authentication timing, and privileged access systems interact in a more complex sequence. That is one reason release-health notes are so important: they reveal not just what is broken, but where the failure boundary actually lives.
For administrators, the takeaway is not that PAM is flawed, but that the combination of PAM and DC boot behavior creates a narrow but dangerous failure mode. It is the sort of scenario where an enterprise’s strongest controls can unexpectedly become the most fragile dependency. That is a classic enterprise IT lesson, and Microsoft has now had to relearn it in the context of the April 2026 update cycle.
From a security standpoint, this is sensible. From an operations standpoint, it introduces another prompt and another policy surface that admins will need to train users on, especially in environments where Remote Desktop has long been treated as a trust-anchored admin workflow. In other words, Microsoft is steadily turning legacy convenience features into more explicit security decision points. (support.microsoft.com)
That shift mirrors the broader direction of Windows servicing in 2026. Microsoft is pushing more caution into the user journey, but it is also increasing the number of behavior changes that can surprise experienced users. The irony is that a patch focused on strengthening user-side authentication hygiene may coexist in the same month with a server-side identity failure that affects administrators far more severely. (support.microsoft.com)
The update notes also call attention to Secure Boot certificate expiration starting in June 2026. That is not an immediate breakage, but it is a signal that Microsoft expects enterprise operators to begin certificate-readiness work now. In practical terms, the company is stacking an upcoming platform trust transition on top of a patch cycle already busy with identity and boot-path issues. (support.microsoft.com)
For organizations running older operational processes, this becomes a governance problem as much as a technical one. It is no longer enough to apply updates monthly and call the job done; teams need structured ring deployment, recovery planning, and certificate lifecycle management. That is especially true when a single patch cycle can touch RDP, BitLocker, Secure Boot, and DC boot reliability all at once. (support.microsoft.com)
Enterprise admins also need to think about recovery windows. A DC that crashes during boot may be hard to service remotely, and a mitigation from Microsoft Support for business may be the safest route if the environment has already taken the update. Microsoft’s recommendation to contact support for a mitigation, rather than simply uninstalling the patch, is a strong signal that the company expects managed environments to need guided remediation.
There is also the risk of delayed discovery. Some environments may not hit the bug immediately, especially if authentication traffic does not arrive very early in startup. That means an admin could reboot a DC, see it come back online, and only later encounter the failure during a maintenance cycle, a power event, or a planned failover test. That kind of latent fragility is often worse than a consistently broken server because it undermines confidence in normal operational assumptions.
This difference in impact matters because it changes how news about “Windows PCs restarting” should be interpreted. The headline may sound like a general client crisis, but the underlying issue is really about server identity infrastructure. In other words, the scary behavior is not broad Windows consumer instability; it is a targeted server outage risk with consequences that can ripple outward to users.
That nuance is easy to miss in fast-moving patch coverage, and it is exactly why administrators should read release-health notes rather than rely on headline summaries. The difference between “Windows PCs keep restarting” and “non-GC DCs in PAM environments may reboot repeatedly” is the difference between inconvenience and an authentication incident.
There is also a sequencing question. If the issue can hit existing DCs as well as fresh builds, then the mitigation may need to be applied across the lifecycle rather than as a one-time repair. That is more complicated operationally, but it is often necessary when a boot-time race condition sits inside identity services. One-off patching logic is rarely enough for issues that emerge during system initialization.
The guidance also suggests Microsoft is still actively investigating a permanent code fix. That is good news, but in the meantime it leaves admins in a familiar Windows enterprise posture: balance security compliance against uptime risk, choose carefully which servers to patch first, and assume the first wave of telemetry may not reveal the full shape of the fault.
A staged response should also include log review and rollback planning. DC startup failures tied to LSASS are not the kind of issue you want to diagnose while users are already locked out, and they can overlap with other April 2026 issues such as BitLocker recovery prompts. Careful sequencing is the only sane way to avoid turning one patch cycle into multiple avoidable incidents. (support.microsoft.com)
Administrators should also watch for whether the problem remains limited to PAM environments or whether broader Active Directory scenarios begin surfacing. That would change the severity calculus significantly. For now, Microsoft’s wording suggests a narrow but serious class of affected deployments, and the best approach is to treat that narrowness as a reason for caution, not comfort.
Finally, April 2026 should be viewed in the larger arc of Windows servicing in 2026: more security hardening, more boot and trust changes, and more pressure on enterprise operators to validate everything before broad rollout. The changes to Remote Desktop, Secure Boot, and BitLocker point to a platform becoming more defensive by design. That is good news for security, but it also means more opportunities for cross-component friction in the places enterprises can least afford it. (support.microsoft.com)
Source: Neowin Microsoft warns Windows PCs keep restarting after KB5082063, KB5082142 update bug
Background
April 2026’s Windows servicing wave arrived as a familiar mix of security fixes, platform changes, and the occasional post-release surprise. Microsoft’s Windows 11 release notes for KB5083769 show the company pushing security improvements, a Remote Desktop phishing defense change, SMB over QUIC reliability work, and a fix for a prior Reset this PC issue. In other words, the update was not a single-purpose patch, but a broad monthly rollup carrying both security and quality changes. (support.microsoft.com)On the server side, the picture is similar. Windows Server 2025’s KB5082063 and Windows Server 2022’s KB5082142 are both April 14, 2026 cumulative updates that roll in the latest security fixes and non-security changes from the prior month’s optional preview. Microsoft’s servicing model means these packages are meant to be routine, but the known-issues track record has become a central part of how IT teams judge whether a patch can be deployed immediately or needs staged rollout.
This matters because identity infrastructure is not an ordinary workload. Domain controllers sit at the center of authentication, authorization, and directory services, so even a narrow boot-time failure can cascade into a broad outage. When LSASS stops working on a DC, the server can fail to validate sign-ins, service tickets, and directory operations, which is why Microsoft’s own wording about repeated restarts should be treated as a critical availability event, not a cosmetic bug.
The specific combination Microsoft highlights is also telling. PAM is designed for tightly controlled privileged access in isolated Active Directory environments, and Microsoft’s own guidance around privileged access architecture has shifted over time toward more modern privileged access strategies for most organizations. Even so, many enterprises still run PAM-style forests or tier-0 isolation in regulated or legacy-heavy environments, which means the affected population may be smaller than the total Windows Server base, but the operational stakes are much higher.
The pattern is also not new. Microsoft has had to publish past LSASS-related fixes for domain controllers when servicing updates interacted badly with directory services. That history is important because it shows the latest April 2026 issue is less an isolated surprise and more part of a recurring class of problems: security updates colliding with the very authentication stack they are supposed to protect.
What Microsoft Confirmed
Microsoft says that after installing the April 2026 Windows security update and rebooting, non-Global Catalog domain controllers in environments that use PAM might experience LSASS crashes during startup. The practical consequence is severe: affected DCs may restart repeatedly, authentication and directory services may fail, and the domain can become unavailable. That is a worst-case outcome for any identity-administered environment because the control plane itself becomes unstable.The affected scenario
The issue is not described as a generic Windows Server-wide reboot bug. Microsoft’s language narrows it to non-GC domain controllers in PAM environments, which implies a specific interaction between directory role topology and privileged access configuration. Microsoft also notes that the issue can appear when provisioning a new DC or when authentication requests arrive very early during startup, which suggests a race condition or initialization timing problem rather than a simple post-install regression.That distinction matters because it changes the operational response. A broad client-side reboot bug can often be quarantined to endpoints, but a domain-controller loop can strand multiple business services at once. In environments where DCs are also handling dependency-heavy services such as LDAP bind authentication, Kerberos ticket issuance, or application logons, the downstream failure surface becomes far larger than the number of servers directly patched.
Microsoft’s advisory language also emphasizes that the bug can be hit in more than one moment of the DC lifecycle. Some servers may fail immediately after patching and rebooting, while others may only surface the issue under early authentication load. That means a green reboot is not always a guarantee of safety; admins may need to watch startup behavior and event logs closely even when the machine appears to return online cleanly.
Why LSASS is the alarm bell
LSASS, the Local Security Authority Subsystem Service, is the Windows component that validates sign-ins and enforces local security policy. When LSASS faults on a domain controller, the OS has little choice but to treat the failure as structural, which is why a crash often ends in a reboot rather than a soft recovery. On a standalone workstation that is bad; on a DC, it is potentially domain-wide.The important technical detail is not merely that LSASS crashed, but that it crashed during startup. Boot-time failures are especially painful in domain services because they can stop the machine before it fully advertises itself, synchronizes normally, or answers directory requests. In practice, that can create a chain reaction where one DC falls over, others absorb more traffic, and the whole environment becomes more fragile at exactly the moment administrators are trying to stabilize it.
That also helps explain why Microsoft is treating this as a support-mitigated issue rather than a simple uninstall-the-update recommendation. A DC that is stuck in a restart loop may not give admins many recovery windows, and a rollback may not be safe or immediate in every managed environment. So the company’s mitigation-first posture is consistent with the seriousness of the failure mode.
Why PAM Makes This More Sensitive
PAM, or Privileged Access Management, is built to reduce the blast radius of administrative credentials by controlling when and how elevated access is granted. Microsoft’s own descriptions frame PAM as part of a broader privileged access strategy, especially in environments where isolated administration and tiered trust boundaries are used to protect high-value systems. That makes PAM powerful, but it also means it tends to appear in the most security-conscious and most operationally delicate deployments.The isolation trade-off
PAM and related isolated-forest patterns are meant to make it harder for attackers to obtain privileged account access. But isolation also creates architectural dependencies that can be less forgiving during startup, replication, or authentication initialization. Microsoft’s retired ESAE guidance and modern privileged access strategy both reflect the same underlying truth: the more you harden the path to Tier 0, the more exacting the supporting infrastructure becomes.That is why this bug lands so badly. A feature that exists to protect the most sensitive systems is now part of the trigger path for a fault in the most sensitive servers. For administrators, that creates an uncomfortable paradox: the more serious your security architecture, the more likely you are to notice a deep integration issue before ordinary environments do. It is a reminder that security complexity can become availability complexity.
It also explains why the issue may not affect all customers equally. Many enterprises do not run PAM in the specific configuration Microsoft is describing, and many domain controllers are Global Catalog servers. But organizations that do use a non-GC/DC layout inside a PAM forest are often the very organizations that cannot afford a failed authentication tier. In those environments, the impact is disproportionate to the number of machines involved.
Why non-Global Catalog matters
A Global Catalog server holds a partial replica of every object in the forest and is often used to speed logon and directory lookups across domains. A non-GC DC can still serve core domain functions, but it may rely more heavily on other catalog roles during certain authentication flows. If the startup path intersects badly with PAM-related checks or directory initialization, a non-GC server may become the weak link.This is the kind of issue that tends to escape basic lab testing. A patch can appear stable on a GC-backed test domain while failing in a production topology where non-GC roles, authentication timing, and privileged access systems interact in a more complex sequence. That is one reason release-health notes are so important: they reveal not just what is broken, but where the failure boundary actually lives.
For administrators, the takeaway is not that PAM is flawed, but that the combination of PAM and DC boot behavior creates a narrow but dangerous failure mode. It is the sort of scenario where an enterprise’s strongest controls can unexpectedly become the most fragile dependency. That is a classic enterprise IT lesson, and Microsoft has now had to relearn it in the context of the April 2026 update cycle.
The Broader April 2026 Patch Tuesday Picture
The LSASS/DC reboot issue did not arrive in a vacuum. Microsoft’s April 2026 Windows 11 release notes show a second major security theme: protecting users from phishing via Remote Desktop files. The company also continued work on Secure Boot certificate readiness, SMB over QUIC reliability, and BitLocker-related edge cases, which shows the release was part of a broader systems-hardening campaign rather than a single bugfix drop. (support.microsoft.com)Remote Desktop got stricter
One of the more visible Windows 11 changes in KB5083769 is a new layer of protection for .rdp files. Microsoft says Remote Desktop now shows requested connection settings before connecting, leaves them off by default, and displays a one-time security warning the first time an RDP file is opened on a device. That is a meaningful anti-phishing move because RDP files are often used as a convenience feature in enterprises, which also makes them a tempting social-engineering target. (support.microsoft.com)From a security standpoint, this is sensible. From an operations standpoint, it introduces another prompt and another policy surface that admins will need to train users on, especially in environments where Remote Desktop has long been treated as a trust-anchored admin workflow. In other words, Microsoft is steadily turning legacy convenience features into more explicit security decision points. (support.microsoft.com)
That shift mirrors the broader direction of Windows servicing in 2026. Microsoft is pushing more caution into the user journey, but it is also increasing the number of behavior changes that can surprise experienced users. The irony is that a patch focused on strengthening user-side authentication hygiene may coexist in the same month with a server-side identity failure that affects administrators far more severely. (support.microsoft.com)
BitLocker and Secure Boot remain in the mix
Microsoft also added a known issue in KB5083769 related to an unrecommended BitLocker Group Policy configuration that can trigger a recovery-key prompt after reboot. That is separate from the domain controller reboot issue, but it underscores the same point: April 2026’s servicing wave is carrying multiple high-friction edge cases at once. For admins, that means update validation has become less about binary success/failure and more about whether the environment can tolerate several different failure modes simultaneously. (support.microsoft.com)The update notes also call attention to Secure Boot certificate expiration starting in June 2026. That is not an immediate breakage, but it is a signal that Microsoft expects enterprise operators to begin certificate-readiness work now. In practical terms, the company is stacking an upcoming platform trust transition on top of a patch cycle already busy with identity and boot-path issues. (support.microsoft.com)
For organizations running older operational processes, this becomes a governance problem as much as a technical one. It is no longer enough to apply updates monthly and call the job done; teams need structured ring deployment, recovery planning, and certificate lifecycle management. That is especially true when a single patch cycle can touch RDP, BitLocker, Secure Boot, and DC boot reliability all at once. (support.microsoft.com)
Enterprise Impact vs Consumer Impact
For ordinary Windows users, April 2026 is mostly about security hardening and small workflow changes. For enterprise customers, especially those with Server 2022 or Server 2025 DCs, the story is very different because the issue space is centered on infrastructure roles, not desktop convenience. That distinction is the reason why the phrase “repeated restarts” is more alarming here than it would be on a laptop. (support.microsoft.com)What enterprises should worry about
The most serious risk is authentication outage. If a domain controller goes into a restart loop, users may experience failed logons, service access problems, or directory lookup failures long before the root cause is obvious. In a multi-site environment, even one unstable DC can create disproportionate pressure on other sites, especially if load balancing or replication health is already imperfect.Enterprise admins also need to think about recovery windows. A DC that crashes during boot may be hard to service remotely, and a mitigation from Microsoft Support for business may be the safest route if the environment has already taken the update. Microsoft’s recommendation to contact support for a mitigation, rather than simply uninstalling the patch, is a strong signal that the company expects managed environments to need guided remediation.
There is also the risk of delayed discovery. Some environments may not hit the bug immediately, especially if authentication traffic does not arrive very early in startup. That means an admin could reboot a DC, see it come back online, and only later encounter the failure during a maintenance cycle, a power event, or a planned failover test. That kind of latent fragility is often worse than a consistently broken server because it undermines confidence in normal operational assumptions.
Consumer impact is different
Consumer Windows devices are not the primary target of this reported DC issue. Most home systems do not run Active Directory domain controller roles, and most do not use enterprise PAM configurations, so the reboot-loop risk described by Microsoft is largely outside the consumer threat model. That said, consumers are still seeing the broader April 2026 update strategy in the form of Remote Desktop warnings, BitLocker prompts, and boot-trust changes. (support.microsoft.com)This difference in impact matters because it changes how news about “Windows PCs restarting” should be interpreted. The headline may sound like a general client crisis, but the underlying issue is really about server identity infrastructure. In other words, the scary behavior is not broad Windows consumer instability; it is a targeted server outage risk with consequences that can ripple outward to users.
That nuance is easy to miss in fast-moving patch coverage, and it is exactly why administrators should read release-health notes rather than rely on headline summaries. The difference between “Windows PCs keep restarting” and “non-GC DCs in PAM environments may reboot repeatedly” is the difference between inconvenience and an authentication incident.
Microsoft’s Mitigation Strategy
Microsoft says IT administrators should contact Microsoft Support for business to obtain a mitigation. The company also states that the workaround can be applied to affected devices that have already installed the buggy April 2026 update, and in some cases it can be prepared before the update is installed. That support-first response is common for complicated release-health issues where the failure is specific enough that a single universal rollback is not the safest answer.Why a support mitigation matters
A mitigation delivered through support often indicates that Microsoft has a targeted workaround rather than a public-facing toggle. That can be helpful for large enterprises because it avoids ad hoc registry edits or unsupported workarounds, but it can also slow response time for smaller IT teams that are used to self-service fixes. In practice, that means support quality becomes part of patch resilience.There is also a sequencing question. If the issue can hit existing DCs as well as fresh builds, then the mitigation may need to be applied across the lifecycle rather than as a one-time repair. That is more complicated operationally, but it is often necessary when a boot-time race condition sits inside identity services. One-off patching logic is rarely enough for issues that emerge during system initialization.
The guidance also suggests Microsoft is still actively investigating a permanent code fix. That is good news, but in the meantime it leaves admins in a familiar Windows enterprise posture: balance security compliance against uptime risk, choose carefully which servers to patch first, and assume the first wave of telemetry may not reveal the full shape of the fault.
Operationally sensible next steps
For teams managing affected environments, the safest response is to slow down deployment and identify DC topology before the next reboot cycle. Knowing which controllers are Global Catalog servers, which are non-GC, and where PAM is present is now essential operational metadata rather than optional documentation. If you cannot answer those questions quickly, you are already underprepared for incidents like this.A staged response should also include log review and rollback planning. DC startup failures tied to LSASS are not the kind of issue you want to diagnose while users are already locked out, and they can overlap with other April 2026 issues such as BitLocker recovery prompts. Careful sequencing is the only sane way to avoid turning one patch cycle into multiple avoidable incidents. (support.microsoft.com)
Strengths and Opportunities
Even with the current bug, Microsoft’s response shows that the company is doing several things right. It is publishing release-health information quickly, it is narrowing the affected scenario instead of issuing vague guidance, and it is pairing new security features with clear known-issue tracking. That transparency does not remove the operational pain, but it does give administrators something concrete to work with. (support.microsoft.com)- Microsoft is identifying the issue at the role/configuration level rather than treating it as a blanket Windows failure.
- The company is recommending a support-backed mitigation instead of leaving admins to improvise.
- Release notes clearly distinguish Windows 11 client changes from Windows Server impact, which helps reduce confusion.
- The April 2026 cycle includes genuine security improvements, especially around Remote Desktop phishing resistance.
- Secure Boot preparation is being surfaced early enough for enterprises to plan ahead.
- The known-issue tracking model gives admins a reason to stage rollouts more intelligently.
- Microsoft’s broader privileged-access guidance helps contextualize why PAM-heavy environments may be more exposed. (support.microsoft.com)
Risks and Concerns
The biggest risk is obvious: a domain controller reboot loop can turn into a domain outage. But the second-order risks are just as important, because a mixed patch month can make it harder to tell whether a problem is caused by BitLocker, LSASS, Secure Boot changes, or something else entirely. That sort of ambiguity is expensive for IT teams and dangerous for business continuity. (support.microsoft.com)- DC instability can block authentication across the organization.
- Non-GC and PAM-specific behavior makes the issue easy to miss in testing.
- Early-startup timing bugs are hard to reproduce and diagnose.
- Multiple April 2026 known issues increase troubleshooting complexity.
- Support-only mitigations may slow down smaller organizations.
- Restart loops on identity infrastructure can cascade into service and application outages.
- Confidence in Patch Tuesday can erode when several high-impact bugs land in one cycle. (support.microsoft.com)
Looking Ahead
The next thing to watch is how quickly Microsoft publishes a definitive fix and whether it arrives as a standard cumulative update, an out-of-band release, or a support-delivered mitigation path that later becomes public. The company’s recent servicing history suggests that when identity services are involved, it tends to act quickly once the scope is understood. But the key question is whether the fix can preserve security posture without creating a new boot-path regression.Administrators should also watch for whether the problem remains limited to PAM environments or whether broader Active Directory scenarios begin surfacing. That would change the severity calculus significantly. For now, Microsoft’s wording suggests a narrow but serious class of affected deployments, and the best approach is to treat that narrowness as a reason for caution, not comfort.
Finally, April 2026 should be viewed in the larger arc of Windows servicing in 2026: more security hardening, more boot and trust changes, and more pressure on enterprise operators to validate everything before broad rollout. The changes to Remote Desktop, Secure Boot, and BitLocker point to a platform becoming more defensive by design. That is good news for security, but it also means more opportunities for cross-component friction in the places enterprises can least afford it. (support.microsoft.com)
- Watch for an out-of-band fix or updated release-health entry.
- Monitor whether Microsoft expands the affected scope beyond PAM/non-GC DCs.
- Validate DC restart behavior after patching in a lab that matches production topology.
- Track BitLocker, Secure Boot, and Remote Desktop side effects in the same maintenance window.
- Review privileged-access forest design before the next reboot cycle.
- Confirm support escalation paths before deploying the April 2026 server updates broadly. (support.microsoft.com)
Source: Neowin Microsoft warns Windows PCs keep restarting after KB5082063, KB5082142 update bug
Last edited:
