Introduction

This is part two in my series on “Co-Management Workloads – What Do They Mean to Me?” I have no apologies for it taking six weeks to get back to this series, because we have a new baby boy at home! We welcomed our third child into the world on June 30th and we couldn’t be happier. Now that things are getting into a bit of a routine, it’s time for me to pick this back up. If you missed the first post in this series you can catch up here.

As a reminder, through the series I will cover what each of the workloads means when “moved to Intune,” and I plan to add more as more workloads are enabled. This post assumes that you are running ConfigMgr version 1910 or later and is going to cover Windows Update policies. Microsoft documentation here is a touch scant so I hope this post will answer some “unknowns.”

Frequently Asked Questions (FAQ)

Q: If I move the Windows Update policies workload to Intune, can I still manage Microsoft Updates through ConfigMgr?
No. Enabling this workload offloads Microsoft Updates to Intune.

Q: You said “Microsoft Updates” before. Are other update types unaffected?
Yes! You can still deploy 3rd party updates and Microsoft 365 Apps (formerly Office 365) updates from ConfigMgr. The latter has a separate workload to move if you want to offload them to Intune as well. Remember that to patch 3rd party updates outside of your network you will need to publish them to a CMG/Cloud-DP or internet-facing DP with IBCM.

Q: If I’m enabling Microsoft Updates, do I automatically get feature updates too?
Not necessarily. While still in “public preview” there is a feature update deployment policy that you can create. The devices assigned to that policy will not receive any feature updates beyond the version that is selected in the policy. You can still use a task sequence in ConfigMgr to upgrade them, or when the time comes you can select a new feature update level for co-managed clients.

What Happens When I Move the Slider?

ConfigMgr instructs the client that Intune will now manage updates through Windows Update for Business (WUfB).

Client Side Changes

After enabling the workload for a collection or for all systems, any co-managed devices upon their next machine policy refresh will update their co-management configuration to enable the workload. You can see this happen in the CoManagementHandler log.

You’ll notice here, that the workload for Windows Update policies (17, which is Windows Update Policies [16], plus Co-Management Enabled [1] together) is being merged with the other enabled policies. In this case the other enabled policies are Co-Management Enabled [1] and Compliance Policies [2]. Remember from the last post that merging is just doing a bitwise operation (bOR in this case) to merge two binary values together (bOR means that if any bit between the two values is “on,” then it should be included in the output). The output of the bOR gives us 19 (1 + 2 + 16). Again I’ll call out Ben Whitmore’s great blog post outlining the capability matrix for co-management features.

You’ll see some noise about this in the WUAHandler.log file too:

Also, you will notice that the “dreaded” Dual Scan is now enabled in the registry and local policy (double negative in local policy). This is expected – how else could you scan against both your WSUS database and Microsoft Update? However, this is important because if you have a policy/configuration baseline that is actively disabling dual scan there is going to be an epic battle between GPO and ConfigMgr.

ConfigMgr Side Changes

In your ConfigMgr console under Monitoring > Co-management you should see some devices enabled for the Windows Update policies workload after the dashboard summarizes:

Additionally, in WMI under the SMS_Client_ComanagementState class, the device(s) in question should reflect the new workloads under the MDMWorkloads property:

Intune/Microsoft Endpoint Manager Admin Center Changes

Inside MEMAC (https://endpoint.microsoft.com) if you look at the device, you should now see the Intune managed workloads list Windows Update for Business.

What Do I Lose?

Scheduling and Update Selection Granularity
Windows Update for Business (WUfB) policies (what Intune is managing) are simple for a reason – Windows updates are simpler these days (monthly cumulative quality, .NET, and SSUs) and not all businesses need the granular control over scheduling or which quality updates to apply. You might balk at the idea of simplicity, but many ConfigMgr based organizations (potentially even your own) are already replicating something similar to WUfB with ADRs.

That last statement does come with a caveat – as Bryan Dam so eloquently puts it… “Patch Tuesday is a LIE.” When (not if) a patch is released out-of-band, in a traditional monthly-patching ConfigMgr/WSUS environment, you’re not auto-deploying those non-Patch Tuesday patches. Co-managed clients with this workload enabled on the other hand, will receive the updates based on the deferral period set in your WUfB policies.

Servicing Windows Images from ConfigMgr
If you decide to go full steam ahead and remove Windows Updates from your software update point, now there’s no updates for your imported images. Though if you’re still servicing your images this way – I’d highly recommend you look into OSDBuilder or WIMWitch instead, because you’ll have leaner, cleaner images using them.

Reporting
If you’re removing the updates from your WSUS database, ConfigMgr has no knowledge of the updates to report on. This can be mitigated if you leave the updates in WSUS, at the expense of having a bloated catalog for only the purposes of reporting. The other option is to use Azure Analytics to measure update compliance, but having two panes of glass for reporting isn’t always optimal either. There’s not really a “good” answer here, but it’s still possible.

What Do I Gain?

Storage
Does your storage team hate you? If you move Microsoft Updates to Intune you don’t have to store all of that content locally anymore! Save yourself multiple gigabytes a month, and if you don’t tell your storage team, you just found a few extra gigabytes to store some sweet TikTok videos before TikTok is banned stateside.

No More WSUS Maintenance Woes
Remember when Microsoft added a new product for Windows 10 1903 and later updates? Pepperidge Farm remembers. Remember all the x86 patches that you don’t need because you haven’t had a 32-bit system for years? Remember when all 50,000 of your clients had to consider whether or not to install a Visual Studio update because you have 3 developers you want to make sure stay up to date? What about all those superseded updates that are clogging your console?

None of this is your concern now that the catalog is out of your hands.

Easier Pause/Rollbacks
Nobody ever had an issue with a Microsoft Update, so I don’t even know why I mention this.

… Please forgive me while I go cry in the corner.

Intune Windows Update policies have an easy button (well, buttons) for pausing an update ring and rolling back/uninstalling updates. Stop the fire from spreading by pausing the updates, and provided your broken machines can still boot, you can rollback the latest quality update that caused that in-house developed app that nobody owns or maintains to stop functioning.

Windows Patched Anywhere*
Anywhere the device has connectivity to Microsoft Updates at least. Since you’re getting updates from Microsoft, you don’t have to be “on the network” to get patches. This means that Keith who never comes into the office and rarely connects to the VPN on his 3G hotspot (does that guy even work?) will still get updates (well, as fast as you can get them over 3G).

Native SSU Prioritization
Windows Update natively prioritizes servicing stack updates (SSU) in front of other updates. No need to create some complicated ADR to make sure that the SSU gets applied before the monthly cumulative that requires it (and hope that your device re-scans the deployment in a reasonable amount of time to detect the newly required quality update).

What Do I Need to Consider?

Peer to Peer Content Sharing
If you want to have a really bad time, disable Delivery Optimization (DO) and let all 50 of those machines at a remote branch on a single T3 line go and download updates. I’ll wait. When network bandwidth is a concern for you or your ISP charges you an arm and a leg for every kilobyte of data that comes in, you’ll want to make sure that your devices are sharing update content with each other… because sharing is caring!

It’s important to note that while BranchCache is a supported P2P technology for WSUS/ConfigMgr, as far as I can tell this is not natively the case for Microsoft Update (and I’m not sure it’s configurable – although the 2Pint team probably has found a way). Don’t automatically assume you’re good to go if you only have BranchCache enabled!

Make sure your Intune policies are in place!
This really goes for all of the co-management workloads, but for the updates workload especially. You don’t want your devices going FU and downloading the latest FU (feature update) without your consent. If you get lazy and move the workload and tell yourself, “I’ll create the Intune update policies tomorrow” your machines will probably reach out and look for updates before you get around to it. (Ask me how I know)

What to do about FUs
Since we’re talking about feature updates, we may as well talk about how to block them. Previously, you could really only delay feature updates for 365 days with WUfB policies. This is no longer the case. While the feature is still in “public preview” as I mentioned earlier, you can create a Windows 10 feature updates (Preview) policy to lock assigned devices to a specific feature update release. That way you can have more control over your servicing, or go back to using task sequences. If you’re in the latter category, it might be worth looking into servicing though. Many are finding it can work for enterprises (see Adam Gross’ post).

Firewall / Policies / VPN
It’s worth considering any firewall policies you may have in place to block Microsoft Updates endpoints as your devices will now need to reach out to stay patched. Consider any GPOs you might have in place that are limiting the use of Windows Updates. Finally, consider whether or not you have split-tunneling capabilities on your VPN since it’s not optimal to download the updates to your datacenter and then send them back to your client.

Closing Thoughts

The decision to move this workload isn’t as cut and dry as the compliance policies workload I covered in the first post. There are certainly many things you’ll want to consider when moving, but I honestly think this is a great opportunity for a lot of organizations. Bryan Dam has a nice post detailing his experience with Intune patching in general and I’d recommend you give it a read (he’s funnier than I am). We share a lot of the same thoughts and he goes into a little more detail on a few of the specifics. Let me know if there’s anything I missed or even your own thoughts and experiences!

Happy admining!