Delivery Optimization : comprendre le téléchargement multi-source, le P2P et Microsoft Connected Cache

L’essentiel

Delivery Optimization, souvent abrégé DO, ne décide pas quelle mise à jour ou quelle application doit être installée. Le caller — Windows Update, Microsoft Store, Intune, Microsoft 365 Apps, Edge ou un autre composant compatible — demande un contenu. DO prend ensuite en charge son transport et choisit les sources disponibles selon les stratégies, le réseau, le coût de la connexion, l’énergie, la mémoire et le disque.

Le téléchargement peut associer la source HTTP ou CDN, un nœud Microsoft Connected Cache et des pairs Windows. Le pair-à-pair reste facultatif. Le mode 0 désactive le P2P tout en conservant le moteur DO, ses métadonnées et ses contrôles d’intégrité. Il ne faut donc pas présenter ce mode comme une désactivation des mises à jour.

Chaque bloc reçu d’un pair est vérifié avec les métadonnées de hachage du contenu avant son utilisation. Un poste voisin ne devient pas une source de confiance générale et ne partage pas les fichiers personnels de l’utilisateur. Le protocole P2P est un protocole binaire propre à DO sur TCP 7680. Il n’utilise ni SMB, ni partage UNC, ni multicast.

Microsoft Connected Cache apporte une source locale persistante, utile lorsque les postes sont peu nombreux, souvent arrêtés ou régulièrement réinitialisés. MCC complète les pairs. Il ne remplace ni Intune, ni Windows Update, ni Configuration Manager, et son état Healthy ne prouve pas à lui seul que les clients y téléchargent des octets.

Le point à retenir: Delivery Optimization transporte le contenu. Le service qui appelle DO conserve la responsabilité du ciblage, de l’approbation, de l’échéance et de l’installation.

Pourquoi cette technologie existe

Une vague de mises à jour Windows, une réimagerie ou un lot Autopilot peut demander plusieurs fois les mêmes gigaoctets sur une liaison WAN. Un téléchargement strictement individuel depuis Internet fonctionne, mais il répète le trafic pour chaque appareil. DO réduit cette répétition lorsque plusieurs clients ont besoin du même identifiant de contenu dans une fenêtre suffisamment proche.

Le problème n’est pas limité aux mises à jour du système. Selon la version de Windows et le caller, DO transporte aussi des applications Microsoft Store, des définitions Defender, des applications Win32 Intune dans le cloud public, des mises à jour Microsoft 365 Apps, Edge, des mises à jour dynamiques et certains contenus Configuration Manager. Le support du transport HTTP, du P2P et de MCC n’est pas identique pour chaque type de contenu.

Le cache local d’un poste permet à ce poste de fournir plus tard des blocs déjà validés. Cette source disparaît toutefois avec un effacement, un nettoyage de cache ou l’arrêt prolongé de l’appareil. MCC répond à un autre besoin: conserver une copie locale indépendante du cycle de vie des endpoints et la servir à plusieurs vagues successives.

Le bénéfice réel se mesure en octets venant des pairs ou de MCC, en réduction du trafic CDN et en temps de téléchargement. Une configuration peut être techniquement correcte et produire peu d’économie si les appareils ne demandent pas le même contenu, si les fichiers sont sous le seuil de cache, si les seeders s’éteignent ou si les vagues sont trop espacées.

Illustration publiée par l’équipe Microsoft Intune Customer Success. Les choix de configuration doivent ensuite être validés avec les versions de Windows, les types de contenus et la topologie du réseau concernés.

Architecture, composants et flux de données

Le caller remet au client DO les informations du contenu à récupérer. Le client contacte ensuite les services cloud DO pour obtenir sa configuration, la géolocalisation utile et la correspondance des pairs admissibles. Il évalue en parallèle les stratégies locales, la nature du réseau, l’état du poste et les sources déjà connues.

Le service cloud rapproche les appareils à partir de l’identifiant du contenu, du GroupID, de l’adresse IP externe, de la proximité et de caractéristiques du transfert. Il ne transfère pas lui-même les blocs entre les postes. Le trafic P2P circule directement entre les clients sur TCP 7680 à l’intérieur des frontières autorisées.

DO ne suit pas une séquence fixe dans laquelle il essaierait toujours les pairs, puis MCC, puis le CDN. Il réévalue les sources pendant le téléchargement. Les délais HTTP et MCC peuvent favoriser une source locale, mais un délai excessif ralentit le repli quand aucun pair ou aucun bloc de cache n’est réellement disponible.

Le cache client conserve les contenus admissibles jusqu’à expiration ou jusqu’à ce que Windows récupère de l’espace. La taille maximale n’est pas une réservation permanente. Après un téléchargement réussi, DOMaxCacheAge vaut par défaut 259200 secondes, soit trois jours, et DOMaxCacheSize correspond par défaut à 20 % selon la stratégie et la version.

MCC se place au plus près des clients. Les postes le découvrent par DOCacheHost, par l’option DHCP 235 ou selon la combinaison documentée des deux méthodes. Le nœud obtient le contenu Microsoft à la première demande, le conserve, puis répond localement aux demandes suivantes compatibles.

Prérequis, compatibilité et limites de support

Le premier prérequis est le support du contenu par le caller. Les mises à jour Windows, les applications UWP du Store et les définitions Defender prennent en charge HTTP, P2P et MCC sur les versions documentées. Les applications Win32 Intune prennent en charge le P2P et MCC dans le cloud public, tandis que les applications Win32 du Store ou Windows Package Manager utilisent DO sans annoncer les mêmes sources locales.

Les clients doivent atteindre les services DO en HTTPS et les endpoints de métadonnées nécessaires. Les noms comprennent notamment *.do.dsp.mp.microsoft.com, *.dl.delivery.mp.microsoft.com et *.windowsupdate.com. Les adresses IP ne doivent pas être figées car Microsoft peut modifier l’infrastructure qui répond à ces FQDN.

Le proxy doit préserver les requêtes HTTP Range et les réponses 206 Partial Content. Les en-têtes Range, Content-Range et Accept-Ranges font partie du fonctionnement. Une inspection TLS incompatible avec le certificate pinning peut laisser le CDN accessible tout en empêchant la géolocalisation, la découverte de pairs ou l’initialisation MCC.

Le P2P exige TCP 7680 entre les appareils qui doivent réellement communiquer. Les modes Groupe et Internet peuvent aussi s’appuyer sur Teredo en UDP 3544 pour traverser certains NAT. Ouvrir ces flux partout n’est pas nécessaire: la règle doit suivre les frontières réseau choisies.

Windows Server 2019 ou ultérieur utilise par défaut le mode 0, alors que le client Windows utilise généralement le mode LAN 1. Une absence de P2P sur un serveur n’est donc pas une panne par défaut. Le comportement exact reste lié à la version, au caller et aux politiques effectives.

• Une seule autorité par paramètre entre Intune, OMA-URI, GPO et Configuration Manager.
• Accès aux endpoints DO et au contenu sans inspection TLS incompatible.
• Support des requêtes Range et des réponses HTTP 206 par le proxy.
• TCP 7680 limité aux frontières où le P2P est attendu.
• Contenu, version de Windows et cloud compatibles avec la source recherchée.
• Espace disque, mémoire, batterie et coût réseau compatibles avec la participation.
• Mesure avant/après disponible sur le poste ou dans WUfB reports.

Cycle de fonctionnement, étape par étape

Le cycle commence quand un caller crée une demande. Windows associe cette demande à un contenu et récupère les métadonnées nécessaires. DO charge ensuite la configuration effective et vérifie si le poste peut télécharger, mettre en cache ou envoyer des blocs dans les conditions présentes.

La recherche de pairs utilise le mode de téléchargement, le GroupID et les restrictions supplémentaires. En mode LAN, Windows recherche des appareils dans le périmètre local prévu. En mode Groupe, le même GroupID peut réunir plusieurs sous-réseaux, sauf si DORestrictPeerSelectionBy limite à nouveau la sélection.

Lorsque plusieurs sources sont proposées, le client mesure leur disponibilité et leur performance. DOMinBackgroundQoS peut conduire DO à compléter une source pair trop lente avec HTTP. Les délais de téléchargement depuis HTTP ou de repli MCC influencent le temps accordé aux sources locales.

Après validation des blocs, DO remet le fichier assemblé au caller. Le caller poursuit alors sa logique: installation de la mise à jour, traitement de l’application ou publication d’un état. Les métriques DO décrivent le transport terminé, pas ce résultat applicatif final.

Modes de téléchargement et frontières de pairs

DODownloadMode définit les grandes familles de sources. Le mode 0 conserve HTTP et MCC mais coupe le P2P. Le mode 1 active les pairs LAN. Le mode 2 utilise un groupe logique. Le mode 3 autorise aussi des pairs Internet et reste exceptionnel dans une entreprise. Le mode 99 n’utilise ni service cloud DO ni P2P, tout en pouvant utiliser MCC.

Le mode 100, nommé Bypass, est déprécié sous Windows 11. Il contourne DO au lieu de couper uniquement le peering et peut provoquer l’erreur 0x80D03002 pour un contenu qui exige le moteur DO. Le remplacement attendu pour désactiver le P2P est le mode 0.

DOGroupID accepte un GUID explicite. DOGroupIDSource peut dériver le groupe d’un site Active Directory, du SID de domaine, de l’option DHCP 234, du suffixe DNS ou de l’ID du tenant Microsoft Entra. Sans valeur explicite, Windows suit l’ordre documenté pour chercher une source disponible.

DORestrictPeerSelectionBy ajoute une limite. La valeur 1 impose le même sous-réseau selon le masque. La valeur 2 active la découverte locale DNS-SD ou mDNS sous Windows 11 et empêche le peering inter-sous-réseaux. Une restriction peut donc neutraliser un GroupID conçu pour couvrir plusieurs VLAN.

Le GroupID n’est pas une authentification. Il sert à faire correspondre des appareils autour d’une frontière de partage. La segmentation réseau, le pare-feu et les politiques de sécurité restent responsables de la portée effective des connexions.

Cache client, bande passante et Microsoft Connected Cache

DOMinFileSizeToCache fixe le seuil d’admissibilité au peering, pas un seuil de téléchargement HTTP. Sa valeur par défaut est 50 MB. Microsoft propose de tester 10 MB pour un groupe de plus de trente appareils et 1 MB au-delà de cent appareils. Ces valeurs sont des points de départ, car plus de petits contenus augmente aussi le nombre d’éléments conservés et partagés.

DOMaxCacheAge et DOMaxCacheSize doivent correspondre à la cadence des vagues. Une rétention de trois jours ne permet pas à un seeder de servir un appareil qui reçoit le même contenu une semaine plus tard. Augmenter l’âge à sept ou trente jours peut aider, mais l’espace libre et le comportement de nettoyage doivent rester surveillés.

Sans plafond explicite, DO mesure la capacité disponible. Une valeur 0 sur les limites de bande passante signifie ajustement dynamique et non débit nul. Sur un lien faible, les plafonds absolus en KB/s sont plus prévisibles que les pourcentages calculés à partir d’une estimation de capacité.

MCC devient pertinent pour une agence avec WAN contraint, des kiosques réinitialisés, un laboratoire ou une vague Autopilot. Un premier appareil alimente le cache, puis les suivants réutilisent le contenu tant qu’il reste admissible et présent. Le test doit couvrir un cache froid, un cache chaud et un cache indisponible.

La découverte statique utilise DOCacheHost. DOCacheHostSource peut interroger l’option DHCP 235. La priorité entre liste statique et DHCP dépend de la valeur 1 ou 2 et doit être testée sur les builds cibles, en particulier pour les appareils mobiles qui quittent le réseau d’entreprise.

Sur un point de distribution Configuration Manager, MCC possède son propre cache, distinct du contenu classique du DP. Le client et le point de distribution doivent se trouver dans le boundary group prévu. BytesFromCacheServer apporte alors une preuve côté client, tandis que DoincSetup.log, DistMgr.log et les journaux IIS expliquent l’état serveur.

Interfaces d’observation, commandes et exemples

Get-DOConfig expose la configuration que le client DO utilise. Get-DODownloadMode donne le mode courant. Ces commandes doivent être rapprochées de la stratégie Intune, de gpresult et de la clé HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization afin de distinguer la valeur effective de son autorité.

