Endpoint and Device Management: A Production Playbook

Endpoint and device management is the operational backbone that connects identity, security, and productivity in a modern enterprise. If you are joining a production team responsible for a Microsoft 365 or hybrid AWS/Azure environment, you will inherit devices already enrolled, policies already assigned, and compliance states that directly gate access to corporate resources. This tutorial walks through the concepts, tooling, and day-to-day operational discipline you need to manage endpoints safely without breaking production access for end users.

#What You Need Before You Start

Endpoint management touches identity, compliance, and access control simultaneously, so before you make any change in a production tenant, confirm the following prerequisites and permissions:

• An Entra ID account with the Intune Administrator role, not Global Administrator. Global Administrator is over-privileged for device operations and should be reserved for break-glass scenarios. If your tenant uses scope tags for delegated administration, confirm your role is also constrained to the correct scope tag before you touch any policy object.
• Confirmation that the target devices are licensed for Intune (Microsoft 365 E3/E5, EMS E3/E5, or a standalone Intune license). Unlicensed devices can enroll in some configurations but will not receive compliance or configuration policies reliably, which produces confusing “policy not applied” tickets later.
• Access to the Microsoft Intune admin center (endpoint.microsoft.com) and, where policy changes need auditing, the Microsoft Graph PowerShell SDK or Graph Explorer with at least DeviceManagementConfiguration.Read.All and, for write operations, DeviceManagementConfiguration.ReadWrite.All consented on your account or the app registration you use for scripted changes.
• Knowledge of your organisation’s device naming convention, dynamic group structure, and existing Conditional Access policies — changing a compliance policy without checking Conditional Access dependencies is one of the most common causes of unplanned lockouts.
• A documented change record if your organisation uses ITIL-style change management (ServiceNow, Jira Service Management, or similar). Device policy changes are production changes; treat them accordingly, including a named approver and a rollback owner.
• A known-good “break-glass” account that is excluded from Conditional Access policies and device compliance requirements, tested and confirmed working before you begin. If a compliance change locks out the wrong group, this account is how you regain administrative access without waiting on someone else’s help desk.

#Understanding the Device Lifecycle

Every managed device moves through a predictable lifecycle, and your operational responsibilities differ at each stage:

1. Enrollment — the device registers with Entra ID and enrolls into Intune, either via Windows Autopilot, Apple Automated Device Enrollment, or Android Enterprise enrollment.
2. Configuration — configuration profiles push settings such as Wi-Fi, VPN, BitLocker, or endpoint firewall rules.
3. Compliance evaluation — compliance policies assess the device against rules (encryption enabled, OS version, jailbreak/root detection) and produce a compliance state consumed by Conditional Access.
4. Ongoing management — patch management, application deployment, and security baseline enforcement continue for the device’s operational life.
5. Retirement — the device is wiped, retired, or its corporate data selectively removed when it leaves the fleet (offboarding, loss, or replacement).

Production incidents almost always originate at the boundary between stages — a device that enrolled but never received its compliance policy, or a configuration profile that conflicts with an existing one and silently fails to apply. Treat each transition between stages as a checkpoint worth its own verification step rather than assuming the platform will always progress a device cleanly from one stage to the next.

#Step-by-Step: Assigning a Compliance Policy Safely

This is the single most common day-to-day task you will perform. The example below targets Windows devices, but the same staged approach applies to macOS, iOS, and Android policies.

1. In the Intune admin center, navigate to Devices > Compliance policies > Create policy, select the platform, and define your rules (for example, require BitLocker, require a minimum OS build, require Microsoft Defender to be active).
2. Under Actions for noncompliance, configure a grace period (commonly 24–72 hours) before Conditional Access enforcement triggers. This gives users time to remediate without an immediate access block.
3. Assign the policy to a pilot dynamic group first — never assign directly to “All Devices” on first rollout. A dynamic group scoped to a department or a small percentage of the fleet lets you observe impact before wider deployment.
4. Apply a scope tag matching your team’s delegated administrative boundary. Scope tags enforce least privilege by ensuring regional or business-unit admins can only manage the devices assigned to their tag.
5. Save and monitor for at least one full device sync cycle (Intune sync intervals default to roughly every 8 hours, though users can force a sync from the Company Portal or via Get-Sync in the Intune app).

For teams that prefer scripted, auditable changes over portal clicks, the same assignment can be validated through Microsoft Graph. A read-only check before widening scope might look like this:

1GET https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies/{policyId}/assignments

Compare the returned group IDs against your pilot group’s object ID before you edit the assignment to include the broader ring. This small discipline prevents the surprisingly common mistake of editing the wrong policy object when two policies have similar display names.

#Verifying the Rollout

Do not assume a policy assignment succeeded because the portal accepted it. Verify using at least two independent signals, and record the evidence in your change ticket so the rollout is auditable after the fact.

Treat any mismatch between these sources as a stop signal. Widening a rollout while one of your evidence sources disagrees with the others is how a contained pilot issue becomes a tenant-wide incident.

#Common Failure Modes and Diagnostic Table

Recognising these patterns early will save you hours of troubleshooting. The table below maps the symptom you will see in a ticket to the likely cause and the first diagnostic action to take.

#Monitoring and Ongoing Operational Health

Verification at the point of rollout is necessary but not sufficient; endpoint fleets drift over time as new devices enroll, users change roles, and OS updates change compliance posture. Build monitoring around three recurring checks rather than relying solely on ad hoc verification during a change window:

• Daily compliance trend — export or dashboard the percentage of noncompliant devices per platform. A sudden spike after a Patch Tuesday or an OS feature update usually indicates a compliance rule that needs an updated minimum OS build rather than a genuine security regression.
• Stale device report — devices that have not checked in for 30+ days should be reviewed for retirement; they inflate your compliance denominator and can mask real issues in reporting.
• Assignment drift audit — periodically export policy assignments via Graph and diff them against your change log. Undocumented assignment changes, whether from a delegated admin or an automation script, are a common source of “it worked yesterday” incidents.

Where possible, feed Intune compliance and enrollment failure logs into your existing SIEM or log analytics workspace alongside Entra ID sign-in logs. Correlating a spike in Conditional Access blocks with a specific compliance policy change dramatically shortens incident triage time compared with checking each portal in isolation.

#Rollback and Change Management

Every policy change should have a documented rollback path before you deploy it, written down in the change record before the change goes live, not improvised after something breaks:

1. Unassign, don’t delete, first. Removing the group assignment from a policy is faster and safer than deleting the policy object, and it preserves your configuration for re-deployment after fixing the issue.
2. Use staged rings. Structure rollouts as Pilot (1–5% of devices) → Broad (25–50%) → Production (100%), with a minimum 24-hour observation window between rings for anything touching Conditional Access or encryption enforcement. Do not compress this window to meet an arbitrary deadline; the observation window is what turns a potential outage into a caught pilot issue.
3. For compromised or lost devices, use Retire (removes corporate data and management, leaves personal data on BYOD devices) or Wipe (full factory reset, corporate-owned devices) from the Intune device blade — these actions cannot be undone, so confirm the correct device serial number and last check-in timestamp before executing.
4. Log every change in your change management system with the policy name, assignment scope, before/after configuration snapshot, and rollback owner, so an on-call engineer unfamiliar with the change can reverse it without needing you specifically at 2 a.m.
5. Rehearse the rollback for any change touching Conditional Access or BitLocker enforcement by testing the unassign action against a non-production or low-impact pilot group first, confirming that removal restores prior access behaviour within one sync cycle.

If a rollback is triggered mid-incident, communicate the reversal to affected users and to your service desk immediately — a silent rollback without notification tends to generate duplicate tickets and confuses anyone still troubleshooting the original symptom.

#Where AWS and Hybrid Fleets Fit In

If your organisation also manages EC2-based servers or hybrid endpoints, device management extends beyond Intune. AWS Systems Manager (SSM) Agent provides patch compliance, inventory, and session management for server fleets in a manner conceptually similar to Intune’s compliance model. Treat SSM patch baselines and maintenance windows with the same staged-rollout discipline described above — a patch baseline pushed to “all instances” without a pilot tag is the server-side equivalent of assigning a compliance policy to “All Devices” without testing first. Use resource tags to build your SSM equivalent of a pilot dynamic group, and confirm patch compliance via aws ssm describe-instance-patch-states before widening a maintenance window across the fleet, mirroring the Graph-based verification step used for Intune. Where identity is federated between Entra ID and AWS IAM Identity Center, remember that a device compliance change in Intune can indirectly affect AWS console access if Conditional Access policies gate federated sign-in, so cross-check both systems’ access logs when investigating an access issue that spans both platforms.

Endpoint and device management is not a one-time configuration task; it is continuous operational stewardship of the boundary between user productivity and organisational security. The discipline that matters most is not any single portal setting but the habit of piloting changes, verifying outcomes against independent data sources, monitoring for drift after the change window closes, and always knowing your rollback path before you click deploy. Build that habit now, document it consistently in your change records, and you will handle production incidents calmly rather than reactively — and just as importantly, you will hand off a fleet that the next engineer on your team can understand and safely modify without having to reverse-engineer your intent from the audit log alone.