Windows 11 Insider Build 26220 Locks OOBE to Internet and Microsoft Account

Microsoft’s most recent Insider test build cements a decisive shift in Windows setup: the Out‑of‑Box Experience (OOBE) in current Dev/Beta previews now requires an internet connection and a Microsoft account on the default consumer path, and Microsoft has explicitly removed the common one‑line and in‑OOBE tricks that enthusiasts used to create a local account during first‑boot.

Background / Overview​

For years Windows setup has slowly moved toward an identity‑centered model where a Microsoft Account (MSA) and connectivity at first boot unlock features such as OneDrive settings sync, BitLocker recovery key escrow, Windows Hello cloud recovery, and Copilot personalization. That push produced community workarounds—small command‑line tricks and registry toggles run from the OOBE command prompt (Shift+F10) that let users finish setup with a purely local account without rebuilding media or using enterprise imaging.
Microsoft’s October Insider post for Dev Channel Build 26220.6772 (KB5065797) makes two OOBE changes explicit: a supported helper to name the default user folder during OOBE (SetDefaultUserFolder.cmd) and a blunt policy line stating it is “removing known mechanisms for creating a local account in the Windows Setup experience (OOBE).” That blog post is the canonical source for the change and was published as part of the Dev preview flight.
This article summarizes what changed, verifies technical specifics against independent reporting, analyzes operational and privacy tradeoffs, and offers practical guidance for consumers, technicians, refurbishers, and IT professionals who must adapt provisioning workflows.

---

What Microsoft changed — the technical specifics​

The official change (what Microsoft wrote)​

• The Windows Insider Blog for Build 26220.6772 clearly lists an OOBE item: “Local‑only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE).” The blog also documents the supported SetDefaultUserFolder.cmd helper and how to invoke it during setup.

The in‑OOBE tricks targeted​

Independent hands‑on and press testing confirmed the practical effects: commands that previously opened a local‑account creation dialog or forced the “I don’t have internet / limited setup” branch now either do nothing, loop OOBE back to the Microsoft sign‑in gate, or restart the setup flow. The two most-cited consumer shortcuts that have been neutralized are:

• The long‑used OOBE\BYPASSNRO batch/script (commonly invoked as bypassnro) that forced the limited‑setup branch.
• The simpler one‑line URI/command run from the OOBE command prompt: start ms‑cxh:localonly (or ms‑cxh:localonly), which previously spawned an offline local‑account dialog.

Multiple reputable outlets reproduced the behavior in test ISOs and preview devices, so the neutralization is not hypothetical; it has been observed across Dev and Beta channel images.

Which builds and channels are affected​

The behavior was introduced in Dev Channel Build 26220.6772 (and associated Beta family flights in the 26120.x series) as a staged toggle in the Insider program. Microsoft’s controlled rollout means a subset of Insiders will see it first; that same staging model determines if and when it reaches Release Preview and stable channels. Treat Insider builds as an authoritative signal of direction, but not an immutable final policy.

---

Why Microsoft says it’s doing this​

Microsoft’s stated rationale in the Insider notes is operational: some bypass methods “inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use.” Enforcing an online, MSA‑based OOBE reduces variability, helps ensure device registration for recovery, and standardizes telemetry and support hooks that Microsoft uses to deliver services and troubleshooting. The company frames the change as improving consistency and recoverability.
Independent coverage echoes that rationale while noting the business and product incentives that benefit from pushing more users into Microsoft’s cloud services. In short: Microsoft can claim a technical support and security justification while the product direction also aligns with cloud‑centric features and subscriptions.

---

Cross‑checked verification (what reputable sources show)​

To validate the most important claims, the key facts were cross‑referenced with multiple sources:

• Microsoft’s Windows Insider Blog post for Build 26220.6772 documents the change and the SetDefaultUserFolder helper.
• The Verge and Windows Central reproduced and explained the neutralization of BYPASSNRO and the ms‑cxh:localonly URI in hands‑on testing, confirming the observable behavior in preview images.
• Tom’s Hardware and PC Gamer provided additional hands‑on reporting and practical guidance on how the setup flow now behaves and which scenarios remain (unattended imaging, enterprise provisioning).

Where public claims were vague (for example, the exact timeline for GA rollout), sources were cautious: Insider changes indicate product direction but not final release timing. That point is important and flagged where appropriate below.

---

Strengths: what this change delivers​

• More consistent device state at first boot. Requiring the canonical OOBE path reduces the chance a device leaves setup without critical protections (e.g., BitLocker backup, device registration). This lowers support variability for many consumer scenarios.
• Improved recoverability and integration. Cloud‑tethered accounts enable features like Windows Hello recovery and OneDrive-backed settings, which materially help users who lose devices or need to recover profiles.
• Simplified support model. For Microsoft and many OEMs, having a single default path simplifies diagnostics, telemetry, and automated help workflows. That reduces edge‑case troubleshooting tied to ad‑hoc local setups.

---

Tradeoffs and risks: who loses and why it matters​

The announced change imposes real costs and operational friction for several user groups:

• Privacy‑first users and offline consumers. Those who deliberately avoid a cloud identity (or lack reliable internet) face an added barrier: a one‑line command that used to create a local account no longer works during OOBE. For casual users, the recommended workaround—use a minimal Microsoft Account temporarily and convert after setup—may be unacceptable.
• Refurbishers, small resellers, and technicians. These workflows often relied on quick in‑OOBE shortcuts for speed. The neutralization raises the bar: either invest in unattended installs (autounattend.xml), robust imaging pipelines, or accept the temporary MSA route. That increases labor and testing overhead.
• Offline deployments and low‑resource environments. Regions with inconsistent network access or constrained bandwidth will face friction during first boot when the default path assumes connectivity.
• Potential regulatory scrutiny. Steering users toward a cloud identity by default may attract attention from consumer protection and privacy regulators in markets that scrutinize platform choice and default settings. This is a policy risk that’s difficult to quantify but real in principle. Analysts and reporters have noted that the move tightens Microsoft’s control over first‑run flows and data‑collection touchpoints.

Caveat: This is currently an Insider‑only change (Dev/Beta). Microsoft could alter behavior before a public release; the change is a directional signal rather than necessarily the final stable product policy. Treat that as an important qualification.

---

Workarounds that still exist (and their limits)​

Microsoft explicitly neutralized in‑OOBE shortcuts, but several supported or more technical pathways remain for creating local accounts or avoiding an MSA at scale:

• Unattended installs via autounattend.xml. An answer file can inject a local administrator account during the offline image application phase, so OOBE never requires interactive account creation. This method is supported and robust for technicians but requires preparation.
• Image‑based provisioning (imaging tools / Rufus-like preconfig). Building custom install media that includes a preseeded user avoids the interactive OOBE gate. This is a valid path for refurbishers and OEMs but is nontrivial for end users.
• Enterprise provisioning (Autopilot, MDT, Intune). Managed environments retain deterministic enrollment flows that do not rely on consumer OOBE shortcuts. These are the recommended enterprise options.
• Post‑setup conversion. A practical consumer workaround: sign in briefly with an MSA during OOBE (or use a throwaway/minimal MSA), finish setup, then create a local account and remove the Microsoft account. This preserves local control at the expense of a short-lived cloud sign‑in. Note this is a pragmatic compromise, not a pure local‑first flow.

Important caveat: third‑party hacks or ephemeral tricks will continue to appear in the community, but they are likely fragile and subject to rapid patching. Any deployment that relies on such hacks risks sudden failure when Microsoft hardens the installer further.

---

Practical, step‑by‑step guidance​

For home users who want a local account (simplest path)​

• During OOBE, finish the setup with a minimal Microsoft Account (create one if needed).
• After first boot, create a local administrator account via Settings > Accounts > Family & other users > Add account > I don’t have this person’s sign‑in information > Add a user without a Microsoft account.
• Sign into the new local account and remove the Microsoft Account from the original profile if desired.
• Immediately review privacy/telemetry and BitLocker settings; back up recovery keys to a secure location.

This is the least technical approach and minimizes disruption. It does, however, involve a short MSA sign‑in during OOBE.

For refurbishers, small resellers, and labs (recommended)​

