Introduction

Continuing on the Co-management and flipping the switch journey. I have previously been going through how to initially enable Co-management with Configuration Manager and Microsoft Intune, and how to move some of the Endpoint Protection workloads to Intune MDM.

• Flipping the switch, part 1: How to enable Co-management in SCCM Current Branch (System Center Configuration Manager)
• Flipping the switch, part 2: Moving Endpoint Protection workloads to Intune MDM (Co-management with SCCM)

This time I will walk you through how I moved the Software Updates workload from Configuration Manager to Intune MDM. Everything still based on a production environment and along the lines some additional ramblings on the topic.

Configuration Manager

The actual moving of the workload takes place in Configuration Manager, more specifically in the console in the Administration work space in the Cloud Services -> Co-management node.

See below picture for a full illustration of where and how. In this scenario, I still have Co-management running as a pilot project and as of such, the workloads are limited to a pilot collection.

When the slider has been switched to Pilot Intune as seen above, the clients will pick up the new workload following the next Machine Policy refresh.

You can watch CoManagementHandler.log on the client to see the changes come into effect. Having above 3 workloads switched to Intune, will be represented as Co-management Capabilities 51. Also seen on the General tab of the Configuration Manager applet in the control panel:

Microsoft Intune

The rest of the doing and configuration is happening in Intune, with a few gotchas in the on-premise Active Directory where I previously had an old school GPO for WSUS.

• Log in to the Azure portal and locate Microsoft Intune: https://portal.azure.com
• The Software Updates menu is located in the main Microsoft Intune menu as illustrated in below picture

Create new Windows 10 Update Rings

I’m not going into all the possible details here, but I will instead just let you know and showcase how I initially has configured the update rings. Some of my choices are subject to change once they hit production and I encourage anyone doing this to try the options for themselves 🙂

• Create a new Update Ring on Create. Give it a suitable name and description. For your inspiration and for the time being, I have 2 rings called:
  • SU – SAC (Targeted) – Pilot
  • SU – SAC – Production

• In details the Pilot update ring looks like this (next picture below):
  • Servicing channel: Semi-Annual Channel (Targeted) formerly known as Current Branch (the choice here only has an impact on feature updates)
  • Microsoft product updates: Allow (this essentially turns Windows Update into Microsoft Update allowing updates to other Microsoft products)
  • Automatic update behavior: Auto install and restart at a scheduled time
    • I’m trying out the different options here, as this is limited compared to what offered through Configuration Manager. In this scenario, updates are installed every week on wednesdays at 12PM.
  • Restart check: This checks for user activity, and if any, reboot will be delayed
  • Delivery Optimization: HTTP blended with peering across private group (I have DO setup for this and this essentially means that Software Updates will work with DO as it’s configured for my group. That’s another blog, another day 🙂

Note #1: I do think the documentation on this part from Microsoft is a bit off and they are referencing terms that no longer exist, like maintenance windows. See: https://docs.microsoft.com/en-us/intune/windows-update-for-business-configure
Note #2: I strongly urge anyone doing this to try the different options. The automatic update behavior options alongside with active hours, is what we have to our disposal in terms of when and how updates are installed. More specifically study this section: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-allowautoupdate

Assign the Windows 10 Update Ring

Put the update ring til use and assign it. You have the option to both assigning it to a group of computer or group of users. In my scenario, I have a dynamic group consisting of all my Windows 10 1803 computers. 1803 is y default being co-managed in my environment, and it’s the same group I use for assigning everything else regarding Co-management.

What else do I want to know?

In Settings -> Windows Update you will find an option to see what update policies you have configured for the computer. I advice you to take a closer look on this, as you may have some policies configured coming from old school GPO you no longer want applied.

Remember that the Configuration Manager client automatically applies local policies for Software Updates/WSUS. Those policies will be listed in there along with the new MDM policies. The infamous DualScan will be enabled (and needs to be enabled).

If you have other group policies in place managed centrally, I recommend that you exclude your Co-managed devices from these. Something similar to this:

Verifying MDM policies

Back in the Settings app, find Access work or school and click Info

Find the awesome option to create a report, listing all the applied configurations of the device

Final notes

1. The computer will no longer report compliance about Windows Updates to Configuration Manager. Instead use Windows Analytics (again, another blog another day)
2. Office 365 Pro Plus updates can still be managed through Configuration Manager
3. Feature updates will be delivered and cannot be completely avoided when using Software Updates in Intune. I’m using deferral for 180 days and plan on delivering the feature updates through Configuration Manager task sequences as usual.

I hope this was helpful 🙂