Defender for Identity sensors: installation and health issues on domain controllers

Microsoft Defender for Identity only detects what its sensors can see. A sensor that won't install, keeps restarting or quietly stops collecting Windows events leaves a blind spot on your most important servers. In this post I'll separate the classic v2.x sensor from the newer v3.x sensor you activate on domain controllers, then work through prerequisites, the Directory Service account, the Health issues page and the fixes for the alerts you're most likely to meet.

Symptoms#

• Settings › Identities › Health issues (under Deployment) shows open items such as Sensor stopped communicating, Sensor service failed to start, Directory services user credentials are incorrect or NTLM Auditing is not enabled.
• A domain controller never shows up as a sensor, or the activation list says it needs the classic sensor or an OS upgrade.
• Classic setup fails, or the sensor services won't stay running.
• Identity alerts and timelines are thin for one site or domain while others look normal.

Why it happens#

Two sensor generations now run side by side, and many problems come from applying one generation's rules to the other.

Beyond the version mix-up, root causes fall into five groups:

• Prerequisites: a missing cumulative update or Defender for Endpoint onboarding (v3.x); .NET Framework, Npcap or power plan problems (v2.x); dynamic memory on virtual domain controllers (both).
• Connectivity: a firewall, proxy or TLS inspection device between the sensor and its cloud endpoints. v3.x uses the Defender for Endpoint URLs.
• Identity: a Directory Service account with a wrong or expired password, or a gMSA the server isn't allowed to retrieve.
• Auditing: advanced audit policy, NTLM auditing (event 8004) or object auditing on the domain, Configuration container, AD FS or AD CS not configured as required.
• Resources: not enough CPU or memory, so the sensor drops events or restarts.

How to fix it#

1. Decide which sensor each server should run#

In the Defender portal open Settings › Identities and check the Activation page (newer tenants may show this as the Sensor management tab of the On-premises page). It uses device inventory to show whether each server can take the new sensor, needs the classic one or needs an OS upgrade first. Mixed v2.x and v3.x environments are supported, but a server can't run both: v3.x activation requires that no v2.x sensor is installed, so migrate server by server.

2. Activate v3.x on eligible domain controllers#

1. Confirm the server is onboarded to Defender for Endpoint (Microsoft Defender Antivirus can be active or passive) and has the July 2026 or later cumulative update:
   PowerShell

   Get-Service -Name Sense | Select-Object Status, StartType
   Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -Name OnboardingState   # 1 = onboarded
   Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 3 HotFixID, InstalledOn

   If Sense won't onboard, work through SENSE onboarding errors first.
2. Select the server and choose Activate, or turn on automatic activation so eligible servers are activated as they're discovered.
3. On Hyper-V, disable Dynamic Memory for virtual domain controllers; on VMware, reserve all guest memory.
4. Turn on automatic Windows auditing configuration on the Identities Advanced features page. With manual Group Policy auditing, some v3.x environments keep raising auditing health issues even when the settings are correct; the automatic option resolves them. With sensor 3.0.8 or later (July 2026 cumulative update) RPC auditing is also applied automatically, which clears Sensor v3.x RPC Audit Misconfigured.

3. Install the classic sensor cleanly (v2.x)#

From Settings › Identities › Sensors, select Add sensor to download the package and copy the access key. For a silent install, run:

"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<access key>"

Setup adds .NET Framework if needed (which can require a restart) and, since version 2.184, installs the Npcap 1.0 OEM driver. A Sensor has issues with packet capturing component issue means WinPcap, an old Npcap or a misconfigured Npcap is present: follow Microsoft's Npcap guidance before reinstalling. Set the High performance power plan, or you'll see Power mode isn't configured for optimal processor performance.

4. Fix the Directory Service account (v2.x)#

Directory services user credentials are incorrect appears on the Global health issues tab. For a standard account, re-enter the password under Settings › Identities › Directory Service accounts. For a gMSA, check from a domain controller that it can retrieve the password:

Test-ADServiceAccount -Identity mdiSvc01        # should return True
Get-ADServiceAccount -Identity mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
klist -li 0x3e7 purge                            # refresh the computer's group membership without a reboot
Install-Module DefenderForIdentity -Scope CurrentUser
Test-MDIDSA -Identity mdiSvc01 -Detailed

Two behaviours are by design. Automatic gMSA password rotation can briefly raise the alert, which closes once the sensor picks up the new password. And while a workspace-level DSA exists, it's validated on every sensor, v3.x included, so remove it after the last v2.x sensor is migrated.

5. Close auditing gaps#

Generate a report of what's missing, then fix it with Group Policy or let Defender for Identity configure it:

New-MDIConfigurationReport -Path "C:\MDI" -Mode Domain -OpenHtmlReport

Advanced audit policy and NTLM auditing are validated once a day per sensor, object auditing once a day per domain. The Configuration container replicates forest-wide, so configure its auditing once even if several domains report it.

6. Restore communication and stop service failures#

• Sensor stopped communicating fires after five minutes without a keep-alive. Check firewalls, proxies and TLS inspection. On v2.x, Test-MDISensorApiConnection from the same module tests the path to the sensor API; on v3.x, validate Defender for Endpoint connectivity as described in moving to streamlined connectivity.
• Sensor service failed to start means at least 30 minutes of failure. On v2.x, check the AATPSensor and AATPSensorUpdater services and read Microsoft.Tri.Sensor-Errors.log in C:\Program Files\Azure Advanced Threat Protection Sensor\<version>\Logs, then Microsoft.Tri.Sensor.log for context. Setup logs go to the installing account's %temp% folder. v3.x runs on the Windows Sense platform rather than as a separately installed service, so start from its health issue and the server's Defender for Endpoint health.
• Sensor reached a memory resource limit, Some Windows events are not being analyzed or Some network traffic could not be analyzed: add CPU and memory, or spread the load across more domain controllers in the site. On VMware guests, disable Large Send Offload V2 (IPv4) and IPv4 TSO Offload inside Windows.

Verify the fix#

• Health issues move from Open to Closed automatically once the cause is gone. Configuration checks run daily, so auditing issues can take up to a day to clear.
• The Sensors list shows the server healthy with a current version. A Sensor outdated (v3) issue means the required cumulative update is still missing.
• On v2.x, Get-Service AATPSensor, AATPSensorUpdater shows both Running.
• Every domain controller reports fresh activity in advanced hunting:

IdentityLogonEvents
| where Timestamp > ago(1h)
| where Application == "Active Directory"
| summarize Events = count(), Latest = max(Timestamp) by DestinationDeviceName
| sort by Latest asc

Good looks like: no open sensor health issues, and every domain controller in the results with a recent Latest value.

Prevent it next time#

• Move eligible domain controllers to v3.x and keep them current — the cumulative update level is now part of sensor health.
• Prefer automatic Windows auditing configuration over hand-built GPOs.
• On v2.x, use a gMSA as the Directory Service account; remove it once nothing needs it.
• Give virtual domain controllers fixed memory and the High performance power plan.
• Before planned maintenance, suppress the server's issue (suppression lasts seven days), then set it back to Open so it can close by itself.
• Healthy sensors matter beyond detections: automatic attack disruption disables compromised Active Directory accounts through domain controllers running the sensor.

References#

• Microsoft Defender for Identity health issues
• Deploy the Microsoft Defender for Identity sensor v3.x
• Activate the Microsoft Defender for Identity sensor v3.x