MD-102: Managing and Securing Microsoft 365 Endpoints

MD-102 covers enterprise endpoint management with Microsoft Intune and related Microsoft 365 technologies. The focus is not simply enrolling a laptop. Organizations need consistent identity, deployment, application, update, and security practices for many device types, including remote and personally owned devices where permitted. A Microsoft endpoint administrator must balance usability with protection and operational visibility. Microsoft's published study material also identifies an October 27, 2026 skills update. As of October 10, that date is still ahead, so candidates should compare the objectives that apply to their examination rather than treating the future version as already effective.

Select the right device identity and enrollment model

A managed device can be registered with Microsoft Entra ID, joined to it, or connected through supported hybrid arrangements. Those states are not synonymous. Registration may represent a user associating a device for supported access, while joining provides a stronger organizational identity and management relationship. Organizations must choose based on ownership, connectivity, operating system, security requirements, and how the device will be deployed. Simply choosing the most restrictive-looking option does not make a system secure if the resulting process is impossible for employees to follow or if older devices cannot satisfy the requirements.

Intune enrollment adds another layer. Automated enrollment for corporate devices, platform-specific enrollment methods, and personally owned device approaches have different privacy and management implications. A consultant should explain what the organization can see and manage on each device type. Enrollment restrictions can block unsupported or unapproved platforms; dynamic groups can target policies based on device attributes. A successful strategy handles replacement devices, employees leaving the organization, lost devices, and enrollment failures. The Microsoft Entra identity model is important context because device registration and access policy depend on a reliable understanding of the underlying tenant identity system.

Design Windows provisioning and Autopilot operations

Windows Autopilot can support provisioning workflows that reduce manual imaging and help devices reach the correct user and management state. Deployment choices include user-driven or appropriate automated experiences, with prerequisites for identity, enrollment, licensing, connectivity, and profile assignment. The administrator should know how deployment profiles, enrollment status, device naming, and application installation affect first-use experience. A computer that appears successfully provisioned but lacks a required security agent or business application is not ready merely because the desktop is visible.

Operational planning includes hardware registration, profile targeting, device preparation, ownership transfer, and recovery when provisioning becomes stuck. Devices may be deployed to offices, remote employees, or shared spaces, and not every scenario should follow exactly the same profile. Policies applied during enrollment can compete with application timing or reboot behavior. A useful test measures the time until a real user can complete representative work, not just the duration of the enrollment stage. When errors occur, the administrator should inspect enrollment diagnostics, policy targeting, licensing, and device identity before wiping and retrying indiscriminately.

Use configuration policies to express actual requirements

Configuration profiles can apply operating system settings, compliance-related controls, Wi-Fi and VPN parameters, security baselines, and other device behaviors. Administrative templates, settings catalogs, scripts, and supported platform mechanisms have different strengths. A settings policy should be tied to a reason: reducing attack exposure, enabling a service, or meeting a business requirement. Applying dozens of overlapping profiles without ownership creates hard-to-debug conflicts. Changes should be tested against representative device and user groups, with attention to prerequisites and unsupported settings on certain platforms.

Compliance policies assess whether devices meet configured requirements; configuration policies attempt to enforce particular settings. That distinction matters for Conditional Access. A device might be configured to encrypt storage but still report noncompliance because encryption has not completed or reporting is delayed. A policy targeting the wrong group can deny legitimate access to a critical application. The relationship with Conditional Access is therefore operational as well as security-related: access decisions must reflect trusted device state and account context, and administrators need exception procedures that do not quietly become permanent bypasses.

Protect endpoints without undermining productivity

Endpoint protection includes operating system security capabilities, disk encryption, device compliance, attack-surface reduction where available, security baselines, and integration with Microsoft Defender for Endpoint. The administrator should distinguish preventing malicious activity from detecting and responding after a device may already be compromised. Security policies must consider user role, application compatibility, platform capabilities, and change timing. An aggressive control that disables an essential line-of-business application can drive users to unsupported workarounds, so rollout should use suitable rings and evidence from pilot devices.

Recovery and isolation are part of the design. A lost device may need a remote wipe or other supported action depending on ownership and platform. A compromised device may require containment by security responders before ordinary troubleshooting resumes. Credential, certificate, and key handling must respect privacy and access requirements. Administrators should understand the difference between clearing a user's corporate data and resetting an entire personal device. Security decisions should be documented and authorized, particularly when they affect employee-owned equipment or regulated information.

