This article will describe how to set up a single app kiosk device with Windows Autopilot.
Situation:
- We have a web browser app where different people have to log on to, on one computer
- Intune managed computers (mix of Hybrid Joined & Azure AD Joined)
Target:
- Deploying a Kiosk device with Windows Autopilot, with only the Edge browser pointing to the web browser app immediately. Users can’t log on with their UPN. So that has to be blocked off. And we don’t want the device going in timeout or sleep or hibernate.
1. Create a Dynamic Group targeting all Kiosk devices
The first thing to do is creating a dynamic group targeting all our Kiosk devices (we will use the Group Tag to achieve this). Dynamic Groups in Azure AD have their advantages. You can use query’s to populate groups automatically. You can target users or devices. More info here. So let’s go to the Device Management Portal, and click on the Groups blade. In the Groups blade, click on ‘New Group’. Fill in the ‘Group name’, and as Membership type choose ‘Dynamic Device’. This means we’ll use a query to populate our group. At last click on ‘Add dynamic query’.
Click on ‘Edit rule syntax’, and then add the following rule: ‘(device.devicePhysicalIds -any _ -eq “[OrderID]:Kiosk”)’. Afterwards save your group.
As we go trough the OOBE process to enroll our machines with Windows Autopilot, we will use a PowerShell script (Upload-WindowsAutopilotDeviceInfo.ps1) to upload the hardware hashes of the devices into Intune immediately. We can provide a GroupTag along with that. Take care that in our dynamic query the GroupTag is still referenced as ‘OrderID’. I hope at one point they will change it to GroupTag also here. This gives us the advantage that our dynamic group we are creating here will get populated automatically with all the devices we import with the GroupTag ‘Kiosk’. More info on using dynamic groups with the Windows Autopilot service here.
2. Create a Windows Autopilot profile
Next, navigate to Devices, Enroll Devices, Deployment Profiles.
In the Windows Autopilot deployment profiles blade, click on ‘Create Profile’ Give the profile a name, and leave the ‘Convert all targeted devices to Autopilot’ on ‘No’. We don’t want all our existing devices that aren’t registered yet with a Windows Autopilot profile to get our Kiosk profile. So that’s why we leave this on ‘No’. Click on ‘Next’.
For Deployment mode, choose ‘Self-Deploying (preview)’. Windows Autopilot self-deploying mode enables a device to be deployed with little to no user interaction. For devices with an Ethernet connection, no user interaction is required; for devices connected via Wi-fi, no interaction is required after making the Wi-fi connection (choosing the language, locale, and keyboard, then making a network connection). You’ll also see that Self-deploying mode only works at this moment with Azure AD Joined devices. But that’s ok for our Kiosk devices. Choose the correct Language (Region). You can see that I still put Automatically configure keyboard on ‘No’. In my testing, I noticed that even though I put the Language (Region) on Dutch (Belgium), he still chooses a QWERTY layout even though we use an AZERTY layout in Belgium. So test it for sure! We want a Standard user. And we also want our devices to get a naming convention. They all have to start with KIOSK- and then get a random 4-length string of numbers. Click on ‘Next’ when everything is filled in correctly.
Click on ‘Select groups to include’ and here we choose our dynamic group we created in Step 1. Click on ‘Next’.
On the next screen, review your settings, make sure they are correct and click on ‘Create’.
3. Create a Kiosk configuration profile
Go to Devices, Configuration profiles, click on ‘Create profile’. Give your profile a name, as Platform, obviously choose ‘Windows 10 and later’ and for Profile type choose ‘Kiosk’. On the Select a kiosk mode blade, choose ‘Single App, full-screen kiosk’. More options will appear. User logon type choose ‘Auto logon (Windows 10, version 1803+), for application type choose ‘Add Microsoft Edge browser’. And for Microsoft Edge browser settings, leave it at ‘Digital/Interactive signage’. If you want you can also fill in the extra options for a fixed maintenance time for App Restarts.
Click twice on ‘OK’ and then on ‘Create’. Your Kiosk profile will be created. Assign it also to your dynamic device group from step 1.
We now made a configuration profile where we specify which Kiosk mode we want. But in this profile we can’t give a lot of settings for Edge (like the URL we want published). So we need to create another configuration profile.
4. Create a Kiosk Edge settings profile
Go to Devices, Configuration profiles, click on ‘Create profile’. Give your profile a name, as Platform, obviously choose ‘Windows 10 and later’ and for Profile type choose ‘Device Restrictions’. In the Device restrictions blade, choose ‘Microsoft Edge Browser’, a new blade will appear. There we will choose Use Microsoft Edge kiosk mode ‘Digital/Interactive signage (single-app kiosk). In Start experience blade, choose your ‘Start page’.
In the Privacy and security blade, we set Cookies on ‘Allow’. On the Send do-not-track headers option choose what works for your site/web application you are targeting. If you don’t want the website to track the user, leave it on ‘Yes’.
Click twice on ‘OK’ and then on ‘Create’. Your Kiosk Edge settings profile will be created. Assign it also to your dynamic device group from step 1.
Now we are in fact ready with the configuration for our Kiosk device. We have set up a single app Kiosk, with a fixed browser link configured in Edge. But this still leaves some back doors open. When users press ‘Ctrl+Alt+Del’ on the Kiosk Device, they will get to the login screen. And they will be able to sign in with their UPN of their Azure AD user account. We don’t want that. We also don’t want that the Kiosk device goes in hibernation or in sleep mode. So we will also configure this further.
5. Create a Kiosk Local Logon only profile
So we don’t want our users to be able to logon with their Azure AD account. So we will push a configuration profile to the Kiosk device that only allows Local Profiles to log on to the computer. That way we can avoid users logging in with their Azure AD account. Go to Devices, Configuration profiles, click on ‘Create profile’. Give your profile a name, as Platform, obviously choose ‘Windows 10 and later’ and for Profile type choose ‘Custom’. Click on ‘Settings’.
Here we will click on Add, and configure one OMA-URI to get to our target. Choose a name for your custom OMA-URI. These are the settings:
OMA-URI: ‘./Device/Vendor/MSFT/Policy/Config/UserRights/AllowLocalLogOn’
The data type is ‘String’
And the value for the data type is ‘<![CDATA[*S-1-5-113]]>’
You can find more info on the SID we are targeting here. You can see we are targeting this:
Click twice on ‘OK’ and then on ‘Create’. Your Kiosk Local Logon settings profile will be created. Assign it also to your dynamic device group from step 1.
So now we are almost ready. Only thing left for us to do is set the timeout settings for hibernate.
6. Create a Kiosk Timeout Settings profile
So we don’t want our display to go black after x minutes. We also don’t want our Kiosk device to go into sleep mode or hibernate. We will configure this with 6 OMA-URI’s in one profile. Go to Devices, Configuration profiles, click on ‘Create profile’. Give your profile a name, as Platform, obviously choose ‘Windows 10 and later’ and for Profile type choose ‘Custom’. Click on ‘Settings’.
Here we will click on Add, and configure six OMA-URI’s to get to our target. You can find all six values here:
The first one we will name ‘DisplayOffTimeoutOnBattery’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/DisplayOffTimeoutOnBattery’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterVideoDCPowerDownTimeOut” value=”0″/>’
The second one we will name ‘DisplayOffTimeoutPluggedIn’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/DisplayOffTimeoutPluggedIn’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterVideoACPowerDownTimeOut” value=”0″/>’
The third one we will name ‘StandbyTimeoutOnBattery’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/StandbyTimeoutOnBattery’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterDCStandbyTimeOut” value=”0″/>’
The fourth one we will name ‘StandbyTimeoutPluggedIn’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/StandbyTimeoutPluggedIn’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterACStandbyTimeOut” value=”0″/>’
The fifth one we will name ‘HibernateTimeoutPluggedIn’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/HibernateTimeoutPluggedIn’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterACHibernateTimeOut” value=”0″/>’.
The sixth and last one we will name ‘HibernateTimeoutOnBattery’
The OMA-URI is ‘./Device/Vendor/MSFT/Policy/Config/Power/HibernateTimeoutOnBattery’
The data type is ‘String’
The value is ‘<enabled/><data id=”EnterDCHibernateTimeOut” value=”0″/>’.
Click twice on ‘OK’ and then on ‘Create’. Your Kiosk Local Logon settings profile will be created. Assign it also to your dynamic device group from step 1.
So now we have configured all that we want. Our Kiosk profile is ready, we pointed to the website we wanted to display in the Edge browser. And we locked down the device so you can’t login with Azure AD accounts. And at last the device won’t go into sleep or hybernate, or the display won’t go into saving mode.
7. Deploy a single app Kiosk device with Windows Autopilot
First thing to take care of here is, you need a machine with an actual TPM 2.0 chipset. So you won’t be able to do this with a Virtual Machine that doesn’t support TMP 2.0 virtualisation. You’ll also need Windows 10 1903 for TPM Attestation. In my personal experience, sometimes the devices fail to join Azure AD. This comes because of the TPM chipset. Make sure this chipset is updated to the latest firmware drivers and clear the TPM before going on. Take notice of this. You can find more info on the requirements here.
So after reading the requirements and making sure everything is in order, we boot our device with Windows 10 1903 minimum.
First we choose our Region. In my case I choose Belgium (België). Click on ‘Yes’.
Next we choose our keyboard layout, in my case I choose ‘Belgisch (punt)’. Choose whichever you want and click on ‘Yes’.
On the next screen we get asked to add a second keyboard layout. For now ignore that question. Press ‘Shift+F10’ to open a command prompt. In the command prompt type ‘powershell’ to open the PowerShell mode and press ‘Enter’.
Once in the PowerShell mode, first thing to do is set our ExecutionPolicy right. So type ‘Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted’. And press Enter.
Now we will install the ‘Upload-WindowsAutopilotDeviceInfo.ps1’ script. Type: ‘Install-Script -Name Upload-WindowsAutopilotDeviceInfo’ and press Enter. They will ask you a few time to continue. Always acknowledge with ‘Yes’ or ‘Yes to All’.
Now we want to run the Upload-WindowsAutopilotDeviceInfo script with the correct parameters. So type this: ‘Upload-WindowsAutopilotDeviceInfo.ps1 -TenantName “switchtomodern.be” -GroupTag “Kiosk” -Verbose’ and press ‘Enter’. This will start the script. At some point it will popup a login screen, login there with an Azure AD account with the right roles assigned (Global Administrator – Intune Administrator).
As you can see here I don’t get asked for a password. This is because I have enabled passwordless sign-in on my tenant. And activated it in my Microsoft Authenticator App.
At last this is the screen we get to see, where we can see the device serial of the VM, and the message to Sync the devices in our Intune portal.
So now we navigate to our Device Management Portal again and click on Devices, Enroll Devices, Windows Autopilot Devices and there we’ll click on ‘Sync’. You’ll notice that our device will get imported here with the correct GroupTag that we supplied running the PowerShell script. You’ll also notice that it has no Autopilot profile assigned (yet). This is normal behaviour. The device will need to get in our dynamic group first. And then it will get the correct configuration profiles assigned together with the correct Windows Autopilot profile. This can take up to 15-30 mins. So give it some time.
While waiting we can check our dynamic group, and we’ll see that the group will populate with the device.
So now we just have to wait till the Windows Autopilot Profile get assigned. So get a coffee and give it some time.
At some point you’ll see in the Devices, Enroll Devices, Windows Autopilot Devices blade that the profile is Assigning. This means we are almost ready to continue deploying. A few more minutes to wait.
After a few more minutes. The Windows Autopilot profile will be assigned.
Back to our device, to be sure I always trigger a reboot in the command prompt before continuing. Type ‘shutdown -r -t 0’ and press ‘Enter’. The device will reboot immediately.
You’ll device will import the Autopilot profile, trigger a reboot, and depending on the setting concerning ‘automatically configure keyboard’, it will just ask for this one setting or not. The device will then go through the Autopilot process, join your Azure AD tenant, register for device management in Intune, get the correct configuration profiles and it will boot and log on with the web page or web application you provided in the configuration profiles.
Happy testing!
More articles on Windows Autopilot:
