When managing Microsoft Defender on Windows client devices, most organizations are choosing Microsoft Intune as their central management platform. It is the best-known and well-versed system to push different settings.

When it comes to servers, there is no clear-cut choice available. There are four different options:

• Powershell
• Group Policy
• System Center Configuration Manager (SCCM)
• Defender Security Management      

Managing the settings through Microsoft Defender (Defender Security Management) is the most recent option, but it has been around since 2022. Initially, the solution was limited and did not contain all the features required (more on that later). This meant I also recommended other solutions, such as GPO. Over recent years, this has changed quite a bit. This article walks through the different options and discusses when Defender Security Management is a good choice.

Making the Case for PowerShell

PowerShell is the simplest solution to configure Microsoft Defender. By using the Set-MpPreference command, it is possible to set each setting. PowerShell can be used when you are configuring a machine just once. While PowerShell can scale to ensure to deploy settings to multiple machines. Other third-party remote management tooling (non-Microsoft) might use PowerShell in the background to push settings. It can be useful to configure a single machine as a one-off or for troubleshooting, but besides that, the other options are better suited.

Using GPO’s

Pushing the configuration using Group Policy is one of the ‘oldest’ options and is easily scaled for a large number of machines. There are built-in ADMX templates that allow you to pick the correct setting and use the GUI to set up the configuration. If desired, it is quite easy to create multiple policies to scope specific settings or exclusions to a subset of machines.

Making the Case for SCCM

If SCCM is available, I prefer it over GPO. Configuration Manager also has some built-in templates available that allow you to easily pick the correct value for each setting.

SCCM, as a product, has a more robust way of deploying settings to machines compared to GPO. You can easily get the status of the deployment and get detailed information on that status. It is also possible to check the configuration of the setting on an endpoint using something called configuration baselines. Configuration baselines check the actual value on the machine. With a GPO, there is some uncertainty around whether the setting has actually been applied.

The main downside of SCCM is that you are dependent on the updates of the product to receive support for the newest settings. Within the same GPO, you could easily add a registry key configuration. For SCCM, it is not possible to include custom settings in the same policy. This means you must split it between two policies, which is not ideal for clarity. While new settings aren’t delayed that often, it is a scenario to consider.

Defender Security Management

A couple of years ago, customers I was working with at the time were surprised that Defender had no built-in configuration option. You always had to use another system, such as GPO, SCCM, etc. This was strange for customers who were migrating from other security tools that offer this. This is why Microsoft introduced Defender Security Management.

Instead of using another tool, you can use the Microsoft Defender portal to deploy settings. The settings are deployed using the Defender agent installed on every device and do not rely on other resources such as a domain or MDM connection. This greatly simplified configuration.

Defender Security Management uses Microsoft Intune in the background, but does not require you to visit the portal or have an Intune license. As seen in Figure 1, it needs to be enabled manually within the Defender Settings.

After enabling Security Management, there is an option to configure the scope. Either you enable it for all devices or only for devices that have the ‘MDE-Management’ tags added, as seen in Figure 2.

In the early stages, Security Management required that all devices were (hybrid) joined into Entra ID. This is no longer the case. While a device object is created within Entra ID, this is just done to be able to deploy policies. The device isn’t actually registered in Entra ID.

After enabling it, it is possible to create policies using the following URL in the Defender portal: https://security.microsoft.com/policy-inventory.

For every supported operating system, there is a specific tab available. In here, it is possible to create multiple policies and push those to devices.

If you want to configure specific targeting, Entra ID groups are required. You can create dynamic Entra ID groups to automatically populate certain groups. A simple example is the following query: (device.deviceOSVersion -contains “Server”), which focuses on servers. Unfortunately, it is not possible to easily create groups based on the server role (IIS, SQL). This will need to be done manually or based on the naming convention.

While the product has come a long way, there are a few limitations:

• Computers need outbound internet access for this to work. Access to limited to the service URLs already in use by Defender for Endpoint. If devices don’t have internet access, SCCM or GPO is recommended.
• This solution doesn’t work very well when another security product is installed.

Verify the Configuration

Because there are multiple configuration options, the portal allows you to verify the actual values of a setting on an endpoint. This is possible by going onto the device page and navigating to configuration management > effective settings, as seen in Figure 3. The last but one column, ‘Configured by’, provides insights into what management tool configured the setting.

Non-persistent VDI’s

Non-persistent Virtual Desktop Infrastructure (VDI) is typically not a great fit for Defender Security Management. The main reason for that is that there is a potential delay of 90 minutes until a device receives a policy. Because non-persistent VDIs are continuously spun up and down again, there is a risk that a user lands on a device without a proper configuration. Such devices are better handled using another method that has a faster deployment time, such as GPO or configuring the settings on the golden image.

A word on Linux

Linux behaves much the same way in terms of Security Management, but the number of configuration options is limited, and some are still in preview. It is important to note that Microsoft has some great guides available for Ansible and other tooling, if that is currently being used in the environment.

One Portal to Rule Them All

With some exceptions, Defender Security Management can manage almost all operating systems from a single pane of glass. This simplifies the configuration compared to the times when we needed SCCM, GPO, Intune, and Ansible to push configuration. While the product is not without its flaws, it is the standard I recommend to my customers because of its simplicity and the fact that it is fully built into the portal.

Using multiple management solutions on a single endpoint is not recommended. There is no clear documentation on policy preference, and it gets confusing quite quickly. It is recommended to find a tool that works for all options and stick with it.