Keep Defender for Identity sensor v2 scope to legacy controllers and non-DC identity roles

Frame this document as a source-led configuration and assurance check: Keep Defender for Identity sensor v2 scope to legacy controllers and non-DC identity roles. Only the official source and traced locations below supply facts. Confirm applicability before acting.

Source fact:

The official Microsoft Defender for Identity sensor v2.x prerequisites from Microsoft supports the following bounded statements:

• Sensor v2 supports domain controllers running Windows Server 2016 or earlier and AD FS, AD CS, or Microsoft Entra Connect servers that are not domain controllers. The research record locates this support at In this article > supported v2 scenarios.
• For domain controllers running Windows Server 2019 or later, Microsoft recommends sensor v3 instead of sensor v2. The research record locates this support at In this article > Tip following supported v2 scenarios.
• Defender for Identity deployment requires one of the listed EMS, Microsoft 365 Security, or standalone licenses; both F5 options also require the listed F1, F3, and EMS E3 prerequisites. The research record locates this support at Licensing requirements.

The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee.

What the source does not establish

Windows Server 2012 and 2012 R2 are past extended support; existing sensors can report but OS-dependent functionality may be unavailable, so this v2 page is not an operating-system support extension. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates.

Applicability questions

• For source statement 1 at In this article > supported v2 scenarios, which observable configuration, record, or test can confirm applicability here?
• For source statement 2 at In this article > Tip following supported v2 scenarios, which observable configuration, record, or test can confirm applicability here?
• For source statement 3 at Licensing requirements, which observable configuration, record, or test can confirm applicability here?
• Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance?
• How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations?
• Who approves the conclusion, exception, test window, and rollback threshold?

DSE recommendation:

DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation.

Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets.

Verification and evidence

Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations In this article > supported v2 scenarios; In this article > Tip following supported v2 scenarios; Licensing requirements. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator.

Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.

Official references

• Microsoft Defender for Identity sensor v2.x prerequisites — Microsoft