Troubleshooting Delivery Optimization : diagnostiquer P2P, proxy, téléchargement et Microsoft Connected Cache

Résumé opérationnel

Un taux P2P nul n’est pas toujours une panne. Le contenu peut ne pas prendre en charge les pairs, le fichier peut être inférieur à DOMinFileSizeToCache, aucun autre appareil ne peut demander le même identifiant de contenu ou le premier poste peut avoir nettoyé son cache. Le diagnostic doit commencer par l’éligibilité avant de tester le pare-feu.

Le mode 99 inattendu oriente vers la communication avec le service cloud DO. Des pairs visibles mais injoignables orientent vers TCP 7680 ou une frontière réseau. Un téléchargement bloqué avec 0x80D05011 pointe vers HTTP Range. Un MCC Healthy sans BytesFromCacheServer indique plutôt une découverte absente, un contenu non supporté ou un cache encore froid.

Je collecte la configuration effective, l’état du service DoSvc, le transfert courant, PeerInfo, PerfSnap, les événements Operational et les valeurs sous HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization. Je relève aussi le caller, l’heure UTC, le réseau, le VPN, le GroupID et l’identité du contenu.

La première correction cible la première divergence prouvée. Je ne supprime pas le cache par réflexe: cette action retire une source pour les autres appareils et efface une partie du contexte qui permet de comprendre le comportement.

Le bon point de départ n’est pas « DO fonctionne-t-il? », mais « pour ce contenu précis, quelle source était attendue et quelle condition a empêché son utilisation? »

Symptôme, contexte et périmètre de l’incident

Le ticket doit décrire un résultat observable. Exemples: aucun octet pair sur un site pendant une vague Windows Update, DownloadMode 99 alors que le profil Intune demande le mode 2, une erreur 0x80D02002 pendant un téléchargement Win32, ou un nœud MCC Healthy qui ne sert aucun octet aux clients.

Je fixe une fenêtre temporelle courte avec l’heure locale et UTC, le dernier changement de stratégie, le début du téléchargement et le moment où l’erreur apparaît. Les métriques de vingt-huit jours ne remplacent pas cette fenêtre: elles mélangent plusieurs contenus, réseaux et versions de politique.

La population touchée donne déjà une indication. Un seul poste évoque ressources, cache, service ou état local. Un VLAN complet évoque pare-feu, GroupID, DHCP ou proxy. Tous les sites évoquent plutôt un changement d’autorité, un endpoint cloud bloqué, un proxy central ou un contenu qui ne prend pas en charge la source recherchée.

Le caller est indispensable. Windows Update, Intune Win32, Microsoft 365 Apps et Microsoft Store ne publient pas exactement les mêmes contenus ni les mêmes signaux d’installation. Un téléchargement DO terminé n’explique pas à lui seul une règle de détection Win32 en échec ou une mise à jour déclarée non applicable.

• Symptôme exact, code 0x80D… et texte associé.
• Caller et type de contenu.
• Heure locale, UTC et durée observée.
• Appareils, sous-réseaux, sites et VPN concernés.
• Dernier changement Intune, GPO, OMA-URI, Configuration Manager, proxy ou pare-feu.
• Source attendue: CDN, pairs LAN/Groupe ou MCC.

Questions à résoudre et méthode de diagnostic

La première question porte sur l’éligibilité: le caller, le contenu et la version de Windows annoncent-ils le P2P ou MCC? Si la documentation ne prévoit que HTTP DO, l’absence de BytesFromLanPeers n’est pas une anomalie.

La deuxième question porte sur l’intention. Quelle valeur gagne réellement pour DODownloadMode, DOGroupID, DORestrictPeerSelectionBy, DOCacheHost, les délais et les seuils? Un profil Intune assigné peut être contredit par une GPO, un ancien OMA-URI ou une charge Configuration Manager.

La troisième question porte sur l’accès aux services. Le client résout-il les endpoints DO, négocie-t-il HTTPS sans inspection incompatible et reçoit-il les métadonnées attendues? Un accès général à Internet ne prouve pas que geo, array ou les endpoints de contenu fonctionnent correctement.

La quatrième question porte sur la source locale. Le pair se trouve-t-il dans la même frontière, écoute-t-il au moment du test et conserve-t-il le même contenu? MCC est-il découvert, joignable et déjà alimenté? Enfin, une politique de VPN, de coût, de batterie ou de mémoire suspend-elle le transfert?

Cartographie du flux à diagnostiquer

Le diagnostic suit le transfert dans son ordre réel. Le caller crée d’abord le job. Le client DO charge ensuite ses politiques et contacte le service cloud. Il découvre les pairs et MCC, tente les sources admises, reçoit des blocs, les vérifie puis rend le contenu complet au caller.

Une erreur en amont peut ressembler à une absence de pairs. Si le caller ne crée aucun job, Get-DeliveryOptimizationStatus reste vide. Si le service cloud est inaccessible, le client peut apparaître en mode 99. Si la frontière est incorrecte, PeerInfo ne propose pas les appareils attendus. Si TCP 7680 est bloqué, les pairs peuvent être proposés sans connexion réussie.

La dernière couche appartient au caller. Une application Intune peut être téléchargée puis échouer à l’installation ou à la détection. Windows Update peut télécharger un package puis attendre un redémarrage. Le diagnostic DO s’arrête lorsque le contenu complet est remis sans erreur au composant demandeur.

État initial et prérequis de collecte

La collecte commence avant un redémarrage de service, un nettoyage du cache ou un changement de profil. Je note la version Windows, le dernier redémarrage, l’espace libre, la mémoire, l’alimentation, le type de réseau, le VPN, le proxy et le coût de la connexion. Ces conditions peuvent changer le comportement sans produire une panne permanente.

Le poste doit reproduire un téléchargement suffisamment volumineux et compatible. Tester deux clients avec des contenus différents ne valide pas le P2P. Le second téléchargement démarre après que le premier a obtenu et conservé le même identifiant de contenu, généralement après une attente de dix à quinze minutes dans un scénario contrôlé.

Pour MCC, je conserve l’état du nœud, le heartbeat, la version, l’espace disque, l’ingress, l’egress et la méthode de découverte côté client. Le scénario distingue cache froid, cache chaud et cache arrêté. Sans ces trois états, un miss initial peut être confondu avec une panne.

Les droits administratifs sont nécessaires pour certaines commandes, le Registre machine et les journaux. Les sorties peuvent contenir noms d’appareils, adresses et GroupID. Elles restent dans le dossier d’incident protégé et sont réduites avant tout partage externe.

• Poste témoin et poste en échec sur le même contenu.
• Version Windows, heure UTC et dernier redémarrage.
• Mode, GroupID, restriction et cache attendus.
• Adresse IP, masque, NAT, proxy et état VPN.
• État de DoSvc, disque, mémoire, batterie et coût réseau.
• Téléchargement compatible et assez volumineux pour le test.
• MCC froid, chaud et indisponible lorsque le cache est dans le périmètre.

Collecte des preuves : journaux, registre et états

La stratégie effective se lit d’abord avec Get-DOConfig et Get-DODownloadMode. La clé HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization confirme les valeurs de stratégie présentes, mais elle ne prouve pas leur origine. Intune, gpresult et Configuration Manager indiquent quelle autorité devait écrire chaque paramètre.

Le journal Microsoft-Windows-DeliveryOptimization/Operational fournit la chronologie locale. Les ETL se trouvent dans %SYSTEMROOT%\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Logs. Get-DeliveryOptimizationLog -Flush et Get-DeliveryOptimizationLogAnalysis -Flush rendent ces traces plus lisibles pour une fenêtre de reproduction.

Get-DeliveryOptimizationStatus indique le job, sa progression et les octets par source. PeerInfo montre les pairs connus. PerfSnap et PerfSnapThisMonth donnent une tendance. Une commande exécutée après la disparition du job peut renvoyer peu d’informations, d’où l’importance de lancer la collecte pendant le transfert.

WUfB reports ajoute la vue sur vingt-huit jours. PeerEligibleTransfers sépare les contenus qui pouvaient utiliser un pair. PeersSuccessCount et PeersCannotConnectCount distinguent une absence de proposition d’un échec de connexion. TimeGenerated doit rester visible pour ne pas comparer un état ancien à une correction récente.

Pour MCC sur Configuration Manager, les traces serveur comprennent HKLM\SOFTWARE\Microsoft\Delivery Optimization In-Network Cache, \SMS_DP$\Ms.Dsp.Do.Inc.Setup\DoincSetup.log, DistMgr.log et les journaux IIS sous %SystemDrive%\inetpub\logs\LogFiles. Sur MCC autonome, la santé Azure et les journaux de l’hôte complètent la preuve client.

Investigation pas à pas

L’investigation s’arrête dès qu’une étape diverge. Si le contenu n’est pas éligible, ouvrir TCP 7680 ne changera rien. Si DODownloadMode vaut 0, le P2P est volontairement coupé. Si le service cloud ne répond pas, corriger le GroupID avant le proxy ajoute seulement une seconde variable.

Pour un problème de débit, je compare premier plan et arrière-plan. Les plafonds, plages horaires, délais HTTP et délais MCC peuvent produire un comportement lent sans erreur. Je vérifie aussi que le proxy renvoie 206 Partial Content et ne transforme pas chaque Range en téléchargement complet.

Pour MCC, la découverte précède les hits. DOCacheHost, DOCacheHostSource et l’option DHCP 235 doivent produire le cache attendu sur le réseau courant. Une liste statique peut prendre le pas sur DHCP selon la valeur choisie. Le test doit inclure un poste mobile ou hors site si ce comportement fait partie du design.

Commandes et scripts de diagnostic en lecture seule

La première collecte produit un instantané lisible sans modifier les politiques, le cache ou le service. Elle doit être lancée pendant le téléchargement lorsque le symptôme concerne la progression ou les sources. Les objets retournés peuvent ensuite être copiés dans le dossier d’incident avec l’heure de collecte.

Le test réseau vise un pair ou un cache déjà identifié. Test-NetConnection ne doit pas être lancé contre une adresse arbitraire: il confirme seulement qu’un chemin TCP précis est joignable depuis ce poste. Un succès sur 7680 ne prouve pas que le contenu existe dans le cache du pair.

L’analyse ETL est déclenchée après avoir fixé la fenêtre de reproduction. Le mode verbeux détaillé reste temporaire car il augmente le volume des traces. Le bundle du DO Troubleshooter peut contenir des données réseau et doit rester protégé.

param(
    [ValidateRange(10, 500)]
    [int]$MaxEvents = 150
)

$ErrorActionPreference = 'Stop'

try {
    $service = Get-Service -Name DoSvc
    $mode = Get-DODownloadMode
    $config = Get-DOConfig -Verbose
    $status = Get-DeliveryOptimizationStatus
    $peers = Get-DeliveryOptimizationStatus -PeerInfo
    $performance = Get-DeliveryOptimizationPerfSnap
    $policy = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization' -ErrorAction SilentlyContinue
    $events = Get-WinEvent -LogName 'Microsoft-Windows-DeliveryOptimization/Operational' -MaxEvents $MaxEvents

    [pscustomobject]@{
        CollectedAtUtc = [DateTime]::UtcNow
        Service        = $service
        DownloadMode   = $mode
        Configuration  = $config
        Status         = $status
        Peers          = $peers
        Performance    = $performance
        PolicyRegistry = $policy
        Events         = $events
    }
} catch {
    Write-Error "Collecte Delivery Optimization impossible : $($_.Exception.Message)"
    exit 1
}

$ErrorActionPreference = 'Stop'

try {
    Resolve-DnsName 'geo.prod.do.dsp.mp.microsoft.com'
    Resolve-DnsName 'dl.delivery.mp.microsoft.com'
    Test-NetConnection -ComputerName '<PAIR_OU_CACHE>' -Port 7680
} catch {
    Write-Error "Test réseau Delivery Optimization impossible : $($_.Exception.Message)"
    exit 1
}

$ErrorActionPreference = 'Stop'

try {
    Get-DeliveryOptimizationLog -Flush
    Get-DeliveryOptimizationLogAnalysis -Flush
} catch {
    Write-Error "Analyse des journaux DO impossible : $($_.Exception.Message)"
    exit 1
}

10:12:14Z  Policy     DownloadMode=2  GroupID=Site-Paris  RestrictPeerSelectionBy=1
10:12:19Z  Job        Caller=WindowsUpdate  Status=Downloading  TotalBytes=734003200
10:12:23Z  Discovery  NumPeers=4  PeersCannotConnectCount=4
10:12:28Z  Network    Pair=10.20.14.26:7680  Result=TcpConnectFailed
10:12:44Z  Source     BytesFromHttp=52428800  BytesFromLanPeers=0
10:13:02Z  Decision   FirstDivergence=PeerConnectivity

Lire les résultats, les journaux et les codes d’erreur

La chronologie d’exemple montre quatre pairs proposés et quatre échecs de connexion. Le client connaît donc le groupe et reçoit une liste de candidats. La première divergence se situe après la découverte, au moment d’ouvrir TCP 7680. Modifier DOGroupID ou le seuil de taille avant de tester le pare-feu déplacerait le diagnostic sans traiter cette preuve.

