Kiosk Chaos to Calm. Building Multi-App Assigned Access with Intune

Lock down kiosks. Troubleshoot blocks fast.

Happy New Year, everyone. I hope your coffee is strong, your Intune policies are stronger, and your devices do not decide to re-enroll themselves for fun at 2 a.m. Also, if you are kicking off a fresh year of cleanup, standardization, or “let’s finally lock this down” projects. Welcome. You are in the right place.

I’m not sure what took me so long to write about this one. It seemed that 2025 was the year for multi-app kiosks for me. I would take notes from time to time, and then eventually realized I should probably turn those notes into an actual blog post.

By now, you’ve probably heard that all the cool kids call these kiosks Assigned Access. I’m still struggling to say that with a straight face. It’s like the whole Azure vs Entra situation. I still mix those up too, and I refuse to be shamed for it.

Assigned Access relies heavily on an XML file. That XML is created and configured in Intune using a Custom CSP. I want to walk through the XML creation and talk at a high level about how I build these profiles, plus how I troubleshoot them when they inevitably decide to act like a toddler in a candy aisle.

There are plenty of XML examples in the Microsoft Docs, and I’ll also provide a sample in my GitHub for reference.

Schemas

Schemas, the xmlns namespaces, tell Windows which “version” of the Assigned Access XML vocabulary you’re using. In other words, it helps Windows validate and correctly interpret the elements and attributes in your file.

The base schema covers the core structure. Additionally, the extra versioned schemas (like rs5 or 2022) unlock newer features. That way you can use things like AutoLaunch attributes or Windows 11 StartPins without older parsers getting confused and throwing a fit.

Profiles

Next up, we have our Profile ID. This profile is simply a GUID. When creating a new xml, I simply run “New-Guid” and use that value. The GUID identifies the kiosk profile that should be assigned. This same GUID will be used twice in my xml. One to identify the profile, and the other to let the PC know which profile should be automatically logged in.

Allowed Apps

The AllowedApps section is the allowlist for a multi-app kiosk profile, meaning only the executables you specify (by DesktopAppPath or AUMID for Store apps) are permitted to run for the kiosk user.

This is where things got “fun” for me. I worked on an app for a customer that had a .bat file calling a .js file. Yes, really. It was already a party before Assigned Access showed up and said, “Cool. Now do it with one hand tied behind your back.”

My Approach

First, in my sample XML, I’m using rs5:AutoLaunch to automatically launch Edge. This works because we included those extra schemas I mentioned earlier. Here’s the idea:

  • Auto-launch Edge
  • Pass a URL in the arguments, for example: https://mysite.domain.org

Then I allowed the .bat file and some other apps.

The “wait, why is this blocked” moment

Afterward, we discovered the .bat file was calling built-in Windows executables. Those executables were not on the allowlist, so Assigned Access blocked them. Accordingly, it was troubleshooting time.

So I temporarily added a few helpful tools to the allowlist:

  • Event Viewer (eventvwr.exe and mmc.exe)
  • Notepad (to read logs)
  • Command Prompt

Disclaimer. I know PowerShell is cooler. I was working with .bat. Do not judge.

With those tools available, I launched Event Viewer from CMD and navigated here:

  • Microsoft-Windows-AppLocker/EXE and DLL

From there, I tracked down the events showing what was blocked. Using a sample screenshot below, using this method we can easily search for Errors and remediate from there. Simply add those .exe’s that are needed into your xml.

StartPins

Next up is StartPins. This defines the pinned items on the Windows 11 Start menu for the kiosk user. It uses a JSON pinnedList (exported via Export-StartLayout) that points to specific .lnk shortcuts:

One big “learn from my pain” note. Those shortcuts need to exist in the actual Start Menu locations under %APPDATA% or %PROGRAMDATA%. A random .lnk sitting somewhere on the device will not work. Speaking from experience on this one, and yes, I was personally offended when Windows ignored my “perfectly good shortcut.”

Also, StartPins is mainly about quick launch convenience. It does not replace AllowedApps. You still need the allowlist for what’s permitted to run.

In my example, I pinned things like File Explorer and CMD for troubleshooting. I would remove those once this moves to production, because giving kiosk users tools is like giving a raccoon access to your pantry.

The “everything else” section

The next section gets more custom to your setup. There is a ton of information in the Microsoft Docs if you want to go deeper into schema definitions. It’s genuinely useful, and it can also help you fall asleep at night.

In my example, I want to show the taskbar. The display name for the auto-signed-in user will be “Kiosk User”. That same user is set as the automatically signed-in account for the device, and the kiosk profile GUID is referenced as the default profile.

Quick note on auto-sign-in. This seemed to work, then not work, then work again over the past year. According to the Microsoft Docs it’s now fixed, and lately it has been behaving for me. I’ve also used a remediation in the past to set the correct registry values and restart the device.

Testing the XML

Now that you have your XML, it’s time to deploy it in Intune. You copy the XML and paste it as a String value under the Assigned Access CSP. Easy, right.

Yes. Until one missing bracket or comma turns your kiosk into modern art.

I’ve used this method to test quickly. Run PSEXEC and launch PowerShell as SYSTEM, then apply the XML locally. If there are errors, it usually tells you the line number.

Here’s the general idea of what that looks like when applying via CIM:

Policies I Still Layer on Top

While Assigned Access locks down a lot, there are still a few extra settings I like to stack on top, depending on the scenario. For example:

  • Block Microsoft accounts sign-in/add
  • Hide Search on the taskbar
  • Disable OneDrive file sync
  • Hide Windows Security notification area control

For reference, this is Microsoft’s documentation on what is applied during Assigned Access. Assigned Access Policy Settings | Microsoft Learn

Leave Notes for Future You

Finally, add comments and notations to your XML. Your future self will thank you. Also, your future self deserves to know important things, like whether cheeseburgers are great.

Wrapping Up

If you’re building multi-app kiosks (sorry. “Assigned Access”), the big wins come from keeping a simple rhythm:

  • Start with the right schemas so you can use modern features without surprises.
  • Treat AllowedApps like your bouncer. If it’s not on the list, it’s not getting in.
  • Use AppLocker logs to quickly answer “what got blocked and why”.
  • Remember that StartPins is convenience, not permission.
  • Test locally as SYSTEM before Intune rollout, because typos love production.

Lastly, keep your XML commented and readable. You will forget why you added mmc.exe at some point. Future You should not have to solve Past You’s riddles at 2 a.m.

Dustin Gullett
Dustin Gullett

Dustin Gullett is a Microsoft MVP focused on Microsoft Security, Intune, Entra ID, and Zero Trust architecture. He writes practical guides for admins deploying Microsoft security tools in the real world.

Articles: 38