Explore Yubico

Hacking Windows kiosk mode – Single Intune config for multiple devices needing unique URL’s, with self-provisioning autopilot.

Posted on by Geir Dybbugt

Overview

This writeup is for a deployment I did a good while back, and revolves around using Microsoft Intune to deploy windows kiosk mode devices that will be used as “Booking” screens for a larger amount of meeting rooms. A solution where you can simplify the deployment and amount of config is the goal.

The booking displays is mounted on the outside of each meeting room, and shows the availability an upcoming bookings for each meeting room.
Microsoft Surface Go devices were used as the booking panels.

In this scenario the devices where deployed via Windows autopilot as self provisioning kiosk devices, meaning a minimum amount of user interaction is needed to deploy the devices. For the Kiosk mode, the “Single App, full-screen kiosk” was used, and Microsoft Edge web browser the application type.

The “Kiosk mode type” used was Digital/interactive signage (InPrivate).
 

The booking solution used in the background was Pronestor.
Pronestor creates a unique web page pr meeting room/device/booking panel, and the booking panel for each room needed to show the correct web page for the room on the deployed device.

The content

Intune limitations

When you are deploying Single-app kiosks with Microsoft Intune, a limitation quickly showed itself.
When you create the Configuration Profile for a single app kiosk, and Microsof Edge browser as application, you need to define the url for the kiosk device in this configuration profile.

This is fine if the URL you are going to show is the same across a multitude of devices.

But for this deployment – with more than 60+ device , with seperate URL’s – this means that out of the box, with the current settings in the configuration profile, you will need to create a seperate Configuration Profile pr device – obviously that is not a good solution in the long term (or short term).

Hacking the limitation

With the limitation identified, a way to work around this limitation was the next step.
So looking at what I had to work wit, I needed:

  • A way to configure the correct URL pr device, based on where it should be placed (Pronestor URL for the device)
  • The possibility to change the URL on the device from one location in case of repurposing/switching the device for a room.
  • Preferrably do the base kiosk configuration using just one Configuration Profile

This quickly made it obvious that I needed to have a datasource containing the needed information pr device. This gave the idea to collect this information in a CSV file, containing the device serial pr device,  the correct url for the correct serialnr and other useful information.

I concluded with putting this information in an Azure Storage Blob – kind of like the way that can be used to deploy wallpaper/lockscreen – as mentioned in a previous post.

This would cover the first to requirements, the next step was to figure out how to use this information in a way to make use of only one Configuration Profile.

Limiting the number of needed Configuration Profiles

Since the configuration profile have a setting to configure the “Edge Kiosk URL”, this meant that this information was deployed somewhere on the devices.

My first guess, was that this would be able to find in the Windows Registry on a device.

With that in mind, I set the profile to a “dummy URL”, and deployed one device to see if I could find this information somewhere on the device, this did not take much time, as I quickly found this in the current location in the registry of the device:

HKLM:\SOFTWARE\Microsoft\Windows\AssignedAccessConfiguration\Profiles\#####\AllowedApps

Since I now had the registry location of the setting with the dummy URL, the next step was to verify if Intune was going to change this back – to the URL in the Configuration Profile – if i changed this value in the registry of the device. This did not happen, meaning Intune only pushes this setting once. This gave room to work further on this.

So for the POC for this, the next step was to configure a way of deploying the devices with one Configuration Profile in Intune, then have the device get the correct URL for the device from the Azure Storeage Blob CSV file, and change it accordingly.

I thereby decided to automate the process of downloading a local copy of the CSV file to the device, and have a scheduled task check the CSV file for the configured URL for this device serial number, and change it accordingly if it did not match – and initiate a reboot if it was changed, so that the kiosk showed the correct page. I also wanted to include a part to update the local CSV file as the contents would change over time, the same goes for the various local scripts in use.

This was done by creating a set of powershell based scheduled tasks for the job.
The scheduled tasks were deployed to the device via PowerShell scripts in Intune.

Note: You could also cover this with proactive remediations, but that only runs once pr 24 hours and is not ideal in this case.

Azure Storage Blob

