Microsoft Defender XDR Security Settings Management

Introduction: The Reality of Managing Security in 2025

If you've been managing Windows environments for more than five years, you've lived through one hell of a transformation. Let's be honest about where we've been and where we're going.

The Server Story

Remember when managing servers was simple? Deploy Windows Server, join the domain, apply GPO, maybe install Configuration Manager agent if you were fancy :). Those days are gone. Today's server infrastructure spans on-premises datacenters, Azure VMs, AWS EC2 instances, and edge locations that may not even have reliable connectivity to your domain controllers.

Azure Arc changed the game for servers. Suddenly, you could manage hybrid and multi-cloud servers from a single pane of glass. Defender for Cloud added security posture management. But here's the thing - both of these solutions focus on infrastructure and compliance, not day-to-day security policy management. Moving from Configuration Manager to Azure Arc creates a new problem: how do you handle all the settings on the machines themselves? Microsoft built Azure Guest Configuration services, but that requires strong DSC and PowerShell knowledge that many organizations sadly don't have today. And if your servers are still domain-joined, do you want to keep using GPOs? GPOs work fine, but there's no proper reporting. The question becomes: how do you handle configuration settings in 2025 and moving forward? Different options are available, but it's hard to choose the right approach.

The Workstation Evolution

Workstations went through their own journey. Group Policy worked great when everyone sat in the office. Then laptops became mobile. Then came BYOD. Configuration Manager tried to bridge the gap with internet-based client management. Co-management (ConfigMgr + Intune) became the compromise solution for organizations not ready to go full cloud.

But co-management is complex. You're running two management systems, dealing with policy conflicts, and trying to figure out which system is responsible for what. Many organizations are moving to Intune-only management, but that requires Entra ID join or Hybrid Entra ID join - not always possible or desired for every device. Microsoft's focus has clearly shifted to Intune standalone, with all the new features and investments going there rather than co-management scenarios. Configuration Manager is still strong in many ways and works well for what it does, but honestly, it doesn't seem to have much of a future in Microsoft's roadmap.

Enter Security Settings Management

Microsoft Defender XDR's Security Settings Management (GA since November 2023) offers a different approach. It's not trying to replace Intune or Configuration Manager. It's focused on one thing: security policy management for devices that are already onboarded to Defender for Endpoint.

Here's what makes it different:

• No Intune enrollment required
• Works with workgroup machines (perfect for DMZ servers)
• Supports domain-joined devices without hybrid join complexity
• Handles Azure Arc-enabled servers seamlessly
• Domain Controllers are fully supported (no longer preview)

What This Actually Means:

You can deploy a server with Azure Arc, onboard it to Defender for Endpoint, and immediately start managing its security policies through Defender XDR. No domain join required. No Intune licensing. No co-management complexity. This is huge for servers because Intune standalone can't manage servers anyway - you'd need Configuration Manager or direct management. People have been asking Microsoft for years to add server support to Intune, but it seems like that's never going to happen :)

For workstations, it provides security policy management in scenarios where traditional device management isn't optimal. Maybe you're using a third-party device management solution but want Microsoft to handle security policies. Or your security team wants to own the entire security stack without depending on the infrastructure team's device management timelines. Everything managed from one portal - the Defender XDR console.

The Unified Security Operations Story

Microsoft is rapidly evolving toward unified security operations. In 2025, we're seeing major integrations that change how we approach security management:

• Microsoft Sentinel in Defender Portal: Based on the Microsoft Sentinel onboarding guide, you can now connect Sentinel workspaces directly to the Defender XDR portal. This unifies incident management and advanced hunting across both platforms.
• Sentinel Data Lake (Preview): The new Microsoft Sentinel data lake provides a cloud-native security data lake that transforms how organizations manage and analyze security data at scale.
• Defender XDR Integration: Security Settings Management works seamlessly within this unified ecosystem, allowing you to manage security policies while leveraging the full power of integrated security operations.

This unified approach means your MDE Settings Management deployment isn't just about policy management - it's part of a comprehensive security operations strategy that spans detection, investigation, and response.

What This Guide Covers:

This isn't another rehash of Microsoft documentation. We'll explore the solution in general and show you how to go end-to-end with real implementation details. You'll see actual registry values, confirmed Event IDs for monitoring, and honest pros and cons based on real-world experience. We'll cover Sentinel integration concepts and show you how everything connects together.

What Changed with Synthetic Device Identity (And Why It Matters)

The November 2023 GA release fundamentally changed how devices register with Entra ID for security policy management. Let's break down what actually happens and why it's a big deal.

The Pain Before GA

Before Security Settings Management went GA, managing server security policies through the cloud was painful:

• Full Hybrid Join requirement: Servers needed to be hybrid Entra ID joined to receive cloud policies
• Entra Connect complexity: You had to modify sync rules to include Windows Server 2012 R2 and other older servers
• Domain Controller dependencies: Everything relied on your domain controllers being healthy and connected

What Synthetic Device Identity Really Means

Based on the official Microsoft documentation, here's what actually happens:

"For devices that aren't fully Microsoft Entra registered, a synthetic device identity is created in Microsoft Entra ID that allows the device to retrieve policies."

