Windows 365 Boot: turn a company laptop into a gateway to the Cloud PC

Platforms

Windows 11

Products

IntuneWindows 365Windows Autopilot

Result

A physical Windows 11 laptop boots directly into the user’s Cloud PC, in shared or dedicated mode

Overview

Turn a company laptop into a simple, locked-down gateway to the user’s Cloud PC. The user switches on the laptop, signs in once and lands straight in Windows 365, with no local desktop to manage or protect.

How Windows 365 Boot works

Many companies already give people a Cloud PC, but users still sign in to a full local Windows first, open the Windows App and only then connect. That means two desktops, two sets of apps to patch and two places where company data can end up.

Windows 365 Boot removes the local desktop from that picture. The PC still runs Windows 11 and is managed by Intune, but the user signs in on the normal Windows sign-in screen and lands straight in their Cloud PC. With single sign-on turned on for the Cloud PC, there is no second sign-in. Signing out of the Cloud PC brings the device back to the sign-in screen.

Boot doesn’t create Cloud PCs; it only changes how the device connects to one. The setup has three building blocks:

• Cloud PC (Windows 365): a provisioned Cloud PC for every user, ideally with single sign-on.
• Boot configuration (Intune): the Windows App and a Cloud Desktop settings profile that switches the device to Boot mode.
• Physical device (Windows Autopilot and Intune): a wiped Windows 11 PC that gets the configuration during Autopilot, plus policies that hide what users don’t need on the local PC.

Shared or dedicated mode

Mode	Typical use	Sign-in methods
Shared	One device, many users: shifts, nurses, call centres	Password, FIDO2 key
Dedicated	One device per user, e.g. a company laptop	Password, Windows Hello, FIDO2 key

Two ways to set it up

• Option A: the guided scenario (wizard) creates all Boot resources in one go, named with one prefix. It fits a new tenant, a POC or a quick start (3.3).
• Option B: manual setup builds only the Boot-specific pieces and reuses your own Autopilot profile, ESP and update rings. It fits a tenant with an existing Autopilot design, naming rules and change control (3.4).

Windows 365 Boot, Link or Windows App?

Microsoft has three ways to reach a Cloud PC from a Windows device. Boot sits in the middle: it reuses PCs you already own, but locks them down only as far as your policies go. Compared on Microsoft Learn:

	Windows 365 Link	Windows 365 Boot	Windows App
Device	Purpose-built device	Any Windows 11 Pro/Enterprise PC	Any Windows PC
Straight to the Cloud PC	Yes	Yes	No
Shared devices	Yes	Yes	Only kiosk + auto logoff
Local apps	None, by design	Blocked, optional way back	Full local desktop
Third-party software	Blocked	Possible	Possible
Join type	Entra joined	Entra or hybrid joined	Also Entra registered
Sign-in methods	Passkey, Authenticator	Also password, smart card, Hello	All
Zoom/Webex plugins, printers	No	Yes	Yes
Licence	Enterprise, Flex or Business	Enterprise	Any edition

Green marks the stronger side, red the weaker one. Boot is a corporate-device scenario: for a personal PC, the Windows App or the web client at windows.cloud.microsoft is the right choice.

Feature status (October 2026)

Status checked in What’s new in Windows 365 and the Boot guides on Microsoft Learn:

Feature	Status	Source	Sec.
Shared PC mode and dedicated mode	GA 02/2024	Learn	3.3
Sign-in screen branding (company name, logo)	GA 02/2024	Learn	3.3
Return to physical PC (Ctrl+Alt+Delete, error screens)	GA 03/2025	Learn	3.6
Self-deploying Autopilot profile	GA	Learn	3.3
Captive portal Wi-Fi (hotel, train)	GA 03/2026	Learn	4

Since March 2026, the Windows 365 Boot wizard is the only guided scenario left in the Intune admin center.

Prerequisites

Before you start, check that you have the following.

Configuration

Agree on the design first, make sure every user has a working Cloud PC, then build the Boot configuration with the wizard or by hand, lock down the physical device and secure the Cloud PC connection.

