Take Windows Up to 11

Tag: Windows 10

Windows 10 1903 nice to know for IT Pros and Enterprise admins (curated link list)

With the release of Windows 10 1903 I want to start a curated link list for every Windows 10 release. A place where I can store interesting articles about new features, settings or bugs. I plan to update with new content as soon as I find it.
If you find something new before me or if I missed anything important please write a comment or send me a message via Twitter.


Topic Description Source
What’s new for IT Pros New and Updated Features of interest to IT Pros Link
What’s new in WUfB What’s new in Windows Update for Business in Windows 10 Link

Group Policies

Topic Description Source
New GPOs Group Policy Changes in Windows 10 1903 Preview Link
New GPOs New GPO settings in Windows 10 1903: enforce updates, Storage Sense, and logon Link
Security Baseline (Final) Security Baseline (Final) for Windows 10 1903 Link
Security Baseline 1903 Security Compliance Toolkit Link
WMI Filter Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.18362%" and ProductType = "1" Link

Autopilot, OSD, SCCM and MDT

Topic Description Source
WSUS category Windows 10 1903 has ist own WSUS product category, SCCM 1902 required to manage 1903 Link1 Link2
What’s new in ADK Changes to the ADK especially the known issues Windows SIM x64 error Link
Autopilot The latest news on Windows Autopilot Link
Autopilot Companion Example Companion App to change settings during White Glove deployments Link
Autopilot White Glove Windows Autopilot for white glove deployment Link


Topic Description Source
What’s new in MDM What’s new in MDM for Windows 10, version 1903 Link


Topic Description Source
Sandbox Enable Windows Sandbox on 1903 with and without PowerShell Link
Sandbox Configuration How to configure Windows Sandbox Link
Sandbox Mapped Folder If you use mapped folder in Windows Sandbox, note that the ReadOnly value should be in lowecase like “true” and not “True” Link | Reserved Storage | Windows 10 and reserved storage |Link
WSL What’s new for WSL in Windows 10 version 1903? Link

“Something went wrong” error when enabling Windows 10 facial authentication


When I was at a customer’s site lately and tried to enable the Windows Hello face recognition feature I encountered an error. After pressing the Get started button on the Windows Hello setup page Sorry, something went wrong was displayed without further explanations.

Windows Hello Setup
Windows Hello Setup Error

When I checked the Windows Event Log I could find a DistributedCOM error with the EventID 10016 which stated that the application did not have the local activation permission for the COM application.

Windows eventlog error DCOM

After that I looked up the APPID from the event in the Component Services and found out that it was the RuntimeBroker which controls the execution of the AppX(Universial)-Apps. Thinking about that I remembered that we had limited the access to the camera to certain AppX-Apps via Group Policy.

Component Services

I opened regedit as an Administrator and removed the value


and tested again. Then it worked! So I just needed to find out which AppX needs access to the camera. I looked up the installed AppX with the PowerShell command:

Get-AppxPackage | select Name | sort

There it was the Microsoft.BioEnrollment_cw5n1h2txyewy AppX which looked like the app I was searching for. I reset my registry changes with a Group Policy update and added the AppX name to the value of:


Registry privacy camera

After that I tested again and it still worked to setup the facial recognition.

Camera working


Adding the AppX Microsoft.BioEnrollment_cw5n1h2txyewy to the Put user in control of these specific apps or the Force allow these specific apps fields of the Let Windows apps access the camera setting in the GPO under Computer Settings\Administrative Templates\Windows Components\App Privacy resolved the issue and users are able to use their face to authenticate on Windows.

GPO settings camera privacy

Windows 10 1803 ADMX Files SearchOCR error $(string.Win7Only) not found


Update 2: On 7/13/2018 Microsoft released Version 2.0 of the 1803 ADMX files without the issue
Update: Included feedback from @Jtracy_ItPro regarding multiple orphaned ADML files.

I just updated the Windows 10 ADMX files in the Central Policy Store of my lab domain with the Windows 10 1803 ADMX files. After that I got the error that the resource $(string.Win7Only) referenced in attribute displayName could not be found when accessing the Administrative Templates with the Group Policy Editor.

ADMX Error

I checked the mentioned searchocr.admx and the corresponding searchocr.adml file and found out that the modified dates differed by around three years (2015 and 2018).
Looking at the extracted 1803 ADMX files from the download revealed that they only include the SearchOcr.ADML files not the corresponding ADMX.

ADMX 1803

The c:\Windows\PolicyDefinitions folder of a running instance of Windows 10 1803 does not contain the two files.


Update 2: On 7/13/2018 Microsoft released Version 2.0 of the 1803 ADMX files without the issue

As long as I cannot find the 1803 version of the SearchOcr.admx I restored the old SearchOcr.adml file(s) from my backup and the error went away. Or even better remove the SearchOcr.ADML from every language that you want to import to the Central Policy Store.

@Jtracy_ItPro pointed out to me that the SearchOcr.adml is not the only orphaned ADML in the ADMX pack. The following list ADML files are orphaned in the 1803 ADMX pack as well

  • fileservervssagent.adml
  • microsoft-windows-geolocation-wlpadm.adml
  • microsoft-windows-messaging-grouppolicy.adml
  • searchocr.adml
  • terminalserver-winip.adml
  • userdatabackup.adml
  • wwansvc-admin-group-policy-data.adml

Any of these files can cause similar errors if you already have an older version of the ADMX and ADML in your Central Policy Store.

Therefore I wrote a small PowerShell function to find any orphaned ADMLs in a PolicyDefinitions folder.

You can use this function to find and remove any orphaned ADML before importing the files to the Central Policy Store

Install Microsofts January Meltdown / Spectre Updates during SCCM or MDT Build and Capture Task Sequence


I tried to create images of Windows 7 and Windows 10 (1607, 1703, 1709) with a SCCM Build and Capture Task Sequence. I deployed the January Windows Updates to the imaging clients so that the images should include the fixes for the Meltdown and Spectre vulnerabilities. But unfortunately this did not work. The reason is that the Antivirus compatibility Registrykey mentioned in this article had not been set before the updates were installed.

Update: After testing Build and Capture of Windows 10 with MDT I have added the necessary steps to the article.
Update 2: Thanks to @manelrodero for pointing out that a reboot is not required between setting the key and the Install Update step.
Update 3: Microsoft announced that this is not longer necessary beginning with the Cumulative Update 03-2018


You just have to add the registry in your Build and Capture sequence right before the update step performs the update scan.


  1. Add a Run Command Line Step to your Build and Capture Task Sequence before the Install Updates step containing the following line
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" /v cadca5fe-87d3-4b96-b7fb-a231484277cc /T REG_DWORD /D "0x00000000" /F

QualityCompat Key
2. Make sure that the box Evaluate software updates from cached scan results is not checked in the first Install Updates step.

Install Updates step


  1. Add a Run Command Line Step to your Build and Capture Task Sequence before the Windows Update (Pre-Application Installation) step containing the following line
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" /v cadca5fe-87d3-4b96-b7fb-a231484277cc /T REG_DWORD /D "0x00000000" /F

QualityCompat Key

Group Policy Security Baselines and Windows as a Service – a Layered Approach

How to align the rollout of the Microsoft Security Baselines Group Policies with the Windows 10 servicing model

Update: Added WMI-Filter for Windows 10 1903

The Problem

Microsoft released security baselines in form of a Group Policy backup set for its operating systems in the recent years. Many enterprises are using these baselines as a security foundation. Enterprises have to adopt new settings on a lot higher frequency with the change of the servicing model and the additional release speed of Windows 10. New security baselines are now available with every release of Windows 10 every 6 months.

Note: If you want to learn more about Windows as a Service look here

The nature of Group Policies where small changes can have a huge impact on your client landscape made it necessary for enterprises to build solid change processes around them to document and verify any change. These processes are normally slow and inflexible which makes it very hard to combine them with the fast speed of new security baselines.

Another challenge for enterprises is the complexity of testing each baseline setting against a variety of several hundred applications. The traditional way was to do this in an OS upgrade project.
First, the complete baseline was activated and then redefined them during application testing. But with Windows 10 branch upgrades there are no upgrade projects and to validate a baseline with over 50 changed settings against your client landscape on a regular basis is not a feasible scenario for many companies.


In order to help the security settings keeping track with the speed of the baseline releases I am using a layered approach.

What does “layered” mean?

I distinguish between two sorts of Group Policies, the Baseline-GPOs and Custom-GPOs. The main difference between these two are that Baseline-GPOs are not changed by me at all. Every setting which differs from the baselines is made in a Custom-GPO.

Another difference between the Baseline-GPOs and the Custom-GPOs is that the baselines are filtered via WMI-Filter to the corresponding Build version of Windows 10. In contrast the Custom-GPOs are filtered to apply on all Windows 10 clients.

The WMI-Filters

We need a WMI Filter for Windows 10 and for every active Build currently used. Microsoft supports the last three Build versions so you should have a maximum of three (maybe four) active builds and WMI-Filters.

WMI Filter for Windows 10 1709

Windows 10
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0%" and ProductType = "1"

Windows 10 1607
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.14393%" and ProductType = "1"

Windows 10 1703
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.15063%" and ProductType = "1"

Windows 10 1709
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.16299%" and ProductType = "1"

Windows 10 1803
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.17134%" and ProductType = "1"

Windows 10 1809
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.17763%" and ProductType = "1"

Windows 10 1903
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.18362%" and ProductType = "1"

The WMI-Filters contain a query about the Windows Version and the ProductType. The latter is defined as follows

  • 1 – Client Computer
  • 2 – Domain Controller
  • 3 – Member Server

With these filters we make sure that the Windows 10 GPOs will only apply on Windows 10 client devices (of the defined Build Version).

The Baseline-GPOs

You can download the Baseline-GPOs from here.

I have written a short PowerShell function to import all baselines at once. You just have to export them in one folder and add ‘-Version’ (e.g. ‘-1709’) to the folder name.

extracted baseline

Then change the ExportPath to your folder path in the following script and execute it. You will need to import the Group Policy WMI filter cmdlet module prior to successfully running the script.

The script will create or update the GPOs and name them as you can see in the picture below. Additionally it will set the corresponding WMI-Filter if it includes the Build number (e.g. 1709)

Imported Windows security baselines

Create the Custom-GPOs

You can create a Custom-GPO for each corresponding type of baseline (Defender, Computer, …) or as I did in the example below just one Custom-GPO for all baselines.

Custom GPO

Linking the GPOs

After having everything in place we can now link the GPOs to the OU(s). In the next picture, you can see the GPO Link order of my Windows 10 OU.

Linked Group Policies

The Custom-GPOs have to be linked with a lower order number or to a Sub-OU to apply at last and overwrite the Baseline-GPO if needed.


A common baseline setting which many of my customers perceive as too strict is the UAC configuration in the baseline for Standard Users which is set to Automatically deny elevation requests.

UAC Baseline

In the Custom-GPO I changed that setting to Prompt for credentials on the Secure Desktop

UAC custom setting

As you can see in the screenshot of a Group Policy Result of a Windows 10 1709 client the baselines are applied as described and the UAC setting is overwritten by the Custom-GPO.

Group Policiy Result

What is the advantage?

Instead of integrating and validating every single new baseline setting you only have to import the new Baseline-GPOs and the corresponding WMI-Filter.

Microsoft released the baselines when the Windows 10 Build became available in the Semi-Annual-Channel (formerly known as Current Branch for Business). With the release of the Fall Creators Update the final version of baselines even became available with the release to the Semi-Annual-Channel(targeted) (formerly known as Current Branch). So, it is very unlikely that you have deployed a large number of clients with the newest build before the baselines are available.

Therefore, when you start to upgrade your clients to the newest build you will automatically test the new baselines along with the new OS Version without an effect on your productive clients.

If you have to change a setting in your Custom-GPOs because of the new baselines it is very unlikely that this setting will have a negative effect on your existing clients. Because it is either a new setting which isn’t applicable for the old builds or it isn’t set in the old baselines. If the latter is the case you will set it back to the default value in most cases which already worked.

It also makes it easier to find out which of your settings differ from the baselines. You do not have to compare different GPOs with the baselines. You only have to look at your Custom-GPOs or in a Group Policy Result Report which of the settings are applied from a Custom-GPO.