Byteben

[Michelle Benitone]

Backin March 2021 I was invited to contribute over at To avoid blog post duplication, you will find all my new ConfigMgr, Intune, Windows 10 and Azure related post at the URL above. I will still blog other content here at Byteben Thanks for your support ?

The Win32App Migration Tool is a free community tool that has been developed to do the scoping and heavy lifting for you as you consider building Win32apps in Intune while using your ConfigMgr apps as a reference. The tool is designed to inventory ConfigMgr Applications and Deployment Types, build .intunewin files and create Win32apps directly

This script wont necessarily fit your environment, it may do with tweaking, but my hope is that it will give you an idea of how you can approach different challenges using the different tools in you arsenal. TL;DR The script can be found here -homedrive.ps1 During a recent Windows 10 adoption project there was a

In our previous post How to Uninstall Adobe Flash Player from Windows 10 with ConfigMgr (byteben.com) we reviewed the End of Life for Adobe Flash Player and what that meant for Windows 10 devices. We also stepped through a tutorial showing you how to deploy the update with ConfigMgr. Please review this post first as

In this post we will be looking at how we can list actual vs expected DNS records for a Microsoft 365 tenant with PowerShell. Background A Microsoft Office 365 Tenant requires certain DNS entries to be in place, for a verified domain, to ensure things like mail, collaboration and device management all work as expected.

You may have seen No Items Found when looking at the Monitoring > Reporting > Reports node in the Configuration Manager console TL;DR One of the more common reasons for your reports to be missing is an expired certificate on your SQL Server Reporting Services Web Service If this is the case, you will have

In this short post we will be looking at app requirements in the context of installing Win32 apps. What are App Requirements? App Requirements allow you to specify certain requirements are met before your app gets installed on your endpoint. If the requirements are not met the app will not install. Many admins create groups

Software Engineer @PatchMyPC Microsoft MVP - Enterprise Mobility Microsoft Certified Trainer Microsoft 365 Certified: Enterprise Administrator Expert Blogger/Speaker @MSEndpointMgr Contributor @MEMbersHut @eoemug

Community driven and passionate Technical Architect with 20 years experience in driving adoption and technology change within the Enterprise.

Often a simple and effective solution seen by the customer requires lots of work 'under the hood' - this is where my skill set puts me.

This blog post will highlight some of the concepts around co-management, recap on what it actually is and detail how the Windows Update workload is affected by Dual Scan and the newer Scan Source policy.

We will also spend some time looking at how you can still deliver 3rd-party patching from Configuration Manager whilst making use of the benefits of controlling Microsoft Updates from Intune. This is especially attractive if you want a super granular transition for managing your all your patching from Microsoft Intune.

Co-management only works between the Configuration Manager client and the Windows MDM agent. To caveat that statement, the Intune Management Extension is also co-management aware, so technically there are 3 agents at play.

It is important to note that when you move the workload for Windows Update Policies to Intune, you are only moving the workload for Microsoft 1st-party updates. When the Windows Update policy is moved to Intune, 3rd-party updates still come from Configuration Manager. 3rd-party updates are normally built as Win32 apps in Intune. In order to target updates to devices from Intune, as Win32 apps, you must set the Client Apps workload to either Intune, or Pilot Intune.

If you want to stop clients receiving 3rd-party updates from Configuration Manager, you should adjust your 3rd-party Software Update deployments to not target devices that have had their Windows Update workload moved to Intune.

In testing, this removed all the Windows Update policies and registry keys from the client that the Configuration Manager client had previously set. Be sure to check for tattooed policy that Geoff was responsible before when he created that GPO 74 years ago. The image below depicts the policy/registry key removed for Windows Update.

Every co-management workload has an associated numerical value. We refer to this as the capability value. You can very easily see the capability value assigned to the client in the Configuration Manager control panel applet and also the CoManagementHandler.log log file.

The available capability values changed drastically in Configuration manager 2111. If you like deep diving down rabbit holes, check out this post at Co-management Workloads and Capabilities (Revisited) (msendpointmgr.com)

