The sensors article argued which generation belongs on which machine and why. This is the build for standing the estate up, from a tenant with no sensors to a fabric that is instrumented, auditing itself where it can, and proven to deliver a detection into the queue. Most of it is short. The parts worth slowing down for are the ones the sensors article already flagged as quiet failures: a group managed service account left configured where it now breaks response, auditing half-applied, or a controller that reports healthy while detecting nothing. The final step is the only one that actually proves the estate works, so do not skip it.
Decide the generation per machine first
Before you touch a single server, sort the fabric into the two generations, because the steps diverge completely from here. The rule from the sensors article, rendered as a decision you can run down a server list:
| Machine | Generation | How it gets there |
|---|---|---|
| Domain controller, Windows Server 2019 or later | Current | Activated from the portal on a controller already onboarded to Defender for Endpoint. Includes controllers that also run federation, certificate, or sync roles. |
| Domain controller, Windows Server 2016 or earlier | Previous | Classic sensor installed from the downloaded package. |
| Standalone AD FS, AD CS, or Entra Connect server | Previous | Classic sensor installed from the downloaded package. |
One trap lives in this table. A controller that carries an extra identity role can be activated onto the current sensor directly, but it cannot be migrated onto it in place from an existing classic sensor, because migration is supported only on pure controllers. If such a controller already runs the classic sensor, the path is to remove the classic sensor and then activate the current one, not to look for a migrate button that will not offer itself. Sort activation and migration as separate operations with separate eligibility and this never bites you.
Standing up the current sensor
The current sensor has no installer. The work is confirming the prerequisites and activating it, and the prerequisites are where care pays off.
| Prerequisite | Value | Why |
|---|---|---|
| Operating system | Windows Server 2019 or later domain controller | The current sensor’s supported machine class. Older controllers stay on the classic sensor. |
| Defender for Endpoint | Onboarded on the controller itself | The sensor is a capability of the endpoint agent. Onboarding the endpoint elsewhere is not enough; this specific controller must be onboarded. Antivirus may be active or passive. |
| Cumulative update | A current Windows Server cumulative update | A rolling floor Microsoft moves forward with sensor releases. Read the exact build off the deployment page at deploy time rather than trusting a number from a runbook. |
| Existing sensor | None present | A controller running the classic sensor is a migration or a remove-then-activate case, not a fresh activation. |
With those true, activation is a portal action under the identity settings, where eligible onboarded controllers appear and can be activated individually or automatically as they are discovered. No reboot is required, the first sensor can take up to an hour to report and later ones only minutes, and there is no service account to create because the current sensor runs as the machine’s local system identity for everything it does.
Turn on the automatic Windows auditing configuration while you are here. It lets the sensor configure and continuously maintain the audit policy the detections depend on, correcting drift on a daily cadence rather than leaving you to deliver it by Group Policy and hope it stays applied. On the current sensor this is the recommended path and it removes an entire category of silent misconfiguration. You still confirm it took, but you are confirming a toggle rather than auditing a policy object by hand.
The action-account setting, before anything else fires
This is the one setting that will bite you silently if you inherit an older configuration, so set it deliberately and set it early. In the action-accounts configuration for the workspace, select the option to use the sensor’s own local system account for response actions.
| Setting | Value | Why |
|---|---|---|
| Action account | Automatically use the sensor’s local system account | Required for the current sensor and recommended everywhere. A group managed service account left configured for actions is not merely ignored by the current sensor; it breaks response actions, including automatic containment, with no obvious error. |
| Workspace service account | Remove only after the last classic sensor is gone | Workspace service-account credentials are validated against every sensor, so a stale one raises false credential alerts on current sensors that never use it. Keep it while any classic sensor still needs it, then remove it. |
Standing up the previous sensor
For the standalone identity servers and the older controllers, the classic sensor is a real install, and it wants a few things the current one does not. Download the package and its access key from the portal, and on the server confirm the platform prerequisites: the sensor carries its own capture component and expects the framework runtime, so a silent-install that needs a reboot will take one. The classic sensor does use a directory service account, and a group managed service account is the right choice for it, with read access across the domains you monitor and to the deleted-objects container. That account is what lets the classic sensor read the directory, reach the deleted-objects container, and resolve across the domains you monitor, so it is not optional the way it is on the current sensor.
Auditing on the classic sensor remains your responsibility. Deliver the required advanced audit policy, the NTLM auditing, and the object-level auditing through Group Policy or the configuration module, because the classic sensor does not self-configure the way the current one does. This is the manual work the current sensor retired, and it is the reason that, all else equal, a controller eligible for the current sensor is less work to run than a standalone server stuck on the classic one.
Validate before you trust it
A sensor that shows up in the portal is not the same as a sensor that is healthy and detecting. Check the estate before you rely on it. Microsoft publishes a readiness script that checks a domain for the prerequisites and auditing the sensors need, and it is the right first pass across the fabric.
.\Test-MdiReadiness.ps1
# On a classic-sensor server, confirm the sensor service is running:
Get-Service -Name AATPSensorIn the portal, the sensors page under the identity settings is the source of truth for health. Every sensor should read as up to date and healthy, with no open health issues, and the page distinguishes the two generations and their states. A sensor stuck starting, an open auditing health alert, or a controller that never appears at all is a sensor you have not actually deployed yet, whatever an activation or install step claimed. Resolve the health issues here before moving on, because an unhealthy sensor is a blind spot that reports as coverage.
The end-to-end test that actually proves it
Everything above proves the plumbing. This proves the product. The cleanest end-to-end test on this platform is also a control you want in place anyway: the honeytoken. Create a dormant account with an attractive name, one that no legitimate process will ever touch, and tag it as a honeytoken in the identity settings. Then, from a test host, attempt an authentication against it, a deliberate sign-in with that account. Because the account is bait and nothing legitimate uses it, that single authentication should raise a honeytoken alert, and it should arrive in the incident and alert queue in the unified portal within a few minutes.
That is the whole proof. A controlled action against the fabric produced a visible alert in the queue, end to end, which is the only evidence that the sensor is not just present but actually feeding detections into the surface the previous article taught you to work. Leave the honeytoken in place afterward, because the test you just ran is a detection you want running permanently.
The short version to run down before you call the estate stood up:
- Every server is sorted into a generation, with role-bearing controllers activated rather than migrated.
- Current sensors are activated on onboarded controllers meeting the live cumulative-update floor, with automatic auditing on.
- The action account is set to the sensor’s local system account before any response action can fire.
- Classic sensors have their directory service account and their auditing delivered by hand.
- The readiness script passes and the sensors page shows every sensor healthy with no open issues.
- A honeytoken authentication produces an alert in the queue, end to end.
Where this sits
With the estate stood up and proven, the design of the pillar is complete: the two-ended shape from the anchor, the two sensor generations instrumenting the fabric, the detections and response surfaces they feed, and the posture that tells you what to close before anyone tries it. The sensor rides the same endpoint machinery you built in the endpoint onboarding work, which is the whole reason standing it up is this short. What remains for the wider suite, the attack-disruption machinery that ties identity response into cross-workload containment and the exposure surface that rolls identity posture up with everything else, arrives in the pillars that follow.
Defender XDR
‹ Previous: [D 3.1] Sensors: One Fleet, Two Generations
Next: [D 3.2] Detections and Response: Operating the Identity Alert Queue ›
