Continuing the Co-management journey from last week, where I went through the steps required to setup co-management with Configuration Manager. This week I’m moving the Endpoint Protection workloads into Intune MDM. The ability to transition the Endpoint Protection workload is brand new, and became available in Configuration Manager 1802. As of now, the endpoint protection workload consists of following features:
- Windows Defender Application Guard
- Windows Defender Firewall
- Windows Defender SmartScreen
- Windows Encryption (BitLocker)
- Windows Defender Exploit Guard
- Windows Defender Application Control
- Windows Defender Security Center
- Windows Defender Advanced Threat Protection
Following walkthrough is exactly how I moved some of the Endpoint Protection features (more specifically Exploit Guard and some modifications to the Defender Security Center) into Intune MDM for at pilot group consisting of computers.
In my case right here, I’m actually transitioning the workloads away from GPOs (Group Policies). An educated guess is that most companies moving towards Modern Management does as well. (At the very least when speaking of managing Windows Defender, BitLocker, Windows firewall etc.)
- First of all, create the Device Configuration Profile in Intune on Device configuration -> Profiles
- Click Create Profile and fill out the required fields. In this case, that be Name, Platform and Profile type. Move to the next blade on Settings/Configure and click Windows Defender Exploit Guard
- Now, customize the configuration as it suits *your* environment. Using the features in Windows Defender Exploit Guard will require thorough testing as it potentially can prevent users from launching applications properly (this is not an Exploit Guard post, but now I said it 🙂
- Next, I added another Device configuration profile where I modified a few settings in the Windows Defender Security Center. For your inspiration, those settings are exactly what’s shown below:
- With all of above in place, we have two brand new configuration profiles for use. But before putting them to use, we need a new group (on-premise AD group, synced to Azure) consisting of computers for two purposes: Assignment in Intune and for exclusion on the GPO (remember, in my exact scenario I actually have all of these settings in place already coming from GPOs)
- I’m not covering the how-to on creating a new on-premise Active Directory group. For your inspiration, I have a group consisting of my piloting computers called: Intune_Co-mgmt_Computers. The very same group I use for targeting the actual co-management in ConfigMgr and now also the new Configuration Profiles in Intune. Below is how I excluded that group from my Windows Defender GPO
Switch the workload in Configuration Manager
- Now that you have excluded the computers from the GPO, you switch over the workload to Intune. In the Configuration Manager console, in the Administration workspace, the co-management properties should look like this (in regards to Endpoint Protection). This will enable the Endpoint Protection workloads to be managed by Intune for your pilot group
Assign the profiles
- Make sure to assign the Device configuration profiles we created earlier to your pilot group as well (Intune_Co-mgmt_Computers). Both profiles should have an assignment equal to this:
Monitor the new changes
- Once the computers picks up the addition of the new workload, you will see some action in C:\Windows\ccm\Logs\CoManagementHandler.log. The new workload is in my case highlighted as ‘CoManagementSettings_Capabilities’ is ’35’, whereas the max capabilities for Co-management is defined as 55
- When the changes has been picked up by the Configuration Manager client, monitor the assignment status of the profiles in Intune. You would want the assignment/deployment status to be succeeded for the computers in your pilot group
- And finally, when both ConfigMgr logs and Intune device status says everything is OK, you can confirm the changes directly on the client being co-managed. You do so by heading to Settings and Access work or shool on a co-managed computer and click Info
- When clicking on Info, you get the option to create a nifty report
- This report will show the applied configuration state of your device including Policy CSP Settings, certificates, configuration sources, and resource information. Scroll down to the Managed policies section and confirm that the Windows Defender policies (among others) are applied
A final note
- The Configuration Manager console has a monitoring node for Co-management as well. When the Endpoint Protection workloads successfully has been switched, you would expect changes in this view. Additionally, you might consider having the new workloads in place before excluding anything from the original settings (in this case excluding the settings from the GPO), to create the proper transition and overlap. This is a test scenario, so the order doesn’t matter much, but if doing this in production, you probably don’t want a scenario where the computers are without management of the workloads being switched
Enjoy and please leave a comment if this was useful 🙂
5 thoughts on “Flipping the switch, part 2: Moving Endpoint Protection workload to Intune MDM (Co-management with ConfigMgr)”
Great guide, very useful!
Thanks for letting me know – much appreciated 🙂
Hi Martin, thanks for your blogs, very useful and much appreciated!
I don’t suppose you actually had an SCCM ‘Windows Defender Application Control’ (WDAC) policy up and running and successfully transitioned that to Intune?
If SCCM installer was setup as trusted by SCCM WDAC, upon moving to Intune, does Intune WDAC automatically trust the SCCM apps? And if a new app is created in SCCM, is it still trusted now Intune is running the show? (And what about a new app in Intune that is not on the Microsoft Graph…).
I enjoy your blogs. Thank you for putting in the time to provide the community this information.
For the GPO piece are you saying configure this in an environment where GPOs are used to manage these settings?