On déploie un nouveau site distant, une vingtaine de postes derrière un lien WAN à débit limité. Le premier déploiement de mises à jour Windows via Configuration Manager sature la liaison en quelques minutes. Le problème n’est pas le volume total de données, c’est le moment et la méthode de transfert. Installer un branch distribution point sur ce site résout une partie du problème, mais sans réglages précis, on déplace simplement le goulot d’étranglement.
Pré-staging du contenu sur le distribution point : éviter le transfert initial massif
Le réflexe classique consiste à ajouter le rôle Distribution Point sur un serveur du site distant, puis à distribuer le contenu depuis la console Configuration Manager. Le contenu transite alors intégralement par le lien WAN. Sur une liaison partagée avec la téléphonie ou les applications métier, c’est exactement le scénario qui provoque des tickets d’incident.
L’alternative, c’est le pré-staging. On exporte le contenu sous forme de fichier compressé (.pkgx) depuis le site principal, on le copie sur un support physique ou via un transfert planifié hors heures ouvrées, puis on l’importe directement sur le serveur distant. Le lien WAN ne voit passer que les deltas ultérieurs, pas la charge initiale.
Pour que le pré-staging fonctionne sans surprise, il faut cocher l’option « Prestage content » dans les propriétés du distribution point lors de l’installation du rôle. Sans cette case, Configuration Manager tente de redistribuer l’intégralité du package à la prochaine évaluation, ce qui annule tout le bénéfice.
Planification de la bande passante et rate limiting dans Configuration Manager
Même après le pré-staging initial, chaque nouveau package, chaque mise à jour cumulative va transiter vers le branch distribution point. La configuration par défaut de Configuration Manager n’applique aucune limite de débit sur ces transferts.
Rate limiting par plage horaire
Dans les propriétés du distribution point, l’onglet « Rate Limits » permet de fixer un pourcentage maximal de bande passante utilisé par les transferts SCCM. On peut définir des créneaux distincts :
- Heures ouvrées (8h-18h) : limiter le transfert à une fraction modeste de la bande passante disponible pour préserver les usages métier
- Heures creuses (18h-8h, week-ends) : autoriser un débit plus large, voire illimité, pour que les packages volumineux arrivent avant le lundi matin
- Fenêtres de maintenance réseau : bloquer totalement les transferts pendant les opérations planifiées sur l’infrastructure WAN
Ce réglage agit côté serveur de site, sur le flux entre le site principal et le distribution point. Il ne contrôle pas ce que les clients téléchargent depuis le DP local, ce qui relève d’un autre mécanisme.
BITS throttling côté client
Les postes clients utilisent le service BITS (Background Intelligent Transfer Service) pour récupérer le contenu depuis le distribution point local. On peut piloter BITS via des stratégies de groupe (GPO) pour limiter le débit en heures ouvrées. Combiner rate limiting serveur et BITS throttling client couvre les deux segments du chemin réseau.
Delivery Optimization et seeder ring : réduire la charge sur le distribution point lui-même
Même avec un DP local correctement approvisionné, si les vingt postes du site lancent simultanément le téléchargement d’une mise à jour Windows, le serveur et le switch local encaissent un pic de charge. C’est là que Delivery Optimization entre en jeu.
Microsoft recommande de configurer Delivery Optimization en Group Mode avec un identifiant de groupe dédié par site. Concrètement, on attribue un GroupID unique à chaque agence ou branche. Les machines d’un même site partagent entre elles les fragments de contenu déjà téléchargés, en pair-à-pair, sans traverser le WAN ni même solliciter le DP pour chaque octet.
L’approche du « seeder ring » complète ce mécanisme. On déploie d’abord la mise à jour sur un petit groupe de machines du site distant. Ces premières machines remplissent le cache pair-à-pair local. Quand on étend le déploiement aux autres postes, la majorité du contenu provient des pairs locaux, pas du serveur.
Les retours varient sur le gain exact selon la topologie locale et le nombre de postes, mais le principe reste le même : plus le cache local est alimenté avant la vague principale, moins le DP et le lien WAN sont sollicités.
BranchCache en mode distribué ou hébergé : quand l’activer
BranchCache est une fonctionnalité native de Windows Server qui met en cache le contenu téléchargé depuis le site principal. Deux modes existent, et le choix dépend de l’infrastructure du site distant.
En mode distribué, chaque poste client met en cache les fichiers qu’il télécharge et les partage avec les autres clients du même sous-réseau. Aucun serveur local n’est nécessaire. Ce mode convient aux petits sites sans matériel dédié.
En mode hébergé, un serveur local (qui peut être le même que le distribution point) stocke le cache de façon centralisée. Les clients y déposent le contenu téléchargé et les autres postes le récupèrent depuis ce serveur. Ce mode est plus fiable quand les postes s’éteignent fréquemment, car le cache survit à l’arrêt des machines individuelles.
- Activer BranchCache sur le distribution point dans les propriétés du rôle (case « Enable and configure BranchCache for this distribution point »)
- Configurer les clients via GPO pour utiliser le mode distribué ou hébergé selon le site
- Vérifier que le pare-feu local autorise le trafic BranchCache entre les postes du sous-réseau
BranchCache et Delivery Optimization peuvent coexister, mais sur des contenus différents. Delivery Optimization gère principalement les mises à jour Windows et les applications du Microsoft Store, tandis que BranchCache couvre les packages SCCM classiques. Activer les deux côte à côte couvre l’ensemble du spectre de contenu distribué vers les sites distants.
Supervision du distribution point et détection des goulets réseau
Un branch distribution point mal supervisé finit par poser problème silencieusement. Le contenu échoue à se distribuer, les clients basculent sur le DP du site principal via le WAN, et la saturation revient sans alerte visible dans la console.
Dans Configuration Manager, le nœud « Distribution Point Configuration Status » signale les packages en erreur ou en attente de redistribution. On surveille aussi les compteurs de performance BITS sur le serveur distant pour détecter les files d’attente anormalement longues.
Côté réseau, un monitoring SNMP ou NetFlow sur le routeur du site distant permet de corréler les pics de trafic WAN avec les fenêtres de distribution. Si on observe du trafic SCCM en dehors des créneaux configurés, c’est qu’un client contourne le DP local, souvent à cause d’un problème de boundary group mal défini.
La combinaison pré-staging, rate limiting, Delivery Optimization en Group Mode et BranchCache forme un ensemble cohérent. Chaque couche traite un segment du problème. Négliger l’une d’elles laisse une brèche par laquelle le trafic WAN s’engouffre.
