Building EPM elevation rules both ways: promoted from the report or from scratch with PowerShell-gathered evidence, the three decisions every rule forces, four worked examples including a deny rule, and the per-persona policy structure that beats sprawl.
Constructing the EPM approval workflow: the approver group that needs no EPM license, a custom Intune role holding only the Elevation Requests permission, the three-part role assignment, a Signal-Action-Why triage discipline, and a queue cadence that survives contact with reality.
The EPM pilot as a build sheet: the user-targeted pilot group with the licensing rationale, the elevation settings policy with every value given and the Not Configured trap named, assignment, three-check device validation, and one elevation request run end to end.
EPM rollout has two halves that move together: expanding rings with the pilot playbook, and actually removing standing local admin as each ring proves out. Plus the operating cadence, rule hygiene, and the four failure modes that kill deployments.
The EPM pilot is a discovery phase, not an agent test: run support-approved with no rules, triage the request queue nobody notifies you about, and promote repeated requests into rules with deliberate choices on anchor, elevation type, and child process behavior.
The EPM build is one policy and one decision: licensing reality including the EM+S trap, the elevation settings policy that provisions the agent, full-scope reporting as the discovery instrument, and why support approved is the right default elevation response.
Update management built on the old MDM commands stops functioning in the 27.0 releases this fall. Declarative Device Management moves the enforcement into the device itself, and that changes what an update policy is.
One assistant that is genuinely GA, three agents still in preview, and one already retired. A status map of Copilot in Intune, and where AI can carry weight in a production tenant today.