For instructions on how to setup the needed parts for the Azure Storage blob, you can review an earlier post using the same methodology here.:

Intune: Setting custom wallpaper and lockscreen on Windows 10 devices with PowerShell and Azure Storage Blobs

The CSV file

The CSV file i am using is uploaded to the Azure storage blob along with the powershell scripts that are to be deployed locally to the devies.
The file name is meetingrooms.csv and has the following content.:

DeviceSerial;URL;Comment;Country

DeviceSerial is the serialnr for the device, URL has the URL that should be the final URL on that device.

Because various file editors can mess up the format of the file, excel in particular removing leading zerose, you can edit the file directly in the azure portal for convenience.

Just head over to your configured storage account and select the file there.

Click into the Edit option, do your changes and click save.

The Intune powershell scripts

To cover the deployment I ended up creating a collection of powershell scripts to use against the deployment.
This is to manipulate/hack the registry to change the URLs from the kiosk configuration profile.
They also deploy the scheduled tasks that will keep the device verifying its configuration over time.

Intune settings for the scripts

All scripts that are deployed to the device group via intune is set with the following properties in intune.:

The scripts that get downloaded locally to the devices is placed inside an Azure Storage Blob, and a URI is generated that is put inside the scripts – telling it where to get the files from.

For steps on how to setup the storage blob and URI’s you can follow the steps in a previous post leveraging the same methodology.

This can be found in this post.:  Intune: Setting custom wallpaper and lockscreen on Windows 10 devices with PowerShell and Azure Storage Blobs

The scripts that were created are as follows .:

Win10 – Kiosk Meetingroom – Deploy KioskURL

This script is the one responsible for checking for the dummy URL used in the initial kiosk configuration profile.
The script will do the following:

  • Create the folder “c:\Meetingrooms-csv” if it does noe exist, this is where local scripts, csv etc will be stored.
  • Download the CheckKioskUrl script to the device
  • Create a scheduled task to run the CheckKioskUrl script at a set interval (6 AM daily)
  • After task is created change the run interval of the task to every hour every day.
    This was because of the need to have quick updates in the testing phase – and should be modified to something that fits your need.
  • Downloads the CSV file from Azure Storage blob to the device.
  • Checks the device serial, and gets the needed kiosk url for this serialnr from the CSV file, and changes this in the registry for the device. To make the change the script looks for the dummy url from the intune configuration profile at the registry location containing the info (HKLM:\SOFTWARE\Microsoft\Windows\AssignedAccessConfiguration\Profiles\*\AllowedApps)
  • After changing the url in registry – reboots the device so it will show the correct url found for the device in the CSV file.

The script therefore creates what is needed to keep the URL correct over time, as well as doing the initial URL change (last 3 steps) on the device, leveraging the initial dummy url.
By doing this we can cover the whole kiosk configuration with only one intune configuration profile instead of one pr device in this scenario.

Win10 – Kiosk Meetingroom – Deploy CheckKioskURL

This script is responsible for creating a task and script that will check the current kiosk url against the information in the CSV file.

The script will.:

  • Create the folder “c:\Meetingrooms-csv” if it does noe exist, this is where local scripts, csv etc will be stored.
  • Download the CheckKioskUrl script to the device
  • Create a scheduled task to run the CheckKioskUrl script at a set interval (6 AM daily)
  • After task is created change the run interval of the task to every hour every day.
    This was because of the need to have quick updates in the testing phase – and should be modified to something that fits your need.

Win10 – Kiosk Meetingroom – Deploy CSV Updater

This script is responsible for creating a task that will update the local CSV file at set intervals.
The script will.:

  • Create the folder “c:\Meetingrooms-csv” if it does noe exist, this is where local scripts, csv etc will be stored.
  • Download the UpdateKioskCSV script to the device
  • Create a scheduled task to run the UpdateKioskCSV script at a set interval (6 AM daily)
  • After task is created change the run interval of the task to every hour every day.
    This was because of the need to have quick updates in the testing phase – and should be modified to something that fits your need.