Manage applications and updates as a service

Applications can be deployed, updated, or retired through appropriate Intune methods, including supported Win32, Microsoft 365, store-based, and platform-specific approaches. Dependencies, detection rules, requirement rules, and installation context determine whether an application is actually present and usable. A failed deployment might be caused by packaging, a missing prerequisite, a user/device assignment mismatch, or conflicting versions. Simply retrying installation repeatedly does not establish the cause. The administrator needs to observe which app detection and install conditions the device reported.

Windows update rings and feature-update policies allow phased deployment and risk management. Quality updates and major feature changes can have different compatibility consequences. A rollout should include pilot users, critical applications, restart windows, and a way to monitor failures or security exposure. Delaying updates indefinitely is not a sustainable compatibility strategy. Conversely, deploying to every device simultaneously increases risk when a problem is discovered. Administrators must understand deferrals, deadlines, reporting, and the implications of devices that are offline for long periods.

Troubleshoot by combining identity, device, and service evidence

Endpoint failures can cross several systems. A user cannot access an app, yet the cause may be an expired device registration, incorrect Conditional Access evaluation, a missing certificate, an application install problem, or network reachability. The right evidence depends on the symptom. Intune device status, application deployment reports, relevant operating system logs, and identity sign-in information can show where the chain broke. Administrators should avoid changing several unrelated policies simultaneously, because that obscures which correction actually resolved the issue.

A helpful diagnostic case is a newly provisioned computer that cannot open a protected business service. First verify device join and enrollment; then check policy assignment and compliance; then evaluate sign-in conditions; finally inspect app installation and network access. Each step should have an expected result. Another case involves a device that stopped receiving updates after a change to deployment groups. Investigating assignments and device check-in is more useful than assuming the update service is defective. These patterns teach candidates to reason through an endpoint lifecycle rather than memorize isolated administration commands.

Govern large-scale devices and validate recovery

Management at scale needs naming standards, role-based delegation, reporting, and documented ownership of policy changes. Scope tags and administrative permissions can reduce inappropriate visibility or modification across departments. Scripts and automated remediation need careful testing, logging, and least-privilege execution. A simple action can affect thousands of devices if its targeting rule is wrong. Device retirement, reallocation, and disposal procedures should remove corporate access and data safely while preserving records needed for legitimate audit purposes.

For MD-102 preparation, rehearse full lifecycles: obtain a new device, enroll it, apply required configuration, install applications, enforce access requirements, deploy updates, investigate an exception, and retire or replace the device. Compare the outcome on a compliant device, an unsupported personal device, and a machine that has been offline. That scenario integrates identity, operating systems, security, and user experience in the way the role actually works. The best endpoint design maintains the security posture without making every device incident an emergency requiring privileged intervention.

There are two additional operational cases worth preparing for. First, consider the employee who moves between business units while keeping the same device. Device policy and application entitlements may change with group membership, but existing certificates, cached content, and configuration state can persist until the next successful evaluation. Administrators should design a transition workflow that checks all relevant access paths, not assume a group update instantaneously erases prior access. Second, consider a temporary contractor with a personally owned device. The organization may need to protect application data without managing the whole device; the appropriate approach depends on supported platform features, contractual terms, and risk.

A third case concerns policy versioning during an urgent security change. An administrator should know which settings are actively enforced, which devices have checked in, and which are reporting an error. Rollout rings and exception tracking provide a path to measure progress and to roll back a harmful change. A dashboard showing a high deployment percentage is insufficient if the remaining failures include the most sensitive or business-critical devices. For this reason, endpoint reporting must support decisions and remediation, not simply display reassuring totals.

Finally, remediation automation has to distinguish observation from permission to act. An unhealthy endpoint report may justify contacting its user or collecting diagnostic detail; it does not automatically justify wiping the machine. Scripts should use bounded actions, clear exit codes, and reliable evidence that the desired state has actually been reached. When repeated failures occur on one hardware model, a device-specific compatibility investigation may be more appropriate than loosening the security baseline for the entire fleet. This distinction between targeted repair and broad policy change is central to safe endpoint administration.