Monday, 14 March 2022

Intune policy not applicable

This is a quick follow up to my recent post where I discussed an issue my customer was having with an unwanted reboot. We narrowed this down to Microsoft Defender Application Control in Microsoft Endpoint Manager, "Application control code integrity policies" being set, even to Audit Only. 

I referred my customer to Peter van der Woude's post, where Peter talks about creating a custom code integrity policy using OMA-URI and the Application Control CSP. I had previously tested the solution successfully was I was quite happy to recommend it. My customer also successfully tested the solution in their lab but ran into difficulty when implementing in a production pilot. The policy status for the pilot devices was "Not applicable". 

This was a little unusual but it was obvious when I figured out why. All testing was carried out in an Intune only environment. However, these devices were co-managed with the following settings.

The Endpoint Protection workload had been moved to Intune pilot. That worked well for Microsoft Defender policies. However the new policy (as per Peter's post) was a device configuration profile. This workload was still set to ConfigMgr and therefore the policy was not applicable to the devices. This was easily solved by moving the device configuration workload slider to Intune. Then the Intune policy applied as expected.

The only thing we had to worry about was that the customer was using some ConfigMgr configuration baselines and still wanted them managed by ConfigMgr. 

Luckily Microsoft provides a solution for that. We selected "Always apply this baseline even for co-managed clients".

I hope this helps if you encounter a similar situation.

Until next time......

Sunday, 20 February 2022

Microsoft Defender Application Control and the unwanted reboot

I came across this issue again this week on a customer site. Windows 10 computers were being rebooted without warning. 

You’re about to be signed out 

Windows will shut down in 10 minutes

I narrowed this down to Microsoft Defender Application Control in Microsoft Endpoint Manager, "Application control code integrity policies" being set, even to Audit Only. 

This is created as a Windows 10 configuration profile, choosing the Endpoint Protection template, then selecting the Microsoft Defender Application Control.

If you use the tooltip and follow the "Learn more" link, you are directed to the Applocker CSP page, so clearly that's what is in use here. 

According to the Microsoft docs, prior to Windows 10 version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). Interestingly, this is the only AppLocker setting that causes a reboot. It's well documented on the Applocker CSP page. 

"The AppLocker CSP will schedule a reboot when a policy is applied or a deletion occurs using the AppLocker/ApplicationLaunchRestrictions/Grouping/CodeIntegrity/Policy URI".

I can verify that the reboot occurs when you apply the policy but also when you remove it.

Some of my colleagues have suggested ways to avoid the reboot. 
  • Peter van der Woude talks about creating a custom code integrity policy using OMA-URI and the Application Control CSP.
  • Rudy Ooms talks about the WDAC wizard.
  • You can read about creating a new base policy in the official docs using the WDAC wizard. 
This reboot is not a problem when you configure the same setting with ConfigMgr.

In ConfigMgr, the WDAC wizard allows us to de-select the check box to enforce the required reboot.

I hope this helps.

Until next time.......

Software updates issue - access denied

We encountered this problem recently on a customer site. The customer uses ConfigMgr to patch their Windows 10 estate. They've not had any major issues for quite some time but then the January CU for Windows 10 v1909 (KB5009545) started to fail with the Access is denied error (0x80070005).

We could see the error in the UpdatesHandler.log file.

WSUS update (92c58401-7a51-4e9d-9457-ca1a93c3e3d9) installation result = 0x80070005, Reboot State = NoReboot

Update execution failed.

But what did that mean? Nothing had changed so why all of a sudden was access denied? What specifically was being denied access?

We found the answer in the CBS.log file. CBS refers to Component-Based Servicing. Some components might be installed or uninstalled during Windows updates, and CBS.log is a file that includes details of these components. This file logs detailed information from your most recent Windows installed updates, and thus it can be used for troubleshooting issues related to your updates.

This log file is located in %windir%\Logs\CBS\ folder. There were several errors like this repeating over and over

2022-02-08 19:32:05, Info                  DPX    DpxMoveFileExW failed, source: \\?\C:\Windows\SoftwareDistribution\Download\55d2d88ec6c8540e1de4d959136d1809\inst\_Windows10.0-KB5009545-x64.cab_\$dpx$.tmp\4f76f8be37b84846a53e298df591e679.tmp, destination: \\?\C:\Windows\SoftwareDistribution\Download\55d2d88ec6c8540e1de4d959136d1809\inst\_Windows10.0-KB5009545-x64.cab_\amd64_microsoft-windows-e..-unifiedwritefilter_31bf3856ad364e35_10.0.18362.449_none_f216a3681960d832\r\uwfservicingscr.scr, hr 0x80070005

We could see similar issues using Procmon

8:51:31.2419935 PM  TiWorker.exe  10516  SetRenameInformationFile C:\Windows\SoftwareDistribution\Download\7998dad7da209654d66a9b53acb8a555\inst\_Windows10.0-KB5010345-x64.cab_\$dpx$.tmp\8bdd9ac34e21374c8fe95160faa8a43e.tmp        ACCESS DENIED            ReplaceIfExists: True, FileName: C:\Windows\SoftwareDistribution\Download\7998dad7da209654d66a9b53acb8a555\inst\_Windows10.0-KB5010345-x64.cab_\x86_microsoft-windows-photoscreensaver_31bf3856ad364e35_10.0.18362.1316_none_1d493b2302fc0b6b\r\photoscreensaver.scr

This error referred to TiWorker.exe which is the TrustedInstaller process and suggested that it did not have Full Control or Full Access to all the folders or sub-folders within the directory named SoftwareDistribution (C:\Windows\SoftwareDistribution). This didn't make much sense as nothing had changed in the environment.

We noticed that all the files that were blocked had a .SCR extension. These were screensaver files that were being updated by the January CU. Then we discovered that there was a McAfee access protection rule in place to block access to .SCR files. 

The fix was then straightforward. We excluded the TiWorker.exe process from the Block all SCR rule and the updates started to install.

I hope this helps if you find yourself in a similar situation. CBS logs and Procmon are your friends 😀

Until next time........

Sunday, 28 November 2021

Convert CMG to virtual machine scale set

Starting in Configuration Manager version 2010, organizations with a Cloud Solution Provider (CSP) subscription could deploy the CMG with a virtual machine scale set (VMSS) in Azure. Starting in version 2107, all organizations can deploy a CMG with a virtual machine scale set. There is no longer a dependency on the subscription type. However, my favourite feature of Configuration Manager 2107 is that, if you have an existing CMG deployed with the classic cloud service, you can convert the CMG to use a virtual machine scale set. I did that conversion in my lab and it worked a treat.

Of course there are some rules:

  • You can change some settings when you convert to VMSS, for example size of VM, CRL check.
  • You cannot change other settings when you convert to VMSS, for example, Azure subscription, Azure AD app, Region, Resource group.
  • The CMG service name will change from to You will have to re-configure the CNAME record.
  • If you don't change the CMG public name then you don't have to re-install the CMG Connection Point.

In the Configuration Manager console, navigate to the Administration workspace > Cloud Services, and select the Cloud Management Gateway node.

Select the classic CMG instance whose Status must be Ready. In the ribbon (or right click), select Convert. This action opens the Convert CMG wizard.

On the General page, select Next. As we said earlier, you can't change any of these settings.

On the Settings page, note the new Deployment name with the suffix for the virtual machine scale set (in my case that is

Make other configuration changes as needed. Then select Next and complete the wizard.

Click Next to finish the wizard and convert the CMG.

Monitor the conversion process in the CloudMgr.log file, the same way as a new deployment.

You will see the new Azure resources. See the Virtual Machine Set and Key Vault, for example. We didn't have these with the classic CMG implementation.

I hope this helps. Until next time....

Sunday, 17 October 2021

My first look at Windows 11 readiness

I'm a little bit late to the party here but I've been very busy this year. Some of my customers have started asking about Windows 11 so I've started looking into Windows 11 readiness. There has been some controversy about this already. Organizations are finding that many of the devices that easily run Windows 10 are not capable of running Windows 11. 

Windows 11 requirements.

Let's start with the hardware requirements. They are clearly defined in the Microsoft documentation. 

  • Processor: 1 gigahertz (GHz) or faster with two or more cores on a compatible 64-bit processor or system on a chip (SoC).
  • RAM: 4 gigabytes (GB) or greater.
  • Storage: 64 GB or greater available storage is required to install Windows 11.
    • Additional storage space might be required to download updates and enable specific features.
  • Graphics card: Compatible with DirectX 12 or later, with a WDDM 2.0 driver.
  • System firmware: UEFI, Secure Boot capable.
  • TPM: Trusted Platform Module (TPM) version 2.0.
  • Display: High definition (720p) display, 9" or greater monitor, 8 bits per color channel.
In general all these requirements seem pretty reasonable. The TPM requirement seems to be the one that has caused the most fuss. Many organizations still have a lot of hardware with TPM 1.2. Fortunately the firmware of many models can be upgraded to give you TPM 2.0, but your mileage may vary on that. Updating firmware on thousands of devices can be an administrative challenge, but we should be doing that anyway, shouldn't we 😀.

Michael Niehaus has published a blog post, Windows 11 new hardware requirements: Justified or not?, which delves into each requirement in detail. It's worth a read.

Windows 10 upgrade

If you want an in-pace upgrade from Windows 10 to Windows 11, you must be running a supported version of Windows 10. Currently that is v1909 or later. You can find the supported versions here

Windows 11 readiness.

This is the part that really interested me. How can organizations verify if their devices are Windows 11 capable or not? I've looked at a few options.


Microsoft have published a script to determine whether an individual device meets the system requirements for Windows 11. Download HardwareReadiness.ps1 and run with an elevated prompt. 

The script output will be a returnCode (is the device capable or not)..... 

..and returnReason (why the device is not capable).

It is recommended to use Microsoft Endpoint Manager or Configuration Manager to deploy the script at scale.

Configuration Manager report

The guys at System Center Dudes have developed a pretty cool Windows 11 readiness report for Configuration Manager. You can download the report for free from their website

The report lists the following components and highlights in red if a component does not match the Microsoft minimum requirement: Device Name, UserName, Client Status, Client Version, OS Edition, OS Version, OS Branch, CPU Speed, RAM, Free Space, Device Manufacturer, Device Model, Secure Boot Status, UEFI Bios status, TPM version and status

Endpoint Analytics

I've been interested in this feature for some time now and it is really useful for assessing Windows 11 readiness. Windows 11 insights are available for all Intune-managed and co-managed devices in Endpoint analytics, as well as devices enrolled via tenant attach with Configuration Manager, version 2107 or newer.

In the MEM console, navigate to Reports > Endpoint Analytics.

Work from anywhere (preview) and click WindowsA chart is displayed showing which specific hardware requirements are the top blockers in your organization.

In the Windows tab, a device-by-device view of Windows 11 hardware readiness is displayed. 

Windows 11 readiness status column indicates if device is Capable of upgrading to Windows 11 based on the minimum system requirements. 

We see a Windows 11 readiness reason if it is 
Not capable.

In most cases, devices with a Windows 11 readiness status of Unknown are inactive. You can verify this by reviewing the last check in time from Intune. I've seen a lot of Unknown devices so I'll be doing some troubleshooting on these and will update this post with my findings.

I hope this helps. Until next time.....