Month: October 2026

Microsoft Intune Deployment Plans in Preview

Intune deployment plans are now in public preview. Why? Because repeatedly changing group assignments to move a rollout along is a faff, and this gives us a reusable way to stage it.

Start in Devices > Manage devices > Deployments. Create a plan with your test, pilot and broader groups, then set the wait between rings. The plan holds the rollout pattern; a deployment uses it to deliver one app or policy. I would begin with a harmless settings catalog change on test devices.


Watch out for existing assignments. They remain on the underlying app or policy, so a pre-existing broad assignment can defeat your carefully staged deployment plan. If a group assignment collides with an existing payload assignment (payload being the underlying app or policy), Intune places the deployment in an error state and prevents further rollout until the conflict is resolved.

The preview supports Windows Win32 apps, Enterprise App Catalog apps, settings catalog policies and endpoint security policies. For apps, it supports Required installations, not Available or Uninstall. Enterprise App Catalog auto-update is not supported with deployments.

This of course does not replace the need to test the payload changes yourself before you send it to your deployment plan! You can pause, resume or cancel deployments, but cancelling a deployment doesn’t automatically act as a rollback, so consider how you’ll recover devices that have already received the change.

https://learn.microsoft.com/en-us/intune/device-management/deployments/overview

Understanding the Autopilot Lifecycle in Microsoft Foundry

Autopilot agents in Microsoft Foundry are digital workers that operate under two identities: an agent identity and an agent user account.

The agent identity is the standard Entra identity used for authentication and governance. The additional user account is what makes an agent an autopilot agent. It gives the agent its own email, calendar, OneDrive, Teams presence, and a place in the organisation chart. This allows the agent to participate naturally in Teams chats, access SharePoint, respond to events, and work with groups rather than only individuals.

Without this user account, an agent can only perform Microsoft 365 actions on behalf of a signed‑in user, which is limiting in collaborative or event‑driven scenarios. The autopilot model resolves this by giving the agent a persistent identity that fits into everyday organisational workflows.

The lifecycle begins with the Blueprint layer. Developers define the agent’s purpose, capabilities, and boundaries, then publish the blueprint. This becomes the template for every instance created later and is effectively the agent’s job description and technical specification.

The Instance layer is where managers hire agents from that blueprint. Each instance receives its own identity, is onboarded into a team, and is granted access to the resources it needs. This is where the agent becomes operational and able to work within Microsoft 365 surfaces such as Teams and SharePoint.

Above both sits the Fleet layer, owned by tenant administrators. This is where approval, policy, consent, licensing, and oversight are applied. The fleet view provides visibility across all agents in the tenant and ensures they comply with organisational rules.

The lifecycle follows a predictable sequence:

✅ Provision – Azure administrators set up the Foundry platform and assign developer permissions.

✅ Build and publish – developers define and test the blueprint.

✅ Approve and configure – tenant administrators review the blueprint, apply policy, and decide who can hire agents from it.

✅ Hire – managers create an instance and give it a role.

✅ Onboard – access managers or team leads grant the agent the resources it needs.

✅ Operate – the agent performs its work, with managers and teammates observing and adjusting as required.

✅ Offboard – when the agent is no longer required, the manager removes it.

✅ Retire or delete – tenant administrators or developers stop new hires or remove the blueprint entirely.

The strength of this model is in its clarity. Each role has a defined responsibility. Autopilot agents become part of the organisation’s operational structure rather than isolated experiments, making them easier to govern, secure, and scale.

Further reading: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/autopilot-lifecycle