In Intune, a deployment is an assignment. Whether that assignment results in a successful installation on every target device is a different question entirely and for most enterprise estates, it is one that goes unanswered in real time.
Most IT Operations teams know this gap exists. They have experienced it: an application is assigned to 2,000 devices, the Intune dashboard shows the deployment as active, and three days later a helpdesk spike reveals that 340 devices in a particular building or VPN segment have failed silently. The failure was always there. Nobody was watching for it.
In a phased rollout, that gap is the difference between a 10% canary group surfacing an issue before it reaches the full estate, and a 100% deployment that is already done by the time the problem is visible.
Deployment monitoring is real-time visibility into what is happening to an application package after it leaves Intune’s assignment layer.
It means knowing, at any point during an active rollout:
And critically: knowing this broken down by phase so that Phase 1 results can be reviewed and a threshold confirmed before Phase 2 begins.
Without this, deployment is a push into the dark. You know what you assigned. You do not know what actually happened.
Microsoft Intune is designed around assignments. You assign an application to a group. Intune schedules delivery. The Intune Management Extension on each device handles the installation when conditions are met.
For most deployments, this works. For large-scale enterprise rollouts particularly of complex Win32 applications, or applications with specific dependency or connectivity requirements silent failures are common and not immediately visible.
Intune’s reporting is asynchronous. Device check-in intervals, network conditions, policy processing delays, and client-side failures all affect whether the installation summary in Intune reflects what is actually happening on endpoints in real time.
For a small estate, this is manageable. For a 5,000-device estate in a phased rollout, an asynchronous reporting lag combined with no threshold gating means phase progression decisions can be made on incomplete data.
Silent deployment failures follow a consistent pattern.
An application is deployed to a 500-device Phase 1 group. Intune shows 420 successful installations. 80 devices report ‘failed’ or remain in ‘pending’ indefinitely. The failure codes are not surfaced proactively. The IT team, watching a summary dashboard, sees ‘84% installed’ and proceeds to Phase 2.
Phase 2 covers 2,500 devices. The same failure pattern affects 400 devices but now at a scale that generates helpdesk volume. Investigation reveals the root cause: a specific device configuration that the test group did not include. The fix requires repackaging, re-deployment, and an additional test cycle.
Had the Phase 1 threshold not been met, the progression would have paused. The issue would have been diagnosed and resolved before 2,500 devices were affected.
That pause requires monitoring. Monitoring requires real-time data, not a 24-hour Intune reporting lag.
ALICE fetches real-time installation summaries from Intune for every active deployment, broken down by phase.
For each active rollout, ALICE displays:
These counts are live. They reflect the current state of the deployment, not a scheduled report.
ALICE tracks progress independently for each phase of a phased rollout: Phase 1 (10%), Phase 2 (50%), Phase 3 (100%). Each phase shows its own installation summary.
This separation is the operational intelligence that aggregate reporting cannot provide. Phase 1 completion at 94% with 6% failed is a different decision from 94% installed, 6% pending. ALICE surfaces both distinctly.
Before Phase 2 begins, ALICE checks whether Phase 1 has met the configured success threshold the minimum percentage of successful installations required before progression is permitted.
This threshold is tenant-configurable. Organisations with high-risk application profiles or sensitive device populations can require 95%+ Phase 1 success. Organisations with predictable estate characteristics can configure lower thresholds appropriate to their risk tolerance.
If the threshold is not met, Phase 2 does not begin whether the trigger for progression is manual or automated. The IT team is alerted and the deployment pauses for investigation.
This is the mechanism that converts a deployment pipeline into a deployment control system.
For teams managing large application estates with frequent update cycles, manual phase progression across every application is not operationally practical.
ALICE’s background scheduler monitors installation success rates on a configurable per-tenant interval (from every 5 minutes to every 30 minutes, or disabled entirely for fully manual control). When a phase meets its success threshold, the scheduler automatically triggers the next phase without requiring a manual review for every deployment.
For high-priority or sensitive applications, manual gate control remains available. The scheduler handles volume. The team handles exceptions.
Email notifications are sent to application owners at every phase transition, whether triggered manually or automatically. The owner knows what happened, when, and what succeeded.
For multi-tenant environments post-acquisition estates or organisations with divisional Intune tenants ALICE provides deployment monitoring across all tenants in a single view.
A deployment that is running across Tenant A (2,000 devices) and Tenant B (1,400 devices) simultaneously is monitored in aggregate and per-tenant. A failure pattern isolated to Tenant B’s device population is surfaced immediately, without the need to cross-reference two separate Intune consoles.
For compliance and security teams managing patch SLA across a multi-tenant estate, this provides the consolidated reporting that manual cross-tenant queries cannot produce in real time.
If you are running phased application deployments across a large estate and want to see what real-time monitoring and threshold gating look like in practice, book a demo.
We will walk through an active deployment view, phase progression controls, and how monitoring integrates with the full ALICE lifecycle pipeline.
ALICE is Camwood‘s platform for Autonomous Application Lifecycle Management. Deployment is not complete when the assignment is made. It is complete when every target device has successfully installed the application and you can see that, in real time, at every phase.
