Skip to content

Change management

An Intune change can reach every device in the company within hours. Good change management is what lets you move quickly without breaking things: small changes, tested on a few devices first, with a way back.

Principles

  1. Every change goes through rings. Even "small" ones. A single wrong value in a widely assigned profile can lock out thousands of users.
  2. Change one thing at a time. If two changes ship together and something breaks, you won't know which one did it.
  3. Know how you'll roll back before you roll forward.
  4. Write it down. What changed, why, who approved it, and which ring it's in.
  5. Two people for high-impact changes. Use Multi Admin Approval for the riskiest resources.

Rollout rings

Ring Who How long before the next ring
Ring 0: IT test IT's own test devices, one of each important model and platform 1 to 2 days
Ring 1: Pilot About 5% of users: a mix of departments, locations and hardware, including people who will report problems About a week
Ring 2: Broad Everyone else n/a

Keep ring groups static and owned by the Intune team. Add or remove members deliberately, not through dynamic rules. See Targeting.

For very large or sensitive changes, add an extra early ring or split the broad ring by region.

Deployment plans

Deployment plans (public preview since September 2026) let Intune run ring rollouts for you. Find them under Devices > Manage devices > Deployments.

  • A deployment plan is a reusable template: rings, the groups and assignment filters in each ring, and the delay between rings. It doesn't contain a payload.
  • A deployment applies one payload (an app or a policy) through a plan's rings, or through rings you define just for that deployment. You can pause, resume or cancel it.

Current rules and limits:

Rule Detail
Supported payloads Windows settings catalog and endpoint security policies; Win32 and Enterprise App Catalog apps (Required intent only)
Timing At least one hour between rings
Virtual groups A ring with All users or All devices becomes the final ring and can't be mixed with Entra groups
Exclusions Exclude groups apply to every ring
Collisions A group can't be both in the payload's own assignments and in a deployment ring. Intune checks at creation and at each ring activation, and pauses the deployment if it finds one.
One at a time A payload can only be in one scheduled or active deployment
Approvals Deployments integrate with Multi Admin Approval

Deployments don't lock the payload. If you edit the policy mid-rollout, devices that already have it get the change at their next check-in, and later rings get the edited version.

A lightweight change record

You don't need heavy process, but every change should answer these questions:

**Change:** Enable LSA protection on Windows (security baseline 25H2 default)
**Why:** Close credential theft gap from Q3 security review (ticket SEC-1234)
**Objects:** WIN-SC-CredentialProtection-AllDevices-v1 (new)
**Rings:** Ring 0 on 3 Nov, Ring 1 on 5 Nov, Ring 2 on 12 Nov
**Test:** Sign-in, VPN, smart card readers, the finance add-in
**Rollback:** Unassign profile; LSA protection with UEFI lock needs local action to remove, so pilot carefully
**Owner / approver:** A. Admin / B. Lead

Back up your configuration

Intune has no "undo" and no built-in version history for most objects. Back up your configuration regularly:

  • What: configuration profiles, compliance policies, endpoint security policies, app protection and configuration policies, scripts, filters, enrollment profiles, and their assignments.
  • How: Microsoft365DSC, the community IntuneManagement tool, or your own Graph scripts. See Automation with Graph.
  • Where: a Git repository, so every backup is a commit and you can see exactly what changed between two dates.
  • How often: at least weekly, and before any large change.

Restoring has limits. A restored object gets new IDs, assignments reference group IDs that must still exist, and some settings (such as certificates and secrets) don't export. Test a restore once a quarter so you know what works.

Rolling back

Situation How to roll back
Bad configuration setting Assign a profile with the previous value. Don't rely on unassigning: some Windows settings stay (tattoo), and most Android settings do.
Bad app version Reassign the previous version, or use supersedence to replace the new version with the old one
Bad Windows quality update Pause quality updates in the affected rings, then uninstall the update if needed. Hotpatch updates can be uninstalled too (with a restart).
Bad Windows feature update Users or scripts can roll back within the update ring's feature update uninstall period. Pause the feature update policy rollout.
Bad Conditional Access policy Switch it to report-only or off. Break-glass accounts get you in if admins are locked out.
Bad app protection setting Edit the policy. Changes reach signed-in users within hours, faster if they sign out and in.

Keeping up with Microsoft's changes

Intune changes every month, and Microsoft retires features on published schedules. Assign someone to read:

Source What it tells you How often
What's new in Intune Features that shipped, and notices Weekly
In development What's coming soon Monthly
Microsoft 365 Message center Changes and retirements affecting your tenant, with dates Weekly
Windows release health Windows updates, known issues and safeguard holds Weekly, and on Patch Tuesday
Apple and Google release notes OS changes that affect MDM, DDM and Android Enterprise Around each major release

Treat "Plan for change" notices as backlog items with a due date. Many of the incidents in this handbook (Apple software update policies, the approved client app grant, the Active Directory connector, certificate strong mapping) were announced months in advance.

Learn more