Get-DeliveryOptimizationStatus décrit les transferts actifs ou récents disponibles dans l’instant. L’option -PeerInfo montre les pairs connus. Get-DeliveryOptimizationPerfSnap et Get-DeliveryOptimizationPerfSnapThisMonth donnent une tendance locale plus large, mais ne remplacent pas un rapport central sur plusieurs cycles.

Le journal Microsoft-Windows-DeliveryOptimization/Operational et les ETL sous %SYSTEMROOT%\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Logs servent à reconstruire la chronologie. Le cache se trouve sous %SYSTEMDRIVE%\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache.

$ErrorActionPreference = 'Stop'

try {
    Get-Service -Name DoSvc
    Get-DODownloadMode
    Get-DOConfig -Verbose
    Get-DeliveryOptimizationStatus |
        Select-Object FileId, Status, TotalBytesDownloaded,
            BytesFromHttp, BytesFromCacheServer,
            BytesFromLanPeers, BytesFromGroupPeers,
            BytesFromInternetPeers
    Get-DeliveryOptimizationStatus -PeerInfo
    Get-DeliveryOptimizationPerfSnap
    Get-DeliveryOptimizationPerfSnapThisMonth
} catch {
    Write-Error "Lecture de Delivery Optimization impossible : $($_.Exception.Message)"
    exit 1
}

UCDOStatus
| where TimeGenerated == _SnapshotTime
| summarize
    CDN = sum(BytesFromCDN),
    LAN = sum(BytesFromPeers),
    Groupe = sum(BytesFromGroupPeers),
    MCC = sum(BytesFromCache),
    Appareils = dcount(GlobalDeviceId)
  by ContentType
| extend Total = CDN + LAN + Groupe + MCC
| extend EconomiePct = round(100.0 * (LAN + Groupe + MCC) / Total, 2)
| order by Total desc

Observabilité : où lire l’état réel

Sur Windows 11, le Moniteur d’activité se trouve dans Paramètres > Windows Update > Options avancées > Optimisation de la distribution. Il montre la répartition des téléchargements par source, les vitesses moyennes et l’upload du mois courant. Cette vue locale aide à expliquer un poste, mais ne représente pas l’ensemble d’un site.

WUfB reports conserve vingt-huit jours d’activité Delivery Optimization dans son workbook. UCDOStatus fournit la vue par appareil et type de contenu. UCDOAggregatedStatus fournit une vue agrégée. Les champs BytesFromCDN, BytesFromPeers, BytesFromGroupPeers et BytesFromCache permettent de calculer la part réellement économisée.

Le ratio d’économie doit être lu avec PeerEligibleTransfers, PeersSuccessCount et PeersCannotConnectCount. Zéro octet pair peut être normal si aucun transfert n’était éligible. En revanche, beaucoup de transferts éligibles et aucun succès orientent vers la frontière, TCP 7680, le service cloud ou les conditions de ressources.

Pour MCC, le portail Azure expose le heartbeat, l’état Healthy ou Unhealthy, la version, le débit et les volumes par contenu. La preuve côté client reste BytesFromCacheServer ou BytesFromCache. Un nœud Healthy qui ne sert aucun octet doit être analysé comme un problème de découverte, de compatibilité du contenu ou de cache froid.

• Configuration effective: Get-DOConfig, Intune, gpresult et Registre Policies.
• Transfert courant: Get-DeliveryOptimizationStatus et PeerInfo.
• Tendance locale: PerfSnap, PerfSnapThisMonth et Moniteur d’activité.
• Chronologie: journal Operational et ETL Delivery Optimization.
• Vision parc: UCDOStatus et UCDOAggregatedStatus.
• MCC: heartbeat Azure, hits, misses, egress et BytesFromCacheServer côté client.

Validation du modèle et cas d’usage

Un test utile emploie deux clients, le même contenu et une fenêtre courte. Le premier appareil télécharge et alimente son cache. Le second démarre dix à quinze minutes plus tard, reste dans la même frontière et demande exactement le même identifiant de contenu. Les octets pair doivent alors apparaître si le contenu, le seuil et les ressources le permettent.

Le scénario MCC comporte trois passages. Le cache froid confirme que le premier téléchargement aboutit. Le cache chaud vérifie que le même contenu est servi localement. L’arrêt contrôlé du cache confirme enfin que le repli CDN se produit dans le délai accepté sans bloquer l’utilisateur ou l’ESP Autopilot.

