Downloading content for CM Software Updates from Microsoft Update

This feature enables Nomad to download content from Windows Update / Microsoft Update (WUMU). Starting in CB version 1806, software updates can be deployed to devices without first downloading and distributing content to Distribution Points, instead clients download updates directly from the cloud.

Refer to Deploying software updates using Configuration Manager for an example scenario about deploying software updates using CM and how you can monitor those deployments using the Content Distribution app.

Configuration

Downloading the following type of updates is enabled by default in the Nomad client (1E Client 4.1 and later). Downloading from Microsoft Update is also enabled by default. Refer to Downloading content for CM Software Updates from Microsoft Update.

The settings are defined in CompatibilityFlags and you will need to ensure the relevant bits remain set if you are using that registry value to configure other options, as follows:

Type

Enable Nomad to download

Enable Nomad to download from Microsoft Update

Software Updates (including Windows 10 feature updates)

Always enabled

Set bit 27 (0x08000000, 134217728 in decimal)

Office 365 updates (Refer to Deploying Office 365 updates.)

Always enabled

Set bit 28 (0x10000000, 268435456 in decimal)

Windows 10 Express Installation Files and Delta Content for Updates

Set bit 26 (0x04000000, 67108864 in decimal)

Set bit 28 (0x10000000, 268435456 in decimal)

To enable all the above, then AND bits 26, 27 and 28 with whatever you have already set in CompatibilityFlags.

Please refer to Enabling Nomad for Applications and Software Updates for how to configure client settings to set Nomad as a download provider for applications and software updates.

Please note, there is no configuration is required on Distribution Points.

How it works

Configuration Manager and Microsoft Updates

Configuration Manager supports Windows Update / Microsoft Update (WUMU) cloud service as a content location for Software Update deployments.

When creating a deployment of a software update, on the Download Settings page you can configure the setting If software updates are not available on distribution point in current, neighbor or site boundary groups, download content from Microsoft Updates. Enabling this setting means intranet-connected clients will download software updates from Microsoft Update if updates aren't available on Distribution Points. Internet-based clients always go to Microsoft Update for software updates content. This setting is beneficial when dealing with extremely large update content and if you want clients to always get content from the Windows Update / Microsoft Update (WUMU) cloud service. This feature supports any update type supported by Configuration Manager software updates management, including Windows and Office updates.

Nomad and Microsoft Updates

Before the introduction of this feature in Nomad 7.0, if Configuration Manager client Content Transfer Manager (CTM) asked Nomad to get a download job from WUMU, it used to fail the job with error code ERROR_UNKNOWN_TRANSPORT 0x2059, which notifies E_FAIL to CTM. Nomad does this because it expects CTM to take over the download using BITS. With the introduction of this new feature in Nomad 7.0, Nomad client can now manage the content download from WUMU, and use Nomad's P2P feature to download content from peers that already have the necessary content.

At the time of writing CB 1902, and therefore Nomad, does not support Windows Update for Business.

Compatibility with Distribution Points

WUMU is treated as just another Distribution Point and features like DP resilience would work as expected. If Nomad was for example, downloading an update from a DP and encountered an issue in reaching the server, then it would continue the download from WUMU (if configured) from wherever it was interrupted.

Hash validation

When downloading from a Distribution Point, Nomad client retrieves the LSZ file and does a full hash validation of the update as well, because Nomad on a DP can retrieve it and keep it in LSZ file. Individual files are validated against HASH fetched from URL’s, but the whole update is not validated together as the full Hash of the update isn’t available anywhere in WMI.