Forum Discussion
Building and Deploying a Kiosk Platform with WinUI 3 and Windows Pro
Hello,
Over the last few months I have been working on a kiosk platform built with WinUI 3, Assigned Access and Windows Pro.
The project goes well beyond the application itself and includes deployment, configuration, system lockdown, policy management, rollback and long-term maintainability.
One of the most interesting lessons learned was that managing a kiosk is often less about the application and more about managing Windows itself: power settings, updates, lock screen, privacy settings, touch keyboard, user experience restrictions and system recovery.
One challenge that isn't immediately obvious from the documentation is how to build, package, deploy and maintain a modern WinUI 3 desktop application within an Assigned Access environment on Windows Pro.
At first glance, Assigned Access appears to solve most kiosk requirements. In practice, deploying and operating a modern desktop application in a production environment requires addressing many additional challenges that fall outside the scope of Assigned Access itself.
Assigned Access itself is well documented, but most examples and tutorials focus on Microsoft Edge, UWP applications or predefined kiosk scenarios. Building, packaging, deploying and maintaining a WinUI 3 application in a real-world kiosk environment introduces additional challenges that are not always immediately apparent when approaching the platform for the first time.
This was one of the reasons why the project evolved beyond application development and became an exercise in Windows deployment, configuration management and operational maintainability.
Another interesting aspect of the project was that it wasn't a greenfield implementation.
The platform originally relied on a UWP-based kiosk application running on Windows 10. One of the objectives was to modernize the solution by moving to WinUI 3 while preserving the existing deployment model and remaining compatible with Windows 10 environments.
This migration raised several practical questions around application packaging, deployment, kiosk integration and operational management, well beyond the user interface itself.
To address these challenges, I designed a policy-based approach where system settings are handled through a three-step process:
→ Save the original state
→ Apply the required configuration
→ Restore the original state
instead of the more traditional approach:
→ Apply a configuration
→ Remove the configuration
This made the solution significantly more reversible, predictable and maintainable.
I believe the lessons learned from this migration and deployment effort could be useful to other developers and architects working on kiosk solutions based on Windows Pro, Assigned Access and WinUI 3.
I would like to share this experience as a technical article for the Windows Community Hub.
Is there a recommended process for community members who would like to contribute a technical article or case study?
Thank you.
Bets Regards
Diego Marino Monetti
2 Replies
Hi DiegoMarinoGuglielmo, this is a really solid area to document because kiosk builds usually fail around operations rather than the app itself. I would separate the project into the WinUI app package, the Windows lockdown/configuration layer, and the recovery/rollback process. Assigned Access can work well, but updates, power settings, and recovery are the bits I would test hardest.
- DiegoMarinoGuglielmoCopper Contributor
Hi,
Thank you very much for your feedback.
I completely agree with your observation. One of the biggest lessons from this project was that, after a while, the WinUI 3 application itself became only one component of the overall solution. Most of the engineering effort shifted toward Windows configuration, deployment, policy management, recovery and long-term maintainability.
Your suggestion to separate the content into three areas makes a lot of sense:
- the WinUI 3 application and packaging;
- the Windows lockdown and configuration layer;
- the recovery, rollback and operational maintenance process.
Interestingly, one of the goals of the article is also to describe how our architecture evolved during the project. We initially started from the assumption that Assigned Access would be the natural foundation for the kiosk. As we moved from development into real-world deployment and operational testing, we learned that some requirements were better addressed through a different management approach while preserving the same kiosk experience for the end user.
I think sharing not only the final solution, but also the reasoning and the evolution behind it, could be useful for developers facing similar challenges.
Would you recommend presenting this as a series of articles rather than a single, comprehensive case study?
Thank you again for taking the time to read my proposal.
Best regards,
Diego Marino Monetti
P.S. One small mystery remains: my Community Hub account shows up as "DiegoMarinoGuglielmo". 😊 I have no idea where the "Guglielmo" came from.My name is Monetti... Diego Marino Monetti. 😉