Step	Console	What you set	Assign to / lands on
3.2	Intune	Provisioning policy with Microsoft Entra join and single sign-on	Boot users Cloud PC
3.3	Intune	Guided scenario: Windows App, Boot profile, Autopilot profile, ESP	Boot device group Laptop
3.3	Intune	Physical device access	IT/support users Laptop
3.4	Intune	Alternative: Windows App and Boot profile by hand	Boot device group Laptop
3.5	Intune	Wipe the device and add it to the Boot device group	Boot device group Laptop
3.6	Intune	Lockdown profile for the physical device	Boot device group Laptop
3.7	Entra	Conditional Access: compliant device	Boot users, Windows 365 + AVD apps
3.7	Intune	Redirection profile for the Cloud PC	Cloud PC device group Cloud PC
–	Intune	Update ring or Autopatch, security baseline	Both groups Laptop Cloud PC

Design decisions before you start

In a lab, a VM stands in for the laptop. In a real rollout the Boot device is a physical laptop enrolled with Windows Autopilot, and it still runs Windows, so it needs the same care as any other corporate device. Decide these points before you open the wizard:

Decision	Options (my pick in bold)	Why
Boot mode	Dedicated or shared PC mode	Dedicated: one user, Windows Hello; shared: kiosks, shifts
Return to the physical PC	Off, or on for a user group	Only for a small IT or support group
Local desktop	Lock it down with a Settings catalog profile	Needed once anyone can return to it
Baseline and updates	Same as other laptops: BitLocker, Defender, LAPS, no local admin, own update rings or Autopatch	Still a corporate laptop, must stay compliant and patched
Access to the Cloud PC	Conditional Access: compliant device	Only managed Boot devices connect
Cloud PC redirection	Block drives and USB storage; keep camera, mouse, keyboard	Data must not leave the Cloud PC session
Assignments to All devices	Exclude Boot devices with a filter, or leave them	Extra apps slow down the ESP
Network before sign-in	Wi-Fi profile assigned to devices, or VPN before sign-in	No network before sign-in means no work
Existing laptops	Wipe and re-enroll with Autopilot	Plan it as a device refresh project

Create the Provisioning Policy

Intune admin center

The guided scenario doesn’t create the provisioning policy, so set it up first. Before you touch the laptop, the user must be able to sign in to their Cloud PC at windows.cloud.microsoft.

In the provisioning policy (Devices > Windows 365 > Provisioning policies):

1. Choose Microsoft Entra Join.
2. Turn on Use Microsoft Entra single sign-on. Without SSO, users sign in twice. Changing SSO later requires the Cloud PCs to be reprovisioned.

On the Image tab pick a current gallery image (in October 2026 the gallery already offers Windows 11 Enterprise + Microsoft 365 Apps 26H2) and assign the policy to the users who get a Boot device. Each of them also needs a Windows 365 Enterprise licence.

If a user has more than one Cloud PC, they choose a default in the web client: on the Cloud PC card open the three-dot menu and select Settings > Integrated experiences, and under Boot to this Cloud PC select Connect while signed in to device.

Run the Windows 365 Boot Guided Scenario (Recommended)

Intune admin center

In the Intune admin center (intune.microsoft.com) go to Devices > Manage Windows 365 Cloud PCs > Cloud PC Overview, scroll down to Windows 365 Guides and select Windows 365 Boot. Read the Introduction tab and select Next.

Basics.

1. Optionally tick Apply device name template and enter a template, for example W365B-%RAND:7% (max 15 characters), so the Boot laptops are easy to tell apart from other devices in Intune.
2. Enter a Resource name prefix (5 to 50 characters), for example W365B, so all created objects are easy to find.

The description is optional and doesn’t accept hyphens. Pick the Boot device mode; I use Dedicated because this laptop belongs to one person. The list below it shows the names the resources will get.

Endpoint updates creates an update ring for the physical devices. The defaults (7 days deferral, active hours 8 AM to 5 PM, 7 days deadline) are fine for a lab. If you use Windows Autopatch, configure it outside the guided scenario. Settings holds the optional VPN and Wi-Fi profile, language, security baseline and the connection timeout (default 5 minutes). I left the security baseline empty because the Boot laptops get the same baseline as the other laptops. Microsoft Learn also lists branding fields (company name, logo, lock screen image) on this tab; in my tenant in October 2026 the tab didn’t show them.

Note on the Wi-Fi and VPN fields. Microsoft Learn says that if you pick an existing Wi-Fi or VPN profile assigned to All users or All devices, the wizard replaces that assignment with the Windows 365 Boot group (Microsoft Learn, step 4). In my lab (October 2026) a Wi-Fi profile assigned to All devices kept that assignment, and the wizard only added the Boot group. To be safe, leave both fields on Select one or pick a profile made only for Boot devices, and check the profile’s assignments after the wizard.

Assignments.

1. Select Create a new group, so the Boot settings reach only Boot devices.
2. Type only the name part, here Devices. The wizard adds the prefix and the word Boot itself, so the group becomes W365B-Devices Boot. If you type W365B-Devices, you get W365B-W365B-Devices Boot.
3. Leave Enable users to access physical device on No. Set it to Yes only for a small user group, such as on-site support or a limited list of admins, and use a group that contains users only.
4. Tick Error screen and/or CTRL-ALT-DEL screen. Error screen gives the group a way out when the Cloud PC can’t be reached; Ctrl+Alt+Delete lets them switch on purpose. I ticked both to test them.

On Review + create check the final group name.

The page talks about a Deploy button, but the button at the bottom is Save. After a moment the wizard shows Deployment succeeded and the resources it created: the Windows 365 app, an enrollment status page profile, an Autopilot profile, a device configuration policy, a Windows Update policy and, if you chose a user group, a physical device access policy. Each name links to the resource, where you can change advanced settings later.

The generated names are long, so I renamed them to my usual pattern (the screenshots still show the original names):

• Device configuration: Windows Settings Catalog - W365 Boot Device Configuration
• Device group: Windows Static Devices - W365 Boot
• User group: Windows 365 Static Users - W365 Boot

Autopilot profile names don’t accept a dash.

This is what the six resources look like after the wizard. Each one is a normal Intune object, so you can open it later from its own blade and change it.

1. Autopilot profile: user-driven, Microsoft Entra joined, standard user account, device name from the template on Basics. It is assigned to the device group.
2. Enrollment status page: blocks the device until the Windows App is installed and installs Windows updates during OOBE, which is why the first start takes a while (4.1). After 60 minutes it shows the error message Windows 365 Boot Setup Failed.

3. Windows App: required for the device group, with the same settings as in the manual setup.
4. Device configuration: the profile that turns the PC into a Boot device, here in dedicated mode with the 5 minute connection timeout.

5. Update ring: the values from the Endpoint updates tab, for the physical devices only. The Cloud PC is updated by its own policies.
6. Physical device access: a user policy for the user group that adds the way back to the physical PC on Ctrl+Alt+Delete and on error screens.

Alternative: set it up manually

Intune admin center

Three resources are enough:

1. Windows App as a Microsoft Store app (new), package identifier 9N1F85V9T8BN, install behavior System, assigned as Required to the device group.
2. A device-targeted Settings catalog profile, category Cloud Desktop, with Boot To Cloud PC Enhanced set to Enable Boot to Cloud Shared PC Mode or Enable Boot to Cloud Dedicated Mode (Cloud only). Optionally Set Max Connection Timeout (5 to 20 minutes).
3. Optional: a user-targeted Settings catalog profile with Enable Physical Device Access On Ctrl Alt Del (User) and/or Enable Physical Device Access On Error Screens (User) set to enabled, assigned to a user group. In my tenant in October 2026 the settings catalog labels both settings (Windows Insiders only).

Autopilot profile, enrollment status page, update rings and Wi-Fi are then your own, as for any other Intune device.

