Migrate identity detection, not just an agent
A domain controller can appear in Microsoft Defender for Endpoint (MDE) without having a properly activated and validated Defender for Identity (MDI) deployment. A successful migration must preserve identity signals, auditing and response capabilities—not simply display a new version number.
Migration from v2 to v3 became generally available in July 2026, including eligible Windows Server 2025 domain controllers. Some features roll out gradually across tenants. This guide proposes an operational rollout method; adapt and validate the examples in your environment.
Identify eligible servers and keep documented exceptions
Mixed v2/v3 environments are supported in the same MDI workspace. Do not consolidate identity roles onto a DC simply to accelerate this project.
Separate platform support from the migration path: the migration page still restricts its prerequisites to DCs without additional identity roles. Release notes also mention expanded automatic auditing, but the deployment matrix retains v2 for non-DC servers. When documentation differs, confirm the specific case with Microsoft instead of forcing installation.
| Situation | Deployment decision |
|---|---|
| Up-to-date Windows Server 2019, 2022 or 2025 DC | v3 candidate; confirm portal eligibility. |
| Windows Server 2016 DC | Keep v2 and plan OS modernization. |
| AD FS, AD CS or Entra Connect server that is not a DC | The deployment matrix still prescribes v2. |
| DC also hosting another identity role | v3 deployment is supported; do not assume in-place migration eligibility. |
| VPN integration or syslog notification dependency | Keep v2 on the affected DCs while that dependency remains. |
Check MDE onboarding, patches and resources
Current v3 requirements include Windows Server 2019 or later, the July 2026 or later cumulative update and actual MDE onboarding. Having antivirus installed is insufficient; Microsoft Defender Antivirus may be active or passive. Migration requires v2 sensor version 2.254.19112.470 or later.
Allocate the VM’s full memory: disable Hyper-V Dynamic Memory and reserve all guest memory on VMware. The v3 sensor limits itself to 30% CPU and 1.5 GB memory; these are not DC sizing values or a guarantee of complete collection under load. Also review ExpressRoute requirements.
Confirm licensing and administrative access
Verify Defender for Identity entitlements for covered users and the MDE rights applicable to servers. Do not assume that an installed agent or an arbitrary Microsoft 365 subscription covers every scenario. Have the licensing owner confirm entitlement.
For MDI administration, use Security Administrator or Microsoft’s required Unified RBAC permissions: System settings (Read and manage) and Security settings (All permissions). Distinguish portal access from Windows privileges needed for local checks. Avoid using Global Administrator as a permanent daily work account.
Capture a PowerShell baseline without changing AD
Start with one pilot DC. These read-only commands run in an elevated PowerShell console; they do not migrate anything. Keep before-and-after results in a protected administration location.
Get-HotFix is an inventory aid, not standalone proof of compliance. Compare the build, restart status and updates applicable to your Windows Server release. Separately verify replication, DNS and the availability of other DCs before maintenance.
- Complete the inventory with Entra Connect, third-party agents, VPN/syslog integrations and network dependencies.
- Record existing health alerts so they are not automatically blamed on migration.
- Maintain a per-DC record: AD site, OS/build, MDI version, MDE health, role, owner, decision and validation evidence.
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber, LastBootUpTime
Get-Service -Name Sense,AATPSensor,AATPSensorUpdater -ErrorAction SilentlyContinue |
Select-Object Name, Status, StartType
Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 8 HotFixID, InstalledOn
Get-WindowsFeature AD-Domain-Services,ADFS-Federation,ADCS-Cert-Authority |
Select-Object Name, InstallState
auditpol.exe /get /category:*Use the official diagnostic script before broad remediation
Download Test-MdiReadiness.ps1 from the linked Microsoft repository, review it and use an approved copy. It reports on prerequisites and configuration; do not treat its output as a substitute for the portal’s migration eligibility status.
Depending on its parameters and version, the script can inspect other identity servers in the domain. Read its help before running it and restrict scope where needed. Reports contain infrastructure details: never post them in a public support discussion.
Get-Help .\Test-MdiReadiness.ps1 -Full
.\Test-MdiReadiness.ps1 -Domain "corp.example" `
-DomainController "dc01.corp.example" `
-Path "C:\Admin\MDI-Readiness" -OpenHtmlReportMigrate a pilot DC through the Defender portal
At security.microsoft.com, open Settings > Identities > On-premises > Sensors. Select a DC marked Ready for migration, choose Migrate and confirm. The transition typically takes up to 20 minutes; v2 runs while v3 is prepared. Do not uninstall v2 beforehand.
Track Migrating followed by Up to date. For Not ready for migration, read the explanatory tooltip and address the stated prerequisite. Microsoft’s uninterrupted-switchover description does not eliminate change planning, particularly for patching and subsequent cleanup.
Separate directory-read accounts from action accounts
The Directory Service Account (DSA) and action account have different purposes. Once any sensor is v3, Microsoft instructs you to select Automatically use the sensor’s local system account in Manage action accounts. v3 response actions use LocalSystem, not a gMSA.
Do not immediately delete every gMSA. Remaining v2 sensors may still need the DSA, and an account may have other consumers. Credential validation continues at workspace scope. Inventory directory-read, response and application dependencies separately before retiring accounts.
Align automatic auditing with Group Policy
After reviewing the change, enable Automatic Windows auditing configuration under Settings > Identities > General > Advanced features. The sensor applies local settings and SACLs; conflicting GPOs can overwrite them. Automatic auditing runs every 24 hours.
For manual configuration, start with a dedicated DC GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration. Follow Microsoft’s matrix, including required SACLs. An audit policy alone does not cover every category.
Compare effective settings, not just GPO links
If your approved DefenderForIdentity module is already installed, Get-MDIConfiguration provides a local readout. The commands below do not create GPOs. Do not run a blanket Set-MDIConfiguration just to clear an alert.
Compare results after a normal policy refresh and the next automatic-auditing cycle. Correct persistent drift in the authoritative configuration source instead of repeatedly applying local fixes.
Import-Module DefenderForIdentity
Get-Command Get-MDIConfiguration -Syntax
Get-MDIConfiguration -Mode LocalMachine -Configuration All
gpresult.exe /scope computer /rRPC and updates: retire outdated instructions
Starting with v3.0.8, RPC auditing is enabled automatically; older guides requiring the Unified Sensor RPC Audit tag no longer describe the current path. v3 updates through Windows Update, and the v2 Delayed update option does not apply.
Include MDI in Windows Server patch rings. Operational recommendation: update one representative DC, verify signals and services, then move to the next group. Avoid restarting every DC in a site simultaneously.
Verify telemetry with KQL
Check device, user and group timelines in Defender, plus sensor health. Make an authorized change to a nonprivileged test group and verify its visibility. Validation must never add a user to a production administrative group.
These are read-only query examples, not detection rules or sensor certification. Replace the FQDN. Machine fields identify involved entities, not necessarily the collecting sensor; combine results with portal health and a known test event.
- Empty results do not prove failure: check actual activity, time range, observed names, permissions and ingestion delays.
- One recent row does not prove coverage of every protocol or DC.
- Keep timestamped evidence for each DC and compare equivalent activity periods before and after.
IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where TargetDeviceName =~ "dc01.corp.example"
| summarize Events=count(), LastSeen=max(Timestamp) by ActionType
| order by LastSeen descIdentityQueryEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "dc01.corp.example"
or DestinationDeviceName =~ "dc01.corp.example"
| summarize Events=count(), LastSeen=max(Timestamp) by Protocol, ActionType
| order by LastSeen descTroubleshoot failures and define rollout stop criteria
For failures, use MDE Client Analyzer to examine onboarding, Sense, connectivity and health. Internet access from a browser does not prove that the MDE service can communicate in its own context. Protect diagnostic reports, which can contain sensitive data.
Recommendation: pause the wave if a DC loses signals, develops new memory pressure or shows AD errors. Keep timestamps, versions, messages and diagnostics for Microsoft support. Do not disable MDE or uninstall agents at random to reset the situation.
| Observation | Next check |
|---|---|
| Not ready for migration | Exact portal reason, OS/build, v2 version and MDE onboarding. |
| Migration failed | Client Analyzer, then support if MDE is healthy. |
| Connected sensor, few signals | Effective auditing, expected activity, ingestion and read permissions. |
| DSA alerts on a v3 sensor | Remaining v2 dependencies and workspace-level credential validation. |
| Resource alert | DC load, reserved memory and partially monitored events. |
Clean up after acceptance and prepare recovery
Migration disables the v2 service but leaves its software installed. After accepting the pilot, schedule its removal; a restart may be needed. Remove Npcap only when no other application uses it.
Do not confuse cleaning up v2 with deleting the v3 entry: deleting a v3 sensor stops its monitoring. Do not improvise rollback by restarting the old service. Before the change, document a recovery process validated with Microsoft for your case; retained v2 files do not guarantee a supported rollback.
A realistic rollout for a small IT team
Example internal plan: day 1 for inventory and gaps; day 2 for a pilot; observe at least one business-activity and policy cycle; then proceed site by site with individual validation. This timing is an operational recommendation, not a Microsoft commitment.
Define completion through evidence: eligible DCs covered, v2 exceptions documented, coherent audits, fresh telemetry, response mechanisms validated in a controlled scope and patch ownership assigned. Sensor migration does not replace AD hardening.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →