writing

Autopilot as state orchestration

A practical model for thinking about Intune and Autopilot in hybrid environments: not as a step-by-step script runner, but as an asynchronous system that needs readiness gates where strict sequencing is non-negotiable.

Date
Area
Endpoint provisioning
Status
Working draft

The model that kept failing me

The default mental model for Autopilot is simple: configure policy, provision device, and let the platform carry the machine into the desired state.

In practice, the failures I kept seeing were quieter than outright deployment failure. The portal reported success, compliance looked green, and the device was still wrong in the way that counted operationally. Recovery keys were missing. Applications landed before their prerequisites were usable. A deployment looked complete from the service side while the useful end state had not actually converged on the device.

The model that fits those failures is not a linear one. Autopilot and Intune behave more like asynchronous state-convergence systems: several services working toward a desired state, not a script executing one guaranteed step after another.

That is not a claim about Microsoft's internal implementation beyond what is publicly documented. It is a working model built from documented ESP behaviour, known hybrid timing issues, and failures I have seen in production.

What the platform documents

Microsoft documents the Enrollment Status Page as a phased process:

  • Device Preparation
  • Device Setup
  • Account Setup

That distinction is important because the platform is not simply executing a linear script written by the admin. Different services are participating in parallel: device registration, identity propagation, policy delivery, Win32 application handling, and user-context work.

In hybrid environments especially, there can be a meaningful gap between a device appearing registered and every downstream dependency being fully ready. Microsoft and community troubleshooting around errors like 0x801c03f3 point to exactly that sort of timing problem: the device can be far enough along to look enrolled while parts of the backend state are still catching up.

I am not asserting a hidden vendor specification. The documented phases, observed timing gaps, and failure patterns are enough to make state convergence a more useful operating model than a guaranteed ordered sequence.

Example one: BitLocker escrow

One of the clearest examples was BitLocker in a hybrid environment.

The policy was implemented according to best practice. It applied successfully, including key escrow on machines that were already in production. With autopiloted devices, encryption completed and compliance reporting showed green checks, but recovery keys were missing.

The explanation that best fit the evidence was not “BitLocker failed” in the simple sense. Policy delivery and encryption could succeed before the device was in a state where escrow would complete reliably, even though the policy required escrow before encryption began.

For the machines autopiloted under these conditions, I implemented key escrow through a detection and remediation script pairing.

The lack of pre-encryption escrow was unacceptable, so the desired state needed to be enforced and verified separately from the compliance result.

Instead of treating the issue as a pure policy problem, the more reliable pattern was to treat it as an execution-and-verification problem: run the work through a Win32 application, explicitly handle protector creation and escrow, and use detection logic that only reports success when the recovery material is actually present where it needs to be.

That is a different engineering posture from setting the policy and assuming the platform will enforce the order correctly.

Example two: application ordering

I hit a similar problem with application dependencies.

In one rollout, one application needed to be fully present before a second application could succeed. I set the dependency in Intune. The dependency was real. The runtime result still failed.

The dependency rule was not useless, but it was not the same thing as a verified readiness gate.

A dependency can stop one installer from starting too early according to the platform's rules. It does not automatically guarantee that every downstream artifact the second application expects is present, settled, and usable at the moment it begins.

That gap shows up most clearly under real provisioning conditions, where retries, concurrent evaluation, identity timing, and post-install settling behaviour all interact.

The practical reframe

The useful provisioning question is often not:

“What is the next step?”

It is:

“What must already be verifiably true before the next thing is allowed to proceed?”

That is the shift from configuration steps to readiness states.

When strict sequencing is genuinely required, I have had better results by building explicit gates:

  • verify the required state
  • report failure if the state is not ready
  • let detection logic determine whether the deployment is truly complete
  • block downstream work until the condition is real, not merely intended

Win32 applications are often the practical mechanism for doing this in Intune because they provide detection logic, retry behaviour, and a way to tie success to an actual verified outcome instead of an optimistic assumption.

Operational effect

This model changes the checks I reach for.

A linear deployment model pushes me toward checking whether the policy exists, whether the assignment is correct, and whether the portal shows success.

A state-convergence model pushes me toward different questions:

  • Is the identity plane actually ready for the operation I expect?
  • Does installed mean usable, or only copied?
  • What condition proves the device is genuinely ready?
  • What can race here?
  • What should be gated instead of merely assigned?

Those questions lead to more useful diagnostics and safer deployment design.

Boundaries

This is not a universal law of Intune.

Many Autopilot deployments work perfectly well with ordinary policy and dependency configuration. Not every problem needs a gate, and overengineering a provisioning flow can create a different class of failure.

The narrower claim is this: in hybrid and timing-sensitive scenarios, especially where encryption, identity-dependent actions, or tightly ordered application chains are involved, declared intent and actual readiness are not always the same thing.

That assumption has served me better than trusting the green checkmark too early.

What changed in my practice

The lasting change for me was not a single script or workaround.

It was learning to design for verifiable readiness.

That means:

  • treating success states skeptically until the operational outcome is confirmed
  • using detection rules as part of orchestration, not just reporting
  • preferring explicit gates where race conditions have real consequences
  • separating what is documented, what is observed, and what is inferred

Autopilot is powerful. But the more useful way to think about it is as a cloud-coordinated provisioning system that still depends on local state becoming true at the right time.

When the required state is high-consequence, I trust a verified gate more than a declared dependency.

Sources and further reading

  • Microsoft Learn: Troubleshoot the Enrollment Status Page
  • Microsoft Learn: Encrypt Windows devices with BitLocker using Intune
  • Nickolaj Andersen / MSEndpointMgr: Silently enable BitLocker for Hybrid Azure AD joined devices using Windows Autopilot
  • Patch My PC: Under the Hood of the IME: The ESP Phases Explained
  • call4cloud.nl: BitLocker remediation / escrow notes for Intune environments
  • Microsoft Learn: Windows Autopilot known issues