Introduction à Windows Update Delivery Optimization (WUDO)
Présentation et objectifs de WUDO
Windows Update Delivery Optimization (WUDO) est une technologie d’optimisation de distribution de contenu introduite par Microsoft pour Windows 10 et Windows 11. Son objectif principal est de réduire la bande passante Internet consommée lors du téléchargement de mises à jour Windows, des mises à niveau (feature updates) ou d’applications Microsoft Store, en s’appuyant sur un mécanisme de partage peer-to-peer (pair-à-pair) entre appareils. Concrètement, au lieu que chaque poste télécharge individuellement une mise à jour depuis les serveurs Microsoft, WUDO permet aux machines d’un même réseau local de s’échanger des portions de la mise à jour, de sorte qu’un poste ayant déjà téléchargé la mise à jour puisse en fournir une partie aux autres. Ce procédé accélère les déploiements (les téléchargements peuvent se faire depuis le réseau local, plus rapide que le WAN) et allège fortement la charge sur la connexion Internet de l’entreprise.
WUDO s’inscrit dans une évolution du modèle traditionnel de distribution de mises à jour. Historiquement, en environnement d’entreprise, des serveurs locaux (tels que WSUS ou des points de distribution Configuration Manager) étaient utilisés pour limiter l’usage de la bande passante WAN. Avec l’adoption croissante de services cloud (Windows Update for Business, Microsoft Intune, etc.), WUDO offre une solution distribuée côté clients : chaque poste Windows peut à la fois télécharger et servir du contenu. Microsoft présente WUDO comme un cache distribué intelligent capable de partager la charge du téléchargement sur plusieurs sources, afin de soulager les points de sortie Internet de l’entreprise et d’augmenter la vitesse effective de téléchargement.
Le principe est optionnel et contrôlé par l’administrateur : si WUDO est activé, les appareils Windows continueront de contacter les serveurs Windows Update mais pourront en parallèle obtenir les données depuis des pairs (autres PC) du réseau local ou via un cache d’entreprise, si disponible (What is Delivery Optimization? | Microsoft Learn) (What is Delivery Optimization? | Microsoft Learn). En somme, les objectifs de WUDO sont la réduction de la consommation de bande passante Internet, l’accélération des mises à jour grâce au LAN, et une distribution plus efficace et évolutive des contenus Windows au sein d’un parc.
Architecture et mécanismes internes
Pour atteindre ces objectifs, WUDO repose sur une architecture combinant un service cloud et des mécanismes locaux sur chaque client Windows. Chaque appareil Windows intègre le composant client Delivery Optimization (service DoSvc), qui pilote les téléchargements optimisés. Lorsqu’un appareil doit télécharger un contenu (patch Windows Update, application Intune, etc.), le processus se déroule en plusieurs étapes : obtention des métadonnées, recherche de sources potentielles, puis téléchargement simultané depuis ces sources multiples.
(Deep Dive into delivery optimization – AI & Modern Device Management) Figure : Architecture simplifiée de Windows Update Delivery Optimization. Le PC “Client A” obtient l’URL de téléchargement de la mise à jour via Windows Update (étape 2) puis récupère les métadonnées du contenu (3) depuis le CDN Microsoft. Le client interroge ensuite le service cloud Delivery Optimization (4) pour découvrir d’autres machines locales (“Client B” et “Client C”) ayant déjà des segments de ce contenu. Enfin, “Client A” télécharge les données en pair-à-pair depuis ces machines (5, 6) sur le réseau local, réduisant ainsi l’utilisation de la connexion Internet. (Deep Dive into delivery optimization – AI & Modern Device Management) (Deep Dive into delivery optimization – AI & Modern Device Management)
Le service cloud Delivery Optimization joue un rôle de coordination. Quand un client Windows initie un téléchargement, il contacte ce service cloud afin d’obtenir une liste de pairs appropriés susceptibles de posséder déjà le contenu requis. La sélection de pairs tient compte du contexte réseau : par défaut, le service retourne uniquement des machines qui partagent la même IP publique (c’est-à-dire probablement sur le même site/réseau local derrière le même NAT) (Delivery Optimization reference | Microsoft Learn). Ce fonctionnement par découverte via le cloud évite aux clients de devoir diffuser des requêtes localement et utilise la connaissance qu’a Microsoft des appareils en ligne téléchargeant ses mises à jour. En plus des pairs, le service cloud peut indiquer si un cache d’entreprise (Microsoft Connected Cache) est disponible (nous y reviendrons dans un article ultérieur). Le client dispose ainsi d’une liste de sources potentielles pour le contenu : d’autres PC du LAN, éventuellement un cache local, et en dernier recours les serveurs de Microsoft (CDN Windows Update).
Côté client, WUDO segmente le fichier à télécharger en blocs (typiquement de 1 Mo) et tente de télécharger ces blocs en parallèle depuis les différentes sources disponibles. Chaque bloc est identifié de manière unique par un hash cryptographique SHA-256 présent dans les métadonnées du contenu (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Grâce à ces métadonnées signées, le client peut vérifier l’intégrité de chaque bloc reçu et s’assurer qu’il correspond bien à la mise à jour attendue. BITS (Background Intelligent Transfer Service), historiquement utilisé pour les téléchargements en tâche de fond de Windows Update, est toujours employé en mode fallback, mais le mécanisme WUDO dispose de sa propre logique optimisée. WUDO utilise HTTP/HTTPS pour les transferts depuis des sources Web (CDN ou cache) et un protocole propriétaire sur TCP 7680 pour les transferts P2P entre machines (Delivery Optimization Frequently Asked Questions | Microsoft Learn). Une fois tous les blocs obtenus (via n’importe quelle combinaison de pairs locaux ou source distante), le client recompose le fichier complet et le remet au composant appelant (le service Windows Update, Intune, etc.) qui en vérifiera à nouveau la signature globale avant installation, comme pour tout correctif Microsoft (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn) (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn).
Modes de distribution et paramétrage
WUDO offre plusieurs modes de fonctionnement configurables, permettant d’ajuster l’étendue du partage P2P selon les besoins et contraintes de l’organisation. Microsoft définit ces modes via la stratégie Download Mode (paramètre DODownloadMode) (Delivery Optimization reference | Microsoft Learn) :
- Mode HTTP uniquement (0) : WUDO est actif en tant que gestionnaire de téléchargement efficace (utilisant des métadonnées, etc.) mais désactive complètement le peer-to-peer. Les clients téléchargent uniquement depuis la source HTTP d’origine (Windows Update, Microsoft Store…) ou un cache connecté s’il est configuré (Delivery Optimization reference | Microsoft Learn). Ce mode équivaut à n’utiliser WUDO que pour son moteur de téléchargement optimisé, sans partage entre pairs.
- Mode LAN (1) (par défaut) : Le mode par défaut autorise le partage entre pairs sur le même réseau local. Plus précisément, le service cloud considérera comme pairs éligibles les machines ayant la même IP publique que le client demandeur (Delivery Optimization reference | Microsoft Learn). Cela signifie que les PC derrière le même routeur/NAT (par exemple dans le même site ou même sous-réseau d’entreprise) pourront s’entraider. Aucun peering avec des appareils extérieurs à ce périmètre ne sera effectué.
- Mode Groupe (2) : Ce mode étend le périmètre en créant des groupes de partage au-delà du simple subnet. Par défaut, Microsoft regroupe les appareils soit par site Active Directory (pour les PC joints au domaine AD DS, Windows 10 v1607+), soit par domaine Active Directory (Windows 10 v1511), soit encore par tenant Microsoft Entra (Azure AD) (Delivery Optimization reference | Microsoft Learn). Tous les PC appartenant au même groupe logique pourront se partager du contenu, même s’ils ne sont pas sur le même subnet IP. Il est également possible de définir un groupe personnalisé via un ID (policy Group ID) pour regrouper des machines spécifiques, y compris inter-domaines (Delivery Optimization reference | Microsoft Learn) (Delivery Optimization reference | Microsoft Learn). Le mode Groupe est recommandé pour la plupart des organisations cherchant la meilleure optimisation de bande passante, car il permet le partage intersites tout en restant dans le réseau de l’entreprise (Delivery Optimization reference | Microsoft Learn). En revanche, il nécessite que les clients puissent communiquer (ports ouverts, routage) entre sites ou segments du groupe.
- Mode Internet (3) : Ce mode autorise le partage avec des pairs sur Internet. Les appareils peuvent échanger des données avec d’autres PC ne faisant pas partie du réseau local ou du domaine – potentiellement n’importe quel PC Windows 10/11 sur Internet utilisant WUDO. En entreprise, ce mode est rarement utilisé pour des raisons de sécurité et de confidentialité (les organisations préfèrent en général ne pas échanger de trafic avec des machines inconnues sur Internet), sauf éventuellement pour des sites isolés où peu de machines locales peuvent se partager les données.
- Mode Simple (99) : Ce mode désactive complètement le service cloud Delivery Optimization et le P2P, et revient à un téléchargement classique HTTP(s) depuis la source d’origine (Delivery Optimization reference | Microsoft Learn). Il est automatiquement utilisé en environnement offline ou restreint (par exemple si le service cloud DO est injoignable ou si la taille du fichier est inférieure à 10 Mo), afin de garantir tout de même le téléchargement. On peut le forcer via la stratégie pour des postes qui n’ont pas d’accès Internet direct.
- Mode Bypass (100) : Ce mode, désormais obsolète à partir de Windows 11, ordonnait au client de ne pas utiliser WUDO du tout et de repasser par BITS uniquement (Delivery Optimization reference | Microsoft Learn). Microsoft déconseille son usage (il peut causer des erreurs de téléchargement) et préconise plutôt HTTP uniquement (0) pour désactiver le P2P tout en gardant les avantages de WUDO, ou Simple (99) si la machine n’a vraiment pas Internet (Delivery Optimization reference | Microsoft Learn).
En complément de ces modes, l’administrateur dispose de nombreux paramètres de stratégie pour ajuster le comportement de WUDO. Par exemple, il est possible de définir une taille de cache locale maximale (% du disque ou en Go), le seuil minimum de RAM ou d’espace disque pour qu’un appareil participe au partage (par défaut un PC doit avoir ≥4 Go de RAM et ≥32 Go de disque pour être pair (Delivery Optimization reference | Microsoft Learn)), le taux maximal de bande passante utilisé en arrière-plan, etc. Par défaut, le cache local de WUDO peut utiliser jusqu’à 20% de l’espace disque disponible sur le PC (Delivery Optimization reference | Microsoft Learn), ce qui est généralement transparent compte tenu de la taille des disques actuels, mais ce ratio peut être ajusté ou plafonné en GB si besoin. La configuration de WUDO s’effectue via des stratégies de groupe (GPO) sous Windows Components/Delivery Optimization ou via un MDM/Intune (CSP DeliveryOptimization), ou encore via le registre pour des ajustements fins.
Optimisation de la découverte locale avec DNS-SD
Initialement, la découverte de pairs locaux par WUDO reposait principalement sur le service cloud (identification par IP publique commune) ou sur les groupes AD/AAD définis (mode Groupe). Avec les versions récentes de Windows, Microsoft a introduit une amélioration pour optimiser la détection de pairs sur un réseau local : la découverte via DNS-SD (DNS Service Discovery). L’idée est de permettre aux appareils d’annoncer et découvrir localement la présence de contenu mis en cache, sans dépendre uniquement de la connaissance du service cloud, ce qui réduit la latence et la dépendance à Internet pour trouver des pairs déjà présents sur le LAN.
Concrètement, avec DNS-SD activé, un client va utiliser le protocole de découverte de service DNS multicast sur le réseau local pour trouver d’autres machines exécutant WUDO et possédant le contenu cible. Ce mécanisme s’appuie sur la norme DNS-SD (décrite par la RFC 6763) qui permet une découverte locale zéro-configuration. Microsoft a ajouté une option de stratégie Restrict Peer Selection By permettant de restreindre la sélection de pairs aux seuls pairs découverts via DNS-SD (What’s new in Delivery Optimization | Microsoft Learn) (What’s new in Delivery Optimization | Microsoft Learn). En activant l’option Local Peer Discovery (valeur 2 de DORestrictPeerSelectionBy), le client n’interroge plus le service cloud pour obtenir des pairs, il se limite aux annonces DNS-SD locales. Cette fonctionnalité, introduite en preview sur Windows 10 (via une clé de registre) et officiellement sur Windows 11, améliore la confidentialité et réduit le trafic sortant vers Microsoft tout en augmentant potentiellement le nombre de pairs locaux découverts (Deep Dive: Delivery Optimization Troubleshooting & Reporting – MSEndpointMgr) (Deep Dive: Delivery Optimization Troubleshooting & Reporting – MSEndpointMgr). En effet, certaines topologies réseau complexes (multiples NAT, VLANs) peuvent empêcher le service cloud de bien regrouper tous les clients appropriés, alors que la découverte locale multicast peut mieux les détecter s’ils sont dans le même domaine de diffusion.
Il convient de noter que le DNS-SD pour WUDO doit être explicitement activé via stratégie MDM (sous Windows 11, ou via registre sur Windows 10) (What’s new in Delivery Optimization | Microsoft Learn). Une fois activé, chaque client annonce sur le réseau local les contenus qu’il peut partager, et découvre les annonces des autres. Cela complète avantageusement le mode de découverte standard : en environnement d’entreprise, on peut ainsi réduire la dépendance au cloud tout en maintenant un partage local efficace. En somme, l’optimisation de la découverte locale avec DNS-SD permet à WUDO d’être plus autonome sur les réseaux internes, d’augmenter le pool de pairs potentiels et de diminuer les sollicitations aux services Microsoft pour l’orchestration – tout en conservant un contrôle sur le périmètre (puisque ces annonces restent locales par design).