Introduction

Originally when the Endpoint Protection workload for co-management was introduced with Configuration Manager 1802, this was done without antimalware policies.

That essentially meant that antimalware policies was still being managed solely by Configuration Manager, while a feature like Exploit Guard was managed by Intune.

Now, this has since changed (at the time of writing, I’m not sure when they snug in the addition, but that’s not related to the post anyway) and the workload now includes antimalware policies enabling us to manage all aspects of Microsoft Defender with Microsoft Intune.

So what does that mean, and are there anything specifically you need to be aware of? I believe there is. 🙂

Configuration Manager

When you do traditional OSD with ConfigMgr, a common scenario is that Endpoint Protection is enabled in your Client Settings and the Default Client Antimalware Policy or any other custom Antimalware Policy will apply. Pretty standard I believe.

But what happens when you move the endpoint protection workload to Intune, and what if you did this long before that Intune was able to manage Antimalware Policies?

Chances are, that you don’t do changes to your antimalware policies very often and everything seems fine and dandy. Until they’re not. 🙂

Antimalware policies in ConfigMgr are located in the console in the Endpoint Protection node like shown below.

When applied to clients, the antimalware policies will create local policies visible when browsing the registry in HKLM\SOFTWARE\Policies\Microsoft\Windows Defender or from running gpedit.msc and browsing Computer Configuration -> Administrative Templates – > Windows Components -> Windows Defender Antivirus.

In a bare metal scenario with ConfigurationManager, the antimalware policies coming from ConfigMgr will apply rather fast and specifically before the device is enrolled into Intune.

What that means is, that whether you like it or not, you will have the settings from ConfigMgr to apply first and later on have the settings from Intune. That be if you have any antimalware settings coming from Intune.

In the EndpointProtectionAgent.log you will see that the workload is recognized as managed by ConfigMgr.

And just later on, once the device is enrolled into Intune and the co-management workload is picked up, you will see that the device expects and verifies that policies are coming from the cloud.

This will happen, even if you just manage some parts of Microsoft Defender with Intune and not specifically antimalware policies.

Note: This is where you potentially and mistakenly can expect that antimalware policies coming from ConfigMgr still applies. Especially if you moved the workload BEFORE antimalware policies was expected to be managed with Intune.

Co-management

The Endpoint Protection workload is glued to the Device Configuration workload (Note: It wasn’t in the very beginning, as the Endpoint Protection workload was introduced prior to the Device Configuration workload).

That means that you will have to move the entire Device Configuration workload to Intune in order to manage Endpoint Protection with Intune.

From ConfigMgr to Microsoft Intune

To configure antimalware policies with Microsoft Intune today, you log into the Microsoft 365 Device Management portal: https://devicemanagement.microsoft.com

Browse your way into Devices and locate Configuration profiles:

Create a new profile:

• Name: Give it a suitable name
• Platform: Windows 10 and later
• Profile type: Device restrictions
• Settings: Locate Microsoft Defender Antivirus from the list of options

What you probably want to do at this stage, is to configure the profile so it matches the antimalware policy in ConfigMgr. Below is an example of the first part of the configuration in Intune.

And below an example of the antimalware policy in ConfigMgr. If this is supposed to target the same devices (ConfigMgr first and later on Intune once enrolled), you probably want to have the same settings configured both places.

Now, this is where it get kinda skewed. Usually this would scream a conflict and to me it’s a weird admin experience, as it’s easy to have settings configured to different values.

What will happen is, that once the device is enrolled into Intune, the settings from Intune will have affect, unless the setting allows merging of values, such as exclusions where both the settings from ConfigMgr and Intune will have effect.

On The Device

Prior to Intune enrollment, the device only has the settings coming from Configuration Manager. See below example, where I have highlighted ExclusionExtension. These are specifically configured with a beginning dot (.) .ost, .pst, .wim

And POST Intune enrollment, and thus now target of the settings coming from Intune, the ExclusionExtension now also INCLUDES the settings coming from Intune where the extensions are defined without the beginning dot (.). The values are merged in this particular scenario.

Why is this important you may ask?

For starters, the docs says that the settings coming from Intune will overwrite the policies coming from Configuration Manager. That’s not quite true, as some of the settings are just being merged.

Secondly, you may experience that the settings from Configuration Manager can be flushed (and they will not come back in this case), and this is happening if the Registry.pol file of several reasons is getting deleted.

ENJOY 🙂