Notice: Due to size constraints and loading performance considerations, scripts referenced in blog posts are not attached directly. To request access, please complete the following form: Script Request Form Note: A Google account is required to access the form.
Disclaimer: I do not accept responsibility for any issues arising from scripts being run without adequate understanding. It is the user's responsibility to review and assess any code before execution. More information

Understanding Microsoft Defender for Identity Sensors: Classic vs Unified Architecture

Microsoft Defender for Identity provides organizations with critical threat detection capabilities for their on-premises Active Directory infrastructure. However, when deploying these sensors to Domain Controllers you need to choose between the classic v2.x sensors and the newer unified v3.x sensors.

Unfortunately as with many technologies there are cavets to using v3 sensors and in some cases you have no choice but to use the classic sensor (v2.xxx)

The Two Sensor Architectures

Classic Sensors (v2.xxx)

The classic Defender for Identity sensor requires manual installation using a setup package and access key downloaded from the Microsoft Defender portal. These sensors have been the foundation of Defender for Identity deployments for years and offer:

  • Manual deployment process: Installation requires running the Azure ATP sensor setup.exe with elevated privileges and following the setup wizard
  • Proven stability: Extensive testing and deployment in production environments
  • Full feature set: Complete access to all Defender for Identity capabilities including health alerts, posture recommendations, security alerts, and advanced hunting data
  • Broad compatibility: Support for Windows Server 2016 and higher, including both desktop experience and server core installations
This is the classic version shown below:


Unified Sensors (v3.x)

The unified sensor architecture represents a significant shift toward automated deployment through the "Activate" section of Defender for Identity, lets look at the benefits:

  • Automatic activation: Domain controllers can be activated either automatically where Defender for Identity activates them as soon as they're discovered, or manually by selecting specific domain controllers from the list of eligible servers
  • Streamlined management: No manual installation or access key requirements
  • Preview status: The v3.x sensor is still in preview and has some limited functionality compared to version 2.x, including reduced functionality for health alerts, posture recommendations, security alerts or advanced hunting data
  • Modern prerequisites: Designed for new domain controllers running Windows Server 2019 or later

This shows where the sensor is activated, which is under Defender > Identity > Activation, and this will install v3 (the unified sensor)


Critical Compatibility Constraints

The Mixing Problem

One of the most important technical constraints to understand is that classic and unified sensors cannot coexist in the same environment. For domain controllers running older operating systems, Microsoft recommends deploying the classic Defender for Identity sensor, and this creates an all-or-nothing deployment scenario.

Windows Server 2016 Limitations

Organizations running Windows Server 2016 domain controllers face particular challenges with the unified sensor approach. While classic sensors support Windows Server 2016, the unified v3.x sensors require Windows Server 2019 or later. This means:

  • Legacy infrastructure: Server 2016 domain controllers cannot utilize the unified sensor architecture
  • Forced classic deployment: Organizations with mixed Server 2016/2019+ environments must use classic sensors across all domain controllers
  • Upgrade pressure: To adopt unified sensors, organizations need complete domain controller infrastructure upgrades

This shows the problem with the older operating system installed, Server 2016 cannot be on boarded as it is "to old" as below:


Real-World Deployment Scenarios

Consider an organization with domain controllers running on different Windows Server versions:

  • Legacy servers: Running Windows Server 2016
  • Modern servers: Running Windows Server 2019+

In this scenario, the Windows Server 2016 controllers cannot support the unified v3.x sensor architecture. This forces the entire environment to use classic v2.x sensors, even on newer hardware that could support the unified approach.

Infrastructure Upgrade Considerations

When planning domain controller upgrades to enable unified sensor deployment, consider:

  1. Complete modernization: All domain controllers must support the unified architecture - the future!
  2. Operating system selection: Windows Server 2025 (and for Domain Controllers this should be core) offers a modern, streamlined approach
  3. Deployment timing: The first activation of unified sensors can take up to an hour to show as running, while subsequent activations appear within five minutes
  4. No restart requirement: Unified sensor activation doesn't require a restart or reboot

Technical Implementation Differences

Classic Sensor Deployment

The classic sensor installation process involves several manual steps:

  1. Download preparation: Download the sensor setup package and copy the access key from the Microsoft Defender portal
  2. Prerequisites: Ensure Microsoft .NET Framework 4.7 or later is installed on the machine
  3. Installation execution: Run the installer with administrative privileges
  4. Service configuration: The installation configures Defender for Identity sensor service and Defender for Identity sensor updater service

Unified Sensor Activation

The unified approach streamlines deployment significantly:

  1. Portal-based activation: Navigate to System > Settings > Identities > Activation in the Microsoft Defender portal
  2. Server selection: Choose eligible domain controllers from the discovered inventory
  3. Automatic configuration: The system handles service deployment without manual intervention
  4. Monitoring: Track activation status through the Sensors page in the portal

Feature Limitations and Considerations

Current Unified Sensor Constraints

Organizations considering unified sensors must understand current limitations:

  • Reduced detection capabilities: Limited functionality for health alerts, posture recommendations, security alerts, and advanced hunting data
  • Preview status uncertainty: Features and stability may change as the platform matures
  • Compatibility requirements: Strict Windows Server version requirements

Classic Sensor Advantages

For production environments, classic sensors offer:

  • Complete feature set: Full access to all Defender for Identity capabilities
  • Proven reliability: Years of production deployment experience
  • Broader compatibility: Support for older Windows Server versions
  • Predictable update cycles: Established update mechanisms with delayed update ring options for gradual deployment

Conclusion

The choice between classic and unified Defender for Identity sensors represents more than a simple version upgrade—it's an architectural decision with significant infrastructure implications. Organizations with mixed or legacy Windows Server environments should carefully evaluate their upgrade roadmaps before committing to the unified sensor approach.

While unified sensors promise simplified management and automated deployment, the current preview status and reduced functionality make classic sensors the safer choice for production environments, particularly those with compliance or comprehensive monitoring requirements.

The fundamental incompatibility between sensor types means this decision affects the entire Active Directory monitoring infrastructure.

Previous Post Next Post

نموذج الاتصال