Mobile Jon’s Guide to Windows 365 Boot

Mobile Jon’s Guide to Windows 365 Boot

intune, Windows 365
Mobile Jon's Guide to Windows 365 Boot

The time we have been waiting for over the last year is FINALLY here. Windows 365 Boot has arrived in Public Preview. Today, we are going to cover W365 Boot in depth. We will cover the Intune setup portion, checking out what is under the covers, preparing the physical endpoint, and the cherry on top: the user experience demo. We will also show you how a 3rd party MDM like Workspace ONE can do this for the sake of inclusion. Being in Public Preview, nothing is perfect but the finished product is something really enticing. A new spin on a stable of VDI done with elegance is something we can all appreciate.

Setting up Windows 365 Boot in Microsoft Intune

The setup inside of Intune is really easy. Microsoft “surfaced” PUN intended a nice setup wizard for setting up Windows 365 Boot. Additionally, I decided to deploy Insider via Intune, which is honestly overkill. I think it’s good to show options, but overall it’s unnecessary. Let’s check out he demo on setting things up inside of Intune:

Checking out the Intune Setup For Windows 365 Boot Under the Covers

I think when you use a setup wizard it’s natural to want to understand exactly what is happening underneath. Let’s check out the different components that create this amazing experience.

Windows 365 Apps

The setup wizard will deploy a few apps specifically:

Obviously, Windows 365 Boot needs applications to actually work.

The one you might not be familiar with is HostApp. It’s a platform component containing a setup of UIs and APIs that AVD developers use for deploying and managing Remote Desktop connections to AVD resources. The main job of HostApp is providing core functionality to the Windows 365 application. This is widely known as the Hosted App Model, which you can read more about here.

Windows 365 Enrollment Profiles

The setup wizard deploys two enrollment components. The Autopilot Profile and the Enrollment Status Page Profile

The Enrollment Status Page Profile is pretty basic. It blocks device use until the two apps above are installed. The settings can be seen below:

The Autopilot Profile is simple too. Some may want to modify it, but it’s pretty basic:

Windows 365 Configuration Policies

Now, we get into the interesting stuff. We will cover the two configuration policies.

Windows 365 Boot Device Configuration Profile

First, we’ll start with the Windows 365 Boot Device Configuration Profile. This is a settings catalog profile that sets these two items:

I’ve found that these correlate to these two registry entries:

HKLM\Software\Microsoft\PolicyManager\current\device\CloudDesktop
DWORD: BootToCloudMode Value: 1
HKLM\Software\Microsoft\PolicyManager\current\device\WindowsLogon
DWORD: OverrideShellProgram Value: 1

I’ve identified the CSPs these are tied to for those who want to implement this in a different MDM:

The XML code to deploy in other MDMs like Workspace ONE is:

<Replace>
  <CmdID>5a34d566-c95e-4e3a-aff8-0a25f0edc4e6</CmdID>
  <Item>
    <Target>    
 <LocURI>./Device/Vendor/MSFT/Policy/Config/CloudDesktop/BootToCloudMode</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
    </Meta>
    <Data>1</Data>
  </Item>
</Replace>
<Replace>
  <CmdID>1474a0b5-055d-4b26-b54b-5d212e75e902</CmdID>
  <Item>
    <Target>     <LocURI>./Device/Vendor/MSFT/Policy/Config/WindowsLogon/OverrideShellProgram</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>1</Data>
  </Item>
</Replace>

   

Windows 365 Boot Shared PC Device Configuration Policy

We also have the Windows 365 Boot Shared PC Device Configuration Policy. These is made up of a pair of custom settings:

This item also is tied to a CSP. The SharedPC CSP to be specific leveraging these items:

The XML code to deploy in other MDMs like Workspace ONE is:

<Replace>
  <CmdID>c52720e2-b3f1-46ec-aa12-a1e47fe5d813</CmdID>
  <Item>
    <Target>
        <LocURI>./Vendor/MSFT/SharedPC/EnableSharedPCMode</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Replace>
<Replace>
  <CmdID>90cebbf8-2468-43b7-a2f9-a9dd36b8e0b3</CmdID>
  <Item>
    <Target>        
<LocURI>./Vendor/MSFT/SharedPC/EnableWIPFlighting</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Replace>

Windows 365 Update Policy

The update policy is pretty standard. This is also why it’s not all that necessary to deploy your insider preview profile. One weird thing is they don’t set it to insider builds for Dev, since you need that for Windows 365 Boot (I presume this is because when its live you won’t need it):

Preparing the Physical Endpoint for Windows 365 Boot

For Windows 365 Boot, we have specific physical requirements:

  • Device must be on the latest build of Dev Channel
  • Device must be on Autopilot
  • Add the device to AAD group you used to deploy Windows 365 Boot

During my testing, I learned these were implicit requirements because I was getting a ton of “not applicable” issues. I identified the main reason is because the CloudPC, WindowsLogon, and SharedPC CSPs can only be deployed at the device context.

With Autopilot, it deals with any concerns about devices getting deleted and all that sort of stuff. That definitely helps. During OOBE, it will pickup on this behavior and address a ton of this.

Let’s checkout this demo below on upgrading to the latest Insider Build on dev. Keep in mind, it can take over 60m to get that done:

Troubleshooting Physical Device Issues for Windows 365 Boot

Microsoft’s article here was a HUGE help with figuring out Windows 365 Boot. I found the major key was checking for the registry keys that I mention in the previous section. I had issues with a few of the CSPs applying, and added keys manually as a workaround. Luckily, in subsequent attempts I didn’t have any issues whatsoever.

As a FYI, if you want to walk back Windows 365 Boot, you just need to remove the device from your Windows 365 Boot AAD group and you will be able to get back to the local PC.

It was surprising to me that once you flip over to Windows 365 Boot, you can no longer access the local machine. It’s a good thing from a security perspective, but it can be a little bit surprising. Now, let’s finish things up with some user experience demos.

Windows 365 Boot User Experience with Email and Password

In this first demo, you can see the standard experience, which I think is pretty cool. No real complaints from me on how it works beautifully. Check the stopwatch and how we get inside within 90 seconds:

Windows 365 Boot User Experience with Windows Hello PIN Authentication

The second demo, I found to be a bit different, but I think I still prefer username and password. You can use either mode really, but I think password is a better user experience:

Delivering Windows 365 Boot to Workspace ONE

We can also extend Windows 365 Boot to Workspace ONE is a fairly elegant way. Our design is a few parts:

  • A Smart Group that powers the devices that get the Windows 365 Boot Mode. For me, we’re targeting all ARM laptops
  • Custom XML Device Profile to deliver CSPs that enable the Cloud PC capabilities on the device.
  • Windows Update Profile that delivers Windows Insider for Dev Builds

We’ll cover these items quickly as they’re pretty easy to achieve.

The smart group is pretty easy to focus on. You can also scope it to Dev Builds (Current one being 23466):

Our Custom XML profile, which is found on my Github, we deploy pretty easily. The custom XML is:

##Deploy Code##
<Replace>
  <CmdID>5a34d566-c95e-4e3a-aff8-0a25f0edc4e6</CmdID>
  <Item>
    <Target>    
 <LocURI>./Device/Vendor/MSFT/Policy/Config/CloudDesktop/BootToCloudMode</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
    </Meta>
    <Data>1</Data>
  </Item>
</Replace>
<Replace>
  <CmdID>1474a0b5-055d-4b26-b54b-5d212e75e902</CmdID>
  <Item>
    <Target>     <LocURI>./Device/Vendor/MSFT/Policy/Config/WindowsLogon/OverrideShellProgram</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>1</Data>
  </Item>
</Replace>
<Replace>
  <CmdID>c52720e2-b3f1-46ec-aa12-a1e47fe5d813</CmdID>
  <Item>
    <Target>
        <LocURI>./Vendor/MSFT/SharedPC/EnableSharedPCMode</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Replace>
<Replace>
  <CmdID>90cebbf8-2468-43b7-a2f9-a9dd36b8e0b3</CmdID>
  <Item>
    <Target>        
<LocURI>./Vendor/MSFT/SharedPC/EnableWIPFlighting</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Replace>
##Removal Code##
<Delete>
  <CmdID>5a34d566-c95e-4e3a-aff8-0a25f0edc4e6</CmdID>
  <Item>
    <Target>     
<LocURI>./Device/Vendor/MSFT/Policy/Config/CloudPC/CloudPCConfiguration</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>1</Data>
  </Item>
</Delete>
<Delete>
  <CmdID>1474a0b5-055d-4b26-b54b-5d212e75e902</CmdID>
  <Item>
    <Target>     <LocURI>./Device/Vendor/MSFT/Policy/Config/WindowsLogon/OverrideShellProgram</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">int</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>1</Data>
  </Item>
</Delete>
<Delete>
  <CmdID>c52720e2-b3f1-46ec-aa12-a1e47fe5d813</CmdID>
  <Item>
    <Target>
        <LocURI>./Vendor/MSFT/SharedPC/EnableSharedPCMode</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Delete>
<Delete>
  <CmdID>90cebbf8-2468-43b7-a2f9-a9dd36b8e0b3</CmdID>
  <Item>
    <Target>        
<LocURI>./Vendor/MSFT/SharedPC/EnableWindowsInsiderPreviewFlighting</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">bool</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data>True</Data>
  </Item>
</Delete>

Profile can be seen below:

The last part is the Windows Update Profile: (The key is enabling Dev Channel and Preview Builds):

The neat thing is the CSPs actually end up deploying all of the resources we need to make Windows 365 Boot just as magical as it is with Intune.

Final Thoughts

Windows 365 Boot has been a fun experience learning over the weekend. I know many of my fellow MVPs prefer to just do stuff on VMs, but I just love testing/fixing/breaking stuff on a physical endpoint. I love seeing it on a finished product like I did with other things. I continue to believe this is the perfect compliment to my Dell ARM Laptop, which continues to elevate the user experience with the battery and performance of a ARM processor. Check things out and let me know what you think!

Facebook
Twitter
LinkedIn

Categories

Social Media

Get The Latest Updates

Subscribe To Our Weekly Newsletter

No spam, notifications only about the latest posts and updates.