Deploying Office 365 updates

Configuration Manager introduced support for Office 365 agents in Current Branch 1602, and Nomad introduced support in version 6.1.100. This section describes how Office 365 deployments differ in terms of ACP requirements and goes on to describe how Nomad behaves during the download.

Refer to Deploying updates for Office 365 for an example scenario about deploying Office 365 updates 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	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 to learn how to configure client settings to set Nomad as a download provider for applications and software updates.

How it works

The Office 365 Click to Run agent (CTR) will process the update metadata obtained from the Configuration Manager Software Update Point and pass a request for content to the Configuration Manager agent. As with non-Office download requests, the same Alternate Content Provider API is used by the Configuration Manager agent; with the Configuration Manager agent Content Transfer Manager (CTM) thread invoking Nomad to download the requested content. When Nomad receives a download job with a manifest file from the CTM it will:

1. Parse the manifest to retrieve the content description.

2. Download the content described in the manifest either from a DP or peer cache.

3. Copy the downloaded data to the destination folder described in manifest.

4. Notify Configuration Manager that the download job is complete.

5. Wait for the next job.

For Office 365 updates the CTM passes different information to Nomad, when compared with other types of content download. The other types typically provide a content identifier i.e. Package ID and version. For Office 365 updates, a manifest file is also passed with the request. It is the manifest file that contains details of the content to be downloaded and its destination path (typically C:\ProgramData\Microsoft\ClickToRun\...). A single update may require multiple download jobs, resulting in multiple manifests being passed to Nomad while it is obtaining the content. Once the content has been downloaded, it is copied into the destination specified in the manifest file. Nomad does not configure hardlinks for Office 365 updates.

Hash checking and communication with the CTR agent

Another difference is that Office 365 updates do not have a Configuration Manager-generated hash associated with the content. For other types of content, Nomad performs an AES256 hash check prior to, and immediately after, download and compares this with the Configuration Manager hash in order to establish the content's validity. For Office 365 updates, there is no comparison hash made available to Nomad. Nomad therefore depends on the CTR for the validity status of the Office 365 update installation (the CTR performs its own hash check). Nomad also listens to the status API exposed by the CTR agent to check if the installation succeeded. If the installation fails, Nomad deletes the update from its cache and retries the download. As soon as Nomad receives a download success status, it sends a status message and stops listening to the CTR agent.

Byte-ranges

In order to make the download process more efficient, Microsoft has implemented a process of byte-range requests rather than (or sometimes in addition to) requesting entire files. Nomad treats byte-range requests in just the same way as files and will initiate a local election for each to minimize the impact of any download across the WAN.

To process and download these byte-ranges, Nomad divides each Office 365 package file into pages of 128MB, for example a 300MB file has 3 logical pages. If we think of a file as a book, then each page of the book is 128MB with each line of a page being 32KB. The byte-ranges described in the manifest indicates the start and end position within our lines of the page. Nomad normalizes these byte-ranges to 32KB blocks, adjusting the start and end positions so that the byte-range contains complete lines and no line is truncated.

Nomad elections

Elections may occur when a Nomad client requires content that is not resident in its cache. An election is not always necessary, with Nomad storing active download broadcast notifications in memory and then connecting direct to these hosts if itself requires the byte-range or file at some later time. All responses peers receive are stored in its Query Result Store (QRS). Before initiating an election, a Nomad client will first verify its QRS to see if relevant peers are available for content downloads. If relevant peer(s) are found in the query store, an election does not occur.

When elections do occur and Nomad clients respond, the receiving Nomad client sorts the list of responders top-down based upon the following criteria:

• Longest byte-range on disk starting from requested offset.

• Longest relevant active downloader.

• Election weighting.

• NomadBranch service start-up time.

• Machine name.

Under certain circumstances, a Nomad client will not reply to an election request, even if it has the data in its cache. This happens when:

• Request comes from an inhibited network.

• P2P SMB is disabled [Connectionless mode is not supported for Office 365 update deployments].

• The Nomad Account (SMSNomadP2P&) is locked out.

• The Nomad Account (SMSNomadP2P&) is not active.

• The machine is a domain controller and SPECIALNETSHARE_MACHINEACCOUNT is not set in SpecialNetShare.

• The P2PElectionWeight registry value is set to zero.

• The Nomad share not available.

Which other Nomad features are supported by the Nomad Office 365 feature?

The following Nomad features are supported:

Nomad feature	Definition
Peer copy over HTTP or HTTPS	Nomad can be used to enable the Office 365 update byte-range request content to be shared amongst Nomad peers.
Single Site Download	SSD can be used to locate byte-range request content across different subnets on the local branch.
Peer-to-peer SMB	Peers can download data from other peers using the SMB protocol.
Work rates and cache priority	Work rates determine the amount of bandwidth Nomad utilizes for the download and cache priority determines when the cache is purged. Refer to Nomad tab.
DownloadTimeout	The timeout in seconds after which a job will be cancelled if the download has not been successful.
Save and restore Nomad cache	Custom task sequence action to Save Nomad Cache either in WinPE or a full Microsoft Windows operating system and a custom task sequence action to Restore Nomad Cache in the new Operating System during provisioning after Nomad has been installed.
Status messages for download events	Status messaging for specific download events. Refer to StatusMsgEvents.
Inhibiting subnets and sites	Defining subnets and AD sites where machines download from the DP and not participate in Nomad elections (status messages are not relayed).
SpecialNetShare	Options for the Nomad share.
Custom ports	Enables the use of custom ports for data transfer and communications.
Cache cleaning	Enables cache management. Refer to Cache management.

The following are not supported by the Office 365 feature:

• Cloud-based DP.

• Connectionless P2P.

• Nomad FanOut

• SMB downloads from the DP.

• Remote differential compression (RDC) integration

• Nomad Pre-caching

• Hash or CRC validation.

• LSZ or metadata creation or download.

• Failover to BITS (SuccessCodes includes 0x9999).