Windows Autopilot

Creating a kiosk or digital sign using Windows Autopilot, Intune, and Edge (Chromium)

Way back when (two years ago to the day actually), I posted a blog that described how to use Windows Autopilot self-deploying mode to create a kiosk that displayed a web page using the Kiosk Browser app.  You can refer back to that post for the basics of the scenario.

Later on, I set up a separate kiosk configuration that used the “legacy” version of Edge to do the same thing.  It was very similar, with one profile to define the kiosk:


And another one to specify the web page to be displayed:


I didn’t blog about that one, although I used it quite a few times for demos.  You’d probably struggle to tell the difference between that experience and the Kiosk Browser experience (unless maybe you were watching closely as it started up – you might be able to tell during the startup).

But now it’s time for option #3: Using Edge (Chromium) to do the same thing.  While Intune doesn’t yet have support for that in the kiosk device configuration profile, that doesn’t mean it can’t be done – you just need to work a little harder at it.

First, you need to create the required configuration as described in the AssignedAccess CSP documentation.  There is a good example in the “Shell Launcher V2 Add” section, which I edited a little:


What that says is to create a local kiosk user account, automatically sign on as that account, and configure it to launch Edge with a specific URL, running full screen.  (I also configures all other accounts to use Explorer.exe, like normal.  That’s useful so you can sign on using an Azure AD admin account.)  I can then use that to create a custom OMA-URI policy in Intune:


The full OMA-URI:  ./Device/Vendor/MSFT/AssignedAccess/ShellLauncher

You can click the folder icon to upload the XML file.  Save the profile and assign it to an appropriate group of devices.  Assuming you’ve already done the Windows Autopilot configuration (registered the device, assigned a self-deploying profile, enabled ESP), you’re ready to deploy.  You’re then ready to deploy to a physical device (VMs aren’t supported for self-deploying mode due to the TPM attestation requirements).  And at the end of the process, you’ll see issue #1:  The Edge first run experience will show up and the browser isn’t full screen.  (Obviously the “—nofirstrun” parameter I tried to add to the Edge command line did no good.)  OK, easy enough to turn that off with an Administrative Templates profile:


Find that “Hide the First-run experience and splash screen” policy (easiest to just search all settings for it) and enable it.  Assign that to your kiosk devices (or all devices if you prefer) and try again.  Now you see something a little more reasonable:


But you’ll still see an issue if you wait a while.  The screen will go blank due to power settings, and depending on what other power settings are in place, the device may go to sleep – not quite what you want for a kiosk.  So one more Administrative Templates profile is needed to adjust the power settings:


I configured four settings for this one (specifying 0 for the timeout values on the “enabled” items, meaning “never”, and to disable entering a password if for some reason the device went to sleep and was later woken (e.g. power failure).  You can figure out the specific settings you want.  (I didn’t configure any “on battery” settings because I didn’t expect the device would ever be running on battery.)  So now if you deploy the device, you should see something that looks just like it did before, but it never goes to sleep.  Finally, a functioning digital sign.

One interesting tidbit about my physical machine:  I used a Surface Pro X, which runs ARM64.  Edge (Chromium) works just fine on that, and runs as a native ARM64 browser.  But did you notice the path in my XML file?  It uses %ProgramFiles(x86)%, which points to “C:\Program Files (x86)”.  Regardless of whether you are using x86, x64, or ARM64, you’ll find MSEdge.exe at “C:\Program Files (x86)\Microsoft\Edge\Application\MSEdge.exe”.  I’m not exactly sure what the reason for that is, but it actually simplifies the kiosk configuration – my XML would work just as well on an x64 system as it does on an ARM64 system.

And if you’re going to have a digital sign display a web page, you’ll probably want that web page to refresh itself.  While the Kiosk Browser can be configured to reload the page, I don’t know of any similar configuration for Edge (Chromium).  The Edge docs are rather brief on the subject.

p.s. I forgot one other step: I deployed Edge too. See the Intune docs for how to do that. Since I deploy this to “All devices” I didn’t need to do anything additional for the kiosk.

p.p.s. Here’s the XML that I used:

Categories: Windows Autopilot

3 replies »

  1. Hello, I am trying to follow this guide but I am getting and error in InTune 0x87d101f4 Which says “Syncml(500): The recipient encountered an unexpected condition which prevented it from fulfilling the request” from the policy that is pushing the XML. Any idea how I have messed this up? I have tried to follow your xml as closely as I can. The device is a Surface Go for Business device.


  2. Hello, I am trying to setup a kiosk to launch legacy Edge and open 2 sites. I was unable to get single app kiosk mode to work properly and in discussions with the client I found out eventually they may want to add an additional app to the kiosk. Therefore I pivoted to use multi-app kiosk mode. I am using legacy Edge due to the issues you point out here in this blog post.

    This should be a fairly straight forward configuration. I have created an autopilot deployment profile for this scenario, multi-app kiosk mode configuration profile, and a device restrictions configuration profile listing the two websites to be opened. Unfortunately it only launches the first site defined not the second one.