Configure Delivery Optimization with Intune for Windows Update for Business

When using the Modern IT approach and building Microsoft 365 powered devices it is a combination of the following cloud services for Modern Management:

WUfB

To support the Windows as a Service strategy with cloud services we rely on the well known Windows Update service, but with the controls for business usage. This is called Windows Update for Business (WUfB). That means our content is provided by Microsoft Update servers and we define the installation behavior like deferrals or even pause of feature or quality updates. The WUfB settings can be configured in Intune via Software Udpates. This article will not show details of the WUfB settings.

For successful servicing we need to make sure an internet break out with proper bandwidth capacity is available to support our devices. To prevent internet traffic congestion we can utilize Peer 2 Peer technologies like BranchCache and Delivery Optimization to optimize Windows 10 update delivery. In case of Windows Update for Business we need to focus on Delivery Optimization (DO).

You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based Windows Update servers.

How does Delivery Optimization work in detail?

First of all the published content must be chunked and hashed. Currently Microsoft supports the following content:

  • Windows Updates (Feature/Quality)
  • Drivers
  • Store Apps

The basic procedure is:

  1. Client A checks for Updates
  2. Client A gets download sources (MS content server and additional clients (peers) B, C, …
  3. Client A requests chunks from MS content server and peers B, C, …
  4. Client A verifies hashes of chunks and builds file from chunks
  5. Client A verifies complete file via hash

The clients will check-in to the Delivery Optimization cloud service as long as the content is valid in its cache. This is necessary to let DO service keep track of devices and let it distribute peer info to requesting clients.

The Delivery Optimization has multiple Download Modes and this is an important part for successful utilization of DO. It configures the logical grouping of devices based on certain criteria. In this example we set Download Mode to Group and we use a custom group ID. This custom Group ID can be delivered by DHCP as an Option ID with code 234 when using upcoming Windows 10 Version 1803.

Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization.

The custom group id delivered by DHCP for scoped devices will let us take control over the grouping. We can assign multiple DHCP scopes the same Group ID or different Group IDs. That’s how we build our device collections and control the peer 2 peer traffic even across NATs.

The DO Peer 2 Peer traffic is a direct TCP/UDP connection on port 7680.

DOFirewall

Now we can build effective groups aligned with our networking infrastructure to restrict P2P traffic to physical sites, multiple sites, subnets, what ever we want.

 

How to configure DO with Intune?

At time of this writing I’m using the Insider Preview for the upcoming Windows 10 Version 1803 to test and include settings which are really worth to mention in this context.

I won’t get into details about every available setting but I will show a complete setup to test DHCP Option ID as source for Group ID.

The custom group ID can be generated by PowerShell:

[guid]::NewGuid()

The custom OMA-URI to configure Download Mode to Group is:

Name: DODownloadMode
OMA-URI: ./Vendor/MSFT/Policy/Config/DeliveryOptimization/DODownloadMode
Data type: integer
Value: 2 (group)

With Windows 10 Version 1803 we can provide the Group ID as a DHCP Option ID with code 234. To configure the client to use DHCP option ID we need to configure the following OMA-URI:

Name: DOGroupIdSource
OMA-URI: ./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOGroupIdSource
Data type: integer
Value: 3 (DHCP Option ID)

Now we need to configure our DHCP infrastructure to provide the DHCP Option ID to our clients. In my example I use a Microsoft DHCP Server:

1. Set Predefined Options

 

MSDHCPpredefinedOptions

2. Configure the Predefined Options

MSDHCPpredefinedoptionsAdd

3. Confirm with OK

MSDHCPGroupIdValue

4. Configure Scope Options

MSDHCPScopeOptions

5. Set Custom Group ID as Option ID 234

MSDHCPScopeOptionsGroupId

6. Verify new Scope Option 234 DOGroupID

MSDHCPGroupIdOptionInScope

This would be enough to let all clients in the same DHCP scope group together and allow P2P traffic.

When testing DO in Virtual Machines I encourage you to configure the following additional settings:

  • DOMinFileSizeToCache to 1 MB to ensure caching with even small downloads
  • DOMinRAMAllowedToPeer to 1 GB to let VMs with small amount of RAM P2P
  • DOPercentageMaxForeDownloadBandwidth to limit manual Store download Bandwith (this will not restrict peer traffic) *
  • DODelayForegroundDownloadFromHttp to 30 seconds to give time to find other peers *

* Windows 10 Version 1803 is needed

Custom OMA-URIs:

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOMinFileSizeToCache = 1 (Integer, in MB)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOMinRAMAllowedToPeer = 1 (Integer, in GB)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOPercentageMaxForeDownloadBandwidth = 10 (Integer, in %)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DODelayForegroundDownloadFromHttp = 30 (Integer, in Sec.)

A test environment configuration may look like this:

DOMDMSettings

For production environments please review all available MDM Delivery Optimization settings and adjust as needed for your environment. For example DOMaxCacheAge, DOMinBackgroundQoS and DOPercentageMaxBackDownloadBandwidth might be from interest for production environments. Remember to check for new settings with every new Version of Windows 10!

 

Test to verify everything works as expected!

Make sure the settings are applied to the test devices. Generate a advanced diagnostic report:

Open Settings > Accounts > Access work or school > Connected to TenantName’s Azure AD > Info > scroll down to the bottom and click “Create report”

AdvancedDiagnosticsReport

Important settings to verify:

DOMDMReport

Test procedure:

On Client A start a download from the Store with 100MB+ download size and wait for finish. You should observe a throttled download when using VMs with setting DOPercentageMaxForeDownloadBandwidth.

On Client B start the same download from the Store and wait for finish. You should notice a significant faster download on Client B, as it will receive data from local peer without restrictions when tested with VMs and mentioned settings above.

Since Windows 10 Version 1803 we can generate a DO log file to trace the behavior:

Get-DeliveryOptimizationLog | ft -Wrap | Out-File -FilePath $env:temp\DOLogs.txt ; notepad $env:temp\DOLogs.txt

Get the log files from Client A and B and look for entry “Using groupID”, here you must find the DHCP Group ID in both logs:

DOLogFileGroupId

On Client B you will find stats regarding communication with Peer Client A on port 7680:

DOLogfilePeerUsage

If you like to test again you can use disk cleanup utility to clean the DO cache:

DODiskCleanup

Then uninstall the Store app and start the test over again.

 

Further information

 

Happy caching and a good P2P utilization!

How to disable SMBv1 with Intune [deep dive analysis]

I recently got motivated to research a bit about new MDM settings available in the latest Windows 10 Insider Build (17074) and how to configure them. Settings available in preview Windows 10 versions normally do not have a lot of technical documentation for it or there is even no documentation for a particular feature and corresponding setting at preview release time.

In this post I would like to show how to get the right pieces of information to configure an ADMX-backed policy setting in Windows 10 via Intune OMA-URIs with no technical documentation for it. We need to get all implementation details by our self. My goal is to show some of the inner workings how parts of the MDM policies are implemented and how we can get a deeper understanding of them.

I’ll demonstrate my analysis with some new Windows 10 latest Insider build settings (at time of writing build version 17074) derived from MSSecurityGuide to control SMBv1 on the device. The two settings are:

  • ConfigureSMBV1ClientDriver
  • ConfigureSMBV1Server

These settings control the SMB 1.0/CIFS File Sharing Support

Optional Feature SMBv1

 

How do we get to know this new available settings?

First we have a look at the registry. There is a new place where you can find MDM Policy CSP settings. Group Policy settings are stored in the Policies registry key and MDM Policy CSP settings can be found in the PolicyManager key here:

HKLM\SOFTWARE\Mircosoft\PolicyManager

As we see in the screenshot below there are two different sub keys. One current key and a default key.

Within the current key we find all settings configured for this device by Policy CSP via MDM like Intune. Within the default key we find all available settings for the particular Windows 10 release.

RegistryPolicyManagerDefault

As mentioned the latest Windows 10 version (at time of writing build version 17074) has a sub key for MSSecurityGuide with additional sub keys for ConfigureSMBV1ClientDriver and ConfigureSMBV1Server.

RegistryPolicyManagerSMBv1

If we have a look at the details, for example of ConfigureSMBV1ClientDriver we see the value name admxMetadataDevice. This gives us a hint that this particular policy is an ADMX-backed policy.

SMBv1ADMXHint

 

How do we configure it if we don’t know the input values for it?

The way Microsoft implemented the feature ADMX-backed policies is as follows:

A defined set of the default policies which come with the OS in the path C:\Windows\PolicyDefinitions are parsed at OS build time and stored in the MDM store as converted MDM policies. The second way is to ingest custom ADMX files after OS shipment which are then also parsed and stored in the MDM store as MDM policies. I wrote an ADMX file ingestion article for a custom OneDrive ADMX file here: Deep dive ADMX ingestion to configure SilentAccountConfig with OneDrive.

For a thorough understanding everyone should read the Background section of the Microsoft docs article Understanding ADMX-backed policies.

With all that in mind we need to find the original ADMX file for the policy and then we can derive the actual values for configuration because ADMX-backed policies are configured by a schema derived from the ADMX xml file structure.

Luckily I know that the MSSecurityGuide is provided by Microsoft through the Microsoft Security Compliance Toolkit 1.0 and within that package is the Windows 10 Version 1709 Security Baseline.zip. This includes the SecGuide.admx in the subfolder Templates.

SecGuideAdmx

Due to public knowledge how to configure ADMX-backed policies we can derive the configuration input values from the SecGuide.admx file. To derive the input values we need to study the article Understanding ADMX-backed policies especially the sections ADMX-backed policy examples and Sample SyncML for various ADMX elements.

To create the OMA-URI we append the registry key MSSecurityGuide and the sub key ConfigureSMBV1ClientDriver to ./Vendor/MSFT/Policy/Config/

./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1ClientDriver

Now we need to follow the Sample SyncML for various ADMX elements for proper Enum usage as input value to disable the SMBv1 Client driver

  1. find enum
  2. get name from id attribute
  3. choose value for disable

SecGuideAdmxXml

construct the xml data element with derived values for id and value:

<data id="Pol_SecGuide_SMB1ClientDriver" value="4"/>

The result is the following custom OMA-URI setting:

Name: ConfigureSMBV1ClientDriver
OMA-URI: ./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1ClientDriver
Data type: string 
Value:
<enabled/>
<data id="Pol_SecGuide_SMB1ClientDriver" value="4"/>

 

According to How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server the SMBv1 Server can be controlled by this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB1 REG_DWORD: 0 = Disabled

To disable the SMBv1 Server we need to set the registry value SMB10 and this is the disabled value in the SecGuide.admx xml file.

SecGuideAdmxXml2

The result is the following custom OMA-URI setting:

Name: ConfigureSMBV1Server
OMA-URI: ./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1Server
Data type: string 
Value: <disabled/>

Now we configure this as a custom OMA-URI in Intune and target it to our user group with Windows 10 Insider builds

SMBv1MDMOMAURI

 

How to verify if the settings are correctly deployed?

First of all we can generate a MDM Advanced Diagnostics Report:

Open Settings > Accounts > Access work or school > Connected to TenantName’s Azure AD > Info > scroll down to the bottom and click “Create report”

AdvancedDiagnosticsReport

open the Report MDMDiagReport.html it in Edge and look for:

MDMReport

Second we can check the registry for MDM applied settings:

SMBv1MDMSetting

Third we can verify the SMBv1 LanmanServer > Parameters > SMB1 = 0:

SMBv1ServerSetting

We can query the Windows feature if not enabled via PowerShell:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

SMBv1WindowsFeature

We can verify the SMBv1 Client and Server component via PowerShell:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

SMBv1ServerConfig

sc.exe query MRXSMB10

SMBv1ClientConfig

Congratulations you successfully disabled the SMBv1 protocol as recommended in the Security Baseline for Windows 10!

Important note

SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709
https://support.microsoft.com/en-us/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709

If a Windows 10 Version was upgraded from an earlier edition like RS2 to RS3, SMBv1 is not deactivated, the install state is migrated. SMBv1 will not be installed for fresh RS3 installations. The setting above would enforce uninstall of SMBv1 for migrated devices.

Further information

Deep dive ADMX ingestion to configure SilentAccountConfig with OneDrive

Since Windows 10 1703 you can use a feature called ADMX ingestion to extend policy settings in Intune. What it basically does is to parse an ADMX file and build a MDM policy of it. In the end you can configure the ADMX settings via OMA-URIs in Intune.

More details about ADMX ingestion can be read here Win32 and Desktop Bridge app policy configuration.

During the last time I’m working a lot in the field of Modern IT and Modern Workplace. In the Modern Workplace scenario I like to have Windows 10 clients joined to Azure Active Directory and auto enrolled into Intune (preferred as an AutoPilot enrollment). The nice thing here is, the device gets configured right after the Azure Active Directory join. In this scenario we typically configure necessary system settings. In addition to that I want to drive the user experience and I want to present the files in OneDrive without further sign-in by the user. Normally the user needs to sign-in with his email address to accomplish this.

OneDrivePrompt

To solve this we need to configure OneDrive to silently setup the user account information from the Windows signed-in user. According the article Use Group Policy to control OneDrive sync client settings we can use the following two registry keys for that:

HKCU\SOFTWARE\Microsoft\OneDrive\EnableADAL=1 (dword)
HKLM\SOFTWARE\Policies\Microsoft\OneDrive\SilentAccountConfig=1 (dword)

As we do not have a native Configuration service provider for OneDrive right now we need to configure these settings via ADMX ingestion policy. We can get the OneDrive ADMX from here:

%LocalAppData%\Microsoft\OneDrive\-build-version-\adm\OneDrive.admx

We need the original OnDrive.admx file as a template and we copy the complete policyDefinitions node to a new file. Then we remove every policy node except the policy node with SilentAccountConfig. As we have no node for EnableADAL in the ADMX file we duplicate policy node SilentAccountConfig as additional node under the policies node. In this new node we rename the attribute values “name” and “valueName” to EnableADAL. As last step we replace SOFTWARE\Policies\Microsoft\OneDrive with SOFTWARE\Microsoft\OneDrive.

The result is the following xml file:

<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://schemas.microsoft.com/GroupPolicy/2006/07/PolicyDefinitions">
 <policyNamespaces>
 <target prefix="OneDriveNGSC" namespace="Microsoft.Policies.OneDriveNGSC" />
 <using prefix="windows" namespace="Microsoft.Policies.Windows" />
 </policyNamespaces>
 <resources minRequiredRevision="1.0" />
 <categories>
 <category name="OneDriveNGSC" displayName="$(string.OneDriveNGSCSettingCategory)">
 <parentCategory ref="windows:Software" />
 </category>
 </categories>
 <policies>
 <policy name="EnableADAL" class="User" displayName="$(string.EnableADAL)" explainText="$(string.EnableADAL_Help)" key="SOFTWARE\Microsoft\OneDrive" valueName="EnableADAL">
 <parentCategory ref="OneDriveNGSC" />
 <supportedOn ref="windows:SUPPORTED_Windows7" />
 <enabledValue>
 <decimal value="1" />
 </enabledValue>
 <disabledValue>
 <decimal value="0" />
 </disabledValue>
 </policy>
 <policy name="SilentAccountConfig" class="Machine" displayName="$(string.SilentAccountConfig)" explainText="$(string.SilentAccountConfig_help)" key="SOFTWARE\Microsoft\OneDrive" valueName="SilentAccountConfig">
 <parentCategory ref="OneDriveNGSC" />
 <supportedOn ref="windows:SUPPORTED_Windows7" />
 <enabledValue>
 <decimal value="1" />
 </enabledValue>
 <disabledValue>
 <decimal value="0" />
 </disabledValue>
 </policy>
 </policies>
</policyDefinitions>

Why the replacement of \Policies\ in the registry path?

Excerpt from Win32 and Desktop Bridge app policy configuration

Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the following locations:

  • software\microsoft\onedrive

Because of this exception we can use SOFTWARE\Microsoft\OneDrive to configure the both keys. EnableADAL is listed under the registry key without \Policies\ but SilentAccountConfig is listed under \Policies\ path.

The path \Policies\ is based on the group policy technique where the sub key is used to overlap the default settings of an application. For example: SOFTWARE\Policies\Microsoft\OneDrive\SilentAccountConfig will overlap an application setting SOFTWARE\Microsoft\OneDrive\SilentAccountConfig. With the xml file above we target the application setting of OneDrive and not the policy setting of OneDrive (keep in mind the default value of OneDrive is overwritten then).

Why not using the whole OneDrive.admx file without \Policies? I’m not sure which of the settings all work without \Policies\ in the path. It depends on the targeted application. With further testing you may find settings working successfully like SilentAccountConfig with OneDrive. For me it was enough for now to have the EnableADAL and SilentAccountConfig settings configured.

In Intune we configure a Device Configuration Profile for Windows 10 as a Custom policy. We need to construct the OMA-URI for ADMX ingestion as described here: Win32 and Desktop Bridge app policy configuration

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}

Device Configuration Profile: ADMX Ingestion – CustomOneDrive.admx

DeviceConfigurationProfilesADMX

Name: CustomOneDrive.admx
OMA-URI:
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/OneDriveNGSC/Policy/OneDriveAdmx
Data type: string
Value: <xml content from above>

ADMXIngestion

The next step is to configure the ADMX ingested settings:

Again we follow the article Win32 and Desktop Bridge app policy configuration. Excerpt how to configure user or device policy:

In the policy class, the attribute is defined as “User” and the URI is prefixed with ./user. If the attribute value is “Machine”, the URI is prefixed with ./device. If the attribute value is “Both”, the policy can be configured either as a user or a device policy. 

The policy {AreaName} format is {AppName}~{SettingType}~{CategoryPathFromAdmx}. {AppName} and {SettingType} are derived from the URI that is used to import the ADMX file. In this example, the URI is: ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ContosoCompanyApp/Policy/AppAdmxFile01.

{CategoryPathFromAdmx} is derived by traversing the parentCategory parameter. In this example, {CategoryPathFromAdmx} is ParentCategoryArea~Category2~Category3. Therefore, {AreaName} is ContosoCompanyApp~ Policy~ ParentCategoryArea~Category2~Category3. 

Therefore, from the example: 

  • Class: User
  • Policy name: L_PolicyPreventRun_1
  • Policy area name: ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3
  • URI: ./user/Vendor/MSFT/Policy/Config/ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3/L_PolicyPreventRun_1

