Windows device-management tutorials and guides by Microsoft MVP Jannik Reinhard — Windows 10 and Windows 11 management with Microsoft Intune: Autopilot, Settings Catalog, security baselines, and PowerShell automation.
The more clients are managed in your tenant and the more people have contributor rights in your tenant, the more important it becomes to have good release management processes. In this blog post I would like to introduce you to my Intune CI pipeline that allows you to transfer configurations from one tenant to another. This offers the possibility that only a small number of administrators have access in the Prod tenant and all others create configurations in a Dev tenant and these are then transferred to the Prod tenant via a DevOps pipeline.
Unfortunately, there is no setting in Intune with which you can determine whether an app should be installed during ESP (Enrollment Status Page) or only after ESP. Of course, it is a huge advantage to install as many apps as possible during the ESP or even better during the white glove phase so that you have a ready to use device after enrollment. But there are cases where it can make sense to install an app after the ESP, for example if the installation routine requires an interaction. How you can skip the installation of an app in the ESP I will explain now.
Sometimes the most underrated way to drive change in a fleet is to just talk to the user. Endpoint Analytics surfaces all kinds of useful insights — battery health, boot performance, application reliability — but those signals only become action when they reach the right person at the right moment. The Smartphone Replacement Tool is a small wrapper I built around that idea: trigger a clean, branded dialog on the user’s PC the next time they log on, with a contextual message and a clear next step. The technical scaffolding is intentionally simple: a Win32-deployed tool with a WPF frontend, an Intune Proactive Remediation that decides who sees the dialog, and an Endpoint Analytics-driven trigger.
It is not always easy to reach users via email or other channels. When there are projects running to exchange e.g. smartphones or migrations of files from a network drive to a SharePoint it is hard to reach the users and get an answer. Intune provides with Endpoint Analytics a very good on board tool to easily reach users via a user dialog. In this blog I will show how you can use this with the example of a smartphone exchange. The dialog and the method can be adapted to many other use cases.
Everyone who has enrolled a few devices with autopilot in his life and has encountered errors knows the problem that it can quickly be very cumbersome to find the problem why an enrolment fails. Especially when it comes to network endpoints that are not reachable it can be very time consuming to find them. To enroll a device with autopilot there are also some prerequisites that have to be fulfilled. To check this before the enrollment I have created a script that helps you to check these requirements.
A useful validation step after importing custom ADMX settings is to export the resulting Intune profile and compare it with the vendor documentation. This confirms that the setting name, supported Windows version, and value format match the template you intended to use.
If a policy does not apply, review the device event logs and the MDM diagnostics report before changing the template. Most failures are caused by assignment scope, unsupported OS builds, or value formatting rather than the ADMX import itself.
Custom ADMX and ADML imports are helpful when a required Windows policy is not yet available as a native Intune setting. Treat every import like configuration source code: keep the original vendor files, document the version, and test the policy in a separate device group first.
After importing the templates, verify that the settings appear in the expected Intune category and that the generated policy writes the correct registry values on a test device. This avoids troubleshooting confusion later when multiple custom templates exist in the same tenant.
Most of the policies you’ll ever need are already exposed in Intune’s Settings Catalog — but every IT environment has at least one app whose admins still ship a custom ADMX/ADML template from the on-prem Group Policy days. Adobe Reader, FortiClient, custom in-house tools, and a long tail of vendor utilities all use this format, and Intune supports it natively as long as you know the slightly hidden import workflow. This post walks through importing a custom ADMX/ADML pair into Microsoft Intune end-to-end — where to grab the template files, how to upload them, how to assign the resulting profile, and what to expect on the client. Plus the debugging steps for the most common import failures.
With the Intune service release 2208 there is a really nice feature that provides the support to import ADMX and ADML templates very easy into Intune. This helps you create configurations for e.g. third-party products. I will explain how this works based on Firefox.
Windows 11’s redesigned right-click context menu has its fans and its detractors — some users love the cleaner default; others miss “Show more options” being a single click away. As an Intune admin you’ll get pulled into both camps, often by the same VIP. The good news is that the classic context-menu behaviour can be restored centrally with a single registry key, deployed cleanly through Intune via the Settings Catalog or a tiny PowerShell remediation. This post documents the registry tweak, the Intune deployment workflow, and how to make the change reversible per user.
Windows 11 has brought some changes to the Windows Explorer, including the way the context menu looks. By default, the context menu is reduced to the really necessary functions. This is sufficient for most users. However, if you often need functions that are not in the reduced view, then this can be a hindrance in the workflow. In this blog I want to show you how to get back the Windows 10 context menu with the help of Intune.
Anyone who has worked with Intune and deployed an app knows that this is a bit of work. You have to download the sources, create the IntuneWin file, create the app in Intune. To simplify this I have created the Intune App Creator. With this application you can search within the >9,000 Chocolatey packages and automatically add this app to your Intune app portfolio with just one click.
Intune offers the possibility to show per device not only the apps installed via Intune but also the apps discovered on the device (Control Panel apps). Since this view is relatively static and you only have a per device view here, it is difficult to make analyses of the complete environment, e.g. to see which app is missing in the portfolio, since this is often installed by users themselves. Why don’t we use log analytics to have more options to work with this information? In this blog I want to show you how you can do this easily with a script.
This step-by-step guide shows how to send daily Intune device reports via Logic Apps, email and Teams. The flow combines Microsoft Graph queries, Azure Logic Apps, and your existing Microsoft 365 channels — no third-party reporting tool needed, and the whole pipeline runs on the Azure consumption plan for a few cents per month.
For an Intune admin it is always helpful to get an overview of the current status of their tenant and an overview of the count of devices in the field. In this blog I would like to explain how you can use Logic Apps to send you a detailed daily report.
For the Windows Update reboot notification scenario, keep the message short and action-oriented. Users should immediately understand whether they can postpone, whether a restart deadline exists, and which business application might be affected if they ignore the prompt.
Also check the policy assignment after deployment. If the same device receives multiple update rings or conflicting restart settings, the notification can look correct while the underlying restart behavior is still confusing for users and support teams.
This guide is about Windows Update reboot notifications in Intune and how to make restart behavior predictable for users. The important part is not only enabling a toast, but also choosing timing, wording, and assignment groups that match your patching process.
Before rolling this out broadly, test the notification on a small pilot group and compare the user experience with your existing update rings. That gives you a clean baseline for support tickets, restart deadlines, and expected device behavior after monthly patch deployment.
Windows Update reboots are one of those topics where the default behaviour annoys exactly the people you want least to annoy: knowledge workers in the middle of a presentation, factory operators on a kiosk, and your CEO on a Friday afternoon. Out of the box, Windows shows generic reboot prompts that users either dismiss without reading or only see seconds before the machine restarts. The good news is that Microsoft Intune exposes a complete set of CSP-backed settings to tame these notifications: when they appear, how often they nag, when they auto-restart, and how aggressively they enforce. This post collects the small handful of policies I deploy in every tenant for predictable reboot behaviour, with the gotchas that don’t make it into the docs.
