Update management is an increasingly important topic in modern technology. ‘Cloud cadence’ and ‘as a Service’ approaches mean that there is almost constant change. Change is delivered in the form of updates, and updates can be both large and regular.
Delivered under the banner of Windows Update for Business, Windows 10 includes a feature to help with update management - Delivery Optimization (or DO, or WUDO, for short). And for those of you who know me well, yes, it pains me to write the Americanised version of optimisation, but that’s its name, in the same way as that other product with an Americanised name: System Center.
Anyway.
Delivery Optimization provides Windows 10 with the facility to update on a peer to peer basis – Windows 10 client to Windows 10 client - and can supplement existing enterprise update mechanisms, such as WSUS. Peers can be local to your network or external to it, on the internet, and controls are provided to ensure that updates are obtained from a location you’re comfortable with.
A Brief History
Delivery Optimization was introduced into Windows 10 in v1511. As with many aspects of Windows 10, subsequent feature updates have brought enhancements to the initial rudimentary capability and the improvements included with v1607 and v1703 combine to give the level of granular control required in our environments.
Prior to Delivery Optimization, BITS (Background Intelligent Transfer Service) would have been used to deliver updates to clients, and in more complex deployments extended capabilities such as BITS peer caching may have been employed.
Cloud Service
Despite the updates being delivered peer to peer, Delivery Optimization is actually a cloud service. A service runs on the local client and communicates with the cloud service at the following URLs, over ports 80 and 443:
https://geo-prod.do.dsp.mp.microsoft.com/geo
https://geover-prod.do.dsp.mp.microsoft.com/geoversion
So obviously it’s important to ensure these URLs are accessible through your firewall. It’s probably best to allow *.do.dsp.mp.microsoft.com to be on the safe side.
The cloud service is used for peer discovery and management; this approach is necessary for those who wish to enable the option to obtain updates from internet based peers, and has the advantage over the likes of BranchCache which uses broadcast to identify peers. Broadcasts are contained to the subnet, so wouldn’t work for a service that has the option to stretch way beyond the local network.
The service is also used to verify the authenticity of each payload obtained from a peer, to ensure it is a valid update. The same security measures as obtaining the update from Windows Update are used, and by extension those are the same measures as used by WSUS.
Once a suitable peer is identified, peer to peer connectivity takes place over port 7680, and if you look in Windows Defender Firewall you’ll see two entries – one each for TCP and UDP inbound. Teredo port 3544 is used for NAT traversal – which may be necessary for a peer connecting from another network segment, or over the internet.
Default Configuration
Delivery Optimization is on by default in Windows 10, but the default configuration differs between the editions. With Education and Enterprise, the default is for peer sharing on the same network only, with the DO service identifying peers on the same network as those connecting to the internet with a common public IP address.
The setting controlling DO behaviour is DODownloadMode. The value that sets LAN only peer sharing is 1, with other values available being 0, 2, 3, 99 and 100. DO remains the preferred mechanism in some form with all values except for 100, which is bypass mode and re-enables BITS. 0 doesn’t switch off DO, but instead disables peer to peer caching, allowing updates to be obtained from Windows Update or WSUS.
Natively, Education and Enterprise editions are configured to consume updates from peers but are not configured to act as a peer cache – i.e. serve updates to other peers.
Controlling Configuration and Selecting Caching Peers
There are a number of granular configuration options available to facilitate control over how DO behaves on managed devices:
With a few notable exceptions (Group ID, Max Download Bandwidth, Percentage Max Download Bandwidth, Allow VPN Peer Caching), the majority of the configuration options are provided to control how the peer behaves as a cache for other peers to obtain updates from.
A lot of administrators would no doubt be concerned that unsuitable devices would be used as cache devices, and that would impact their intended daily use as an end user device. With some careful configuration of the available group policy settings, and perhaps even different policies applied in a more targeted way, devices on the LAN can be selected for caching.
The obvious choice for caching peers is the higher specification client. Policy settings such as DOMinDiskSizeAllowedToPeer and DOMinRAMAllowedToPeer can be used to ensure devices with a specification above the administrator defined threshold become caching peers, although of course careful consideration should be given to the purpose of any high specification device – there may be some specialist purpose devices that meet the requirements for caching but you don’t want to fulfil that role. For any such device, ensure they are excluded from the general DO policy.
A more targeted approach can also be used to set preferred caching peers. DOMaxCacheAge, if set with a value of 0 (unlimited), will ensure that device is used more often as a source by other peers.
There is one important thing to remember with regard to peer caches though – the peer only caches updates that are relevant to it, so the more mixed the estate, the more careful planning is likely to be required to execute effective Delivery Optimization.
Activity Monitoring
Once configured and operational, DO is largely invisible to the user of the client on which it is running. If you hadn’t heard of it before reading this blog and you use a Windows 10 client, that gives you an idea of how it’s hiding away, under the covers. Did you know it was enabled on your device?
For the more inquisitive user and administrators there is a simple activity monitor that gives some statistical information on how the client is utilising DO. The activity monitor can be found in Settings, Update & Security, Windows Update, Advanced Options, Delivery Optimization, Activity Monitor.
I took this screenshot from one of my Windows 10 devices, which is running Windows 10 Enterprise in the default configuration and is also configured to obtain updates from Windows Update. The results are not stunning, but that’s probably because the device is mobile and hasn’t spent as much time as usual during the sample timeframe on a network where it’s likely to be able to find a caching peer – and there isn’t likely to be much of a DO infrastructure on the LAN it is connected to. Remember, the default for Enterprise (and Education) is to only use LAN-based caching peers, so it’s interesting that even in an environment not deliberately configured to maximise update efficiency with DO nearly 8.5% of updates have come from one or more peer cache.
There are also statistics for upload, for when a device is operating as a cache for other peers to obtain updates from. As my client is in the default configuration, there’s nothing to see here:
That’s all fine for the device owner and an administrator looking at an individual device, but what about a broader view of what’s happening with the DO infrastructure on the LAN? There isn’t a network-wide monitoring capability at the moment, but Windows 10 v1703 did introduce a couple of PowerShell cmdlets (Get-DeliveryOptimizationStatus and Get-DeliveryOptimizationPerfSnap) that could be leveraged to collate individual client data centrally and facilitate that broader analysis a network administrator may desire.
Serverless: Life after WSUS
Many networks still have a WSUS server for issuing updates to clients and providing efficient management of update downloads from external sources such as Windows Update. DO starts to change that well established position, even though in the short term it’s highly likely that most, if not all, updates will still be obtained from the WSUS server.
So why introduce DO? Well, in a nutshell, it fits with the concept of modern management and ultimately can remove the dependency on a server to manage and control update delivery. One argument put forward today is that the only way to efficiently manage update downloads and not have every client downloading updates individually is to use WSUS. A well-designed deployment of DO can firstly supplement that existing WSUS server, and eventually replace it. Achieving that may take a shift in thinking too; DO and WSUS capabilities are not identical, but DO does do what it sets out to do – it makes the sharing of updates efficient, and reduces the impact on internet bandwidth while using peer to peer technology to remove any dependency on a server.
What it doesn’t do, when paired with Windows Update, is provide granular control over which updates are in play. And that’s where the potential change of thinking needs to come; the frequency of change, and the cumulative nature of updates means that the traditional approach of being selective over which updates to apply is becoming outdated and arguably that level of control is no longer required.