Microsoft MD-102: Growing Into Endpoint Engineering

MD-102 covers a role that has grown far beyond Windows configuration. Microsoft currently describes endpoint administrators as managing devices and client applications across a Microsoft 365 tenant with Intune, Windows Autopilot, Defender for Endpoint, Microsoft Entra ID, PowerShell, Microsoft Graph, Windows 365, and newer agentic tools and workflows.

That breadth changes what “getting better at endpoint management” means after the exam. The next level is not memorizing more policy locations. It is being able to explain device state across enrollment, configuration, security, applications, updates, access, support, and retirement—and to make that state predictable at scale.

Endpoint engineering begins when that breadth turns into repeatable lifecycle control. Knowing more settings than everyone else is not the target; intended device state has to become observable, enforceable, and recoverable across a fleet.

Manage the device lifecycle as one system

An endpoint passes through several states: it is acquired or registered, enrolled, configured, secured, given applications, kept current, supported, and eventually retired. Problems appear when those stages are managed as separate projects.

A device may enroll successfully but never receive the required application. A security baseline may be assigned but conflict with another policy. A machine may remain technically managed while its owner has changed. A retired device may still retain access or data longer than policy allows.

Thinking in terms of the endpoint-management lifecycle makes those handoffs visible. For every stage, define what “healthy” looks like, which evidence proves it, and what should happen when the device fails to advance.

That creates better support questions. Instead of “Why didn’t the setting apply?” ask whether the device is enrolled correctly, in the right group, receiving the expected configuration, evaluating compliance, and communicating recently enough for the state to be trusted.

Intune becomes easier when you stop treating assignment as a button click

Many endpoint problems are really assignment and state problems. A policy exists, but the wrong group is targeted. A dynamic group has not updated. A filter excludes the device. Two configurations conflict. The client has not checked in. The policy arrived but a prerequisite did not.

Deep Intune deployment skill therefore comes from understanding how intent turns into device state. Know which objects are assigned, how users and devices differ, when filters are evaluated, how reporting reflects success or failure, and which client-side evidence helps when the portal is not enough.

Build a small test matrix rather than a large flat fleet. Include at least two device types or enrollment methods, several user roles, and policies with different scope. Introduce conflicts deliberately. Remove a required group membership. Delay a check-in. Change an application requirement rule.

Then follow the evidence from service to device. Endpoint engineering depends on being able to say not only that the deployment failed, but where the intended state stopped becoming actual state.

Provisioning deserves the same discipline. Windows Autopilot is most valuable when it makes a device’s first hours predictable: the correct identity joins the tenant, the expected enrollment path is used, required security controls arrive in the right order, and the applications needed for work are available without an engineer rebuilding the machine by hand. Test the process on replacement devices as well as brand-new hardware, because recovery scenarios often expose assumptions that a clean first deployment does not.

Application delivery is another common source of hidden complexity. Detection rules, requirement rules, dependencies, supersedence, user-versus-device targeting, and installation context can all make an application appear “assigned” while the endpoint never reaches the expected state. Treat application deployment like software delivery: know what proves success, what rollback means, and how the support team can distinguish a packaging problem from an assignment problem.

Update management also needs an operating model rather than a collection of rings. Define how pilot devices are chosen, how quickly security updates should reach the broader fleet, which exceptions are legitimate, and what evidence triggers a pause or rollback. The goal is controlled change: enough velocity to reduce exposure without turning every update into an organization-wide experiment.

Security controls should reinforce one another without making support impossible

Endpoint security is strongest when patching, encryption, application control, endpoint detection and response, identity protection, privilege management, and configuration baselines work together. It becomes fragile when each control is deployed by a different team without understanding the operational effect on the others.

A practical endpoint-hardening model starts with the threat and the recovery path. What are you trying to prevent? What signal proves the control is working? What will support staff see when legitimate work is blocked? How is an exception approved and reviewed?