As different workloads are moved to Intune, the capability will be re-evaluated on the client and the value will change accordingly. This capability is how the different MDM agents/clients know which workload they should enforce or ignore.

One of the early challenges, was correctly identifying policy conflicts when moving different workloads to Microsoft Intune. Unless you had very well documented policies, you would often find devices not applying policy correctly because of legacy Group Policy settings tattooed in the registry. This challenge still exists today as folks start to embrace co-management.

DisableDualScan is one of the main focus points of this blog and it is another policy setting that can adversely affect the delivery of Windows Updates when you move workloads to Microsoft Intune in a co-management scenario. Enabling this policy does not allow update deferral policies to cause scans against Windows Update. DisableDualScan is enabled (set to 1) when the Windows Update workload is set to Configuration Manager. When you move the workload to Microsoft Intune, this value will change to 0 to allow the client to Dual Scan (against both the Windows Update Service and WSUS).

As the image below depicts, the WindowsUpdate.log has been filtered to show you how different services are contacted to check for different types of updates, depending on how Dual Scan (and Scan Source) has been configured.

As we mentioned earlier, when you move the workload for Windows Update Policies to Intune, you are only moving the workload for Microsoft 1st-party updates. 3rd-party updates are normally built as Win32 apps, in Intune. In order to target updates to devices from Intune, as Win32 apps, you must set the Client Apps workload to either Intune, or Pilot Intune.

Carefully sizing a Configuration Manager hierarchy, planning placement of Distribution Points (including a Cloud Management Gateway, a Cloud Distribution/Management Point) and working with the network team to ensure adequate bandwidth is available to deliver content to clients, is critical.

In the world of WSUS, you typically download the updates once from the Content Delivery Network (CDN) and distribute them across that carefully built hierarchy without bringing down your network. As you move the update workload to Windows Update leveraging WUfB/Intune, your Windows devices will now all be reaching out to the CDN individually. The same is true for delivering Win32 apps from Intune for 3rd-party updates. While this is super useful, your Windows devices will be pulling Win32 app content directly from Azure storage. Have you made suitable accommodation for the extra bandwidth those clients will use, sitting nicely within your WAN?

You can be totally smart and well prepared for the move, but it requires careful planning. Technologies like Delivery Optimization and Connected Cache certainly demand attention. The folks over at 2Pint have done a lot of work in this area. Optimal Delivery Optimization settings for Intune managed devices can be found at Delivery Optimization Recommendations for Microsoft Intune (2pintsoftware.com)

When you configure clients to use the Connected Cache server, they no longer request content from the internet. Instead, clients request the content from the cache server. The following content is supported for a Connected Cache server:-

When Windows devices have their Windows Update workload set to Configuration Manager, the registry value HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate DisableDualScan DWORD is set to 0. This means ALL updates come from WSUS. When the workload is moved to either Intune or Pilot Intune, the DisableDualScan value changes to 0.

We can observe the impact Dual Scan has when the Windows Update Agent performs a scan on a Windows 10 device. The WindowsUpdate.log indicates that, in this instance, the Update Orchestrator initiated the Windows Update scan using the service URL The log snippet below has been shortened for simplicity but after Windows Update has been contacted and updates evaluated, the service URL is then changed to the local WSUS server -cm1.byteben.com:8531/ClientWebService/client.asmx and it is indicated that Windows content for WUfB is blocked.

We know that Windows 11 does not support Dual Scan, but when the Windows Update policies workload is moved to Intune for a Windows 11 device, DisableDualScan is still set to 0 in the registry. For prosperity reasons perhaps (shrugs).

Dual Scan is not supported on Windows 11. On Windows 10 it is replaced by the new Windows Scan Source Policy and is not recommended for use on version 2004 or greater.

That being said, Dual Scan is still configured by the Configuration Manager client when co-management is in the picture, irrelevant of the Windows version. This is most probably an intentional decision by Microsoft, given some organizations are still supporting older versions of Windows 10.

3a8082e126