A lot of the environments I work in are currently looking at moving to the new Defender for Identity sensor v3. Being able to activate the latest sensor straight on domain controllers that are already onboarded to Microsoft Defender for Endpoint (MDE) makes day-to-day operations noticeably easier, because the manual installers and extra setup scripts go away. As usual, though, that isn't the whole picture. Before you start, you should know the prerequisites, what v3 can't do yet compared with the classic sensor, and where you still need to be careful. Plenty of hybrid Active Directory setups are less cloud-native than they first appear.

Sensor v3 moves deployment from the DC to the Defender portal

The main change is that the sensor is now deployed remotely. In the Microsoft Defender portal you go to System → Settings → Identities → Activation and select the domain controllers that are already onboarded. Microsoft then rolls out Defender for Identity sensor v3.x in the background. You don't have to log onto the DC or run a local installer, provided the requirements are met.

With a larger fleet this saves real time, and because the rollout is controlled centrally you get less drift and fewer surprises. The limitation is just as clear, though. It only works on domain controllers running Windows Server 2019 or later, and only if they're already onboarded to Defender for Endpoint. Older DCs still need the classic installer for now.

Not every domain controller meets the v3 prerequisites yet

For Defender for Identity sensor v3, the domain controller has to run Windows Server 2019, 2022 or newer and must already appear as an onboarded device in MDE. If it isn't onboarded, the v3 sensor won't be pushed. Some server roles are also not supported by sensor v3.x, namely AD FS (Active Directory Federation Services) and AD CS (Active Directory Certificate Services). Those still need the classic sensor, mostly because of the logging and protocol requirements specific to these workloads.

v3 is developing quickly, but some advanced features (deep event tracing or sensor profiling, for example) are limited or not available yet. If you depend on detailed forensics or have deeper integration requirements, read the current Defender for Identity documentation and the prerequisites page to confirm v3 covers what you need.

Practical tip: Once sensor v3 is active, keep an eye on the sensor health page in the Defender portal (Defender for Identity → Sensor health). The usual problems, such as “Prerequisite not met” or communication failures, nearly always come down to missing updates, the wrong OS version or the onboarding status.

The v3 sensor runs inside the MDE agent instead of next to it

Sensor v3 runs as an add-on within the MDE agent that's already on the server. That helps a lot with lifecycle management and patching, since you no longer maintain two installations and there's less operational overhead. The trade-offs are obvious, though:

  • Only Windows Server 2019 or newer is supported
  • AD FS and AD CS server roles aren't supported
  • Some deep troubleshooting logs and niche features haven't made it into v3 yet

If you need particular forensic capabilities or use features that haven't been ported, stick with the classic sensor for the time being.

Mixed environments keep the classic sensor for a while longer

In actual projects I regularly see hybrid setups with domain controllers from different generations. Many organisations still run Windows Server 2016 or older DCs, or have AD FS/AD CS servers that can't use v3 at all. In some cases third-party monitoring or older integrations keep you on the classic sensor. What has worked best for me is a split deployment. New, supported DCs get sensor v3 through the portal, and older or special-purpose servers keep the classic sensor for now. If you remove the old sensor too early, you can lose visibility, so plan for overlap rather than gaps.

The diagram below shows the activation flow for sensor v3 next to the classic model:

flowchart TD
    DC["Domain Controller"] --> MDEOnboard["MDE onboarding"]
    MDEOnboard --> Activation["Sensor v3 activation (portal)"]
    Activation --> Deployment["Automatic deployment"]
    Deployment --> SensorActive["Sensor v3 active"]
    DC -.-> ClassicSensor["Classic sensor required"]
    ClassicSensor -.-> SensorActive

Figure: Activating Defender for Identity sensor v3 compared with the classic deployment path.

The sensor health page shows where a migration is stuck

Once sensor v3 is enabled, you need to check sensor health. The Identities → Sensor health page in the Defender portal lists every sensor with its status and the typical error messages (for example “Unsupported OS,” “Device not onboarded” or “Role not supported”). That makes it easy to spot the cause, whether it's missing updates, an unsupported Windows version or a gap in onboarding. On every customer migration I go through the sensor inventory in the Defender portal device by device, noting which sensor version is running and what the latest health report says, before I start the next batch.

Sensor v3 is a real step forward if you respect its limits

Defender for Identity sensor v3 makes operations considerably more mature. Local installs disappear, deployment runs through MDE and monitoring is unified. Because of the limitations (older DCs, AD FS and AD CS servers), though, many organisations will be running both sensors for some time. In my experience a hybrid approach, with v3 on new domain controllers and the classic sensor on the rest, gives the best balance of coverage and efficiency. Watch the health page closely and roll out the change in phases. That way you get what sensor v3 offers without losing visibility.