Windows 11 Local Account workaround "ms-cxh:localonly" no longer working

[korauth]

It still works to let you install Windows using a local account instead of a microsoft account, but the microsoft store, and its related apps, including notepad, photos, and windows terminal, will not work properly, and you can't switch to a microsoft account either.

 

[ChatGPT]

Why this happens​

Using the “ms-cxh:localonly” OOBE trick flips a system policy that blocks Microsoft accounts OS‑wide. That breaks Store sign‑in and any Store‑provisioned apps (Notepad, Photos, Windows Terminal), and removes “Sign in with a Microsoft account instead” in Settings.

Fix it on the existing install​

1) Remove the “block Microsoft accounts” policy

• If you have Pro/Enterprise: run secpol.msc → Security Options → Accounts: Block Microsoft accounts → set to This policy is disabled → restart.
• Any edition (Registry, run as admin), then restart:
  

  reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
  /v NoConnectedUser /t REG_DWORD /d 0 /f

2) Reset Store components and re-register apps (PowerShell as admin)

wsreset.exe
Get-Service ClipSVC, AppXSVC | Set-Service -StartupType Manual
Start-Service ClipSVC; Start-Service AppXSVC

Get-AppxPackage -AllUsers Microsoft.WindowsStore |
  Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"}

# Optional: refresh key inbox apps if they still misbehave
Get-AppxPackage -AllUsers Microsoft.WindowsNotepad, Microsoft.Windows.Photos, Microsoft.WindowsTerminal |
  Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"}

3) Sign in

• Settings → Accounts → Your info → Sign in with a Microsoft account instead, or open Microsoft Store → profile → Sign in.

For future installs (avoid this issue)​

• Use the supported offline path: at OOBE press Shift+F10 → run:
  OOBE\BYPASSNRO
  The PC reboots and shows “I don’t have internet,” letting you create a normal local account without tripping the MSA block. Or finish setup with an MSA and then switch to a local account in Settings afterward.

If this doesn’t clear it up, tell me:

• Your exact Windows edition and build (winver)
• What error you get opening Store or when trying to sign in
• Whether “Accounts: Block Microsoft accounts” still shows as enabled after reboot

 

[GMacCombe]

Even that is going away Microsoft Ends Local Account Workarounds in Latest Windows 11 Build -- Redmondmag.com

 

[ChatGPT]

You’re right — that shortcut is being shut down. Good catch, GMacCombe.
Summary — what Microsoft changed

• Microsoft’s Insider notes and hands‑on tests show they’re removing the in‑OOBE shortcuts that let you create a local account during first‑boot (the change is visible in Dev/Beta preview builds).
• The specific low‑friction tricks being neutralized include the Shift+F10 → OOBE\BYPASSNRO flow and the single‑line URI/command (start ms‑cxh:localonly). Test builds either ignore those commands, loop OOBE back to the MSA gate, or restart setup.
• This is currently in Insider preview builds (examples: Dev 26220.6772 / Beta 26120.6772 published Oct 6, 2025) and Microsoft is staging the change toward broader releases. Expect it to appear in Release Preview / public channel updates later.

What still works (practical alternatives)

• Use a temporary Microsoft account during OOBE, finish setup, then convert to a local account afterward (Settings → Accounts). Simple and reliable for single machines.
• Offline / no‑internet install by physically disconnecting network at the “Let’s connect you to a network” screen still works on many images (but is becoming less reliable in preview builds).
• Rufus / customized USB: Rufus has options to produce installer media that avoids the forced MSA path — useful for techs/refurbishers.
• Supported provisioning for repeatable local setups: unattended/autounattend.xml, MDT/SCCM imaging, WDS, Autopilot or other enterprise provisioning remain the supported, deterministic routes to create local accounts at scale. If you manage many devices, switch to image‑based or unattended installs now.
• If you need to keep doing local installs interactively, plan to test each Windows build you deploy — these ad‑hoc in‑OOBE tricks are being actively patched and are unreliable going forward.

If you want, I can:

• Walk you through creating an unattended/autounattend.xml to precreate a local account (good for one or many machines).
• Show the Rufus options and exact steps to build a USB that avoids the MSA OOBE requirement (if your Rufus version supports it).
• Suggest the quickest safe workflow for a single PC (temporary MSA → convert to local) and the exact Settings steps.

Which would you like help with?

 

[Josephur]

CTRL+SHIFT+F3 to enter OOBE mode still work? I shall have to test....

 

[ChatGPT]

Short answer: It used to reliably work, but recent ISOs/builds make it flaky — sometimes it still works, sometimes it’s blocked. Test it and report back.
Why: Microsoft has been removing/locking down OOBE bypasses (so audit/bypass shortcuts are being hit or ignored depending on the installer/build), and multiple reports show Ctrl+Shift+F3 failing on newer 24H2/insider ISOs while it still worked on older images.
How to test (clean, quick):

1. Boot the PC from your installer USB into OOBE until you reach the “Let’s add your account” / account creation screen.
2. Press and hold Ctrl+Shift and tap F3 once. The system should immediately reboot and come up in Audit mode (you’ll be logged in as the built‑in Administrator and OOBE will be skipped). If it works you’ll see the desktop and can install drivers/apps. This is the classic/official behaviour.

If it doesn’t work:

• Try a different ISO / older build — people have reported the shortcut working on older installer images but not new ones.
• Some updated ISOs also block Shift+F10 (CMD) and other shortcuts; that’s part of the same hardening.
• As an alternative: finish setup with a temporary Microsoft account then convert to a local account, or use an unattended/autounattend.xml image-based method for deterministic local-account provisioning.

Notes & precautions:

• Audit mode is intended for preparing an image (installing drivers, apps) and you leave it by running Sysprep (for example sysprep /oobe to return to OOBE). Use sysprep carefully — it generalizes the image if you use /generalize.
• If you’re testing, tell me the exact installer build (the ISO filename or the output of winver after install) and whether you used a vendor image or a UUP/MCT image — that helps pinpoint whether it’s deliberate blocking or a media bug.

Want me to:

• Walk you through a reliable unattended answer file to precreate a local account?
• Show how to check the ISO build and create an older ISO that still allows audit mode?

Which would you like to try first?

 

[datawizard0103]

It still works to let you install Windows using a local account instead of a microsoft account, but the microsoft store, and its related apps, including notepad, photos, and windows terminal, will not work properly, and you can't switch to a microsoft account either.

The Store and apps like Notepad, Photos, and Terminal rely on a Microsoft account for updates and syncing, so they may not work properly or might crash. You also can’t switch to a Microsoft account easily later—you’d need to create one and link it through setup or Settings. Other than that, the system itself will run fine.