{
    "managementType": "MicrosoftSense",
    "trustType": null,
    "enrollmentType": "Unknown", 
    "deviceOwnership": "Unknown",
    "isManaged": null,
    "isCompliant": null,
    "domainName": null,
    "mdmAppId": "0000000a-0000-0000-c000-000000000000"
}

Critical Indicators:

• managementType = "MicrosoftSense" - Confirms Settings Management enrollment
• trustType = null - No domain trust relationship required
• enrollmentType = "Unknown" - Not traditional Intune enrollment

Graph Explorer showing synthetic device object with key MDE Settings Management indicators

The Modern Datacenter Story (From Someone Who's Been There)

I've been working with Azure Arc for Servers since day one. I've delivered custom training classes, led large-scale implementations, and I can tell you this without hesitation: Azure Arc is the best thing Microsoft has done in many years. My Azure Arc enablement service helps organizations realize these benefits quickly and correctly.

Here's why I'm so excited about it: Arc-connected machines become real objects in Azure. Not just inventory items - actual Azure resources that you can manage with policies, extensions, and all the Azure tooling you already know.

The Evolution I've Witnessed:

Traditional: Deploy server → Join domain → Apply GPO → Install SCCM agent → Wait for updates
Modern: Deploy server → Azure Arc onboard → Defender for Cloud protects → Security Settings Management

Result: Unified management across:
- On-premises datacenters
- Azure VMs
- AWS EC2 instances  
- GCP compute
- Edge locations
- All from ONE portal with native Azure tooling

The Perfect Trinity:

• Azure Arc: Makes any server an Azure citizen with policy, extensions, and inventory
• Defender for Cloud: Our go-to solution (P1/P2 packages available) - when we talk servers, it's Defender for Servers; workstations get Defender for Endpoint. Same underlying service, different context
• Security Settings Management: Direct security policy control without the complexity

Why This Changes Everything:

When you combine Arc-enabled servers with Defender for Cloud and Security Settings Management, you get something magical: a server deployed anywhere (on-premises, AWS, GCP, edge location) that gets immediate Azure policy governance, security posture management, and centralized security settings - all without traditional domain complexity.

I've seen organizations go from months-long server onboarding processes to same-day productivity with this stack. That's the power of treating every server as an Azure resource, regardless of where it physically sits.

Complete Workflow: From Azure Arc to Security Settings Management

Here's the complete flow showing how a server goes from initial deployment to targeted security management:

Should You Use Security Settings Management? (Honest Pros and Cons)

Let's cut through the marketing fluff and have an honest conversation about when this technology makes sense and when it doesn't.

The Advantages Nobody Talks About

• No Intune Enrollment Required: Perfect for server environments. No Intune licensing costs or complex enrollment processes.
• Azure Arc Synergy: If you're already using Azure Arc for server management, this is a perfect complement.
• Workgroup Machine Support: DMZ servers, standalone systems, or machines that can't join your domain can still receive centralized security policies.
• Security Team Ownership: Security teams can manage security policies without depending on infrastructure teams.

The Limitations You Need to Know

• Limited Policy Types: You get Antivirus, Firewall, ASR, and EDR settings. No BitLocker management, no Windows Update policies, no custom registry settings.
• 90-Minute Sync Delay: Group Policy applies in seconds to minutes. Security Settings Management checks in every 90 minutes.
• No Compliance Policies: You can't block access based on compliance status like you can with Intune.
• Template-Based Only: No custom settings beyond what Microsoft provides in their templates.

Prerequisites and Platform Support (The Real Story)

If you want to test or implement Settings Management, make sure you have the following prerequisites fulfilled first.

Platform-Specific Requirements

Windows Platforms:

• Windows 10 Professional/Enterprise (with KB5023773)
• Windows 11 Professional/Enterprise (with KB5023778)
• Windows Server 2012 R2 with Microsoft Defender for Down-Level Devices
• Windows Server 2016 with Microsoft Defender for Down-Level Devices
• Windows Server 2019 (with KB5025229)
• Windows Server 2022, including Server Core (with KB5025230)
• Windows Server 2025
• Domain controllers (fully supported, no longer preview)

Licensing Requirements

What You Need:

• Microsoft Defender for Endpoint subscription (standalone or as part of Microsoft 365)
• Access to Endpoint Security node in Microsoft Intune admin center

Network Requirements That Actually Matter

Essential Endpoints:

• *.dm.microsoft.com - Critical for enrollment, check-in, and reporting
• Standard Microsoft Entra endpoints
• Microsoft Defender for Endpoint endpoints

Proxy Configuration Issues:

Many organizations struggle with proxy configurations blocking the *.dm.microsoft.com wildcard endpoint. Plan for proxy exclusions or firewall rules.

PowerShell Constraint Language Mode Killer

Critical Limitation:

Settings Management will not work on devices with PowerShell configured in Constrained Language Mode. This is a hard requirement that often gets overlooked.

Why This Matters:

• Microsoft Defender for Endpoint client functions use PowerShell
• Live Response executes scripts through PowerShell
• Troubleshooting requires PowerShell access
• Performance diagnostics depend on PowerShell scripts

Domain Controller Management

Domain controllers are fully supported but require extra consideration:

Setup Requirements:

• Enable Windows Server devices in enforcement scope first
• Navigate to Settings > Endpoints > Enforcement scope to enable DC support
• If using tagged devices for servers, DCs follow the same tagging rules

Important Limitations:

• Firewall policies are not supported on DCs
• Review all policies to avoid unintended DC targeting
• Settings persist even after unenrolling from Settings Management

Lab Testing Recommendation:

Before production deployment, set up a small lab environment to test the complete workflow from server onboarding through policy application - this helps you understand the timing and troubleshoot any issues.

Getting Started: Enable Settings Management

Now that prerequisites are met, let's walk through the actual implementation process step by step.

Step 1: Configure Enforcement Scope in Defender Portal

Location: Microsoft Defender XDR Portal → Settings → Endpoints → Configuration management → Enforcement Scope

Platform Options Available:

• Windows Client devices (workstations)
• Windows Server devices
• Windows Server Domain Controller devices
• Linux devices
• macOS devices

Recommended Approach for Testing:

1. Start with "On tagged devices" for all platforms
2. Enable Windows Server devices first
3. If testing domain controllers, enable that option separately
4. Leave other platforms disabled until you're ready to expand

Defender XDR portal Enforcement Scope configuration with platform and targeting options

Step 2: Tag Your Test Device

Manual Tagging Process:

1. Navigate to your test device in Defender XDR portal
2. Go to Device page → Manage tags
3. Add the MDE-Management tag
4. Save changes

Step 3: Monitor Enrollment Process

# Monitor registry for enrollment status
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\SenseCM" -ErrorAction SilentlyContinue

# Check Event Logs for enrollment events using efficient XPath filtering
$XPathQuery = @"
<QueryList>
  <Query Id="0" Path="Microsoft-Windows-SENSE/Operational">
    <Select Path="Microsoft-Windows-SENSE/Operational">
      *[System[(EventID=59 or EventID=71)]]
    </Select>
  </Query>
</QueryList>
"@

Get-WinEvent -FilterXml $XPathQuery | Select-Object TimeCreated, Id, LevelDisplayName, Message

Windows Event Log showing successful MDE Settings Management enrollment (Event ID 71)

Registry values in HKLM\SOFTWARE\Microsoft\SenseCM after successful enrollment

Key Event IDs for Monitoring:

• Event ID 59: "Starting command: endpointconfigmanagementenrollcommand"
• Event ID 71: "Succeeded to run command: endpointconfigmanagementenrollcommand"
• Log Source: Microsoft-Windows-SENSE/Operational

Step 4: Verify Synthetic Device Creation

Check in Entra ID Devices Portal

1. Navigate to Entra ID → Devices → All devices
2. Find your device (e.g., SRV02)
3. Look at the "Security settings management" column
4. Verify it shows "Microsoft Defender for Endpoint"
5. Notice "Join type: None" and "MDM: N/A" (indicates synthetic registration)

Entra ID devices portal showing synthetic device managed by Microsoft Defender for Endpoint

Device Visibility in Intune Portal

Don't be surprised - your Settings Management devices will also appear in the Microsoft Intune admin center under Devices → All devices. This is expected behavior since the synthetic device registration creates device objects that are visible across the Microsoft ecosystem.

In the Intune portal, you'll see:

• Managed by: MDE (Microsoft Defender for Endpoint)
• Ownership: Unknown
• Compliance: Not evaluated
• OS version: Properly detected (e.g., 10.0.26100.4946)

Intune portal showing device managed by Microsoft Defender for Endpoint (Settings Management)

Graph API Verification

# Connect to Microsoft Graph (PowerShell 7.x required)
Connect-MgGraph -Scopes "Device.Read.All"

# Find your device
$Device = Get-MgDevice -Filter "displayName eq 'YourDeviceName'"

# Check device properties
$Device | Format-List

# Alternative: Search by management type

$MDEDevices = Get-MgDevice -Filter "managementType eq 'MicrosoftSense'" -ConsistencyLevel eventual -CountVariable mdeCount -Property Id,DisplayName,OperatingSystem,OperatingSystemVersion,ManagementType,DeviceId -All | format-list

$MDEDevices | Format-List

Step 5: Create Security Groups for Policy Targeting

Now that your device is enrolled and verified, create security groups to target policies effectively.

Dynamic Security Groups in Entra ID

Dynamic groups automatically assign devices based on device properties, perfect for Settings Management deployment.

Prerequisites:

• PowerShell 7.x (required for Microsoft.Graph module)
• Microsoft.Graph PowerShell module: Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph with required scopes
Connect-MgGraph -Scopes "Group.ReadWrite.All", "Directory.Read.All"

# Windows Workstations - MDE Managed
$WindowsWorkstationsParams = @{
    DisplayName = "MDE-Managed-Windows-Workstations"
    Description = "Windows client devices managed by Microsoft Defender for Endpoint"
    MailEnabled = $false
    MailNickname = "MDEWindowsWorkstations"
    SecurityEnabled = $true
    GroupTypes = @("DynamicMembership")
    MembershipRule = '(device.managementType -eq "MicrosoftSense") and (device.deviceOSType -eq "Windows")'
    MembershipRuleProcessingState = "On"
}

$WindowsWorkstationsGroup = New-MgGroup @WindowsWorkstationsParams

Dynamic security group in Entra ID populated with MDE-managed devices using managementType filter

Manual vs Automated Targeting

Manual Device Targeting with Tags:

If you prefer manual control, you can use the MDE-Management tag approach:

1. Keep enforcement scope set to "On tagged devices"
2. Manually tag each device in Defender portal
3. Provides precise control but doesn't scale

Automated Targeting with Dynamic Groups:

For production environments, dynamic groups are more efficient:

• Automatically include new devices that meet criteria
• Scale to hundreds or thousands of devices
• Reduce administrative overhead
• Consistent targeting based on device properties

Step 6: Create and Deploy Security Policies

With your security groups ready, create and assign security policies through the Defender XDR portal.

Creating Your First Security Policy

Location: Microsoft Defender XDR Portal (security.microsoft.com) → Endpoints → Configuration management → Endpoint security policies

Required Permissions:
Based on the Microsoft documentation, you need:

• Security Administrator role (minimum) to access the portal
• Core security settings (manage) permissions to view/create policies
• Access to all devices in your organization
• Recommended: Intune "Endpoint Security Manager" built-in role for proper alignment between Intune and Defender portal permissions

Step-by-Step Process:

1. Sign in to Microsoft Defender portal with Security Administrator role
2. Navigate to Endpoints → Configuration management → Endpoint security policies
3. Click "Create new Policy"
4. Select platform from dropdown (Windows Client / Server, macOS, Linux)
5. Select policy template (varies by platform - see template details below)
6. Enter policy name and description
7. Configure settings for each group
8. Assign to Entra ID security groups
9. Review and create policy

Start with Simple Policies:
Begin with basic antivirus settings to test the workflow before deploying complex configurations.

Available Policy Templates by Platform

Policy template selection in Defender XDR portal showing all available Windows security templates

Windows Client/Server Templates (9 total):

• Windows Security Experience - Windows Security app settings
• Microsoft Defender Antivirus - Core antivirus protection settings
• Microsoft Defender Antivirus exclusions - File, folder, and process exclusions
• Attack Surface Reduction Rules - ASR rules configuration
• Microsoft Defender Firewall - Windows firewall settings
• Microsoft Defender Firewall Rules - Custom firewall rule creation
• Defender Update controls - Antivirus definition update settings
• Endpoint Detection and Response - EDR settings and onboarding
• Device Control - USB and removable device restrictions

macOS Templates (3 total):

• Microsoft Defender Antivirus - Core antivirus protection settings
• Microsoft Defender Antivirus exclusions - File, folder, and process exclusions
• Endpoint detection and response - EDR settings and configuration

Linux Templates (4 total):

• Microsoft Defender Antivirus - Core antivirus protection settings
• Microsoft Defender Antivirus exclusions - File, folder, and process exclusions
• Endpoint detection and response - EDR settings and configuration
• Microsoft Defender Global Exclusions (AV+EDR) - Combined exclusions for both antivirus and EDR components

Monitor Policy Deployment

Check Policy Assignment:

1. Return to your policy in Defender XDR portal
2. Select the policy name to view details
3. Review policy status summary showing:
   • Policy status - Overall deployment health
   • Applied devices - Which devices received the policy
   • Assigned groups - Target security groups
4. Wait for the 90-minute sync cycle (or force manual sync)

Policy Editing:

• Select policy → Edit to modify settings
• Edit categories individually: Basics, Settings, Assignments
• Changes must be saved per category before moving to next
• Scope tag edits require Microsoft Intune admin center

Device-Level Verification:

• Navigate to individual device page in Defender portal
• Check Security policies tab to see all applied policies
• Verify policy assignment and status per device

Real-World Timing Example:
In our testing, a Microsoft Defender Antivirus policy took 33 minutes from creation to showing "Success" status in the Security policies tab. However, Effective settings data took additional time to update - there are separate timing cycles for policy deployment status versus effective settings reporting.

# Check if policies are being received
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\SenseCM" | Select-Object LastCheckinSuccess, LastCheckinAttempt

# Verify antivirus settings applied
Get-MpPreference | Select-Object DisableRealtimeMonitoring, SubmitSamplesConsent

Force Manual Policy Sync:

1. Navigate to device in Defender XDR portal
2. Click device actions menu ("...")
3. Select "Policy sync"
4. Wait 2-5 minutes for completion

Step 7: Verify and Monitor with Effective Settings

After policies are deployed, use Effective Settings to verify what's actually applied on your devices.

How to Check Effective Settings

Location: Defender XDR Portal → Device page → Configuration management → Effective settings tab

Device Configuration page before policy application showing "No policies have been applied"

Device Security policies tab showing successful policy deployment with "Success" status

What You'll See:

• Setting names - Individual security configurations
• Policy types - Antivirus, ASR rules, firewall, etc.
• Effective values - What's actually configured
• Source - What configured each setting
• Last report time - When setting was last reported

Effective Settings view showing security configurations and their sources

Configuration Sources:

• Microsoft Defender for Endpoint (your Settings Management policies)
• Group Policy (shows registry paths)
• Intune policies (if co-managed)
• Default settings
• Unknown + registry path (direct registry modifications)

Common Issues and Solutions

Policy Conflicts:

Key Limitations:

• Windows only - Effective Settings not available for macOS/Linux
• Manual review required - No bulk querying across devices
• No KQL integration - Cannot automate compliance reports through Advanced Hunting

When Settings Don't Apply

Troubleshooting Steps:

1. Check Effective Settings for actual configuration source
2. If "Group Policy" is the source - review and update GPO
3. If "Unknown + registry path" - investigate that specific registry location
4. Use "Policy sync" device action to force immediate update
5. Wait up to 90 minutes for automatic sync cycles

Understanding "Unknown" Sources

The Effective Settings display can be confusing when it shows sources like "Unknown (GroupPolicy)". This doesn't mean the configuration is actually unknown - it means:

• Group Policy is controlling the setting (this is known)
• "Unknown" refers to the specific GPO name/path not being identified in the portal
• The setting is working correctly - "Allowed" shows the effective value

Effective Settings showing "Unknown (GroupPolicy)" source - the setting is managed by GPO but specific policy name isn't identified

Sentinel Integration for MDE Monitoring

Microsoft Defender for Endpoint already provides extensive telemetry through Advanced Hunting tables (DeviceInfo, DeviceEvents, etc.), but when managing Security Settings Management at scale, you need additional visibility that isn't available by default. With Microsoft Sentinel now available directly in the Defender portal alongside the new Sentinel Data Lake capabilities, you have a unified platform for correlating MDE data with enrollment events and Entra ID device management - all within the same security.microsoft.com interface where you manage your Settings Management policies.

MDE + Sentinel Data Strategy

What MDE Provides by Default:

Note: This is not a complete list - Defender XDR offers many more Advanced Hunting tables. These are just some examples of the available endpoint-related tables:

• DeviceInfo table - Device inventory and basic management status
• DeviceEvents - Security events and process activity
• DeviceProcessEvents - Process execution details
• DeviceNetworkEvents - Network connections and communications

What's Missing for Settings Management:

• Enrollment status tracking - No visibility into Settings Management enrollment process
• Policy application timing - Can't track when specific policies are applied
• Failure diagnostics - No detailed enrollment failure reasons
• Synthetic device correlation - Can't link MDE devices to Entra ID synthetic devices

Required Data Connectors for Complete Visibility

Core Connectors Needed:

1. Microsoft Defender XDR - Brings MDE Advanced Hunting tables to Sentinel
2. Entra ID - Provides AuditLogs for device management operations
3. Azure Activity - Tracks policy and configuration changes
4. Windows Security Events via AMA - Custom DCR for SENSE operational events

From MMA to AMA: Why This Changes Everything for MDE Monitoring

For those who've been in the trenches with Log Analytics since the early days, you know the pain. Microsoft Monitoring Agent (MMA) was an all-or-nothing proposition. You wanted to collect Windows Security events? Sure, here's ALL of them. Enjoy your massive ingestion bills.

The Old MMA World:

• No granular control over event collection
• Collect entire event logs or nothing
• Brutal ingestion costs for Security event logs
• No way to filter at the source
• Performance impact from collecting everything

Enter Azure Monitor Agent and DCRs:

Data Collection Rules fundamentally changed the game. Now we can say "I only want Event IDs 59 and 71 from the SENSE/Operational log" and that's exactly what we get. This isn't just about cost savings (though your CFO will love you) - it's about collecting meaningful data without the noise.

The Real Benefits:

• Surgical precision in event collection
• Dramatic cost reduction (collecting 2 events vs thousands)
• Better performance on endpoints
• Cleaner data in your workspace
• Easier to build focused analytics

Custom DCR Implementation for SENSE Monitoring

Since SENSE operational events aren't included in standard security event collection, here's the complete DCR configuration:

{
    "location": "westeurope",
    "tags": {
        "Purpose": "MDE Settings Management Monitoring",
        "createdBy": "Sentinel"
    },
    "kind": "Windows",
    "properties": {
        "dataSources": {
            "windowsEventLogs": [
                {
                    "streams": ["Microsoft-SecurityEvent"],
                    "name": "SENSEEnrollmentEvents",
                    "xPathQueries": [
                        "Microsoft-Windows-SENSE/Operational!*[System[(EventID=59)]]",
                        "Microsoft-Windows-SENSE/Operational!*[System[(EventID=71)]]"
                    ]
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/{subscription-id}/resourceGroups/{rg-name}/providers/Microsoft.OperationalInsights/workspaces/{workspace-name}",
                    "name": "SentinelWorkspace"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": ["Microsoft-SecurityEvent"],
                "destinations": ["SentinelWorkspace"]
            }
        ]
    }
}

Key Decisions:

• Temporary or Permanent? I recommend temporary during rollout, then evaluate
• Scope? All devices that will use Settings Management
• Why these events? They definitively show enrollment start (59) and success (71)

Key Event IDs for MDE Settings Management Enrollment

Beyond the AuditLogs in Entra ID, you can also monitor the actual enrollment process on individual devices through Windows Event Logs. These events provide real-time visibility into the Settings Management enrollment process.

Event Log Location: Microsoft-Windows-SENSE/Operational

Critical Event IDs:

• Event ID 59: "Starting command: endpointconfigmanagementenrollcommand" - Indicates enrollment attempt begins
• Event ID 71: "Succeeded to run command: endpointconfigmanagementenrollcommand" - Confirms successful enrollment

Monitoring Strategy:

• Event ID 59 without a corresponding Event ID 71 indicates enrollment failure
• Large time gaps between Event ID 59 and 71 suggest enrollment performance issues
• These events can be collected via Sentinel's Windows Security Events connector for centralized monitoring

SecurityEvent
| where EventID in (59, 71)
| where EventData contains "endpointconfigmanagementenrollcommand"
| extend EnrollmentAction = case(
    EventID == 59, "Enrollment Started",
    EventID == 71, "Enrollment Succeeded",
    "Unknown"
)
| project TimeGenerated, Computer, EventID, EnrollmentAction
| sort by TimeGenerated desc

Sentinel query results showing Settings Management enrollment events - Event ID 59 (enrollment started) followed by Event ID 71 (enrollment succeeded)

Monitoring Synthetic Device Registration in Entra ID

When MDE Settings Management enrolls a device, it creates a synthetic device identity in Entra ID. This operation is logged in AuditLogs and provides valuable insight into the enrollment process.

What You'll See in Sentinel AuditLogs

Here's an actual AuditLogs event showing synthetic device creation for a Windows Server (SRV02):

{
  "TenantId": "XXXXXXXXXXXXXXXXXXXXXXXXXX",
  "SourceSystem": "Azure AD",
  "TimeGenerated": "2025-09-01T16:49:35.2412574Z",
  "OperationName": "Add device",
  "Category": "Device",
  "ResultType": "",
  "ResultSignature": "None",
  "Result": "success",
  "Identity": "Microsoft Intune",
  "InitiatedBy": {
    "app": {
      "displayName": "Microsoft Intune",
      "servicePrincipalId": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    }
  },
  "TargetResources": [
    {
      "id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "displayName": "SRV02",
      "type": "Device",
      "modifiedProperties": [
        {
          "displayName": "AccountEnabled",
          "oldValue": "[]",
          "newValue": "[true]"
        },
        {
          "displayName": "CloudDeviceOSType", 
          "oldValue": "[]",
          "newValue": "[\"Windows Server\"]"
        },
        {
          "displayName": "CloudDeviceOSVersion",
          "oldValue": "[]", 
          "newValue": "[\"10.0.26100.4946\"]"
        },
        {
          "displayName": "DeviceId",
          "oldValue": "[]",
          "newValue": "[\"21c24f9b-c8c4-741e-b1d9-6f9a196a7a71\"]"
        }
      ]
    }
  ]
}

Key Fields for Settings Management Monitoring:

• OperationName: "Add device" - Indicates device registration
• Identity: "Microsoft Intune" - Shows the service performing the action
• CloudDeviceOSType: Identifies the platform (Windows Server, Windows, etc.)
• DeviceId: Unique identifier for correlation with MDE data

The Targeting Challenge Nobody Discusses

Settings Management targeting seems straightforward - assign policies to Entra ID security groups. Done, right? Not quite. When you start planning for production deployments, the limitations become painfully clear, especially if you're coming from the Configuration Manager world.

Here's the reality: every unique combination of settings needs its own policy and security group. You can't say "apply the baseline antivirus policy but exclude this one folder for SQL servers" - you need a completely separate policy. This becomes a management nightmare at scale.

Missing the Power of Configuration Manager Collections

If you've worked with Configuration Manager, this targeting approach feels like a massive step backward. ConfigMgr collections were incredibly sophisticated - you could write WQL queries targeting devices based on any hardware or software attribute, extend hardware inventory to collect custom application data, and build collections based on that data.

Remember configuration baselines? Those allowed complex compliance rules with remediation scripts and exception handling. You could create nested collections with include/exclude rules that gave you surgical precision in targeting. Need to target "All SQL Servers with version 2019 or higher, excluding development environment"? Easy. Want a baseline policy like "Corporate Security Standard with Exchange Server exceptions"? No problem.

The dynamic membership in ConfigMgr collections meant they automatically updated based on changing device properties. You could even use PowerShell discovery scripts to gather custom data for targeting decisions. It was incredibly powerful and flexible.

Unfortunately, Intune never caught up to ConfigMgr's targeting sophistication, and Settings Management inherits these same limitations. We're essentially back to basic group membership for everything.

Why Security Groups Are Both Simple and Limiting

The Reality:

• You can only target Entra ID security groups
• No device-level exceptions within a policy
• No conditional targeting based on device state
• If a device is in the group, it gets ALL the policy settings
• No equivalent to ConfigMgr's collection query rules or hardware inventory extensions

The Challenge for Production Planning:

• If you need different antivirus exclusions for SQL servers vs web servers, that's two separate policies
• If some servers need specific firewall rules, that's another policy
• Each unique combination of settings requires its own policy and group
• This can quickly become complex to manage at scale
• No baseline policies with exception handling like we had in ConfigMgr

Planning Considerations for Group Structure

As I prepare for production deployment, here are the key considerations:

Group Design Questions:

• How to handle servers with different security requirements?
• Should groups be based on server role, environment, or security tier?
• How to manage the multiplication of policies and groups?
• What's the maintenance overhead of multiple policies?

The Fundamental Limitation:
Every unique combination of settings needs its own policy and group. You can't say "apply baseline but exclude this one folder" - you need a completely separate policy. This inflexibility means careful planning is essential before deployment.

Automation Ideas I'm Exploring

Manual group management won't scale for large deployments, and frankly, it goes against everything I believe about infrastructure automation. In my work with Azure Arc for Servers, I rely heavily on Azure Automation for countless tasks - everything from tag-based server management to automated deployment workflows. I've shared many of these solutions through my premium program because automation is what separates good infrastructure management from great infrastructure management.

If you're looking to implement similar automation in your environment, check out our complete solution catalog where you can explore 40+ done-for-you Azure automation solutions and sign up for premium access to get the exact scripts and frameworks I use in enterprise deployments.

When you're getting into Security Settings Management and Azure Arc, you'll quickly realize that the basic targeting capabilities aren't enough. You need a custom solution that simplifies the complex relationships between policies, Entra security groups, device attributes, and Azure Arc tags. This is exactly the kind of challenge that Azure Automation was built to solve.

The Azure Automation Approach I'm Considering:
My current thinking involves leveraging Azure Arc tags as the single source of truth for server classification, then using Azure Automation runbooks to automatically manage Entra ID security groups and device attributes based on those tags. For example, when a server gets tagged with "Role=SQLServer" and "Environment=Production" in Azure Arc, automation workflows could potentially:

Why This Matters for Settings Management:
The power of this approach is that your server classification happens once in Azure Arc (where you're probably already managing these servers), and everything else flows from there automatically. Change a server's role tag in Arc, and within minutes it's moved to the appropriate security groups and receiving the correct security policies. This eliminates the manual overhead that would otherwise make Settings Management unmanageable at scale.

Custom Attributes as the Bridge:
Entra ID's custom attributes become the bridge between Azure Arc tags and dynamic group membership. The automation updates device attributes based on Arc tags, and dynamic groups use those attributes for membership rules. It's a three-tier system that provides the flexibility ConfigMgr admins expect.

Troubleshooting (When Things Go Wrong)

When Settings Management doesn't work as expected, you need a systematic approach to diagnose the issue.

Registry Detective Work

# Check enrollment status
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\SenseCM"

Key Registry Values After Successful Enrollment:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SenseCM]
"EnrollmentStatus"=dword:00000001  (1 = Success, 0 = Failed)
"TenantId"="201d60fd-20c6-4d0c-929f-6510f41a6fb2"
"IntuneDeviceId"="21c24f9b-c8c4-741e-b1d9-6f9a196a7a71"  (Synthetic device ID)
"EnrollmentUrl"="https://edr-neu.eu.endpoint.security.microsoft.com/..."
"LastCheckinAttempt"=hex(b):...  (Will be populated after enrollment)
"LastCheckinSuccess"=hex(b):...  (Will be populated after successful sync)

Common Issues and Real Solutions

Enrollment Error Codes Reference

When enrollment fails, specific error codes help identify the root cause. Here are the most common error codes and their meanings:

Step-by-Step Troubleshooting Process

When enrollment fails, follow this order:

1. Check Event Logs: Look for Event ID 59 without corresponding Event ID 71
2. Registry Analysis: Examine EnrollmentPayload for specific error codes
3. Device Verification: Confirm device meets all prerequisites
4. Network Testing: Verify connectivity to *.dm.microsoft.com
5. License Validation: Ensure proper MDE licensing (not just Defender for Servers)
6. PowerShell Check: Verify PowerShell is not in Constrained Language Mode

MDE Client Analyzer - The Ultimate Diagnostic Tool

When troubleshooting gets complex, Microsoft's MDE Client Analyzer is your best friend. This tool provides comprehensive device analysis and identifies common configuration issues that could prevent Settings Management enrollment.

How to Use MDE Client Analyzer:

1. Download: Get the latest version from Microsoft Learn
2. Run Analysis: Execute MDEClientAnalyzer.cmd from your download location
3. Review Results: Tool creates a timestamped zip file (e.g., MDEClientAnalyzerResult_2504090810.zip)
4. Open Report: Extract and open MDEClientAnalyzer.htm for detailed analysis

MDE Client Analyzer provides comprehensive device analysis including enrollment status, connectivity tests, and detailed configuration information

What the Analyzer Reveals:

• Device onboarding and enrollment status
• Network connectivity to Microsoft endpoints
• Certificate and authentication issues
• Registry configuration problems
• Service status and dependencies
• Policy application conflicts

The analyzer identifies specific issues and provides actionable recommendations for resolving Settings Management enrollment problems

Effective Settings Reality Check

The Effective Settings Reporting Lag

The Effective Settings reporting refresh cycle is not as fast as I initially expected - it appears to update approximately once per day rather than in real-time.

What I've Observed:

• Policy shows "Success" in 30-45 minutes
• Registry shows policy applied immediately after
• Effective Settings tab? Come back tomorrow
• Even manual policy sync doesn't force immediate update

My Testing Results:

• Applied policy at 2:00 PM
• Policy status "Success" at 2:33 PM
• Checked Effective Settings every hour
• Settings finally appeared next morning

The Missing Data That Makes This Harder

What We Don't Have:

• No KQL table for effective settings - Can't query compliance across fleet
• No API for settings data - Can't automate compliance reports
• No bulk export - Manual review only, one device at a time
• No real-time updates - Everything is delayed by ~24 hours

The Critical Gap

Yes, vulnerability management has some security recommendations (like "Defender is disabled" or "BitLocker is off"). But that's not what we need here. When I deploy a Settings Management policy with 10 specific configurations, I need a table showing all 10 settings and their actual values per device.

Workaround:
Use PowerShell to verify actual applied settings:

# Check actual antivirus settings
Get-MpPreference | Select-Object DisableRealtimeMonitoring, DisableBehaviorMonitoring

# Don't trust the portal for immediate confirmation

Automation Scripts for Production Deployment

Manual enrollment works for testing, but production deployments require automation to manage Settings Management at scale. The specific APIs and permissions you need depend on what you're trying to accomplish - device tagging, compliance monitoring, or group management.

When implementing automation, you'll need proper service principal setup with delegated permissions and correct scopes for Microsoft Graph API connections. The complexity varies based on your automation goals.

Example app registration setup - actual permissions depend on your specific automation requirements

Available APIs for Settings Management

While Security Settings Management doesn't have direct APIs for policy management, you can leverage Microsoft's security APIs to automate device management and compliance monitoring.

Microsoft Graph API Permissions for Settings Management Automation:

• DeviceManagementManagedDevices.ReadWrite.All - Query and manage enrolled devices, check enrollment status
• Group.ReadWrite.All - Create dynamic security groups, manage group membership for policy targeting
• Directory.Read.All - Query device objects, search by display name or other properties
• Device.ReadWrite.All - Read device information, update device attributes for group targeting

Microsoft Defender XDR APIs:

• Advanced hunting queries for compliance monitoring and data analysis
• Access to all unified Defender XDR tables under Advanced Hunting
• Important: This is for querying data only, not for invoking actions

Required Permissions for Defender XDR API:

• Application: AdvancedHunting.Read.All - Run advanced hunting queries
• Permission ID: 7734e8e5-8dde-42fc-b5ae-6eafea078693

Microsoft Defender for Endpoint APIs:

• Device tagging for enrollment control
• Machine actions and response automation
• Bulk machine operations (up to 500 devices per API call)

Required Permissions for Defender for Endpoint API:

• Application: Machine.ReadWrite.All - 'Read and write all machine information'
• Delegated (work or school account): Machine.ReadWrite - 'Read and write machine information'

API Limitations and Data Sources

The Data Source Challenge:

Settings Management monitoring requires combining data from multiple disconnected sources:

• Graph API - Device objects with managementType: "MicrosoftSense"
• Entra ID AuditLogs - Synthetic device registration events
• Windows Event Logs - Enrollment Event IDs 59 and 71
• Defender Advanced Hunting - Device compliance and onboarding status
• Portal UI only - Effective settings (no API access)

This is why comprehensive Settings Management reporting is challenging - the data is scattered across multiple systems with different identifiers and timestamps.

Enterprise Automation Capabilities

While manual tagging works for small deployments, enterprise environments require automated approaches. The MDE-Management tag can be applied programmatically through the Microsoft Defender for Endpoint API, eliminating the need for manual portal operations.

Bulk Operations:

• Add or Remove Multiple Machine Tags API - Tag up to 500 machines per API call
• See: Microsoft Defender for Endpoint API documentation

Automation Capabilities:

• Conditional Logic: Filter by OS platform, existing tags, or custom criteria
• Integration Ready: Works with Azure Automation, Logic Apps, or custom scripts
• Audit Trail: All API operations are logged in Entra ID audit logs

Authentication Methods

The Future is Unified (Whether We Like It or Not)

Microsoft's direction is crystal clear: everything security-related will live in the Defender XDR portal. With Sentinel integration, Settings Management, and the new data lake, they're building a security management monolith.

For those of us who've been doing this for years, it's both exciting and concerning. Exciting because we finally have integrated tools that actually talk to each other. Concerning because we're putting all our eggs in Microsoft's basket.

But here's the thing - it works. Being able to manage security policies, monitor with Sentinel, and investigate with Advanced Hunting from one portal is genuinely game-changing. The 90-minute sync delays and daily effective settings updates are annoying, but the alternative (managing 5 different tools) was worse.

What This Means for Your Infrastructure

If you're managing hybrid or multi-cloud environments, the unified Microsoft security platform represents both an opportunity and a commitment. The integration between Azure Arc, Defender for Cloud, MDE Settings Management, and Sentinel creates a cohesive security operations platform that was simply impossible to achieve with disparate tools.

The question isn't whether this unified approach is perfect - it's not. The question is whether it's better than what we had before, and for most enterprise environments, the answer is yes.

Looking Forward

Microsoft's roadmap clearly shows continued investment in the unified security platform:

• Deeper Azure Arc integration - Better targeting based on Arc tags and properties
• Enhanced Sentinel capabilities - More security data sources and automation
• Improved reporting - Better visibility into policy compliance and effectiveness
• Expanded platform support - More granular controls for Linux and macOS

The foundation is solid. The integration points are working. The missing pieces (like real-time effective settings reporting) will likely be addressed as the platform matures.

Whether you're ready or not, the future of Microsoft security management is unified, integrated, and increasingly automated. The organizations that understand this early and plan accordingly will have a significant advantage over those that try to resist the consolidation.

Welcome to the unified security future. It's not perfect, but it's here, and it's getting better every quarter.