Blog
How to automate Microsoft Intune application deployment
Automate Microsoft Intune application deployment with Graph API, Enterprise App Management, and Nerdio across Windows 365 and AVD.
Table of Contents
- Where native Intune automation ends
- Scripting the gap with Graph API and PowerShell
- Automating updates across supersedence, catalogs, and third-party tools
- Automating targeting and provisioning-time deployment
- How Nerdio Manager automates app deployment across Windows 365, Intune, and Azure Virtual Desktop
- Your Intune application deployment automation roadmap
- Frequently asked questions about how to automate Microsoft Intune application deployment
Your team packaged the latest Chrome release as a Win32 app three weeks ago. The vendor has shipped two updates since, and each one means another pass through IntuneWinAppUtil.exe, another .intunewin upload, another supersedence relationship. Across a few hundred applications, deployment stops being a task and becomes the job.
Native Intune automates the easy half of that estate, with Store and catalog apps updating themselves while Win32 packages, line-of-business installers, and Azure Virtual Desktop session hosts stay manual. Automating deployment is really a decision about how much of your app estate falls outside that native coverage, and how you close the rest.
This guide is for IT directors and endpoint management owners deciding how to automate Microsoft Intune application deployment across Windows Cloud (Microsoft's umbrella term for Windows 365 and Azure Virtual Desktop). It also shows where Intune management with Nerdio fits when native packaging, targeting, and update workflows stop short.
Where native Intune automation ends
Native Intune automates updates broadly for two app types. Win32 still requires manual packaging and explicit supersedence work, and line-of-business (LOB) apps require manual upload per update. That split holds whether apps land on physical endpoints or in Windows Cloud environments.
| App type | Packaging | Updates |
| Microsoft Store (WinGet) | None required | Automatic via the Store service |
| Enterprise App Catalog | Pre-packaged by Microsoft | Auto-update for required assignments |
| Win32 (.intunewin) | Manual per version | Manual repackage plus supersedence |
| Line-of-business (LOB) | Manual file upload | Manual upload per update |
Store and catalog apps update themselves
Microsoft Store apps managed through Windows Package Manager (WinGet) are the bright spot because Intune keeps them current automatically when new versions publish, with no packaging step. That makes app selection, not packaging, the main admin decision for this bucket. The old Store for Business path retired on August 15, 2024, so WinGet integration is now the only Store route.
Win32 and LOB apps require manual work for every version
That native automation does not extend across the full app estate. Win32 apps sit at the other end of the operating model. Every version must pass through the Win32 Content Prep Tool to become a .intunewin file, and no native mechanism generates those packages from vendor sources.
The operational problem is version churn. Each release becomes another packaging, detection, upload, and assignment cycle. Apps deploy through the Intune Management Extension, cap out at 30 GB, and need at least one detection rule. Intune re-offers a required app within roughly 24 hours if it detects the app as absent.
Since December 2025 you can upload a PowerShell script as the Win32 installer, which enables prerequisite checks and post-install actions, but the packaging step remains. LOB apps are stricter still where each update is a manually uploaded new file.
The packaging backlog carries a real security cost
The manual packaging gap is large enough that Microsoft's Enterprise App Management documentation lists removing those steps as a catalog benefit, stating that it simplifies "app lifecycle management by removing manual packaging and supersedence steps."
That backlog has a measurable security cost. The Qualys 2026 remediation benchmark found mean time to remediation for complex apps stretched to 5 months and 10 days, far slower than the pace at which vendors ship the patches waiting in the packaging queue.
Because the burden concentrates in Win32 and LOB apps, the standard first response is to script the workflow. That works, with caveats worth knowing before you commit.
Scripting the gap with Graph API and PowerShell
Once native automation runs out, the standard next step is to script the Win32 workflow. You can call Microsoft Graph directly, or you can wrap the workflow in a community PowerShell module. Both work, and both carry ongoing maintenance costs worth understanding before you commit.
Driving Win32 deployment directly through Microsoft Graph
You can drive every step of Win32 deployment through Microsoft Graph, but a single app takes multiple orchestrated calls.
Creation goes through POST /deviceAppManagement/mobileApps with the #microsoft.graph.win32LobApp type and requires the DeviceManagementApps.ReadWrite.All permission. A Microsoft employee confirmed on Microsoft Q&A that the workflow is sequential. You create the app object and content version, upload the file, commit it, then assign the app.
For install-status reporting, Microsoft deprecated the beta deviceStatuses endpoint in May 2023. Microsoft now recommends the DeviceInstallStatusByApp report through the Intune reporting API instead.
Wrapping the workflow with the IntuneWin32App module
The community-maintained IntuneWin32App PowerShell module (v1.4.1 on the PowerShell Gallery) wraps this workflow into 40+ functions that cover packaging, detection-rule setup, assignments, and app relationships like dependencies and supersedence. It also supports non-interactive authentication through a client secret or certificate.
A few production caveats are worth knowing before you standardize on it:
- The module creates assignments with installation deadline and availability set to "As soon as possible" only, so you can't specify a deadline.
- The CommitFile operation fails on PowerShell 7.4.0, and PowerShell 7.3.9 resolves it.
- Microsoft is removing authentication based on the global Microsoft Intune PowerShell application ID.
A fully cloud-native pipeline still needs a Windows host
Packaging carries a harder constraint. The Win32 Content Prep Tool (v1.8.7, released August 13, 2025 with FIPS compliance) cannot execute in the Azure Automation sandbox, so a fully cloud-native pipeline needs a self-hosted Windows agent.
Working patterns do exist. MSEndpointMgr's Intune App Factory combines Azure DevOps Pipelines with the module to check for new versions, download content, package, and publish. A community GitHub Actions proof of concept uses a self-hosted Windows runner with chunked Graph uploads for files up to 777 MB.
Every script route still needs a Windows host for packaging. It also needs someone to maintain the module through authentication migrations and keep per-app version-detection logic current indefinitely. That ongoing packaging and version-maintenance work is what managed catalogs reduce for supported catalog apps, and it's why platforms like Nerdio Manager for Enterprise move catalog selection, policy assignment, and deployment tracking into the management layer.
Publishing version 1.0 is the easy half. Keeping hundreds of apps current is where the hours go.
Automating updates across supersedence, catalogs, and third-party tools
Once packaging is under control, the next question is how new versions actually reach devices. Three mechanisms cover most of the estate, and each has a distinct fit.
Win32 supersedence works within tight limits
Native update automation for Win32 apps runs through Win32 app supersedence, and its constraints shape what you can actually automate.
A supersedence chain supports a maximum of 10 nodes (Win32 app documentation), and superseding apps get no automatic targeting, so each one needs explicit assignment. Auto-update through supersedence applies only to Available assignments, takes two device check-ins (typically 8 to 16 hours total), and requires the user to be signed in to receive the new version.
Detection rules must also be version-aware. A rule that matches every version leaves Intune treating older builds as compliant, so no update ever triggers. For MSI installs, the MSI product code is appropriate, with file-version or registry rules elsewhere.
Enterprise App Management removes packaging for 450+ apps
Enterprise App Management (EAM) changes this math for catalog apps. The Enterprise App Catalog contains more than 450 applications, and auto-update for required assignments reached general availability in July 2026. Intune detects a newer catalog version and updates targeted devices with no new app object and no supersedence relationship.
Most updates land within 24 hours of vendor release, and those needing manual validation typically arrive within seven days. Intune caches catalog data for up to one hour, and EAM has no rollout rings, so a new version deploys to every targeted device simultaneously.
Licensing shifted too. Effective July 1, 2026, Microsoft includes EAM in Microsoft 365 E5 alongside Endpoint Privilege Management and Cloud PKI, with select Intune Suite capabilities in E3.
Third-party and open-source tools cover apps outside the catalog
For apps outside the catalog, third-party or open-source tools can reduce the packaging cycle. Validate catalog coverage, rollout controls, platform support, and roadmap claims against your own app list before standardizing.
- Robopack is a catalog-driven packaging option for Windows endpoints.
- Intune App Factory is the open-source route, free and yours to maintain. You also maintain the Azure DevOps infrastructure underneath it.
For the Windows 365 and Azure Virtual Desktop lifecycle described here, those tools stop short of host-pool image and App Attach workflows. Updates are only half the lifecycle. Apps also have to arrive during provisioning, and on estates that mix Cloud PCs, laptops, and session hosts, that delivery problem splits in two.
Automating targeting and provisioning-time deployment
Updates only matter if the right app reaches the right device at the right time. Targeting rules, provisioning-time delivery, and Azure Virtual Desktop's separate model each shape what a shared automation approach has to cover.
Assignment design decides whether automation lands
Assignment design determines whether automation reaches the right devices at all. Intune supports required, available, and uninstall intents. Excluded groups take precedence over included groups, and mixing user and device groups in include/exclude combinations is unsupported per filter performance recommendations.
For large fleets, dynamic groups are preferable to static ones, and assignment filters help where speed matters. Filters evaluate device properties like OS version and enrollment profile directly at check-in, without waiting on dynamic group membership processing.
Autopilot and Windows 365 install apps before first login
Provisioning-time deployment has improved substantially. Effective January 30, 2026, a Windows Autopilot device preparation policy supports up to 25 apps during the OOBE (Out‑Of‑Box Experience), in both user-driven and automatic modes, including all Cloud PC offerings.
Automatic mode for Windows 365 reached general availability on May 11, 2026 for Windows 365 Enterprise and Cloud Apps. It installs apps and scripts right after Cloud PC creation, before a user ever logs in.
The Enrollment Status Page can separately block device use until required apps finish installing, with up to 100 apps in its blocking list. Dynamic groups aren't supported for targeting ESP profiles on Cloud PCs.
Azure Virtual Desktop follows a different delivery model
Azure Virtual Desktop works differently by design. Session hosts enroll in Intune only during session host deployment (new hosts), Microsoft doesn't support Intune management for hosts joined to Microsoft Entra Domain Services at all, and automatic Autopilot mode isn't a supported AVD scenario.
App delivery instead runs through three paths. Intune manages multi-session hosts like shared Windows client devices. Golden images handle all-user baseline apps. And App Attach, which is Azure Virtual Desktop only, attaches applications to user sessions without touching the image or requiring maintenance windows.
The practical result is two automation stacks. One Intune-side stack for Windows 365 and physical endpoints, and an image-and-App-Attach stack for Azure Virtual Desktop. A shared application catalog has to cover both Intune-managed endpoints and Azure Virtual Desktop host pools.
How Nerdio Manager automates app deployment across Windows 365, Intune, and Azure Virtual Desktop
Nerdio Manager's Unified Application Management (UAM) consolidates applications from WinGet public and private repositories, Microsoft Store, MSIX App Attach, Microsoft Intune, and other 3rd party LOB installers into a single catalog.
Deployment is policy-based, so new and reimaged devices automatically receive their required applications. Targets span Windows 365 Cloud PCs and Intune-enrolled physical devices as well as Azure Virtual Desktop host pools, which is the scope none of the Intune-focused tools above cover.
UAM uses two deployment paths, depending on whether the target is an Intune-managed endpoint or an Azure Virtual Desktop host pool.
Deployment path for Windows 365 and Intune-enrolled endpoints
Nerdio Manager deploys applications to Windows 365 endpoints in about 30 seconds, versus native Intune delivery that can take up to 3 hours since Intune doesn't poll continuously. It also creates, backs up, and restores Intune policies. Native Intune cannot restore a deleted policy. UAM supports policy-based deployment so new and reimaged devices receive required applications.
Deployment path for Azure Virtual Desktop host pools
Desktop orchestration builds app delivery into the image lifecycle. A benchmark by Dr. Benny Tritsch compared native Azure Virtual Desktop administration with Nerdio Manager across resource-management workflows. Updating a custom image dropped from 5:09 and 146 clicks to 0:37 and 13 clicks, and reimaging session hosts dropped from 4:50 and 90 clicks to 0:44 and 10 clicks. Fewer clicks mean fewer manual steps and fewer opportunities for configuration errors.
For per-user delivery, Nerdio Manager includes MSIX App Attach in the same application catalog.
Many enterprises run both Windows 365 and Azure Virtual Desktop. Teams can reuse application definitions and deployment policies from the same console across both paths, so you build the automation once instead of twice.
Your Intune application deployment automation roadmap
Given everything above, sequence the work by effort-to-payoff rather than app count.
- Reclassify first. Move every app with a Store listing to the WinGet-backed Microsoft Store integration. Updates become automatic with zero packaging effort.
- Check your E5 entitlement. If you hold Microsoft 365 E5, enable EAM auto-update with required assignments for catalog apps before renewing any third-party patching contract; the July 2026 bundling may already cover part of what you're paying for.
- Fix detection rules before automating anything else. Version-blind rules silently defeat every update mechanism downstream.
- Decide pipeline versus platform for the long tail. If you script it, budget permanently for a self-hosted runner, module upkeep, and authentication changes. If you buy it, confirm the tool reaches every device type you actually run.
- Unify before you scale. If your estate includes Cloud PCs or session hosts, pick tooling that spans them, or you'll maintain two automation stacks that drift apart.
Done well, third-party app updates stop being a recurring chore, flowing from a catalog instead of a repackaging cycle across Cloud PCs and session hosts alike. Get a demo to see how Nerdio Manager works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.
Frequently asked questions about how to automate Microsoft Intune application deployment
Resources
Learn more about Nerdio Manager
