Defender for Servers Deployment for On-Premises and Hybrid
IT Partner deploys Microsoft Defender for Servers to the Windows and Linux servers that live outside Azure — your datacenter, a colocation or hosting provider, another cloud — and to the Azure VMs that share their subscriptions, so every server reports into one Microsoft Defender estate with endpoint detection and response, vulnerability management and, on Plan 2, file integrity monitoring. In two weeks we choose the plan per server group (Plan 1 or Plan 2, decided against what you already pay for), onboard or reuse Azure Arc, roll out the Defender for Endpoint sensor at scale — including the unified agent Microsoft supports on Windows Server 2016 and 2012 R2 — verify every sensor, route alerts to your own SOC or to our managed detection and response service, remediate an agreed first set of Defender for Cloud server recommendations, and hand over the design, runbook and cost model. It exists for the estate the end-of-support wave leaves behind: Windows Server 2012 R2 hosts whose Extended Security Updates end on 13 October 2026 and Windows Server 2016 hosts that leave extended support on 12 January 2027, per Microsoft's product lifecycle, need detection and vulnerability visibility precisely because the operating system will stop getting fixes. Pricing is an estimate at $20 per server plus a $2,450 base fee for estates of roughly 25 to 500 servers, confirmed in writing once the inventory is agreed; larger estates are quoted as a whole. Microsoft's Defender for Servers plan charges — metered per server-hour to your own Azure subscription — and any log ingestion beyond Microsoft's included allowance are yours and are not part of this fee.
What this engagement is
The servers that most need endpoint detection and response are usually the ones with the least of it. The Windows Server 2012 R2 hosts running out their Extended Security Updates to 13 October 2026, the Windows Server 2016 fleet that leaves extended support on 12 January 2027, the Linux boxes nobody has rebuilt, the servers at a hosting provider that your Intune-managed laptops never see — these are where unpatched exposure accumulates and where attackers look first. Many organizations have already put their client fleet under Microsoft Defender for Endpoint through Intune (our Defender for Endpoint deployment does exactly that) and assume the servers came along. They did not: Microsoft's documentation is explicit that Defender for Endpoint Plan 1 and Plan 2 user licences do not include servers. Server coverage comes from Microsoft Defender for Servers, the server plan inside Defender for Cloud, which is licensed per server-hour rather than per user and which, for machines outside Azure, is delivered through Azure Arc. This engagement is that deployment, done deliberately, for estates of tens to hundreds of servers rather than a handful. The plan decision is the commercial core, so we make it per server group rather than per subscription by default. Plan 1 is the endpoint detection and response layer: Defender for Cloud installs the Defender for Endpoint sensor automatically, servers get the same protection Defender for Endpoint Plan 2 gives client devices — EDR, next-generation antivirus, attack surface reduction where the platform supports it — plus alerts in both Defender for Cloud and the Defender portal, software inventory and agent-based vulnerability scanning through Defender Vulnerability Management. Plan 2 adds the premium Defender Vulnerability Management capabilities, file integrity monitoring, operating-system baseline assessment against the Microsoft Cloud Security Benchmark, missing-update assessment through Azure Update Manager (which Microsoft states carries no additional Update Manager charge for Arc-enabled servers under Plan 2), and a pooled 500 MB per server per day allowance for security data ingested into Log Analytics. Two rules shape the design: Plan 2 is enabled at subscription level and can only be switched off per machine, while Plan 1 can be switched on per machine — so a mixed estate is engineered with subscription placement and tags, not with good intentions. Our default recommendation is Plan 2 for the legacy, ESU-bridged and compliance-scoped groups — file integrity monitoring and baseline assessment are what auditors and insurers ask about on an unsupported host — and Plan 1 for commodity servers where a patch and vulnerability tool is already paid for and working. The deployment itself is less dramatic than its reputation. The Azure Connected Machine agent connects outbound only — directly, through your proxy, or through Azure Arc gateway where your firewall team wants a short allow-list — and if you already have an Arc estate from our Azure Arc Hybrid Server Management implementation we reuse it rather than rebuild it. Once a server is Arc-enabled and the plan is on, Defender for Cloud provisions the Defender for Endpoint extension itself: no per-machine onboarding scripts, and on Windows Server 2016 and 2012 R2 it installs Microsoft's unified solution rather than the retired Monitoring Agent route. Your existing antivirus is not ripped out on day one — Defender Antivirus runs in passive mode next to it until you approve the switch, and on Linux the anti-malware component starts passive when onboarded through Defender for Cloud. Servers Arc cannot take — Windows Server 2008 R2, which Arc does not support, or an operating system Microsoft has stopped supporting on Arc (its prerequisites page lists Windows Server 2012 and 2012 R2 as approaching end of Arc support in November 2026) — go by direct onboarding through Defender for Endpoint instead, which keeps every Plan 1 capability and the premium vulnerability features under Plan 2 but not file integrity monitoring, baseline assessment or Update Manager. We tell you which servers land on which route, and why, before anything is installed. Detection without a reader is theatre, so alert routing is a deliverable, not a footnote. Alerts land in Defender for Cloud and the Defender portal; we wire the email notifications and severity thresholds, workflow automation for the alerts that must page someone, continuous export to an Event Hub or Log Analytics workspace for your SIEM, the Defender XDR connector where you run Microsoft Sentinel (our Sentinel implementation if you do not yet), or the hand-off to our Multi-Platform Managed Detection and Response service if you would rather not staff the queue — and we prove each route with a benign test detection. Then we remediate an agreed, bounded first set of Defender for Cloud server recommendations and leave the rest with named owners. The boundary is worth stating plainly: this is the server workload-protection layer. Cloud posture management is the Defender for Cloud CSPM engagement, client devices are the Intune-family Defender page, on-premises hardening is its own hourly service, and 24x7 operations are the MDR contract. And one honest sentence for the legacy hosts: EDR on an operating system Microsoft no longer patches is a compensating control, not a substitute for the fix — the exit date you attach to each of those servers, whether that is ESU enrollment through Arc, an in-place upgrade to Windows Server 2025 or retirement, is the real control, and the closeout report says so per server.
Success criteria
What you receive
How the work unfolds
Reconcile the inventory from your directory, hypervisors and existing security tooling; establish operating systems, hosting locations, network segments and proxies; review the incumbent antivirus and its contract; map subscriptions, roles and any existing Arc or Log Analytics footprint. Produce the plan decision per server group, the onboarding route per server, the subscription and tag design, and the Microsoft cost model. You sign the design and acknowledge the cost model before anything is enabled.
Configure the subscription: the chosen plan, Defender for Endpoint integration including the unified solution and Linux integration, direct onboarding where the design calls for it, resource groups and tags, the Log Analytics workspace and the file integrity monitoring configuration. Onboard a pilot group that spans your real diversity — current Windows Server, Windows Server 2016 and 2012 R2, Linux, each network segment and each hosting location. Confirm sensor health and passive-mode coexistence, raise a benign test detection, generate a file integrity event, and check that vulnerability data is flowing before anything scales.
Roll the Connected Machine agent out at scale through the chosen mechanism, let Defender for Cloud provision the sensor, run direct onboarding for the machines outside Arc, reconcile the onboarded count against the inventory, and chase the stragglers — there are always stragglers, and the closeout names them. The antivirus switch from passive to active runs in waves, each on your approval and inside its maintenance window.
Wire and test every alert route, apply the server protection configuration in the agreed modes, enable file integrity monitoring on the Plan 2 groups against the agreed rules, capture the vulnerability baseline, and remediate the agreed first set of Defender for Cloud recommendations. Apply per-machine plan exclusions and downgrades so the billing matches the signed design.
Walk every success criterion end to end, run the handover session with your team, and deliver the runbook, the as-built design, the restated cost model and the closeout report with its per-server exit notes for the legacy hosts.
Prerequisites
Who does what
IT Partner
- Produce the plan and scope design, the onboarding route per server, the subscription and tag design, and the Microsoft cost model — and obtain your sign-off before enablement.
- Execute the Azure Arc onboarding or reuse, the Defender for Endpoint sensor provisioning, direct onboarding where designed, and the reconciliation against the inventory.
- Configure server protection settings, antivirus coexistence and the switch sequence, vulnerability management, and file integrity monitoring as scoped.
- Wire and test every alert route with a benign detection, and document the hand-off to your SOC, your SIEM or our MDR service.
- Remediate the agreed first set of Defender for Cloud server recommendations and hand over the remainder with owners.
- Deliver the runbook, as-built design, handover session and closeout report.
- Flag servers that cannot or should not be onboarded — and legacy hosts that need an exit date more than they need a sensor — rather than onboarding indiscriminately.
Your team
- Provide the inventory, administrative credentials, the at-scale deployment mechanism and the Azure subscriptions and roles the design requires.
- Open the outbound connectivity or provide proxy and Arc gateway details per the design.
- Sign off the plan decision per group, the cost model, the antivirus switch timing, attack surface reduction modes and the alert-routing design.
- Provide maintenance windows and change approvals for the antivirus switch waves, enforcement-mode settings and the remediation set.
- Own Microsoft's charges billed to your subscription, the incumbent antivirus contract, and the licensing decisions the engagement surfaces.
- Staff or contract the alert queue after handover — your SOC, your SIEM team, or a separate MDR engagement.
- Own the exit decision for every legacy host the closeout report names.
What's not included
Limitations & technical notes
Frequently asked questions
What is Defender for Servers, and how is it different from Defender for Endpoint?
Defender for Endpoint is the sensor and the detection engine; Defender for Servers is the server plan inside Microsoft Defender for Cloud that licenses it for servers and adds server-specific capabilities. Microsoft's documentation is explicit that Defender for Endpoint Plan 1 and Plan 2 user licences do not cover servers — a server needs Defender for Servers Plan 1 or Plan 2, a standalone Defender for Endpoint Server licence, or Defender for Business servers for small organizations. Defender for Servers is charged per server-hour to an Azure subscription rather than per user, and for machines outside Azure it is delivered through Azure Arc. The result on the server is the same Defender for Endpoint sensor your laptops run, reporting into the same Defender portal.
Plan 1 or Plan 2 — how do you decide?
Per server group, against what you already pay for. Plan 1 gives you endpoint detection and response, automatic sensor onboarding, alerts in Defender for Cloud and the Defender portal, software inventory and agent-based vulnerability scanning. Plan 2 adds the premium Defender Vulnerability Management capabilities, file integrity monitoring, operating-system baseline assessment, missing-update assessment through Azure Update Manager at no additional Update Manager charge for Arc-enabled servers, and a pooled 500 MB per server per day ingestion allowance. Our default: Plan 2 for the legacy, ESU-bridged and compliance-scoped groups, because file integrity monitoring and baseline assessment are what an auditor asks about on an unsupported host; Plan 1 for commodity servers that already have a working patch and vulnerability tool. The design writes the reasoning down so you can revisit it.
Can we mix plans, or does enabling Plan 2 bill every server in the subscription?
Both, and the second point is the trap. Plan 2 is enabled at subscription level and Microsoft bills every supported Azure VM and every connected Arc machine in that subscription unless you exclude it per machine; Plan 1 can be enabled or disabled per machine, and a Plan 2 subscription can downgrade individual machines to Plan 1 by tag, policy or API. So a mixed estate is engineered with subscription placement, resource groups and tags before the plan is switched on — and the success criteria include the line that no server is billed at a plan you did not choose.
Do we need Azure Arc? What is direct onboarding?
Azure Arc is the recommended route and the one that unlocks everything: the Connected Machine agent makes each on-premises server an Azure resource, Defender for Cloud provisions the sensor automatically, and Plan 2's file integrity monitoring, baseline assessment and Update Manager integration all depend on it. Direct onboarding is Microsoft's alternative for servers that only run the Defender for Endpoint sensor: they appear in Defender for Cloud under a subscription you choose, are billed per hour, and get every Plan 1 capability plus the premium vulnerability features under Plan 2 — but no Azure Policy, no file integrity monitoring, no Update Manager. We use it for machines Arc cannot take, such as Windows Server 2008 R2, and as the fallback for operating systems Microsoft is retiring from Arc.
Does this work on Windows Server 2012 R2 and 2016 — and after their support ends?
Yes, with Microsoft's unified Defender for Endpoint solution, which Defender for Cloud installs automatically on those versions and which replaced the retired Monitoring Agent route in 2022. On Windows Server 2016 the antivirus is built into the operating system and must be installed as a feature and updated first; on 2012 R2 the unified package brings both antivirus and the EDR sensor. After the operating system leaves support, Microsoft's documentation states that devices protected by Defender for Endpoint continue to receive its product updates through the existing channels — the sensor keeps working, the operating system simply stops getting fixes. Two caveats the design handles: file integrity monitoring on these versions needs sensor version 10.8799 or later, and Microsoft's Arc prerequisites list 2012 and 2012 R2 as approaching end of Arc support in November 2026, so those hosts carry a direct-onboarding fallback and an exit date.
Is EDR a substitute for Extended Security Updates or an upgrade?
No, and we will not sell it as one. Detection on an unpatched kernel makes an attack noisier and shorter; it does not remove the vulnerability. The honest combination for a host you cannot move yet is ESU where Microsoft still offers it — through Azure Arc for Windows Server 2016 from January 2027 — plus Defender for Servers for detection and vulnerability visibility, plus segmentation for the 2012 R2 hosts after 13 October 2026, and a dated exit per server: upgrade, migrate or retire. The closeout report writes that per-server sentence for you.
What does Microsoft charge, and what do you charge?
Two separate things. Our fee is the estimate on this page — $20 per server plus $2,450 for the engagement, confirmed in writing after the inventory is agreed, paid after you approve delivery. Microsoft charges the Defender for Servers plan per server-hour to your own Azure subscription: Arc-enabled machines while they are connected and sending heartbeats, directly onboarded machines while the sensor reports, Azure VMs while they are running. Log Analytics ingestion beyond Plan 2's pooled allowance is metered too. Microsoft revises its prices, so we print none here; the cost model in the design carries the current numbers for your exact configuration, and you acknowledge it before any plan is enabled beyond the pilot.
We already run a third-party antivirus or EDR — what happens to it?
It stays until you decide otherwise. When the Defender for Endpoint sensor lands next to another antivirus, Defender Antivirus runs in passive mode: the sensor collects and detects, the incumbent keeps blocking. The design sets the coexistence per group, the pilot proves it, and the switch to active mode runs in waves on your approval inside maintenance windows — so no server is ever unprotected. Microsoft notes that some third-party products need a version update before Defender components install cleanly, which discovery checks. Removing the incumbent at scale, and exiting its contract, is separate work we sequence with you.
Does this cover Linux?
Yes. Defender for Servers protects Linux servers through the MDE.Linux extension on Arc-enabled machines or the Defender for Endpoint installer on directly onboarded ones, on the distributions Microsoft lists for both Arc and Defender for Endpoint — Red Hat, Ubuntu, SUSE and their peers, with versions confirmed against Microsoft's support matrices during discovery, since several older releases are also approaching end of Arc support in November 2026. On Linux the anti-malware component starts in passive mode when onboarded through Defender for Cloud, Python must be present, and machines running other security products that use the same kernel file-notification interface are installed manually rather than auto-provisioned. Sensor updates on Linux are handled by the extension by default.
How do alerts reach our SOC — and what if we do not have one?
Alerts appear in Defender for Cloud and the Defender portal the moment the sensor reports them. We configure Defender for Cloud's email notifications and severity thresholds, workflow automation for the alerts that must page someone, continuous export to an Event Hub or Log Analytics workspace for a third-party SIEM, or the Defender XDR connector into Microsoft Sentinel if you run it — and we prove each route with a benign test detection. If nobody on your side can read the queue, our Multi-Platform Managed Detection and Response service takes it under its own contract. Microsoft also sells Defender Experts for Servers, its own managed detection and response for machines under Plan 1 or Plan 2; we will tell you plainly when that is the better fit.
What is file integrity monitoring, and why does it matter for legacy servers?
It watches the files and registry keys an attacker changes to persist — system binaries, startup locations, cryptography and credential stores — and records who changed what, from which process, in a Log Analytics workspace, in near real time from the Defender for Endpoint sensor. It is a Plan 2 capability, it is not on by default, and it needs a workspace and a rule set: we start from Microsoft's recommended Windows, Linux and registry list and add your paths within the 500-rule limit. On a host whose operating system will never be patched again, it is the control that shows whether the host has been quietly changed — and it is the control auditors and cyber-insurance questionnaires most often ask about by name.
What does vulnerability management actually give us on an unsupported operating system?
A running, dated list of what is exposed. Defender Vulnerability Management inventories every installed software component and maps it to known weaknesses, so a 2012 R2 host shows exactly which unpatched kernel and third-party vulnerabilities are accumulating, and the premium capabilities under Plan 2 add assessments such as security-baseline and certificate checks. It will not make the list shorter for the operating system itself — nothing can — but it makes the third-party exposure fixable, gives the compensating-control statement its evidence, and gives whoever owns the exit date a number that grows every month.
Which recommendations do you actually remediate?
An agreed first set, written into the design: endpoint detection and response configuration issues, missing system updates on Plan 2 Arc machines through Azure Update Manager, the high-severity vulnerabilities that a patch or a configuration change fixes, and the operating-system misconfigurations against the Microsoft Cloud Security Benchmark that do not need an application change. Everything that needs a vendor, downtime, an application owner or an operating-system change is assigned to a named person with a date and handed over in the closeout. We prefer a short list you can see closed to a long one nobody owns.
Will onboarding disrupt production? Are reboots required?
Installing the Connected Machine agent and the Defender for Endpoint sensor does not touch workloads and does not normally require a reboot; the extensions install as services making outbound connections. The activities with real change impact are scheduled deliberately: the antivirus switch from passive to active, promoting attack surface reduction rules from audit to block, and patching in the remediation set — each inside a maintenance window you approve, and each proven on the pilot first. The pilot group is chosen to include the oldest, most fragile hosts precisely so the surprises happen there.
Our servers are already in Azure — is this page for us?
Partly. Defender for Servers protects Azure VMs without Arc, and because the plan is enabled per subscription your Azure VMs are designed into the plan decision alongside the on-premises servers that share those subscriptions. If your estate is entirely in Azure and the question is posture — Secure Score, regulatory standards, the other Defender plans — start with the Defender for Cloud CSPM engagement instead; if it is a hybrid estate where the on-premises and hosted servers are the gap, this is the page.
Who runs this after the two weeks?
Your team, equipped for it — the handover session and runbook cover onboarding the next server, reading sensor health, triaging an alert, working the vulnerability queue, tuning file integrity monitoring, changing a machine's plan, and stopping the charge when a server is retired. The alert queue needs a reader: your SOC, your SIEM team, our MDR service, or business-hours triage on the legacy estate through the Managed ESU and Legacy Server Lifecycle service. We do not bundle a retainer into an implementation, and we say which option we would choose in your position.