Once every now and then you get one of those weird and maybe a bad ideas and ask yourself:
“What if I have a Windows 10 computer which cannot run Windows 11, but I really want to run Windows 11 on it in a supported way?“
That was what I asked myself when realizing my old Surface Laptop (first generation) does not support Windows 11.
Putting this in maybe a more real-life like scenario “we have some old hardware and Windows 365. We want to keep using the hardware for a few more years but run Windows 11” or something like that.
This gave me an idea. Can we create a kiosk that runs the Windows 365 app only on a managed Windows 10 computer? And to make it more special, let’s make it as a shared device so that I get MY Cloud PC and you get YOUR Cloud PC! 😊
Since Windows 365 Boot is not coming to Windows 10, we need another solution. This solution could be using kiosk mode and shared mode for Windows.
Pre-reqs
What do we need for this to work?
- Intune managed Windows 10 computer
- Computer registered for Windows Autopilot
- Self-deploying deployment profile for Windows Autopilot
- Shared device policy
- Windows 365 license of some sort
- All other licenses required to use Intune
- The Remote Desktop application installed on a device
- An Azure AD group containing out kiosk PCs
And that is about it.
My thought is to use the old school ShellLauncher method for this, not the fancy assigned app setup since we can make this more dynamic if we want to re-purpose this for another application. This means that we could also use Win32 applications and not only UWP apps.
Using the ShellLauncher method in Intune has gotten really easy, it’s just one custom policy and we are set.
Creating the ShellLauncher script
When looking around for a good source, and inspiration, for this setup I came across this post by Michael Niehaus which is really good and even provides a sample script we can use (why re-invent the wheel?).
Using the script example in the blog above, I came up with this script which you can download from my Github repo.
Basically, what you need to update, is the <Shell> section of this part to the path for your application (Win32) or the AUMID (UWP). In this case, the Windows 365 app for Windows 10 which is a UWP app (as stated in the V2:AppType attribute).
If the remote desktop session is closed, the application will restart.
Creating the ShellLauncher policy
For this, we need to create a custom policy in Intune.
First step is to go to Intune (https://endpoint.microsoft.com) and navigate to Devices > Windows > Configuration profiles and select “+ Create profile“. Select Windows 10 and later as platform, Template as profile type and then the Custom template.
Next, we will give our profile a good name so that we know what the profile does. This should be based on your name standard and naming convention for policies. Then hit next at the bottom of the window.
On the “Configuration settings” tab, select “Add” and give the configuration a name (e.g., ShellLauncher V2). As OMA-URI, enter:
./Device/Vendor/MSFT/AssignedAccess/ShellLauncher As data type, select “String (XML file)” and upload your XML file. When this is completed, press Save at the bottom of the screen.
You will now see that your setting has been added as a row to this configuration setting and you can press Next at the bottom of the screen.
On the Assignment tab, select the group where you have put you targeted kiosk devices and press Next at the bottom of the screen.
You can skip the “Applicability rules” tab and jump straight to the “Review + create” tab to view a summary of your configuration.
Once you have reviewed your settings, you can press Create and your profile will be created.
Shared device policy
The other profile we need to create is a profile for Shared device. This is done by going to Devices > Windows > Configuration profiles and select “+ Create profile“. Select “Windows 10 and later” as platform, “Templates” as Profile type and find and select “Shared multi-user device” and click create.
Give your profile a name, I will call mine “Win365 Shared Kiosk“. When you have given your profile a name, press next.
On the Configuration settings tab, enable the Shared PC mode and add the settings you need based on your requirements. I will use Domain as Guest account type to ensure that only users from my organization will be allowed to sign in. I will also add some additional settings as you can see from the screen. When you have added your settings, hit next.
Assign your policy to the group you created and used for the ShellLauncher policy and press next.
On the last step, review your settings and click create!
Self-deploying enrollment profile
To have this as a zero-touch installation, which would require zero input from an IT person, we can use the self-deploying deployment profile in Windows Autopilot, which means that we need to create a new profile.
In Intune, head to Devices > Windows > Windows Enrollment > Deployment profiles and select “+ Create profile” and select Windows PC.
First step is as always to give you profile a name, I will call mine “Self deployed Kiosk” and then press next.
On the next tab, select “Self-Deploying (preview)” as Deployment mode. You will then see that almost all fields are grayed out. You can leave all values as default, or choose to change the Language, if keyboard should be automatically configured and if a name template should be used.
Notice: If you are to use this on a virtual machine, you will need to use the user-driver deployment mode since self-deploying requires physical hardware.
For this demo, I will leave everything set to default and press next.
The next step is to set assignments, we will select the Azure AD group we created for the policy for this, but you could also use another group. The important part is that the device is in this group.
Press next and you will end up on the review + create tab where you can review your settings before pressing create.
Once the profile is created, it will take around 15 minutes or so for the enrollment profile to be applied to your device, given that it’s not already included in another active assignment. If that is the case, you need to either add an exclusion group or remove it from the other group before the profile will be assigned.
If you navigate to Devices > Windows > Windows Enrollment > Devices you can look at your device and make sure the correct enrollment profile is assigned.
Deploying our kiosk
This is where the fun begins. Let’s deploy our kiosk to our device!
My device needed to be reset, since it’s already managed by Intune, I can simply just use the wipe command and the device will reset. Since I’ve already added it to the target group for my deployment profile, the enrollment will kick off automatically once the device has been reset. However, if you are connecting using Wi-Fi, you will need to select region, keyboard and Wi-Fi network.
Once the Windows Autopilot enrollment process has completed, my Windows 365 kiosk device is ready, and I can now only run the Windows 365 app on my device.
NOTICE!
There is a big flaw in this design at the moment, and that is the fact that we cannot deploy the W365 application during the ESP at this stage, this means that we need to ensure that the application is installed BEFORE we apply the kiosk profile. If and when we can install the application from the “new store” during ESP, this will not be an issue.
This means that we currently need to wait until the W365 app has been deployed before we assign our kiosk profile.
Additional reading:
Awesome post by a fellow W365 MVP Dominiek: Windows 11 Kiosk With The Windows 365 App – techlab.blog
Post by Michael Niehaus how to create a kiosk using ShellLauncher: Creating a kiosk or digital sign using Windows Autopilot, Intune, and Edge (Chromium) – Out of Office Hours (oofhours.com)
Leave a Reply