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.
Since we're trying to unify the experience (endpoint + cloud pc) using Autopilot + Kiosk, we need to capture the window hashes.
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
Dynamic Device Group validation
(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.
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.
Adding Applications to Kiosk Profile validation
Now you want to add your Remote Desktop Client application as a (Win32 app) to the Kiosk profile.
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.
Name |
Company Portal |
AUMID/PATH |
Microsoft.CompanyPortal_8wekyb3d8bbwe!App |
DesktopApplicationId/AUMID for the Win32 app |
N/A |
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.
You want to assign the Kiosk profile to the dynamic device group (DDG) that contains the windows kiosk device.
Windows Updates Ring validation
It's very important to have an Intune Windows Updates RING policy assigned to the DDG group.
You want the policy to be less interactive with the user, automate the overall windows updates experience.
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.
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 |
Perfect, you can skip now towards (Assignments) and select the Azure AD group that was assigned the Kiosk multi-app profile.
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 want to assign this policy to the user.
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.
Then you want to assign the WHFB policy to the DDG that contains the kiosk device.
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).
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.
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.
Considerations
Here are some technical considerations to keep in mind to allow this experience to flow as projected.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.