Healthcare and Life Sciences Blog

8 MIN READ

Windows 365 unified experience (endpoint + cloud pc) desktop-client

Microsoft

Jun 18, 2022

QUICK UPDATE: Windows App is GA, now you can Configure a KIOSK profile for Windows 365 using the new app, follow this technical step-by-step delivered by Shannon Fritz.

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:

Windows 10 Enterprise physical endpoint (e.g., Windows Surface Laptop)
Windows 365 Option 1 or 2 (Entra ID Joined) cloud pc
Windows 365 Microsoft Intune for device management (Intune or Co-Management)
Intune Windows Autopilot
Intune Windows Kiosk Profile
Remote Desktop Client

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 Intune, 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 internet 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 "Entra ID 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

Name	Remote Desktop
AUMID/PATH	C:\Program Files\Remote Desktop\msrdcw.exe
DesktopApplicationId/AUMID for the Win32 app	Microsoft.RemoteDesktop.WPF

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

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

You can add a TXT record to your domain which your user login with (Set up email discovery to subscribe to your RDS feed | Microsoft Docs)
Make sure you use the correct URL for Windows 365 (https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery) It should look like this

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 a 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 Entra ID 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.

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

Thank you for stopping by; Juan Sifuentes | CETS | Healthcare.