Prepare the physical device

Intune admin center

Windows 365 Boot settings are applied during Autopilot, so the device must start clean:

1. In Intune, open the device under Devices > All devices and select Wipe (leave the boxes in the confirmation unticked).
2. Add the device to the Windows 365 Boot group: Groups > All groups > your group > Members > Add members, search by serial number.

After Autopilot, Devices > All devices lists the physical device next to the user’s Cloud PC.

Lock down the physical device

Intune admin center

Windows 365 Boot doesn’t block everything on the local PC by itself. Microsoft lists extra policies in Restrict user access to Windows 365 Boot physical device. I put four of them in one Settings catalog profile (Windows 10 and later), assigned to the Boot device group.

Profile name: Windows Settings Catalog - W365 Boot Physical Device Lockdown

1. Remove Notifications and Action Center (User): Enabled.
2. Turn off toast notifications (User): Enabled, so local notifications don’t pop up over the Cloud PC.
3. Remove Change Password (User): Enabled.
4. Remove Task Manager (User): Enabled. Task Manager disappears from the Ctrl+Alt+Delete screen and from the taskbar menu on the local desktop.

The profile applies only to the physical device. In the Cloud PC, Task Manager works as usual.

These four settings don’t block apps. PowerShell, Settings and File Explorer still open on the local desktop, so keep the physical device access group small. To block apps as well, Microsoft suggests App Control for Business or AppLocker; the policy must allow the Windows App (MicrosoftCorporationII.Windows365_8wekyb3d8bbwe), or the device can’t connect to the Cloud PC.

Secure the Cloud PC connection

Microsoft Entra admin center

Intune admin center

Conditional Access. In Entra admin center, Protection > Conditional Access, I created a policy for the Boot users that requires a compliant device for the Windows 365 and Azure Virtual Desktop apps. The Boot device was compliant, and the sign-in logs showed the policy as satisfied for the Windows 365 Client connections to Azure Virtual Desktop and Windows 365: test passed. Look for these events on the Non-interactive tab of the sign-in logs; the interactive tab shows only Windows Sign In.

Redirection. A user can open the same Cloud PC from another device with the Windows App, so local drives and USB storage must not reach it. Since 2025 Microsoft turns off clipboard, drive, USB and printer redirection by default on newly provisioned and reprovisioned Cloud PCs; cameras, mice and keyboards keep working (Microsoft Learn). To make it explicit, also for older Cloud PCs, I created a Settings catalog profile and assigned it to a device group with the Cloud PCs, not the Boot laptops.

Under Administrative templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection:

1. Do not allow drive redirection: Enabled.
2. Do not allow supported Plug and Play device redirection: Enabled.

Lab result: after a sync and restart of the Cloud PC, This PC showed only the Cloud PC’s own drives, no laptop drive. Both values are in the registry:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' | Select fDisableCdm, fDisablePNPRedir

fDisableCdm fDisablePNPRedir
----------- ----------------
          1                1

User Experience

This is what the user sees on a new Boot device in dedicated mode, recorded in my lab. Long waits are cut down to a few seconds.

First start: Autopilot and first sign-in

For the physical device this is a standard user-driven Windows Autopilot deployment. It looks the same as on any other Windows laptop. The only differences are what Intune adds for Boot:

• Windows App: connects the device to the Cloud PC
• Device configuration profile: switches the device to Boot mode
• Lockdown profile: locks down the physical device

The user signs in once during OOBE and approves MFA, and the enrollment status page sets up the device. After the restart, the sign-in screen already says Sign in to connect to your Cloud PC. On the first sign-in the device runs the account setup part of the enrollment status page and asks the user to set up a Windows Hello for Business PIN.

Connecting to the Cloud PC

Right after the PIN, the device connects to the Cloud PC. On the first connection the user approves MFA once more and confirms Allow remote desktop connection?. A new Cloud PC then runs its own enrollment status page before the desktop appears. When the user disconnects from the Start menu, the device goes back to the Windows sign-in screen with the user’s tile. After the PIN, Welcome <name>! Connecting to your Cloud PC appears, and the desktop is back in about 15 seconds.

In shared mode, signing out of the Cloud PC returns the device to an empty sign-in screen for the next user.

Useful things to show users:

• Ctrl+Windows+Up opens the Connection Center (switch Cloud PC, restart, troubleshoot). Ctrl+Windows+Down shows the connection details.
• Wi-Fi with a captive portal (hotel, train) is supported: an error dialog offers Open network settings, and the user signs in to the portal in a browser. The device must have connected to a normal network once before.
• Bluetooth devices are paired from Quick Settings > Bluetooth, and the taskbar of the Cloud PC shows the laptop’s battery level.

Back to the physical PC

This is a fallback, not daily use: Microsoft names internet or service outages, when the Cloud PC can’t be reached. The button on error screens fits regular users, because it only shows when the connection fails. The Ctrl+Alt+Delete button is always there, so keep it for an IT or support group.

For users in the physical device access group, Ctrl+Alt+Delete in the Cloud PC adds Sign in to physical device. Microsoft Learn calls the button Return to physical PC sign in; in my lab in October 2026 it had the shorter label. The device shows Sign in again to access physical device, goes back to the Windows sign-in screen, and after the PIN the user is on the full local desktop. That is why the lockdown in 3.6 matters for everyone in this group.

To get back to the Cloud PC, the user signs out of the physical PC: Start > account icon > Sign out. After “Returning to sign-in” and the PIN, Windows connects straight to the Cloud PC. Lock is not enough: after the PIN the user lands back on the local desktop.

Troubleshooting

If the user doesn’t reach the Cloud PC

First test the same user in the web client at windows.cloud.microsoft. If that works, the problem is on the physical device. Check the app versions in an elevated PowerShell session:

Get-AppxPackage -AllUsers -Name *MicrosoftCorporationII*

You need Windows App 2.0.285 or later and Azure Virtual Desktop (HostApp) 1.2.4159 or later. Windows App is listed as MicrosoftCorporationII.Windows365; in my lab it was version 2.0.1484.0. A standard user gets “Access is denied” for -AllUsers; without that switch the command shows only the apps of the signed-in user.

Then check these registry values:

In shared mode you also see these values. In dedicated mode this key doesn’t exist.

If the values are missing, open the device configuration profile with your prefix and check Device assignment status. A Sync from the device page in Intune and a restart often fix a slow first deployment.

If the device has no network

In my lab I disconnected the device from the network. The PIN sign-in still worked, but after Signing in the device showed Connection failed due to a network issue and returned to the sign-in screen after 30 seconds. My test user is in the physical device access group, so the screen also offered Sign in to physical device, and on the local desktop Settings showed Not connected. Give Boot devices a Wi-Fi profile that connects before sign-in (3.1).

Logs and other known issues

• For Microsoft support, zip the logs from these two folders:
  • %LOCALAPPDATA%\Temp\DiagOutputDir\Windows365\Logs
  • %LOCALAPPDATA%\Temp\DiagOutputDir\RdClientAutoTrace
• Note the Session ID from the Something went wrong error or the Correlation ID from the 5-minute timeout screen.
• After you remove a device from the Boot device group, Intune takes up to 8 hours to remove the Boot policies.
• Users can’t reset their password on a Boot device; they need another device for that.
• Unexpected sign-outs after idle time come from screen lock policies. Set the same Max Inactivity Time Device Lock on the physical device and the Cloud PC.

Summary

Windows 365 Boot is the cleanest way to make a laptop “just a door” to the Cloud PC. The guided scenario does most of the work, but the result depends on what you do around it: single sign-on in the provisioning policy, a clean Autopilot start, a short list of apps on the physical device and a few lockdown policies.

Sources

• What is Windows 365 Boot?
• Guided scenario: deploy Windows 365 Boot
• Physical device setup and requirements
• Restrict user access to the physical device
• Troubleshoot Windows 365 Boot
• Windows 365 Boot known issues