Defender for Identity Sensor Unable to Start on Windows Server 2016

Windows Server 2016 requires the Defender for Identity v2.x sensor, so inspect its error log immediately after a service-start attempt and resolve the matching gMSA, policy, or connectivity error rather than reinstalling it again.^1^

1. Capture the startup failure

Run an elevated PowerShell session:

$sensor = Get-Service | Where-Object {
    $_.Name -match 'AATP|TriSensor|Sensor' -or
    $_.DisplayName -match 'Advanced Threat Protection Sensor'
}
$sensor | Format-Table Name, DisplayName, Status

Restart-Service -Name $sensor.Name -ErrorAction Continue
Start-Sleep 10
Get-Content "$env:ProgramFiles\Azure Advanced Threat Protection Sensor\*\Logs\Microsoft.Tri.Sensor-Errors.log" -Tail 100

Review these files under:

C:\Program Files\Azure Advanced Threat Protection Sensor\<version>\Logs

• Microsoft.Tri.Sensor-Errors.log — startup errors.
• Microsoft.Tri.Sensor.log — chronological sensor activity.
• Microsoft.Tri.Sensor.Updater-Errors.log and Microsoft.Tri.Sensor.Updater.log — updater failures.

Also correlate the timestamp with Event Viewer → Windows Logs → System. Installation logs are under %USERPROFILE%\AppData\Local\Temp, or possibly C:\Windows\Temp/C:\Windows\SystemTemp when installation ran as a service.^2^

2. If the log says the gMSA password cannot be retrieved

A matching entry resembles:

CreateLdapConnectionAsync failed to retrieve group managed service account password

Check the allowed principals:

Get-ADServiceAccount mdiSvc01 `
  -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

The affected DC computer account—or a group containing it—must be listed. If absent, configure either the DC directly or the intended shared group:

# Direct assignment
$specificDC = Get-ADComputer -Identity 'DC201602'
Set-ADServiceAccount 'mdiSvc01' `
  -PrincipalsAllowedToRetrieveManagedPassword $specificDC

# Or assignment through the existing sensor-host group
$group = Get-ADGroup -Identity 'mdiSvc01Group'
Set-ADServiceAccount 'mdiSvc01' `
  -PrincipalsAllowedToRetrieveManagedPassword $group

Set-ADServiceAccount sets the principal collection; use the intended shared group or preserve every principal that still requires access. After changing group membership or retrieval permissions, refresh the LocalSystem Kerberos ticket and retry the service:

klist purge -li 0x3e7

A reboot also obtains a new ticket. Microsoft documents this exact startup signature and remediation.^3^

If permissions already look correct, check for the documented Secure Time Seeding condition:

Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet,LastLogonDate |
    Select-Object Name,PasswordLastSet,LastLogonDate

If either value is in the future, create a new gMSA with correct dates as the interim workaround and open a Directory Services support request.^3^

3. If the service remains in Starting

If Microsoft.Tri.Sensor-Errors.log reports failure to communicate with configured domain controllers and the System log contains performance-counter Access is denied errors, inspect the effective policy with rsop.msc:

Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Log on as a service

Identify and edit the controlling GPO in Group Policy Management, adding:

• NT SERVICE\ALL SERVICES
• The Defender for Identity gMSA

Then run:

gpupdate /force
klist purge -li 0x3e7

Retry the sensor service. This policy is required when Log on as a service is explicitly configured; rsop.msc only displays the effective policy and does not modify it.^4^

4. Test the “domain controller unreachable” path

That health issue specifically requires the sensor to establish LDAP connections to its configured DC and requires a Directory Service account for every deployed forest.^5^

From the affected server, test the actual configured DC:

Resolve-DnsName DC201602
Test-NetConnection DC201602 -Port 389
Test-NetConnection DC201602 -Port 3268
Test-NetConnection '<workspace-name>sensorapi.atp.azure.com' -Port 443
Test-NetConnection localhost -Port 444

For multi-forest communication, also test ports 636 and 3269 if LDAPS is configured. Sensor v2 requires outbound cloud HTTPS on TCP 443; localhost TCP 444 is used between the sensor and updater.^6^

Only when the log contains an HTTP connection failure, also verify that local firewall/security software is not blocking localhost TCP 443, as specified by the known communication-error guidance.^3^

After correcting the matching error, restart the installed sensor service and confirm:

1. Its Windows service state becomes Running.
2. New errors stop appearing in Microsoft.Tri.Sensor-Errors.log.
3. The portal closes both health issues automatically after it detects recovery.

References

1. Microsoft Defender for Identity deployment overview
2. Troubleshooting Microsoft Defender for Identity sensor using the Defender for Identity logs
3. Troubleshooting Microsoft Defender for Identity known issues
4. Configure a gMSA directory service account for Defender for Identity
5. Microsoft Defender for Identity health issues
6. Microsoft Defender for Identity sensor v2.x prerequisites