Paramétrage et configuration recommandés
Pour tirer le meilleur parti de Windows Update Delivery Optimization en environnement d’entreprise, il est crucial de bien le paramétrer en fonction de la topologie réseau et des besoins. Voici les recommandations principales de configuration :
- Choisir le mode de distribution adapté : Comme évoqué précédemment, le mode Groupe (DownloadMode = 2) est souvent considéré comme l’option optimale pour les organisations (Delivery Optimization reference | Microsoft Learn). Il permet un partage entre pairs étendu à l’échelle de l’entreprise (au-delà du simple subnet), ce qui maximise les opportunités de cache partagé. Si votre infrastructure est répartie sur plusieurs sites interconnectés par VPN ou WAN, le mode Groupe assurera que les postes de différents réseaux locaux peuvent tout de même s’entraider. Ce mode Groupe s’appuie sur les sites AD ou le tenant AAD par défaut, mais il est souvent recommandé de définir un Group ID personnalisé pour maîtriser précisément le périmètre. Par exemple, vous pouvez définir un GroupID unique pour toute l’entreprise (si les sites sont bien reliés et que la latence inter-site est raisonnable), ou au contraire un GroupID par site géographique si vous préférez cloisonner le trafic WUDO par localisation. L’important est que les machines qui peuvent se partager utilement du contenu aient le même GroupID. Notons que par défaut sans configuration, les PC domaine rejoignent un groupe basé sur le SID de domaine ou le Site AD (Delivery Optimization reference | Microsoft Learn) (Delivery Optimization reference | Microsoft Learn), ce qui est déjà une bonne base dans de nombreux cas.
- Limiter le peering à l’entreprise : Par mesure de sécurité et de performance, il est recommandé de désactiver le mode Internet (3), sauf besoin très particulier. Cela évite d’envoyer du trafic poste-à-poste hors du réseau de l’entreprise. Donc, soit on laisse le mode par défaut (LAN) ou Groupe, soit si on veut interdire tout P2P on met en HTTP uniquement (0). Mais généralement, on souhaite le P2P local, donc on opte pour LAN ou Groupe, et on couple cela avec une stratégie qui empêche l’utilisation du mode Internet même en fallback. Concrètement, cela peut se faire via la GPO Allow uploads while under VPN (qu’on désactivera) ou plus simplement en ne configurant jamais le mode 3.
- Configurer la découverte locale DNS-SD selon l’environnement : Si vos postes Windows 11 sont sur des réseaux où le multicast fonctionne bien et que vous voulez minimiser la dépendance au cloud, envisagez d’activer la découverte DNS-SD (DORestrictPeerSelectionBy = 2). Cela peut améliorer le maillage local, notamment dans des environnements où les sites partagent la même IP publique (donc vus comme un groupe unique par le cloud) mais sont en réalité séparés physiquement. DNS-SD permettra aux postes d’un même sous-réseau de se trouver entre eux plus efficacement. Cependant, si votre réseau bloque le multicast ou si vous préférez garder le contrôle cloud, vous pouvez laisser la découverte standard. Cette option est à tester en pilote pour voir son impact.
- Ajuster la taille du cache local si nécessaire : Par défaut, WUDO utilise jusqu’à 20% du disque pour stocker les contenus téléchargés (Delivery Optimization reference | Microsoft Learn). Sur la plupart des PC modernes, c’est acceptable, mais sur des petits SSD de 128 Go par exemple, cela peut être trop. Vous pouvez définir via stratégie Max Cache Size une pourcentage différent ou un maximum absolu (DOAbsoluteMaxCacheSize) (Delivery Optimization reference | Microsoft Learn). Microsoft recommande de ne pas descendre en dessous de quelques gigaoctets, sinon le cache risque de se vider trop souvent et de diminuer l’efficacité du P2P. Une bonne pratique est de réserver ~10 Go sur les PC pour WUDO (valeur courante), ce qui suffit à stocker plusieurs mises à jour cumulatives ou un upgrade de fonctionnalité. Sur des serveurs ou postes costauds, on peut laisser 20% sans souci (ex: 20% d’un disque 500 Go = 100 Go de cache).
- Utiliser les politiques d’arrière-plan par défaut : WUDO, couplé à BITS/LED BAT, gère bien la bande passante en arrière-plan. Il n’est généralement pas nécessaire de brider manuellement la bande passante. Toutefois, si vous constatez des saturations, vous pouvez employer les paramètres de limites absolues ou en pourcentage (par ex. Limit background download bandwidth) pour calmer le jeu aux heures de pointe. Une approche plus simple consiste à planifier via des fenêtres de maintenance quand les mises à jour sont lancées, afin que WUDO s’exécute préférentiellement la nuit ou en heures creuses.
En somme, la configuration recommandée pour une entreprise standard serait : DownloadMode = 2 (Groupe) avec un GroupID géré (comme le tenant Azure AD unique de l’entreprise, ce qui se fait automatiquement), cache de 10-20% du disque, ports 7680/3544 ouverts entre sites, et upload activé par défaut (les postes peuvent envoyer aux pairs quand ils ont fini de télécharger). Cette configuration assure un partage large et efficace. Dans une entreprise plus cloisonnée par site, on pourrait opter pour DownloadMode = 1 (LAN) dans chaque site, ce qui est plus restrictif mais encore très utile (chaque site profite du P2P en interne). Microsoft recommande le mode Groupe comme meilleure option par défaut pour réduire la bande passante WAN (Delivery Optimization reference | Microsoft Learn), à affiner selon votre contexte.
Optimisation du cache local et planification
WUDO repose sur le principe du cache distribué sur les clients : chaque poste conserve les fichiers téléchargés pendant un certain temps pour en faire profiter d’autres. Pour optimiser cela, il faut s’assurer que les postes conservent le contenu suffisamment longtemps et au bon moment :
- Durée de rétention du cache : Par défaut, un contenu reste dans le cache WUDO tant qu’il n’a pas besoin d’être purgé (quand la limite de taille est atteinte, WUDO évince les plus anciens en premier). Il n’y a pas de durée fixe de rétention. On veillera donc à ce que la limite de taille du cache ne soit pas trop faible, comme mentionné plus haut, pour éviter qu’un PC vide son cache avant d’avoir eu l’occasion de servir ses pairs. Par exemple, si le cache est ridiculement petit (1 Go) et qu’on télécharge un gros fichier de 4 Go, le cache va tout de suite supprimer d’autres choses. Une taille généreuse permet de couvrir plusieurs cycles de mise à jour.
- Moments de téléchargement (planification) : On ne pilote pas directement WUDO via un horaire (ce n’est pas planifiable comme les tâches). En revanche, on peut jouer sur la planification des déploiements eux-mêmes. Idéalement, échelonner le déploiement d’une grande mise à jour par vagues. Par exemple, déployer sur 10% des machines le jour 1, puis 30% le jour 2, etc. De cette façon, la première vague télécharge en grande partie depuis Internet (et en partie entre elles), puis les vagues suivantes auront de fortes chances de trouver la plupart du contenu localement sur les machines de la première vague. Cela amortit l’effet de pic et maximise l’utilisation du cache P2P. Si on envoie tout sur tout le monde simultanément, WUDO fonctionnera quand même (après tout, en simultané les pairs se découvriront et partageront), mais on risque d’avoir plus de trafic initial sur le lien externe avant que le partage ne s’amorce pleinement.
- Cas des PC éteints ou nomades: Le pair-à-pair suppose que les machines soient allumées et connectées ensemble. Pensez à garder allumés (ou réveillables) un certain nombre de PC clés pendant les fenêtres de mise à jour, sinon le bénéfice sera moindre. Par exemple, si tous les PC sont programmés pour s’éteindre la nuit et qu’on lance les updates la nuit, aucun partage ne se produira… À l’inverse, on peut utiliser l’option d’entretien automatique de Windows Update qui réveille les PC la nuit pour appliquer les updates – couplé à WUDO, ces PC réveillés peuvent se partager les fichiers sur le LAN en pleine nuit, ce qui est idéal. Pour les PC nomades (qui ne voient pas souvent le LAN), WUDO apportera moins de bénéfice, mais on peut éventuellement les faire bénéficier d’un cache cloud (voir Microsoft Connected Cache) ou du P2P sur VPN si on l’autorise.
En termes d’infrastructure, surveiller le bon fonctionnement du cache local implique de vérifier que les postes ne purgent pas trop souvent (via les indicateurs de cache, voir article 6). Si nécessaire, on peut ajuster DOMaxCacheSize ou même déplacer le cache sur un autre lecteur (via DOModifyCacheDrive si on veut utiliser une partition spécifique plus large).
Surveillance et ajustement continu
Mettre en place WUDO n’est pas un feu vert définitif – il convient d’observer son efficacité et d’ajuster les paramètres si besoin. Après déploiement, utilisez les outils de monitoring (voir article 6) pour vérifier des métriques telles que : la part des octets venant de pairs vs Internet, le nombre moyen de pairs utilisés par téléchargement, le taux de réussite du peering, etc. Par exemple, si vous constatez que seulement 10% du trafic vient des pairs et 90% d’Internet alors que vous espériez l’inverse, c’est qu’il y a peut-être un problème de configuration ou de topologie (pairs qui ne se voient pas, cache trop petit, etc.). Vous pourrez alors ajuster : peut-être passer du mode LAN au mode Groupe pour élargir le partage, augmenter la taille du cache, ou investiguer d’éventuels blocages réseau (firewall interne).
La surveillance doit être continue, surtout lors des premiers déploiements majeurs post-WUDO. Certains contenus se prêtent mieux au partage que d’autres (par exemple, les grosses mises à jour cumulatives mensuelles verront un excellent taux de partage, alors que des petites mises à jour différentes selon les postes verront peu de partage). Il faudra identifier les KPI de succès pertinents (voir article 6) et communiquer ces succès en interne (par ex: « Ce mois-ci 85% des données de patch ont été fournies via le réseau local grâce à WUDO, économisant 500 Go de trafic WAN »). Cela permet de justifier le maintien ou l’ajustement de la configuration.
Au fil du temps, tenez compte des évolutions de Windows. Par exemple, de nouveaux réglages WUDO peuvent apparaître (on a vu l’arrivée de DNS-SD, LEDBAT, etc.). Restez informé via la documentation Microsoft pour adapter les GPO/MDM en conséquence. De même, si l’entreprise change de structure (déménagement de sites, nouvelles lignes Internet, plus de travail à distance), il faudra peut-être reconsidérer le mode ou l’ajout d’un cache. WUDO est flexible mais dépend du contexte réseau qu’on lui offre.
En synthèse, la meilleure pratique est : configurer, surveiller, ajuster. Profitez des logs et rapports pour affiner la configuration avec le temps. Par exemple, si un site distant à faible bande passante ne profite pas assez du P2P inter-sites, envisagez d’y déployer un cache local (voir article 5 sur Microsoft Connected Cache). Si au contraire le réseau est impeccable et sous-utilisé, on pourrait même oser autoriser le partage entre sites distants plus largement. WUDO n’est pas une solution figée, elle gagne à être optimisée de manière itérative dans le cadre de votre stratégie de gestion des mises à jour.