With this the CSV file will keep up to date over time as devices and urls are getting added/changed/removed in the CSV file.

Win10 – Kiosk Meetingroom – Deploy Local Script Update

This script is responsible for creating a task that will update the local scripts on the device at set intervals.
The script will.:

  • Create the folder “c:\Meetingrooms-csv” if it does noe exist, this is where local scripts, csv etc will be stored.
  • Downloads the following scripts from azure storage blob to the device: UpdateLocalScripts, UpdateKioskCSV, CheckKioskUrl
  • Create the scheduled task UpdateLocalScripts on the device, the task is used to keep the local scripts up to date with what is located in the Azure storage blob.
  • The task is set to run daily at 4 AM to make sure it runs before the task that checks the kiosk url on the device.

This ensures that one has the correct scripts locally on the devices over time. If there is no need to update the scripts over time there is no need for this – but for testing it makes things abit more flexible.

Win10 – Kiosk Meetingroom – Deploy TaskCleanup

This script can be used to change the settings for the deployed scheduled tasks on the device should you wish to change them later.

Win10 – Kiosk Meetingroom – Deploy Kiosk Screen Orientation

Depending on your need this scripts can be used to set the screen orientation on the devices.

Adapt the script to your need if it is used.  The comments in the script points you the right way – by default it turns of autorotation and sets the device to landscape orientation.

Scripts deployed locally – via Intune scripts

CheckKioskUrl

  • Gets the device serialnr
  • Checks the url for the serialnr in the csv file
  • If set url does not match the csv info, changes the set url to the one in the CSV file and reboots the device.

UpdateKioskCSV

Updates the local CSV file from Azure storage blob

UpdateLocalScripts

Updates the local scripts on the device from Azure storage blob

The Intune Configuration

When it comes to the general intune configuration profiles in this setup I will not include all of these here. But I will include some, as they were used here, and are also useful to know in other setups as well when it comes to the kiosk functionality.

I will include the follwing to cover what is needed:

  • Dynamic Device Group
  • ESP profile
  • Autopilot Profile
  • Configuration profiles
  • PowerShell scripts
  • Update policy

Dynamic Device group

We will be using a dyamic device group in this setup.
All configuration here is done targeting devices and not users, it is therefore beneficial to have one group that we can use for all assignments, beeing scripts, profiles, policies etc.

I will be using a dynamic group that looks for devices imported into Windows Autopilot with a group tag set on them. The group tag is added to the CSV file during hash harvesting. This means that the group will add the devices to this group as soon as they are imported into windows autopilot and azure ad does its checks.

The rule used for the dynamic group is in this format:

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

Where “YourGroupTag” is the tag you choose to use on your end.
If your devices already are imported into the list of autopilot devices you can set the group tag manually.

NOTE: If you are using devices already imported, you may need to clean these devices away from the current intune management, and the associated azure ad device. You should also verify that other policies etc are not hitting this devices – meaning you may get a conflict of profiles/policies used in this deployment.

Enrollment Status Page (ESP)

Since these devices are self-deployed you may want to have a seperate Enrollment Status Page (ESP)  for these devices.
In my case I created the following ESP for these devices.
Create a new page in the ESP section of Intune and give it a name and click next.:

 

I use the following settings.:

Click next, and assign the ESP page to your device group.

Autopilot Deployment Profile

In this setup we are using Self-Deploying (preview) as the deployment mode for the devices.

This means that a minimal amount of time and interaction is required to deploy these devices.
The devices will connect to intune, and start deploying by them self.
Once deployment is complete, the device in this scenario will dipslay the kiosk application and is ready to use.

Keep in mind that self deploying mode means no users are assigned to the device, and no credentials are required on the device for provisioning. Self-deploying requires your devices to have tpm 2.0 – and should not be an issue on new devices acquired today.

To create the profile head over to windows enrollment page and create a new profile.
Select windows pc in the dropdown.

Give the profile a name, and optionally select the convert all devices and set it to yes.
Click next

In the OOBE options configure as needed and click next.

Assign the profile to your group containing the devices you are targeting for kiosk mode.

This group should contain the devices used for the purpose.
You also need to import the hash for the devices to intune as normal.
Consider using dynamic groups in azure to make this easy to manage.

You could then have a dynamic group looking for the “group tag” on autopilot devices, meaning all devices imported in as autopilot devices with this group tag will be members of the group.
You could then use this group for all assignments in this kiosk setup.

Intune Configuration Profiles

Device – Kiosk – Meeting Rooms – Kiosk Mode

This is the main kiosk configuration profile.

This profile is used to:

  • Set the kiosk mode
  • Set the logon type
  • Set the kiosk application type
  • Set the initial kiosk url -the “Dummy URL” we are using for manipulation via the powershell scripts.
  • Set the kiosk mode type (Digital/interactive Signage)
  • Set the maintenance window for the devices – so that updates etc are not run in the working hours for the device.

To create the profile, head over to intune configuration profiles and create a new profile

Set the profile to windows 10 and later, type to Templates and choose kiosk for the template name and click create.

Give the profile a name and click next

For the settings –  adapt to your need – I’m using the following for demo.

Assign the profile to your group of devices.

Device – Kiosk – Meeting Rooms – Power Settings

This profile sets some power settings to avoid standby etc on these devices.

Device – Kiosk – Meeting Rooms – DisableFirstSigninAnimation

This profile is to disable the Windows 10 first logon animation in order to speed the first sign-in up. The ESP also bypasses the first logon animation. 

 This profile combined with the ESP_SkipUserStatusPage will make this part flow a little better.
We will use OMA-URI to set this configuration on the device.

To create the profile, head over to intune configuration profiles and create a new profile

Set the profile to windows 10 and later, type to Templates and choose Custom for the template name and click create.

Give the profile a name and click Next

In the OMA-URI settings, click add and input the following:


Name.: Disable first sign-in animation

OMA-URI.: ./Device/Vendor/MSFT/Policy/Config/WindowsLogon/EnableFirstLogonAnimation

Description.: Optional

Data type.: Integer

Value.: 0

Assign to your device group, review and create the profile.

Device – Kiosk – Meeting Rooms – ESP_SkipUserStatusPage

This profile is to disable the ESP account setup phase.
These devices are deployed using Autopilot in a self provisioning mode. This also means that no user is assigned to the devices, and the ESP page will be stuck on this screen should a user need to log on to the device locally. This profile combined with the DisableFirstSigninAnimation will make this part flow a little better.
 

We will use OMA-URI to set this configuration on the device.

To create the profile, head over to intune configuration profiles and create a new profile

Set the profile to windows 10 and later, type to Templates and choose Custom for the template name and click create.

Give the profile a name and click Next

In the OMA-URI settings, click add and input the following:


Name.: SkipUserStatusPage

OMA-URI.: ./Device/Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage

Description.: Optional

Data type.: Boolean

Value.: True

Assign to your device group, review and create the profile.

Device – Kiosk – Meeting Rooms – Restrictions

Since this is a single app kiosk using edge, I set some device restrictions for good measure.

To create the profile, head over to intune configuration profiles and create a new profile

Set the profile to windows 10 and later, type to Templates and choose Device Restricitons for the template name and click create.

In my example the following is set in the profile.:
Set what fits your requirements.

Assign to your device group, review and create the profile.

Windows update ring

To handle device updates for the kiosk devices a seperate update ring is configured and deployed to the devices.

To create the profile, head over to Intune Update rings for Windows 10 and later and create a new update ring.

Give the  update ring a name and click next

On the next page, set your required configuration for the update ring.
In my case, drive updates were disabled due to a bad driver coming to some surface devices that basically killed the device.
 

When the settings are to your requirements, click next, assign the profile to your device group, click next.

Review your settings and click create if everything is to your liking.

Final Deployment overview

A breif overview of the components.

A flow of the device deployment flow.

The End

Hope anyone finds this interesting or otherwise helpful.
Once againg a solution was found using/manipulating the windows registry with good help of powershell.
The scripts referenced here are found on my GitHub page
Until next time.

Leave a Reply

%d bloggers like this: