Co-management with ConfigMgr and Intune and a little something about Microsoft Defender antimalware policies

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 πŸ™‚

6 thoughts on “Co-management with ConfigMgr and Intune and a little something about Microsoft Defender antimalware policies”

    • That’s a great question! If you are using ATP you are good, as ATP is able to generate email alerts as well. If you don’t have ATP, I’m actually not sure if possible. I will look into it. πŸ™‚

        • Matt, I just tested this, and it seems as long as alerts for malware is enabled on the collection where the device is a member, the alert is being generated. I just received both an email alert from ATP AND ConfigMgr for my test client, which is being co-managed and have antimalware policies coming from Intune πŸ™‚

  1. Martin, thanks for all the information you share on your site. It has already helped us in many things. Keep it up!

    Now that you write this article, I think it’s nice to give you some extra information. I am currently working on a Microsoft Case to explain the differences. You already wrote that ConfigMgr comes faster than Intune. Something that we have experienced. We have 1709 and 1809 clients. On both it doesn’t work flawlessly.

    We have configured NESSUS and ATP. Both tools came with the comment to enable “E-mail scanning”. Strange situation, because we have that enabled in Intune? In the registry and with get-mppreference, the values ​​are indeed incorrect. (Do not match with Intune)
    As it turns out, in the Default Client Antimalware policy that is still disabled. So it seems that you have to configure both environments the same if you want to be sure of your case. Not quite what I expect when you move the workloads to Intune.

    To let Intune win the configuration, this policy has been made, available from 1803:
    ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP

    This at least removes the ConfigMgr settings set by Intune.

    • Great with some additional information Gidion – thank you. And I agree, the admin experience in this case is skewed and feels weird. I have MDMWinsOverGPO configured as well, but I’m still left with the settings coming from ConfigMgr as these are local policies and are stored locally in the registry.pol file.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.