Defender for Endpoint Onboarding + Intune Security Baselines Without Conflicts · CloudEngineerHub
Intune12 min read5 views
Defender for Endpoint Onboarding + Intune Security Baselines Without Conflicts
Onboard MDE through the Intune connector the right way, then layer Windows MDM and Defender security baselines without the conflict storms — verified with Get-MpComputerStatus and registry checks.
C
CloudEngineerHub Team
Published: September 2, 2026· Last Updated: September 24, 2026·12 min read
Defender for Endpoint Onboarding + Intune Security Baselines Without Conflicts
Microsoft Defender for Endpoint plus Intune security baselines is the standard zero-trust floor for Windows. Deployed carelessly, though, the same settings arrive twice with different values and devices light up with policy conflicts that erode trust in the whole stack. Here is the clean path: onboard through the connector, verify locally, then layer baselines as a floor — not as a fight with your configuration profiles.
Visual Walkthrough
What must be true before Defender policies can do their job.
Interactive FlowMDE Onboarding — Sensor to Attack Surface Control6/6
1
Licensing verified
MDE P1/P2 entitlements mapped to users (not devices).
deploy
2
Onboarding package via Intune
Configuration profile ships the onboarding blob.
telemetry
3
Sensor reports in
Endpoint sensor connects to MDE service; device visible in portal.
ASR, device control, firewall, web protection via Intune.
6
Attack surface shrinks
Alerts, TVM score and ASR blocks show measurable lift.
MDE Onboarding — Sensor to Attack Surface Control. 1. Licensing verified: MDE P1/P2 entitlements mapped to users (not devices). — 2. Onboarding package via Intune: Configuration profile ships the onboarding blob. — 3. Sensor reports in: Endpoint sensor connects to MDE service; device visible in portal. — 4. OS/platform updated: Defender platform + intelligence updated automatically. — 5. Policies flow: ASR, device control, firewall, web protection via Intune. — 6. Attack surface shrinks: Alerts, TVM score and ASR blocks show measurable lift.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Licensing: Microsoft Defender for Endpoint (E5, Defender for Endpoint Plan 1/2, or equivalent) plus Intune licenses for the same users.
Tenant connection: security admin access to security.microsoft.com and Intune Administrator rights to establish the connector.
Enrolled devices: the auto-onboarding flow targets Intune-enrolled Windows devices; servers follow the MDE server path.
A ring model: baselines and profiles are assigned by group — design rings before you deploy either.
Verification tooling: the MDE Client Analyzer for stubborn cases, and local cmdlets (Get-MpComputerStatus) as the ground truth.
Onboard Through the Connector, Not Ad-Hoc Blobs
Start at intune.microsoft.com → Endpoint security → Microsoft Defender for Endpoint and set Connect Microsoft Intune to Microsoft Defender for Endpoint to On. That toggle establishes the compliance-signal pipeline and exposes automatically configure devices to onboard to Microsoft Defender for Endpoint — auto-onboarding for enrolled Windows devices, with no onboarding blob choreography. For explicit per-platform control, the Endpoint detection and response profile (Endpoint security → Endpoint detection and response → Windows) lets you set sample sharing, telemetry reporting frequency, and a manual onboarding package.
The connection also enables the reverse direction: MDE's Microsoft Defender Vulnerability Management data surfaces in Intune, and device compliance signals from MDE can feed Conditional Access — the connector is a two-way street, not just an onboarding button.
How the Pieces Fit Together
Interactive FlowMDE + Intune baseline flow6/6
1Intune enrollment
2MDE onboarding policy
3Defender sensor check-in
4Security baseline (single source)
5ASR + EDR policies
6Monitor conflicts in Defender portal✦
MDE + Intune baseline flow. Full text: Intune enrollment
MDE onboarding policy
Defender sensor check-in
Security baseline (single source)
ASR + EDR policies
Monitor conflicts in Defender portal
Three planes interact. The onboarding plane gets the sensor running and reporting to the MDE service (verify OnboardingState, OrgId). The policy plane configures the Defender stack: security baselines, endpoint security profiles for AV/ASR/firewall/EDR. The signal plane carries compliance state from Intune to Entra ID for Conditional Access, and MDE risk data back to Intune for device-risk-based compliance policies. Conflicts happen in the policy plane when the same setting arrives from two profiles — the fix is architectural (one owner per setting), not procedural (reshuffling assignments).
Verify on the device rather than trusting the console alone:
PowerShell
1
2
3
4
5
6
Get-Service Sense | Select-Object Status, StartType
Get-MpComputerStatus |
Select-Object AMRunningMode, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' |
Select-Object OnboardingState, OrgId
# Expected output: Sense Running/Automatic, AMRunningMode 'Normal', OnboardingState = 1 with a populated OrgId
OnboardingState = 1 means the device is onboarded and AMRunningMode should read Normal. For stubborn cases, run the Microsoft Defender for Endpoint Client Analyzer and cross-check tenant-side health at security.microsoft.com → Settings → Endpoints before blaming the network team.
Baselines as a Floor, Not a Fight
Under Endpoint security → Security baselines you'll find the Windows MDM baseline, the Microsoft Defender for Endpoint baseline, and the Edge baseline. Two disciplines keep them conflict-free:
One instance per baseline type per device group. Baseline versions are pinned per instance; when Microsoft ships an update, use the compare-versions view to review deltas before migrating the instance.
Treat baselines as the floor. Where a baseline and a configuration profile set the same setting differently, the baseline wins by Intune's documented behavior — so don't attempt to override baseline values with broad configuration profiles. Instead, scope a narrow settings catalog profile for genuine exceptions and document why it exists and who owns it.
Classic conflict generators to avoid: Attack Surface Reduction rules defined in both the baseline and a separate ASR profile, antivirus exclusions layered from two sources, and firewall settings arriving from both the baseline and endpoint security firewall profiles. The per-device policy views in Intune (device record → policy conflict details) show exactly which profiles fought; fix the conflict at the source rather than reshuffling assignments and hoping.
Configuration Deep Dive: ASR Rules Done Once, Done Right
Attack Surface Reduction rules are the highest-value, highest-conflict Defender setting. Deploy them through the Endpoint security → Attack surface reduction profile — one owner, one profile, per ring. Audit first: set each rule to audit mode, read the ASR report (Reports → Attack surface reduction), then promote proven rules to block. Verify the effective state locally, because the report tells you what policy says while the engine tells you what the device does:
PowerShell
1
2
3
4
# ASR rules as seen by the local engine — compare against policy intent
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
# Expected output: parallel lists — rule GUIDs and matching action codes (1 = block, 2 = audit, 6 = warn)
When the console says enabled but the engine disagrees, you have found a conflict — trace which profile actually won on that device before editing anything.
Real-World Enterprise Scenario: From Conflict Storm to Clean Baseline in Three Rings
A healthcare provider onboarded 4,200 Windows 11 workstations and immediately generated 300+ "policy conflict" tickets — ASR rules in both the MDE baseline and a legacy ASR profile, firewall settings in both a baseline and old configuration profiles. The remediation was architectural: one baseline instance per type per ring, a single ASR profile as the only ASR source, firewall consolidated into endpoint security firewall profiles, and every exception written as a narrow settings catalog profile with an owner and expiry note in the description. Conflicts dropped to zero within two ring cycles, and the compliance-signal pipeline to Conditional Access ran clean enough to enforce "compliant device required" for their EHR application.
Troubleshooting
Symptom
Likely cause
Fix
AMRunningMode shows Passive Mode
Third-party AV owns real-time protection
Remove the competing product or accept passive mode deliberately; never run two real-time engines
OnboardingState = 0 after auto-onboarding
Connector off, or device not licensed for MDE
Re-check the connector toggle and license assignment; rerun the EDR profile
Device shows policy conflicts in Intune
Same setting from baseline + another profile
Open device record → policy conflict details; remove the duplicate source
ASR rule in block mode but not blocking
Another profile overrode the action, or engine state stale
Compare Get-MpPreference output to policy intent; fix the source profile
Compliance signal missing in Entra
Compliance policy not assigned, or connector sync lag
Verify compliance policy assignment and force device sync; check the compliance report
Common Errors
Two baseline instances of the same type hitting one device — split rings so exactly one instance applies per device.
"Settings catalog override" attempts against baselines — baselines win; build exceptions as narrow profiles or accept the baseline value.
AV exclusions from two sources — exclusions are additive and dangerous; keep a single documented owner.
Manual onboarding blobs on connector-managed devices — double onboarding paths create drift; let the connector own it.
Visual Walkthrough
From Microsoft's download to drift-free enforcement in five gates.
TimelineSecurity Baseline — Download to Enforcement5/5
phase 1
1
Download + inventory
Baseline security template grabbed; current estate baselined.
phase 2
2
Gap analysis
Compare against GPO/Intune reality; conflicts listed.
phase 3
3
Pilot ring enforced
Baseline applied to canary devices; telemetry watched.
phase 4
4
Adjust + document
Exceptions documented with owners and expiry.
phase 5
5
Fleet enforcement
Broad assignment; drift detection via compliance + scripts.
Security Baseline — Download to Enforcement. 1. Download + inventory: Baseline security template grabbed; current estate baselined. — 2. Gap analysis: Compare against GPO/Intune reality; conflicts listed. — 3. Pilot ring enforced: Baseline applied to canary devices; telemetry watched. — 4. Adjust + document: Exceptions documented with owners and expiry. — 5. Fleet enforcement: Broad assignment; drift detection via compliance + scripts.
Best Practices
One baseline instance per type per ring; review version deltas before migrating instances.
One owner per security domain: ASR, firewall, AV exclusions each live in exactly one place.
Verify locally with Get-MpComputerStatus and Get-MpPreference — the console is intent, the engine is truth.
Use the MDE Client Analyzer when a device disagrees with everyone.
Document every exception profile with owner and rationale; audit them quarterly.
Security Considerations
The connector ties device health to Conditional Access — unonboarded or passive-mode devices should be non-compliant and blocked from sensitive apps, or your zero-trust floor has a trapdoor. Keep real-time protection unambiguous: one engine owns it. ASR rules in block mode with a live report review cadence is where Defender policy pays rent; audit-first applies to ASR exactly as it does to App Control. And remember baselines are floors, not ceilings — your own threat model justifies going beyond them, never below.
FAQ
Do I still need manual onboarding packages if the connector is on?
No — auto-onboarding covers enrolled Windows devices. Manual packages remain for explicit control or special cases via the EDR profile.
Which baseline wins when it conflicts with a configuration profile?
The baseline, per Intune's documented behavior — design exceptions as narrow settings catalog profiles, not broad overrides.
Can I run two antivirus engines side by side?
One owns real-time protection; the other goes passive. Choose deliberately and document it — accidental passive mode is a common audit finding.
How do I see which profiles conflicted on a device?
Open the device record in Intune and review the policy conflict details view — it names the fighting profiles and settings.
Is the MDE security settings management alternative to Intune?
MDE offers its own settings-management path, but if you manage via Intune, pick one plane and keep ownership there — split-brain policy is a conflict factory.
Conclusion
A conflict-free Defender baseline stack is mostly discipline, not heroics: onboard through the connector, verify with the engine rather than the console, keep one owner per setting, and let baselines be the floor. Build it ring by ring, and pressure-test your understanding with /mock exams, /tools automation helpers, and the security bundles in the /store.
Comments
0No comments yet — be the first to share your thoughts.