Co-management workloads

In my previous post we discussed the paths to co-management, the related components and how to enable them.

Once we have decided which path for co-management is right for the environment and have set up the necessary configurations, its time to have a look at the available workloads and how to manage them.

Note: Make sure the new configurations are properly tested and optimized before moving the workloads, if not configured properly it can be a security risk and can lead to improper management of policies. This is also an opportunity to look back at the trivial configurations which are no longer needed and can be removed with proper investigation and replacement with latest alternative.

It's not necessary to switch any of the workloads right away. Once we are confident that the required settings and configurations are ready to handle them and manage devices, they can be switched individually, multiple at once, or all at the same time. However, until the workloads are switched over to Intune, SCCM continues to manage the workloads which are not switched to Intune, along with all other features of SCCM that co-management doesn't support.

If you switch a workload to Intune, but later change your mind, you can switch it back to Configuration Manager, although there might be an impact. For example, Windows and Office versions will remain at a later version if installed by Intune.

Co-management supports the following workloads:

• Compliance policies
• Windows Update policies
• Resource access policies
• Endpoint Protection
• Device configuration
• Office Click-to-Run apps
• Client apps

Compliance policies

Compliance policies define the rules and settings that a device must comply with to be considered compliant by conditional access policies. Also use compliance policies to monitor and remediate compliance issues with devices independently of conditional access. You can add evaluation of custom configuration baselines as a compliance policy assessment rule.

In Intune we get two options either create a compliance policy based on the provided configuration options, or a custom compliance poilicy.

Custom settings provide flexibility to base compliance on the settings that are available on a device without having to wait for Intune to add these settings to the built-in policy templates. for custom compliance policy you need to upload a JSON file containing custom settings and values, message template and much more, and a discovery script which runs on a device to discover the custom settings defined in your JSON file.

If the below option is configured, co-managed devices will need all settings (configuration items) in Configuration Manager to be compliant.:

Based on the compliance results, you can configure below actions if the device is found to be Non-compliant:

Adding device to the retire list does not automatically retire it, an admin needs to perform that action manually.

More details on compliance policies in a dedicated post in this topic.

Windows Update policies

Moving from SCCM\WSUS updates where you have granular control over what updates gets deployed to the clients and in case a patch turns out to be faulty you have the liberty to remove it from deployment and run a separate task to uninstall that patch. Extensive reporting options so on and so forth is a challenging decision for most organizations. But moving Windows updates to Intune (WUfB) makes life easier you set the rings and delay, deferral. notification options, setup Log analytics and create custom workbooks or use the default reports and workbooks utilizing Azure monitor for insights.

Windows Update for Business policies let you configure deferral policies for Windows 10 or later feature updates or quality updates for Windows 10 or later devices managed directly by Windows Update for Business.

Policy types to manage updates

Intune provides the following policy types to manage updates, which you assign to groups of devices:

• Update rings for Windows 10 and later:
• Feature updates for Windows 10 and later:
• Quality updates for Windows 10 and later:
• Driver updates for Windows 10 and later:
• Monitor:

You can opt for Windows Autopatch as well which is a cloud service that automates Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams updates to improve security and productivity across your organization. I'll create a detailed post on Windows Autopatch later in a separate series.

Resource access policies

Starting in version 2203, Resource Access policies are deprecated from SCCM, so create the existing resource access profiles in Intune as soon as possible and move it before you get trapped in unwanted issues like Update\Upgrade failures, policies not applying to the clients etc.

Resource access policies configure VPN, Wi-Fi, email, and certificate settings on devices.

Note

The resource access workload is also part of device configuration. These policies are managed by Intune when you switch the Device Configuration workload.

Endpoint Protection

This is a tricky one, you need to have a proper infra setup for Defender for Endpoint before making any moves in the workloads. Collaborate with security teams for best practices and required configuration and migration plans if moving from 3rd party Antivirus to Defender.

The Endpoint Protection workload includes the Defender suite of protection features:

• Microsoft Defender Antivirus
• Microsoft Defender Application Guard
• Microsoft Defender SmartScreen
• Microsoft Defender for Endpoint (formally known as Windows Defender Advanced Threat Protection)
• Windows Defender Firewall
• Windows Encryption (also known as BitLocker)
• Windows Defender Exploit Guard
• Windows Defender Application Control
• Windows Defender Security Center

Note

When you switch this workload, the SCCM policies stay on the device until the Intune policies overwrite them. This behavior makes sure that the device still has protection policies during the transition.

The Endpoint Protection workload is also part of device configuration. The same behavior applies when you switch the Device Configuration workload.

When the Endpoint Protection workload resides with Intune, Windows Information Protection settings will apply from both Configuration Manager and Intune. Configuration Manager will continue to apply Windows Information Protection policy until the Device Configuration workload is moved to Intune.

The Microsoft Defender Antivirus settings that are part of the Device restrictions profile type for Intune Device configuration are not included in scope of the Endpoint protection slider. To manage Microsoft Defender Antivirus for co-managed devices with the endpoint protection slider enabled, use the new Antivirus policies in Microsoft Intune admin center > Endpoint security > Antivirus. The new policy type has new and improved options available, and support all of the same settings available in the Device restrictions profile.

The Windows Encryption feature includes BitLocker management.

More details on this topic in a separate future post.

Device configuration

The device configuration workload includes settings that you manage for devices in your organization. Switching this workload also moves the Resource Access and Endpoint Protection workloads.

You can still deploy settings from Configuration Manager to co-managed devices even though Intune is the device configuration authority. This exception might be used to configure settings that your organization requires but aren't yet available in Intune. Specify this exception on a Configuration Manager configuration baseline. Enable the option to Always apply this baseline even for co-managed clients when creating the baseline. You can change it later on the General tab of the properties of an existing baseline.

To use Windows Autopatch with these devices, this workload needs to be managed by Intune. For more information, see Prerequisites for Windows Autopatch.

For more information on the Intune feature, see Create a device profile in Microsoft Intune.

Note

A policy created from the settings catalog is controlled by the Device Configuration workload slider regardless of the contents of the policy.

When you switch the device configuration workload, it also includes policies for the Windows Information Protection feature. Only policies from Intune will apply once the Device Configuration workload is moved to Intune.

Note

In order to tattoo remove Endpoint protection settings, Device Configuration workload also needs to be switched.

Office Click-to-Run apps

This workload manages Microsoft 365 Apps on co-managed devices.

• After moving the workload, the app shows up in the Company Portal on the device
• Office updates may take around 24 hours to show up on client unless the devices are restarted
• There's a global condition that's added by default as a requirement to new Microsoft 365 applications. When you transition this workload, co-managed clients don't meet the requirement on the application. Then they don't install Microsoft 365 deployed via Configuration Manager. The global condition is named either:

Updates can be managed using either of the following features:

• Use Update Channel and Target Version settings to update Microsoft 365 with Microsoft Intune Administrative Templates
• Manage Microsoft 365 Apps with Configuration Manager.

Note

To use Windows Autopatch with these devices, this workload needs to be managed by Intune.

Client apps

This feature may appear in the list of features as Mobile apps for co-managed devices.

Use Intune to manage client apps and PowerShell scripts on co-managed Windows 10 or later devices. After you transition this workload, any available apps deployed from Intune are available in the Company Portal. Apps that you deploy from Configuration Manager are available in Software Center.

Starting in version 2006, the Company Portal app is now the cross-platform app portal experience for Microsoft Intune family of products. By configuring co-managed devices to also use the Company Portal app, you can provide a consistent user experience on all devices.

Note

In Windows 10 version 1903 and later, PowerShell scripts still run on co-managed devices even if you haven't switched the Client Apps workload to Intune.

When you enable Microsoft Connected Cache on your Configuration Manager distribution points, they can serve Microsoft Intune Win32 apps to co-managed clients.

Most of the content in this post is directly taken from the MS documentations, this is for creating a basic understanding on each of the workloads before we deep dive in each of them.

Below is a diagrammatical representation of Co-Management workloads and how it connects with SCCM and Intune:

Hope this post was helpful in creating a basic knowledge about Co-management Workloads, We'll talk about each of them in details in later posts.

In Part 6 We'll talk about Third-party MDM coexistence with Configuration Manager. Hopefully with an example.

Please #share your #reviews and #suggestions so I can improve my #content. If you need any help with #Endpoint related projects please connect!! ??

Stay #connected !! ???????????