In Intune we configure a Device Configuration Profile for Windows 10 as a Custom policy with two custom settings. Important we need to specify EnableADAL as ./User to map it to HKCU and SilentAccountConfig as ./Device to map it to HKLM.

Device Configuration Profile: ADMX Config – CustomOneDrive.admx

DeviceConfigurationProfilesADMX

OMA URI Settings:

Name: EnableADAL
OMA-URI: ./User/Vendor/MSFT/Policy/Config/OneDriveNGSC~Policy~OneDriveNGSC/EnableADAL
Data type: string
Value: <enabled/>

EnableADAL

Name: SilentAccountConfig
OMA-URI:
./Device/Vendor/MSFT/Policy/Config/OneDriveNGSC~Policy~OneDriveNGSC/SilentAccountConfig
Data type: string
Value: <enabled/>

SilentAccountConfig

In the end we assign the device configuration profile to a user group and if applied successfully we will see OneDrive singed-in shortly after the Desktop appears:

OneDriveTaskbar

If you look into Start > Settings > Accounts > Access work or school > your Tenant > Info your should see Policy listed as: OneDriveNGSC~Policy~OneDriveNGSC as defined above.

CustomOneDriveConfigSettingsMenu

Special thanks to Mark for inspiring me to write about that topic my very first blogpost here.

Peter van der Woude has a good article about ADMX ingestion to configure Google Chrome site isolation.