A device appearing in the inventory is a starting point, not the acceptance criterion for an endpoint-security deployment. The pilot must also demonstrate that protection settings apply, telemetry arrives and the security team can investigate what it sees.
Scope: a proposed lab walkthrough for supported Windows 11 devices enrolled in Microsoft Intune. This is a deployment guide, not a report of tests performed in a customer tenant. Review the linked Microsoft documentation against your environment before implementation.
1. Define a small, measurable pilot
Create a dedicated device group, for example LAB-MDE-Windows-Pilot. Include a standard workstation and a device representing a business application dependency. Record the device names, owners, operating-system builds, existing antivirus and management authority. Agree an escalation contact and a maintenance window.
My suggested acceptance criteria are: every intended device reports recently; the onboarding policy succeeds; protection settings match the approved design; an appropriate detection validation reaches the portal; and a scoped analyst can investigate it. Record evidence for each criterion instead of relying on a single green dashboard.
2. Check licensing, platform and connectivity
Verify the Defender for Endpoint entitlement for the capabilities being evaluated. Intune requires its own entitlement; do not assume an endpoint-security subscription includes device management. Servers require an appropriate server license and a separate deployment design. Review supported operating systems, service connectivity, proxy handling and antivirus coexistence before enrolling the pilot. See Microsoft’s minimum requirements.
Keep the initial exercise on a supported Windows 11 build. A security agent does not replace an operating system’s support lifecycle. Document who owns proxy changes and how device connectivity will be checked from the service context, rather than only from an administrator’s browser.
3. Separate configuration and investigation permissions
For Intune onboarding, Microsoft documents Endpoint Security Manager or equivalent scoped permissions. For the Defender-side connector configuration, its guide documents the Entra Security Administrator role or the relevant Defender permission. Custom Intune roles need the specific Mobile Threat Defense and Endpoint Detection and Response rights for the tasks performed. Validate scope as well as role membership. Integration and permission requirements.
Use a separate analyst assignment for investigation. Avoid leaving the deployment account as the default operational identity. Test whether an analyst can see the pilot devices without automatically giving access to every production device.
4. Connect the services and onboard the pilot
- In Intune, open Endpoint security > Defender for Endpoint and check the connection status.
- If needed, enable the Intune connection under the Defender portal’s endpoint advanced features; return to Intune to verify the connection.
- Create a Windows Endpoint detection and response policy using the supported onboarding configuration.
- Assign the custom policy to the pilot device group. Review the assignment before saving; the broad quick-setup option is unsuitable for this limited exercise.
- Synchronize the test devices and inspect the per-device policy results and Defender device inventory.
The connector links the services; it is not by itself proof that every endpoint has onboarded. Microsoft’s connector and onboarding procedure.
5. Configure protection separately
Create targeted Antivirus and attack surface reduction policies in addition to onboarding. Microsoft’s Intune deployment guidance separates these policy types. For ASR rules that support it, assess audit results before enforcement and document each exception. Confirm antivirus coexistence and avoid contradictory assignments from Intune, Group Policy and Configuration Manager. Windows onboarding and protection-policy guidance.
6. Validate detection and operational visibility
Use a Microsoft-documented evaluation or detection test applicable to the device’s operating system. Check the supported-platform section before running it: the linked PowerShell onboarding-verification page currently lists server platforms. Do not assume one test is appropriate for every Windows client. Detection-test documentation.
For your selected test, record the device identity, execution time, resulting alert, telemetry timestamp and analyst visibility. An antivirus notification alone does not prove the full investigation workflow. Do not weaken protection or add broad exclusions merely to make a demonstration succeed.
7. Troubleshoot and approve the next deployment ring
- Device missing: check group membership, policy assignment, synchronization, onboarding errors and service connectivity.
- Device present but stale: inspect its last-seen time, sensor health and network path.
- Policy conflict: identify the management authority for the setting and resolve overlapping assignments.
- Analyst cannot see it: review workload activation, role scope and device-group access.
Expand only after the evidence is reviewed. Keep a rollback owner and use the documented offboarding procedure if offboarding is actually needed; removing a policy assignment is not a substitute. The handover should include coverage, exceptions, support ownership and a repeatable validation checklist.
Documentation reviewed: 10 October 2026. Menu labels and feature availability can vary by tenant.
