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

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!

 

 

Requirements

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

Juan_Sifuentes_59-1655530875885.png

 

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".

Juan_Sifuentes_60-1655530875922.png

 

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

Juan_Sifuentes_61-1655530875926.png

 

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"

Juan_Sifuentes_62-1655530875928.png

 

  • 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")

 

 

 

 

 

 

Juan_Sifuentes_63-1655530875930.png

 

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"

Juan_Sifuentes_64-1655530875933.png

 

  • 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!

Juan_Sifuentes_65-1655530875936.png

 

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.

Juan_Sifuentes_66-1655530875943.png

 

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

Juan_Sifuentes_67-1655530875944.png

 

  • 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"

Juan_Sifuentes_68-1655530875947.png

 

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

Name

Remote Desktop

AUMID/PATH

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

DesktopApplicationId/AUMID for the Win32 app

Microsoft.RemoteDesktop.WPF

Juan_Sifuentes_69-1655530875948.png

 

Juan_Sifuentes_70-1655530875949.png

 

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

Name

Company Portal

AUMID/PATH

Microsoft.CompanyPortal_8wekyb3d8bbwe!App

DesktopApplicationId/AUMID for the Win32 app

N/A

 

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

Name

Settings

AUMID/PATH

windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel

DesktopApplicationId/AUMID for the Win32 app

N/A

Juan_Sifuentes_71-1655530875951.png

 

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.

Juan_Sifuentes_72-1655530875953.png

 

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"

Juan_Sifuentes_73-1655530875956.png

 

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)"

Juan_Sifuentes_74-1655530875958.png

 

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)

Juan_Sifuentes_75-1655530875960.png

 

Juan_Sifuentes_76-1655530875962.png

 

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.

Juan_Sifuentes_77-1655530875965.png

 

  • 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

 

Juan_Sifuentes_78-1655530875967.png

 

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

Juan_Sifuentes_79-1655530875969.png

 

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

Juan_Sifuentes_80-1655530875972.png

 

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"

Juan_Sifuentes_81-1655530875975.png

 

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

Juan_Sifuentes_82-1655530875976.png

 

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"

Juan_Sifuentes_83-1655530876004.png

 

Juan_Sifuentes_84-1655530876010.png

 

Juan_Sifuentes_85-1655530876016.png

 

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"

Juan_Sifuentes_86-1655530876020.png

 

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)"

Juan_Sifuentes_87-1655530876022.png

 

Juan_Sifuentes_88-1655530876026.png

 

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"

Juan_Sifuentes_89-1655530876028.png

 

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.

Juan_Sifuentes_90-1655532168918.png

 

Juan_Sifuentes_91-1655532168927.png

 

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

Juan_Sifuentes_92-1655532168930.png

 

The device will automatically restart.

Juan_Sifuentes_93-1655532168935.png

 

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

Juan_Sifuentes_94-1655532168937.png

 

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

Juan_Sifuentes_95-1655532168946.png

 

Juan_Sifuentes_96-1655532168954.png

 

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

Juan_Sifuentes_97-1655532168965.png

 

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]

Juan_Sifuentes_98-1655532168979.png

 

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

Juan_Sifuentes_99-1655532168984.png

 

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

Juan_Sifuentes_100-1655532169023.png

 

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)

Juan_Sifuentes_101-1655532169053.jpeg

 

Juan_Sifuentes_102-1655532169058.png

 

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

Juan_Sifuentes_103-1655532169065.png

 

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

Juan_Sifuentes_104-1655532169089.jpeg

 

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

Juan_Sifuentes_105-1655532169102.png

 

Juan_Sifuentes_106-1655532169111.png

 

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

Juan_Sifuentes_107-1655532169128.png

 

Juan_Sifuentes_108-1655532169131.png

 

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.

 

Juan_Sifuentes_109-1655532413532.jpeg

 

Juan_Sifuentes_110-1655532413534.jpeg

 

Juan_Sifuentes_111-1655532413536.jpeg

 

Juan_Sifuentes_112-1655532413538.jpeg

 

Juan_Sifuentes_113-1655532413540.jpeg

 

Juan_Sifuentes_114-1655532413541.jpeg

 

Juan_Sifuentes_115-1655532413545.jpeg

 

Considerations

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: https://aka.ms/HLSWindows365

Thanks for visiting – Juan Sifuentes LinkedIn

 

3 Comments
Co-Authors
Version history
Last update:
‎Jun 21 2022 02:25 PM
Updated by: