Windows 365 unified experience (endpoint + cloud pc) desktop-client
Published Jun 17 2022 11:16 PM 4,221 Views

Learn how to unify Windows 365 experience (endpoint + cloud PC) to make it feel like a one-device.


Now we’re ramping up on advanced scenarios, remember to loop back to the main deck for Windows 365 Cloud PC Healthcare Series


This is an in-depth technical guidance focused on deliver a "unified personalized experience"; if you're looking for the high-level-business overview associated with this document, we show you How we solved the use case for “Windows 365 Personalized experience for mobile clinicians”.


Let’s dive in!




These are some basic requirements you’ll need to achieve this unified experience:



Technical Planning

We’re going to try to break-down the implementation, as it’s a bit combined between the experience and the deployment, there is an area of validation that you don’t want to miss (I will consider that your FIRST part of the puzzle). There’s a lot of work that was already pre-built in the lab, therefore I can’t really go and start from scratch. I will suggest reading the whole document and understanding the areas of involvement that need to be prioritized and based on your environment inject the content as applicable.


The user experience area is tied to OOBE, Windows login and Windows 365 Cloud PC, while the validation area will fall directly to Windows Autopilot, Microsoft Endpoint Manager, Remote Desktop Client, and Kiosk profile.


OOBE (User Experience area) part 1

When you boot into OOBE, you need the device connected to the network (wired or Wi-Fi) to load the windows hashes online to Autopilot.


  • My device is already wired connected to the network (laptop); I can hit (Shift + F10) from here
  • Otherwise, if needs Wi-Fi connection you'll have to continue to (Network) and start from there



Since we're trying to unify the experience (endpoint + cloud pc) using Autopilot + Kiosk, we need to capture the window hashes.


  • Make sure you tag your device in my case I'm using "UserDriven"






PowerShell.exe -ExecutionPolicy Bypass
Install-Script -name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Get-WindowsAutopilotInfo -Online -GroupTag UserDriven







The device will be scoped automatically with a dynamic device group (DDG), based on rule membership for (GroupTag) that equals to "UserDriven".



Now is time to validate your work…

DO NO CONTINUE in OOBE until you cover the VALIDATION area.


Validation area (most important!)


Windows Hashes validation

  • Validate the windows hashes were uploaded to Autopilot, the Profile Status will show as "Not Assigned" temporarily



Dynamic Device Group validation

  • Validate the device was captured by the dynamic device group (DDG)
  • I have already created one "KIOSK Dev (User-Driven) Devices"



  • You'll need a dynamic membership rule for the DDG, that will automatically capture the Autopilot devices tagged with "UserDriven"
  • I have already created my rule (DDG membership rule):






(device.devicePhysicalIds -any _ -eq "[OrderID]:UserDriven")









Windows Autopilot validation

You want your Autopilot profile (Deployment mode) set to "User-Driven" and (Convert all targeted devices to Autopilot) set to "Yes", this will automatically associate the hash with the Autopilot profile.


  • I have already created my Autopilot profile "ADJAutopilot_UserDriven ADJ_KDevU"
  • You want to assign the Autopilot profile to the DDG group
  • I have already assigned mine to my device group "KIOSK Dev (User-Driven) Devices"



  • Now we see the (Profile Status) has changed to "Assigned" for the windows hash and the device has been associated with Autopilot profile… everything automatically!



Kiosk Profile validation

BEFORE we go back to OOBE, we want to build our Kiosk Profile for the Autopilot device to unify the experience between the endpoint + Cloud PC.



  • I have already created my Kiosk device configuration profile "Win10 - KioskDev DesktopClient (Remote Desktop Client)"



  • You want for (Select a kiosk mode) the option "Multi app kiosk" as is needed for (Remote Desktop Client) application, it won't work with a Single-app kiosk
  • Then select for (User logon type) the option for an "Azure AD user or group"
  • Then add the user or group that will be assigned the Kiosk profile
  • I have already assigned it to "Autopilot Users"



Adding Applications to Kiosk Profile validation

Now you want to add your Remote Desktop Client application as a (Win32 app) to the Kiosk profile.


  • I have already configured my RDC application, copy as-is


Remote Desktop


C:\Program Files\Remote Desktop\msrdcw.exe

DesktopApplicationId/AUMID for the Win32 app






OPTIONAL: you can add more Kiosk apps to the Kiosk profile.


  • I have added by AUMID the Company Portal (useful to force a device Sync)
  • IMPORTANT: you will also need to deploy the Company Portal app from Intune


Company Portal



DesktopApplicationId/AUMID for the Win32 app



  • I have also added by AUMID the Settings (helpful to see the device properties)





DesktopApplicationId/AUMID for the Win32 app




You can have more options configured for the Kiosk profile.


  • In my case I want to lock-down the experience for the user to secure the endpoint.



You want to assign the Kiosk profile to the dynamic device group (DDG) that contains the windows kiosk device.


  • I already have mine assigned to "KIOSK Dev (User-Driven) Devices"



Windows Updates Ring validation

It's very important to have an Intune Windows Updates RING policy assigned to the DDG group.


  • IMPORTANT: Kiosk multi-app profile is not supported on Windows 11
  • I have mine created as "Win10 - SemiAnual (REGULAR) CPC(HDJ)/Kiosk/KDev(U-D)"



You want the policy to be less interactive with the user, automate the overall windows updates experience.


  • Make sure you block Upgrade to Windows 11
  • Make sure you select the General Availability channel (not any pre-release builds that will include Windows 11)





Remote Desktop Client validation

We need to target the windows application (Remote Desktop Client) to be deployed with Intune as a Win32 app converted via IntuneWimFile.



  • The configuration is targeted to the user, also make sure you choose (Device restart behavior) to be "Determine behavior based on return codes"
  • This is my configuration for the user:

Install command

msiexec /i "RemoteDesktop_1.2.3004.0_x64.msi" /qn ALLUSERS=2 MSIINSTALLPERUSER=1

Uninstall command

msiexec /x "{4F1C5D10-F012-4039-89CF-2F4830A991AA}" /qn




  • You’ll need to set your application OS requirements.



  • You need to set your Detection Rules, since we're using an MSI file you can pick that option automatically.



Perfect, you can skip now towards (Assignments) and select the Azure AD group that was assigned the Kiosk multi-app profile.


  • I have mine assigned to "Autopilot Users"



Automatic Cloud PC resource discovery validation

Also, you want to automate the Remote Desktop App Cloud PC resource discovery using the email address instead of typing the URL (much easier for the user).


You can achieve this in two ways:


1. TXT Record



2. Settings Catalog

  • You can also target via Settings Catalog to push the policy to the user
  • I have already created a Settings Catalog policy "Win10 - Remote Desktop Client Subscription Discovery"







You want to assign this policy to the user.


  • In my case it’s assigned to the same (user group) we associated with the Kiosk policy "Autopilot Users"



Windows Hello for Business validation

Windows Hello! Why not? This is a personalized experience for the user, to make and feel as a single-device (not multiple authentications) and pass the token to the cloud pc.


  • You can target Windows Hello for Business policy with Intune to enable authentication features (e.g., PIN, Face, Security FIDO keys)
  • I have already created a WHFB policy "Win10 - WHFB Enable PIN (ADJ, KDevU)"





Then you want to assign the WHFB policy to the DDG that contains the kiosk device.


  • I have mine assigned to "KIOSK Dev (User-Driven) Devices"



You're DONE! You have validated your work and now it is time to go back to OOBE and finalize the unified experience.


OOBE (User Experience area) part 2

NOW we're ready to move forward with the OOBE prompts.





Once you hit Network, OOBE will find online an Autopilot profile assigned to the windows hash.



The device will automatically restart.



The device will then attempt to review the account (user) associated with the device.



Since we don't have a user assigned to the device, the user will be prompted to authenticate.





After the user authentication, the device will begin to initiate registration and enrollment to the organization.



Once enrolled it will start to pick up all Intune policies (Kiosk profile, Windows Updates Ring policy, WHFB profile, Remote Desktop application).


  • This process can take some time to complete, you want to wait for OOBE to finish [DO NOT click on Continue Anyway]



We can see the device is now being evaluated and enrolled in the organization.



Eventually the device will automatically restart and prompt the user to select their settings.



And finally complete the OOBE process, presenting the user with Windows Login experience.


  • BUT wait! You don't want to login just yet; you want to wait for all policies to apply (specially the Kiosk profile and the Remote Desktop app)





The RDC app is targeted to the user level "Autopilot Users", so it will only trigger the install once the user authenticates.



Now we can have the user (who is a member of group "Autopilot Users") login to the device.



Once authenticated, the Remote Desktop Application will begin to install.





Now Windows Hello profile is kicking into setup Face recognition and PIN.





Final User Experience

That’s it, this is the final part of the user experience. Here’s the captured unified experience (endpoint + cloud pc) when the user login with his Azure AD credentials against a managed Windows Surface endpoint (Intune) using FIDO security key fingerprint authentication, then the token is used against the Remote Desktop application to authenticate against the Cloud PC resource (no password is used) and finally login to his Windows 365 ecosystem.

















Here are some technical considerations to keep in mind to allow this experience to flow as projected.


  • Make sure you're not targeting the user with MFA to login to the endpoint as it may fail the Kiosk profile to load up (exclude Kiosk users from MFA policy)
  • Make sure you’re excluding the user from any Conditional Access policy you have in the organization
  • Don't deploy Edge browser (it conflicts with Kiosk profile)


Some helpful troubleshooting documents:



Well, I hope you had fun going through this amazing journey! It’s always challenging to try to solve a business use case, keep in mind that the future of Windows 365 #BootToCloud will be somewhat similar or better yet, a much seamless unified experience (endpoint + cloud pc), but in the meantime you have a technical layout to help you solve this today!



Bookmark this link for Windows 365 Cloud PC Series:

Thanks for visiting – Juan Sifuentes LinkedIn


Version history
Last update:
‎Jun 21 2022 02:25 PM
Updated by: