Outil gratuit
Delivery Optimization Advisor
Quel mode, quel groupe, et où faut-il un cache ?
Décrivez vos sites — leur nombre de postes et le débit de leur lien — et l'outil nomme le mode Delivery Optimization qui convient à votre topologie, dit où un cache se justifie, et écrit les politiques à poser avec leurs valeurs. Il chiffre aussi ce qu'une vague coûte à chaque lien : ce qu'elle coûte si chaque poste télécharge depuis le CDN, et ce qu'elle coûterait si un seul le faisait. L'écart entre les deux est l'enjeu ; là où vous tomberez entre les deux, seul un pilote le dit.
Aucune inscription, aucun cookie : ce que vous saisissez reste dans votre navigateur et s'efface quand vous fermez l'onglet — rien n'en sort. Seule la visite est comptée, par une mesure d'audience sans cookie qui ne vous identifie pas, décrite dans les mentions légales.
Le parc
Le mode est une politique unique pour tout le parc, et ces questions sont ce qui le décide : par où vous sortez, ce que votre sortie laisse passer, et de quoi vous disposez pour désigner un groupe. Les sites, en dessous, décident du reste.
Vos sites
Un site, c'est un ensemble de postes derrière un même lien. Deux bâtiments reliés en fibre noire et vus du WAN comme un seul point de sortie sont un seul site ici ; deux étages sur deux liens distincts en font deux.
La configuration
Les deux volumes affichés sont les bornes d'un intervalle : tout depuis le CDN d'un côté, un seul téléchargement par site de l'autre. Aucun parc ne tient l'une ou l'autre. Où vous tomberez entre les deux dépend du rythme de vos vagues, de la fenêtre d'expiration du cache — trois jours par défaut — et de la part de postes réellement éligibles au partage, trois choses que cette page ne peut pas voir. Mesurez un site pilote sur une vraie vague avant d'annoncer un chiffre à qui que ce soit.
Une aide à la décision, pas un audit. L'outil raisonne sur ce que vous déclarez ; il ne voit ni vos règles de pare-feu, ni votre proxy, ni la version de DoSvc réellement installée — dont dépend une partie du comportement, poussée par le service cloud de Microsoft. Vérifiez la configuration effective sur un poste par site avant d'en faire un standard.
La stratégie
Delivery Optimization : ce qu'il faut savoir pour décider
Delivery Optimization n'est pas « le P2P » : c'est le service qui télécharge le contenu Microsoft, et le partage entre pairs n'est qu'une de ses trois sources. Ce qui suit est ce dont il faut disposer pour choisir — les modes, ce que le réseau doit laisser passer, et les pièges qui font échouer la moitié des déploiements sans rien afficher.
Un téléchargeur multi-source, pas « le P2P »
Delivery Optimization est le service Windows — DoSvc — qui télécharge le contenu Microsoft : Windows Update, le Store, Microsoft 365 Apps, les applications Win32 d'Intune, Edge, les définitions Defender. Il assemble chaque fichier par pièces d'environ un mégaoctet, en parallèle, depuis trois sources : le CDN de Microsoft, un cache local s'il en existe un, et d'autres postes. Le partage entre pairs n'est qu'une couche optionnelle : même en mode 0, c'est DoSvc qui télécharge, applique les limites de débit et alimente la télémétrie. Seul le mode 99 coupe tout contact avec le service cloud.
Deux filtres décident de ce qui est réellement partagé, indépendamment du mode : la politique de contenu du service cloud doit l'autoriser, et le fichier doit dépasser DOMinFileSizeToCache — cinquante mégaoctets par défaut. Une application Win32 de trente mégaoctets n'est donc jamais partagée, quoi que vous configuriez.
Les cinq modes
| Valeur | Nom | Portée des pairs | Ce qu'il vaut en entreprise |
|---|---|---|---|
| 0 | HTTP seul | Aucun pair | Serveurs, et postes exposés à un réseau non maîtrisé. Défaut de Windows Server. |
| 1 | LAN | Même adresse IP publique | Défaut client, et le bon choix dès que chaque site a sa propre sortie. |
| 2 | Groupe | Même GroupID, franchit les NAT | Pour une sortie centralisée — à condition de maîtriser le GroupID. |
| 3 | Internet | N'importe quel pair | À proscrire : un défaut grand public. |
| 99 | Simple | Aucun, aucun contact cloud | Réseaux isolés — et repli automatique quand le service est injoignable. |
Le mode 100 (Bypass) est supprimé sous Windows 11 : une GPO héritée de Windows 10 qui le pousse encore ne produit rien, et la valeur est traitée comme 0.
Ce que le réseau doit laisser passer
Un seul de ces flux bloqué suffit à faire retomber tout le parc en mode Simple, sans message et sans alerte. C'est l'erreur de configuration rencontrée le plus souvent.
| Flux | Port | Sens | Si bloqué |
|---|---|---|---|
| Service cloud DO — *.prod.do.dsp.mp.microsoft.com | TCP 443 | Sortant | Ni politique de contenu ni pairs : mode Simple |
| Métadonnées — dl.delivery.mp.microsoft.com, *.windowsupdate.com | TCP 80 | Sortant | Aucun octet de pair ne peut être vérifié, donc aucun n'est accepté |
| Échange de pièces entre pairs | TCP 7680 | Entrant et sortant | Plus de partage ; les téléchargements continuent par le CDN |
| Teredo — traversée de NAT | UDP 3544 | Sortant | N'affecte que les modes 2 et 3 entre NAT différents |
| Découverte locale mDNS | UDP 5353 | Multicast local | Local Peer Discovery indisponible (Windows 11) |
Le proxy cloud casse le regroupement par adresse publique
Le mode LAN n'a qu'une seule clé de regroupement : l'adresse IP publique que le service voit. Derrière un proxy cloud — Zscaler, Netskope, Prisma Access, Umbrella — il n'y a plus de sortie par site : chaque poste part vers le point de présence le plus proche, et l'adresse qui en ressort n'est plus une propriété du bâtiment. Un opérateur qui distribue un pool de NAT tournant produit exactement le même effet.
Deux pannes en découlent, et elles sont l'image l'une de l'autre. Le site se coupe en morceaux : deux postes voisins présentent deux adresses et ne sont jamais mis dans le même groupe. Et deux sites fusionnent : sortant par le même point de présence, ils présentent la même adresse et s'échangent des pièces à travers le WAN. Aucune des deux ne se voit — les téléchargements aboutissent, par le CDN.
Ce qui répare
- Passer au mode 2 : le GroupID est une valeur que vous contrôlez, pas une adresse que le proxy choisit.
- Le fixer explicitement — option DHCP 234 de préférence, à défaut le site Active Directory.
- Ajouter DORestrictPeerSelection = 1 : le sous-réseau est la seule frontière que le proxy ne peut pas déplacer.
- Sauf si les VLAN du site se parlent en gigabit — là, cloisonner coûte plus que ça ne protège.
Ce qui reste à surveiller
- Sans option DHCP ni site AD, les deux clés manquent à la fois : le partage ne tiendra pas.
- Des postes voisins aux adresses publiques différentes deviennent des pairs « de groupe » : eux sont soumis aux limites de bande passante, les pairs LAN ne le sont pas. [à valider au pilote]
- Le cache, lui, est insensible au problème : il est désigné par une politique, pas par une adresse observée.
- Et il faut l'exclure du proxy : le flux client vers cache est du HTTP clair sur le port 80, hors politique de proxy.
Microsoft Connected Cache — un cache, pas un catalogue
MCC ne pré-charge rien et ne gère aucun catalogue : il stocke ce que les clients lui ont demandé. Le premier poste du site paie le téléchargement, les suivants sont servis en local — y compris quand le partage entre pairs ne fonctionne pas, ce qui est sa vraie valeur.
Avantages
- Indépendant des postes : ni batterie, ni disque, ni fenêtre d'expiration à surveiller.
- Sert aussi les contenus trop petits pour être partagés entre pairs.
- La ressource Azure est gratuite ; la licence est celle des postes servis (E3, E5, F3, A3, A5).
- Les métriques Azure disent ce que le cache a réellement évité, indépendamment des clients.
Inconvénients
- Un serveur à installer, à mettre à jour et à surveiller sur chaque site concerné.
- Aucun proxy admis entre le client et le cache : la politique de proxy ne s'applique pas à ce flux.
- Un FQDN instable ou un nom court non résolu produit un repli CDN permanent, et invisible.
- Cent gigaoctets de disque dédiés au minimum, sous peine d'échec à l'installation.
Mesurer : deux pièges de lecture
BytesFromHTTP inclut les octets servis par le cache. Lu comme « ce qui vient du CDN », il fait disparaître l'essentiel de l'économie : un site bien servi par un cache affiche un pourcentage de pairs très bas et une économie WAN excellente. Le bon indicateur est 1 − BytesFromCDN / TotalBytes, avec BytesFromCDN = BytesFromHTTP − BytesFromCacheServer.
L'efficacité globale est tirée vers le bas par tout ce qui pèse moins de cinquante mégaoctets et n'est donc jamais partagé. Rapportez les deux chiffres : l'efficacité globale, et celle sur les seuls fichiers éligibles. Et sans données de diagnostic au niveau « Requis », les rapports WUfB ne montrent rien du tout côté Delivery Optimization.
Ce qui reste à mesurer avant tout engagement chiffré
- Le seuil de densité réel — celui à partir duquel le partage devient significatif sur un site. Les 200 à 300 postes cités partout sont un ordre de grandeur, pas une loi.
- La configuration poussée par le service cloud — une partie du comportement du client est ajustée par Microsoft selon la version de DoSvc : deux postes aux politiques identiques peuvent différer.
- Le comportement d'un cache lent — le repli est documenté pour un nœud injoignable ; pour un nœud simplement lent, il se mesure.
- La régulation d'upload sur vos liens — elle cède la priorité au trafic interactif, mais se comporte différemment sur des liens à forte gigue.
- Les gains hors Windows Update — Microsoft 365 Apps et les applications Win32 d'Intune donnent des résultats très inférieurs : contenu plus petit, plus fragmenté.