• Adopt an unattended/autounattend.xml workflow or image creation pipeline that preseed local accounts and configuration. Test against the latest Insider images before deploying to catch behavior changes. Update documentation and QA scripts.

For enterprises and IT teams​

• Continue using Autopilot, Intune, or MDT/SCCM with preconfiguration to preserve deterministic enrollment. Run pilot deployments against the same Insider channel you plan to evaluate so server‑side toggles in preview builds don’t surprise production testing.

---

How this affects privacy discourse and user choice​

The technical move to remove in‑OOBE local‑account shortcuts is narrow but symbolically significant: defaults matter. Making the account‑first path the enforced default in OOBE will change the day‑one identity state on millions of devices if carried to GA. That shift improves some security and support outcomes but reduces frictionless choice for users who prefer local profiles or limited telemetry.
Historically, consumer outcry and regulatory scrutiny have shaped product adjustments; Microsoft’s messaging emphasizes device readiness and recoverability rather than data collection as the motive. Nonetheless, the tradeoff between supportability and user autonomy is now front and center in conversations about platform defaults. Expect consumer advocacy, tech communities, and perhaps regulators to continue debating this balance.

---

Critical analysis — strengths, blind spots and long‑term implications​

• Strength: this move reduces a class of incorrectly configured devices that skip critical setup steps; for mainstream consumers that’s a net benefit because it lowers helpdesk calls and increases the chance the device is recoverable if lost or reset.
• Blind spot: the change assumes network availability and user willingness to sign into a cloud identity at first boot. That assumption excludes legitimate offline or privacy‑focused scenarios and raises the cost of ownership for refurbishers and technicians who managed large fleets with quick in‑OOBE tricks.
• Product strategy implication: enforcing account‑first defaults deepens Microsoft’s ecosystem lock‑in because many convenience and safety features are gated behind an MSA. That’s a rational product decision from a service integration standpoint, but it tightens the user journey toward Microsoft cloud services by design.
• Regulatory/policy risk: different jurisdictions may view default linking to cloud identities through the lens of consumer protection and competition, especially where platform choice or data sovereignty is a concern. Companies that push defaults have faced inquiries when nudges materially change consumer options; this should be watched.

---

Key takeaways (quick list)​

• Microsoft’s Insider Build 26220.6772 explicitly removes known in‑OOBE mechanisms for creating local accounts; the official note is in the Windows Insider blog.
• The well‑known community shortcuts BYPASSNRO and the ms‑cxh:localonly URI have been neutralized in preview images; hands‑on reporting confirms this behavior.
• Supported alternatives remain: unattended/autounattend.xml installs, image provisioning, and enterprise enrollment (Autopilot/MDM). For casual users, the simplest compromise is a temporary MSA sign‑in followed by creating a local account post‑setup.
• The change prioritizes supportability and recoverability at the cost of ease for privacy‑focused and offline users. Expect continued community testing and possible product adjustments before any final GA rollout.

---

Final assessment and recommendations​

This Insider change is an important product signal: Microsoft intends the consumer OOBE to be account‑first, and it is actively hardening the installer against low‑friction in‑OOBE local‑account bypasses. For most mainstream consumers this will reduce setup confusion and improve device recoverability; for power users, refurbishers, and offline deployments it is a material operational shift that requires updated workflows and tooling.
Actionable recommendations:

• If you manage a few PCs and want a local account: use a minimal Microsoft Account to complete OOBE, then create and move to a local account immediately and secure the machine.
• If you manage many devices or refurbish hardware: move to unattended installs, image‑based provisioning, or enterprise enrollment now; test against Dev/Beta images to catch changes early.
• For privacy‑conscious individuals who cannot tolerate an MSA at any point: consider alternate OS choices for specific devices or be prepared for extra setup complexity and tooling investment.

This change completes a long‑running arc in Windows design: the platform’s defaults are moving toward cloud identity as the baseline. The technical enforcement of that choice is now visible in Insider builds; how broadly Microsoft applies it in production and whether it refinements will follow depends on feedback, testing, and possibly regulatory attention. For administrators and enthusiasts the pragmatic response is straightforward—stop relying on fragile one‑liners and adopt supported provisioning methods that will survive future installer hardening.

---

---

Source: Windows Report Windows 11 test build kills more local‑account hacks — Microsoft account now required

 

[ChatGPT]

Microsoft’s latest Insider preview tightens the screws on Windows 11’s Out‑of‑Box Experience (OOBE), formally removing the familiar consumer shortcuts that let people create local accounts during setup and steering the default install path toward an internet‑connected Microsoft Account (MSA).

Background​

Windows has been nudging users toward an account‑first model for years, and that nudge has steadily hardened into requirements in consumer flows. Microsoft argues that cloud‑backed identity improves device recoverability, BitLocker key escrow, settings sync, and supportability; critics counter that mandating online sign‑in reduces user choice, complicates offline or privacy‑first installs, and raises friction for refurbishers and labs.
The immediate trigger for the current round was the Windows Insider Dev Channel release identified as Build 26220.6772 (KB5065797), whose release notes include two OOBE‑related items: a supported helper to let technicians name the default user folder during setup, and a blunt policy line stating that Microsoft is “removing known mechanisms for creating a local account in the Windows Setup experience (OOBE).” That single sentence is the authoritative, product‑level statement behind the changes now appearing for Insiders.
Multiple independent outlets and community testers reproduced the behavior in recent preview images and documented which shortcuts were affected. Reporting and hands‑on testing are consistent: low‑friction, in‑OOBE tricks that previously produced a local user flow are being neutralized.

---

What changed in Build 26220.6772 (Dev)​

The official change, in plain terms​

• Microsoft added a supported OOBE helper to let technicians set the default profile folder name during setup via a command available in the OOBE command prompt (SetDefaultUserFolder.cmd). The helper accepts up to 16 Unicode characters and strips special characters; it applies only when the MSA sign‑in path is completed.
• Microsoft explicitly declared that it is removing “known mechanisms” that allowed local account creation during OOBE — in practice, the consumer‑facing command tricks and script shortcuts commonly used by enthusiasts and technicians are being ignored, looped, or otherwise neutralized so they no longer produce an offline/local account flow.

The direct effect for most users​

• On default, retail installations using current Dev/Beta preview images now expect an internet connection and an MSA to complete OOBE. Attempts to use the old command‑line shortcuts either do nothing, return you to the Microsoft sign‑in gate, or force OOBE to restart.
• Enterprise provisioning, imaging, and unattended installs (Autopilot, unattend.xml, MDT/SCCM/MDM) remain supported and are not the target of this change. Those programmatic flows can still create local or managed identities before OOBE. Microsoft’s enforcement is focused on consumer, interactive OOBE shortcuts.

---

The bypasses that were targeted — technical anatomy​

To understand the significance of Microsoft’s move, it helps to look at the specific tricks the community used.

BYPASSNRO (oobe\bypassnro)​

• What it was: a well‑known helper/script (often invoked as oobe\bypassnro or BypassNRO.cmd from the OOBE command prompt) that toggled a registry value and reordered OOBE flow so the installer offered a “limited setup / I don’t have internet” branch. That branch exposed a local account creation path.
• How Microsoft neutralized it: Microsoft removed or ignored the script in preview images. Where the script file was previously present in setup media, the latest preview behavior treats the script or equivalent entry points as inert — invoking it either does nothing or restarts OOBE back to the network/account gate.

The ms‑cxh URI trick (start ms-cxh:localonly)​

• What it was: a later, simpler convenience method discovered by the community. In OOBE, press Shift+F10 to open Command Prompt and run:
• start ms-cxh:localonly
  That URI invocation used the Cloud Experience Host (CXH) handler to instantly surface a legacy local‑account creation dialog without rebooting. It quickly became the low‑friction favorite.
• How Microsoft neutralized it: patched preview images neutralize the consumer‑facing handler in the interactive OOBE surface. Running the same command now often returns you to the Microsoft sign‑in gate or otherwise fails to spawn the offline dialog.

Registry toggle (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\BypassNRO)​

• What some users did: when Microsoft removed the script, community researchers demonstrated that the underlying function could be reproduced by setting a registry DWORD named BypassNRO under:
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE
  Setting this value to 1 causes OOBE to present the offline "I don’t have internet" path after a restart. The fix can be applied from Shift+F10 via regedit or via a one‑line reg add command followed by a reboot:
• reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f
• shutdown /r /t 0
  Multiple community guides and independent tests documented this workaround after Microsoft removed the original script.
• What’s important to note: Microsoft removed the script file, not the conceptual flag. The registry technique was widely reported and replicated across independent outlets and community threads; however, that technique is fragile and Microsoft can (and likely will) close that exact loophole in subsequent builds.

Rufus and modified install media​

• What it was: tools like Rufus (and other installer customization utilities) added options to bake a non‑MSA setup path into the install media itself and to skip privacy questions or the MSA requirement by modifying windows install settings within the image or during media creation. Rufus’ 3.19+ betas included explicit UI options to bypass the MSA requirement for consumer installs.
• Why it matters: editing the installation image or crafting unattended/unattend.xml responses is more durable than an in‑OOBE trick, because it changes what the installer will do before the first interactive run. Microsoft’s OOBE enforcement targets in‑session shortcuts, not image‑level provisioning; build‑level changes may not always block a preconfigured install image.

---

What remains possible today (and what’s fragile)​

• Short answer: there are still ways to avoid an MSA during setup, but they are increasingly higher friction and more fragile:
• Set the BypassNRO registry DWORD from an OOBE command prompt, reboot, and continue the offline flow — this has been reproduced by many testers but could be neutralized in subsequent builds.
• Use Rufus or other tools to craft install media that preconfigures an unattended answer file (autounattend.xml) or removes the MSA requirement at image level — a robust, supported technique for IT pros but not a simple interactive trick.
• Enterprise provisioning workflows (Autopilot, MDT, unattend.xml, Intune) remain usable for deterministic local or domain account setups. These are supported options for organizations.
• Why these remaining methods matter: they show Microsoft is explicitly trying to eliminate consumer‑facing, in‑session shortcuts that cause incomplete device setup, not to remove every technical path to create local accounts. That distinction matters in how the move will affect refurbishers, IT pros, and privacy‑minded consumers.

---

Microsoft’s stated rationale — and where the argument is strongest​

Microsoft frames the change as a pragmatic supportability improvement: the ad‑hoc bypasses sometimes skip critical OOBE screens such as BitLocker setup, recovery key backup to your MSA, telemetry/diagnostics opt‑ins, device registration, or other device configuration steps. Enforcing an online MSA sign‑in ensures a more consistent first‑run configuration, which in turn makes devices easier to support and recover. That reasoning is coherent from an operational and SaaS‑integrated perspective: many modern Windows features rely on cloud identity to function as intended.
Strengths in Microsoft’s case:

• Predictability: fewer half‑configured devices leaving OOBE reduces support calls and data loss risk from unbacked recovery keys.
• Feature parity: online sign‑in ensures users immediately benefit from OneDrive, settings sync, Windows Hello recovery, and other cloud services.
• Security and recovery: backing BitLocker recovery keys and enabling account‑tethered recovery workflows can materially help when a device is lost or a user forgets credentials.

---

The trade‑offs and risks (what Microsoft’s rationale misses or underweights)​

• Privacy and local control: forcing MSA sign‑in by default undermines expectations of local‑first operation for privacy‑conscious users. While a user can still convert an MSA account to a local account later, that interim step still creates a cloud‑tethered identity and often results in profile folder names and telemetry defaults tied to that email.
• Offline deployments and accessibility: people who set up machines in air‑gapped environments, low‑connectivity regions, or lab/test benches now face extra steps and complexity. The remove‑the‑shortcuts approach raises operational friction for these scenarios.
• Refurbishers and small technicians: the old one‑line tricks reduced time and complexity for refurbishers who prepare many PCs for resale. The requirement pushes them toward creating and maintaining custom deployment images or temporarily using throwaway MSAs then cleaning them up — both heavier workflows.
• A cat‑and‑mouse dynamic: history shows the community will continue to discover new low‑friction workarounds; Microsoft will patch or neutralize them; the cycle repeats. That dynamic is inefficient and creates ephemeral guidance that quickly goes stale. It also increases the chance that users following published tricks will run into inconsistent behavior across builds.

---

Practical advice for users, technicians, and IT admins​

• For regular consumers: the easiest path is to complete OOBE with a Microsoft Account (temporary or permanent) and then, if desired, create a local account afterward and remove the cloud account. This is the least risky approach for recoverability and feature access.
• For privacy‑minded home users who insist on local accounts:
• Test the current build in a virtual machine or spare hardware before proceeding with real hardware.
• If you prefer to avoid MSA at first boot, prepare a custom image or use Rufus (or similar) to create install media that embeds unattended options — recognize these methods may be affected by future build changes.
• For refurbishers and small labs:
• Move to image‑based provisioning or a scripted unattended workflow that can reliably create local accounts pre‑OOBE.
• Document and sanitize any temporary MSAs used in bulk provisioning to avoid account sprawl and security exposure.
• For enterprise admins:
• Continue to use supported provisioning tooling (Autopilot, MDT, Intune, unattend.xml) for deterministic outcomes. Confirm your workflows in the preview channel if you rely on the latest images being representative of upcoming production behavior.

---

Verification and cross‑checks​

• Microsoft’s own Windows Insider blog entry for Build 26220.6772 is the source of the release notes that explicitly describe both the removal of local‑only commands and the SetDefaultUserFolder helper; that is the primary, authoritative record for what Microsoft claims it shipped in that preview.
• Independent tech outlets including The Verge, Tom’s Hardware, and Windows Central reproduced and reported the neutralization of the BYPASSNRO and ms‑cxh:localonly shortcuts and described the practical effects for consumers and technicians. Those independent tests corroborate the behavior observed by community testers.
• Community documentation and testing (forum threads and how‑to guides) show the registry toggle approach (creating HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\BypassNRO = 1) still worked in the builds immediately after Microsoft removed the script file — but those community guides also emphasize the technique’s fragility and the likelihood that Microsoft will target it in subsequent updates. Treat claims of persistent workarounds as ephemeral unless confirmed across fresh builds.

Cautionary note: any published step that relies on invoking undocumented OOBE internals or registry flags should be treated as a temporary workaround. Microsoft can remove or re‑route those code paths in subsequent preview updates without notice, particularly in the Dev channel where behavior is explicitly experimental.

---

Policy and user‑experience implications​

• This change is product‑level, not merely a security fix: making the consumer OOBE account‑first by default nudges millions of devices toward cloud identity and Microsoft service integration at first run. That is a strategic posture aligning Windows’ user experience with Microsoft’s broader platform goals (security, recovery, telemetry, and service continuity).
• Regulatory and antitrust observers will note the balance Microsoft must strike: tighter integration can improve security and user experience for the many, but it can also reduce meaningful choice for a vocal minority of users. The technical shift — neutralizing consumer workarounds while preserving enterprise provisioning — is a pragmatic compromise, but it doesn’t eliminate the policy debate.

---

Conclusion​

Microsoft’s removal of in‑OOBE local‑account shortcuts in Windows 11 Insider Build 26220.6772 is a clear and deliberate step toward an account‑first OOBE. The change closes the most accessible, consumer‑facing loopholes — the oobe\bypassnro script and the start ms‑cxh:localonly shortcut — and offers a narrow supported concession (SetDefaultUserFolder.cmd) to address a perennial annoyance without restoring offline account creation.
For mainstream users the benefits are tangible: fewer misconfigured devices, better recovery posture, and smoother onboarding into cloud services. For privacy‑conscious users, refurbishers, and those who need offline installs, the cost is increased friction and the need to adopt image‑level or enterprise provisioning workflows. The registry toggle and Rufus‑style media edits remain practical options today, but they are fragile and will likely be the target of future patches if Microsoft judges them to undermine OOBE integrity.
This is not the end of the story but the next chapter in a long‑running cat‑and‑mouse between platform design and power‑user ingenuity: Microsoft will continue to harden interactive OOBE surfaces for predictability and supportability, and the community will continue to adapt with more durable, image‑level techniques when local control is essential.

---

Source: Beebom Microsoft Cracks Down on Local Accounts in Windows 11, But Did It Close All Workarounds?