Security baselines should not become untouchable configuration simply because they are labeled “secure.” Test them against real applications, device classes, and user workflows. A control that drives widespread bypasses or permanent exemptions is often weaker than a slightly less restrictive control that the organization can enforce consistently.

Defender for Endpoint adds another important dimension: device configuration and security telemetry meet. Endpoint administrators should know enough of the detection and exposure data to understand how management decisions affect security posture, even if a dedicated security team owns incident response.

Identity and device trust meet at the access decision

Modern endpoint administration is deeply connected to identity because access decisions increasingly consider who the user is, which device they are using, and whether that device meets policy. That makes Microsoft Entra ID and Conditional Access part of the endpoint operating model.

The difficult cases are rarely “is the user valid?” or “is the device managed?” in isolation. They are combinations: a valid user on an unmanaged device, a managed device that is noncompliant, a privileged user from an unexpected location, or a device whose registration state no longer reflects ownership.

In identity and endpoint architecture, device state has to be considered alongside privilege, access policy, governance, and monitoring. The endpoint is not only a configuration target; it is one of the signals used to decide what the user can reach.

Support teams need visibility into that decision. When access is blocked, the explanation should identify the relevant condition without exposing more security detail than necessary. Users will invent workarounds if security behavior feels random.

Automation should remove repetitive diagnosis before it removes repetitive clicking

Endpoint administrators naturally encounter repetitive work: inventory, compliance reporting, group checks, application assignments, stale device cleanup, configuration verification, and ownership review. PowerShell and Microsoft Graph can reduce that effort, but the most valuable scripts are often diagnostic before they are corrective.

Start with a tool that answers a question you ask every week. Which devices have not checked in? Which compliant devices are missing a required application? Which machines are owned by departed users? Which policy assignments differ from the expected standard?

Read-only automation is safer and teaches the data model. Once the output is trustworthy, add controlled remediation. Keep changes small, log what happened, and make the script idempotent where possible so a rerun does not compound the problem.

Source control matters even for administrative scripts. A script that can change hundreds of endpoints is production code whether or not the author thinks of themselves as a developer. Review, versioning, documentation, testing, and secret handling all belong in the workflow.

Automation also reveals process problems. If a script has to clean up the same category of stale device every Friday, ask why the lifecycle is producing those objects in the first place. Good endpoint engineering fixes the source of repeated manual work when it can.

Support quality improves when device state is explainable

A mature endpoint team should be able to reconstruct why a device is in its current state. Which enrollment method was used? Which policies were targeted? Which applications were required? Which compliance result affected access? Which update ring applies? Which user owns the device? When did it last communicate?

That does not mean every support technician needs unrestricted administrative access. It means the organization should expose enough trustworthy evidence for the right support tier to diagnose common problems without guessing.

Build runbooks around evidence, not folklore. “Reboot and sync” may be a useful step, but it should not be the entire troubleshooting strategy. Record where to inspect assignment, client logs, management-extension state, Entra sign-in information, Defender status, and application-detection results for the problems your environment actually sees.

Track recurring incidents. If one policy generates a large share of tickets, revisit the policy design. If enrollment failures cluster around one hardware model or provisioning path, test that path separately. Support data is feedback on the management architecture.

Endpoint engineering is ultimately about reducing uncertainty across a fleet

The administrator who can configure a device is useful. The engineer who can explain why ten thousand devices are converging—or failing to converge—toward an intended state is operating at a different level.

Choose a small fleet or lab and make the state measurable. Define the expected enrollment path, configuration set, security posture, application baseline, update behavior, access rules, and retirement process. Then introduce drift. Remove a group membership, change ownership, break an application detection rule, delay a policy, or make a device noncompliant.

Measure how quickly the environment exposes the problem and how easily another administrator can understand it. Improve the telemetry and process until the answer no longer depends on the person who originally built the configuration.

A well-run endpoint estate should make ordinary questions easy to answer: what state should this device be in, why is it different, which control changed it, and what is the safest way back? Teams that can answer those questions consistently are already operating beyond policy-by-policy administration.