The business problem
The company already owned licensing for Microsoft Defender for Business, but no device had been onboarded. Computers were joined to an on-premises domain and not enrolled in Intune, which meant the usual cloud-first rollout path did not apply. Settings lived in older group policies, servers needed different treatment from workstations, and one line-of-business server had to stay up above all else.
Designing around the existing environment
Instead of forcing a disruptive migration, domain-joined PCs stayed domain-joined. Group Policy onboarded them to Defender, and Defender’s security settings management let Intune policies apply without enrolling each device. A fuller move to Intune remained an option for later.
Servers got their own track. They use separate antivirus, firewall, and attack-surface policies that preserve local exclusions and avoid settings that would disturb server workloads. The business-critical application server was left for last, with narrow, deliberate exclusions defined before it was touched.
Proving it, then widening it
Started with a single pilot machine and a harmless detection test that exercised the whole pipeline: sensor, cloud, alert, email, and ticket. Once the path was proven, the rollout widened in stages to every workstation, then to the domain controllers and member servers, with role-specific health checks after each server such as directory replication, web services, remote-access gateways, and virtual machines.
Endpoint security settings were migrated from legacy group policies to portal-managed Intune policies setting for setting. The old policies were filtered off migrated machines so each device has one source of truth. Effective settings were verified on the machines themselves, not assumed from a console.
Alerts that reach a person
Medium and high alerts email IT and open a service desk ticket automatically. Lower-severity alerts notify IT only. Attack-surface rules and network protection started in audit mode, with a plan to review hits, add exclusions, and move rules to block one at a time.
Handling the one that broke
When onboarding one server coincided with users reporting problems in a critical application, the decision was business continuity first. Only that server was offboarded using the signed package, with antivirus and firewall protection kept in place. The team documented what was and was not established instead of claiming a cause, and the real cause was identified later.
The result
Every workstation and the core servers now report to Defender, managed from one place, with alerts wired into the ticketing process. Gaps and exceptions, such as legacy systems that cannot be onboarded, are recorded with owners and next steps instead of ignored.