Un Get-DeliveryOptimizationStatus vide n’est pas un verdict. Le job peut être terminé, annulé ou jamais créé par le caller. Je rapproche l’heure de la commande du journal Operational et du journal du caller. Si aucune demande n’existe, le diagnostic revient à Windows Update, Intune ou au produit qui devait appeler DO.

DownloadMode 99 est interprété avec son origine. Une politique explicite peut l’imposer. Sans cette intention, DNS, HTTPS, proxy et inspection TLS deviennent prioritaires. Le HealthCheck du DO Troubleshooter aide à confirmer cette couche avant toute modification de groupes ou de ports locaux.

Les codes de blocage 0x80D03801, 0x80D03803, 0x80D03804, 0x80D03805, 0x80D03807 et 0x80D03808 correspondent à des conditions de coût, cellulaire, énergie, réseau, VPN ou mémoire. La correction doit supprimer la condition ou ajuster la politique qui la traite. Relancer le job sans changement produit généralement le même résultat.

0x80D05010 et 0x80D05011 orientent vers Range. Une capture ou un journal proxy doit montrer la requête Range et une réponse 206 cohérente avec Content-Range. Une réponse 200 complète peut expliquer une absence de progression ou une consommation WAN anormale.

Arbre de décision : symptômes, causes et corrections

La matrice relie chaque symptôme à une preuve discriminante. Elle ne propose pas de correction tant que cette preuve manque. Par exemple, zéro octet pair avec PeerEligibleTransfers à zéro n’a pas la même cause que zéro octet pair avec des centaines de PeersCannotConnectCount.

MCC exige la même discipline. Healthy confirme le heartbeat du nœud, pas son usage. DOCacheHost, la résolution, l’accessibilité, le type de contenu et BytesFromCacheServer doivent converger avant de modifier les délais ou de redéployer le cache.

Validation de la correction et critères de clôture

La validation rejoue le même caller, le même contenu et la même frontière. Elle conserve l’heure UTC, le mode et les compteurs avant/après. Changer simultanément de contenu, de poste et de réseau empêche d’attribuer l’amélioration à la correction.

Pour le P2P, le second appareil doit recevoir des octets depuis un pair et PeersSuccessCount doit progresser sans connexion hors frontière. Pour le mode 99, le client retrouve le mode prévu après correction du service cloud. Pour Range, le proxy montre une réponse 206 cohérente et le job progresse.

Pour MCC, le cache chaud sert des octets, puis le CDN reprend dans le délai accepté lorsque le nœud est arrêté. Le heartbeat revient après redémarrage. Le test ne se termine pas au premier hit: un téléchargement complet et le reporting du caller doivent aussi réussir.

Le ticket se ferme lorsque la première divergence a disparu, que les sources correspondent au design, qu’aucune régression de temps ou de WAN n’apparaît et que la correction est appliquée par l’autorité de gestion attendue. Une amélioration ponctuelle sans preuve reproductible reste en observation.

• Même contenu et même population que lors du diagnostic.
• Mode et configuration effective conformes à l’intention.
• Octets pair ou MCC observés lorsque le transfert est éligible.
• Aucune connexion hors frontière approuvée.
• Repli CDN validé dans le délai accepté.
• Code 0x80D… absent sur deux reproductions.
• Installation ou traitement final confirmé par le caller.

Retour arrière, escalade et points de vigilance

Le retour arrière le plus sûr pour isoler le P2P consiste généralement à appliquer DODownloadMode=0 depuis l’autorité de gestion. DO et le CDN restent disponibles. Les valeurs de groupe, restrictions, délais, plafonds et cache retrouvent ensuite leur état précédent de manière explicite.

Une règle pare-feu ou une exemption proxy créée pour le test est retirée si elle n’est pas retenue. L’arrêt de MCC n’intervient qu’après validation du repli CDN. Le nœud est remis en service et son heartbeat contrôlé si le test ne confirme pas la cause.

L’escalade vers le réseau conserve le poste source, le pair ou le cache cible, les ports, l’heure et la preuve d’échec. L’escalade Microsoft conserve le bundle DO, la version Windows, le caller, l’identifiant du contenu, les événements et les causes déjà écartées. Pour MCC, ajouter l’ID de nœud, la version, le heartbeat et les journaux d’hôte.

Le bundle peut contenir des adresses, noms d’appareils et détails de topologie. Il doit être traité comme une donnée opérationnelle. Les captures et exports partagés hors de l’équipe sont réduits aux informations nécessaires au cas.