Learning Endpoint and Device Management Through a Safe Microsoft Intune Lab

#Introduction

Microsoft Intune is the endpoint management service that most graduate engineers meet first when an organisation needs to enrol, configure and monitor devices it does not physically control. Endpoint and device management exists because unmanaged devices are a governance and security liability: without a managed compliance and configuration layer, nobody can reliably confirm that a laptop connecting to corporate email is encrypted, patched or still assigned to a current employee. This guide builds a safe, bounded understanding of how Microsoft Intune expresses that management logic, using a lab you can run without touching production identities, production devices or real user data. The guide assumes you have access to an isolated or trial tenant rather than a live corporate environment, and that you will confirm your own tenant’s current Intune version, licensing and permissions before repeating any step described here.

#Learning Objectives

• Explain how Microsoft Intune expresses endpoint and device management through compliance policies, configuration profiles and assignment groups.
• Design one bounded Intune compliance policy exercise scoped to a dedicated, non-production test group.
• Validate device compliance state using both the Intune admin centre and read-only Microsoft Graph PowerShell queries.
• Roll back a test assignment safely and confirm the rollback with observable evidence.
• Recognise when a compliance or configuration outcome must be escalated rather than resolved independently.

#Prerequisites

• Access to an isolated or non-production Microsoft 365 / Intune tenant (trial or lab tenant), not a live production tenant.
• An Intune administrative role scoped, where possible, to a single test group, confirmed before you begin.
• Confirmation of your own tenant’s current Intune and Microsoft Graph API version, and applicable licence entitlement, since this guide does not assume a specific version.
• Basic familiarity with device management vocabulary: enrolment, policy, profile and assignment.

#Content

#

Core Concepts

Microsoft Intune manages devices through four cooperating objects. A compliance policy defines the minimum security posture a device must meet, such as disk encryption or a minimum operating system version. A configuration profile pushes settings onto a device, such as a Wi-Fi configuration or a restriction. An assignment connects a policy or profile to a target — almost always a group rather than an individual device, so that scope stays deliberate and auditable. A device’s compliance state is the evaluated outcome, refreshed on a check-in cycle rather than instantly, and it is this state that downstream systems such as Conditional Access can consume as a signal.

#

How the Workflow Fits Together

In production, the sequence is: a device enrols into Intune; an administrator authors a compliance policy and a configuration profile; both are assigned to a group; the device checks in on its own schedule and evaluates against the assigned policy; and the resulting compliance state becomes visible in the admin centre and, in mature tenants, feeds Conditional Access decisions elsewhere. The lab in this guide reproduces every stage of that sequence except the last, because Conditional Access integration touches identity infrastructure that is out of scope for a bounded device-management exercise.

#

Warnings and Risk Considerations

• Caution: compliance and configuration assignments are state-changing even when the review step beforehand was read-only; do not follow an unreviewed read with an unreviewed apply.
• Caution: never target “All devices” or “All users” during this exercise; use one dedicated test group with a known, small membership you control.
• Danger: do not repeat this workflow against a tenant containing real employee devices. The permission scopes used here can change a device’s compliance state and, in a production tenant, that state can influence network or application access decisions for a real person.

#Examples

The safest way to build this workflow is portal-first, with Microsoft Graph PowerShell used only to verify what the portal already shows, not to skip past it.

#

Portal-based example

1. In the Intune admin centre, navigate to your device compliance area and create a new policy scoped to the platform of your test device (for example, Windows).
2. Set one clear requirement, such as disk encryption, so the exercise produces an unambiguous compliant/non-compliant result.
3. Assign the policy to your dedicated test group only, and confirm the group’s membership list on screen before saving.
4. Wait for at least one device check-in cycle before judging the result; compliance state does not update instantly.

#

Graph PowerShell verification example

Once the portal-based assignment is visible, a read-only Graph query lets you confirm the same fact programmatically, which is good practice before trusting a dashboard view alone. The exact cmdlet names and required scopes for your tenant’s current Microsoft Graph PowerShell SDK version should be confirmed against your own environment before use, since this detail changes between SDK releases and is not treated as verified for this guide.

1Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
2Get-MgDeviceManagementDeviceCompliancePolicy
3Get-MgDeviceManagementDeviceCompliancePolicyAssignment -DeviceCompliancePolicyId <policy-id>

#Exercises

Run this bounded exercise only inside your isolated tenant, with a test group containing one or two devices you are explicitly permitted to change.

1. Scope: one compliance policy, one assignment group, one or two test devices. No production users, groups or devices are touched.
2. Action: create the compliance policy described above, assign it to the test group, and record the exact group id and policy id before proceeding.
3. Stop condition: if the assignment step shows any group other than the intended test group, stop immediately and remove the assignment before investigating.
4. Observation window: allow at least one full device check-in cycle before reading the compliance state as final.
5. Rollback: remove the assignment using the Graph rollback command or the portal’s assignment removal control, then confirm the removal in the audit log.

#Validation Guidance

Treat compliance state as evidence, not as an instant confirmation. A device that has not checked in recently will show “not evaluated” rather than a real result, and reading that as a failure is a common source of confusion.

• Confirm the assignment target in the portal matches only your test group id.
• Confirm the same fact independently using the read-only Graph query shown above.
• Confirm the audit log records the assignment action with your identity and a plausible timestamp.
• Confirm the test device’s compliance state updates within one expected check-in cycle, and investigate rather than assume if it does not.

#

Escalation Path

Escalate to a senior Intune administrator or the platform owner, rather than continuing independently, if: the assignment appears against an unintended group; the compliance state contradicts the device’s known real configuration; or the audit log entry does not match the action you took. These are signals that the tenant’s policy inheritance, group nesting or your own permission scope may not match what you assumed, and widening the exercise before resolving that mismatch increases blast radius rather than learning.

#Common Mistakes

• Assigning a test policy to “All devices” instead of a dedicated test group, which removes the containment this exercise depends on.
• Judging compliance state immediately after assignment, before any device check-in has occurred.
• Skipping the licence and permission confirmation step, then discovering mid-exercise that the tenant cannot evaluate the policy as expected.
• Treating a portal view and a Graph query result as automatically consistent without actually comparing them.
• Leaving a test assignment in place after the exercise, rather than rolling it back and confirming removal.

#Key Takeaways

A safe Intune exercise is defined by its boundary before it is defined by its outcome: one policy, one group, one recorded rollback path, checked twice — once in the portal and once through a read-only query — before you trust the result. That discipline is the same discipline a production change requires, only rehearsed at a scale where a mistake costs a lab tenant nothing rather than costing a real device its network access.