Une campagne Autopilot doit mesurer le p50 et le p95 du temps ESP, le volume CDN par appareil, les timeouts et l’état des applications. Un anneau d’amorçage de cinq à dix pour cent peut alimenter les caches avant les vagues suivantes si les appareils restent allumés et si la même révision de contenu est demandée.

La validation couvre aussi un poste hors site, le VPN, un lien facturé et un site segmenté. L’objectif n’est pas d’obtenir du P2P partout, mais de vérifier que chaque contexte produit la source et le repli prévus sans traversée WAN inattendue.

• Deux clients reçoivent le même contenu dans la même frontière.
• Le second client reçoit des octets pair lorsque le transfert est éligible.
• MCC sert des octets au second passage et se replie vers le CDN lorsqu’il est arrêté.
• Aucun pair n’est utilisé hors de la frontière approuvée.
• Les conflits entre GPO, Intune, OMA-URI et Configuration Manager sont absents.
• Les temps de téléchargement et le trafic WAN sont comparés à une référence mesurée.

Limites, modes de panne et lecture des erreurs

Un mode 99 inattendu indique souvent que le client n’atteint pas le service cloud DO. La première vérification porte sur DNS, HTTPS, proxy et inspection TLS. Configurer volontairement le mode 99 est différent d’un repli observé parce que la communication cloud échoue.

L’erreur 0x80D02002 signale qu’un téléchargement ne progresse plus. Elle ne désigne pas automatiquement DO comme cause racine. Le contenu peut venir de WSUS, d’un point de distribution, de MCC ou d’un serveur HTTP dont le proxy altère les requêtes Range.

Les erreurs 0x80D03801 à 0x80D03808 décrivent des suspensions dues au coût, au cellulaire, à l’alimentation, à l’absence de réseau, au VPN ou à la mémoire critique. Dans ces cas, répéter une synchronisation ne change pas la condition qui bloque le transfert.

Les erreurs 0x80D05010 et 0x80D05011 orientent vers HTTP Range. Il faut alors examiner la réponse 206, Content-Range et les intermédiaires plutôt que vider le cache. Un proxy qui renvoie le fichier entier ou réécrit les plages casse le téléchargement par blocs.

L’absence de BytesFromCacheServer n’est pas suffisante pour déclarer MCC en panne. Le contenu peut ne pas être compatible, le cache peut être froid, DOCacheHost peut être absent ou le client peut se trouver sur un VPN qui interdit MCC. La santé Azure et la découverte client doivent être lues ensemble.

Adoption progressive, réversibilité et vigilance

La préparation commence par une carte des NAT, sous-réseaux, VLAN, sorties Internet, VPN, DHCP et proxys. Les politiques GPO, Intune, OMA-URI et Configuration Manager sont inventoriées avant de créer un nouveau profil. Cette étape évite qu’un paramètre apparemment incohérent soit simplement gagné par une autre autorité.

Un laboratoire vérifie d’abord le transport et les limites. Le pilote couvre ensuite deux à cinq pour cent du parc avec au moins un site simple, un site segmenté, un appareil mobile et un scénario Autopilot. L’extension par site ne commence qu’après deux cycles comparables.

Le retour arrière client utilise généralement DODownloadMode=0 pour couper le P2P sans casser DO. Les groupes, délais, plafonds et tailles retrouvent leurs valeurs précédentes depuis l’autorité de gestion. Supprimer seulement la nouvelle stratégie ne garantit pas que chaque valeur locale revienne immédiatement à l’état attendu.

Le retrait de MCC commence par la preuve du repli CDN. DOCacheHost ou l’option DHCP est retiré sur une vague contrôlée, puis le volume CDN et les temps de téléchargement sont surveillés. Le nœud n’est désinstallé qu’après confirmation de non-utilisation.

Un GO exige l’absence de trafic hors frontière, aucun échec critique attribuable à DO, un repli CDN fonctionnel, un gain reproductible et une observabilité suffisante. Un NO-GO s’impose si l’inspection TLS reste incompatible, si le trafic traverse un WAN non prévu, si MCC est instable ou si le bénéfice disparaît sur deux cycles.