Sur un site distant sans serveur dédié, distribuer des mises à jour ou des applications via Configuration Manager pose un problème concret : la bande passante du lien WAN ne suit pas, et installer un serveur complet sur place coûte cher. C’est précisément dans ce scénario qu’un Branch Distribution Point prend son sens face à un point de distribution classique.
Les deux remplissent le même rôle (mettre du contenu à disposition des clients), mais leur fonctionnement, leur dimensionnement et leurs limites divergent nettement.
Branch Distribution Point : un poste de travail suffit pour distribuer du contenu
Le Branch Distribution Point (BDP) a été conçu pour les bureaux distants dépourvus d’infrastructure serveur. On installe le rôle directement sur un poste de travail Windows standard, sans OS serveur. Le poste télécharge le contenu à la demande, lorsque ses clients locaux en ont besoin, ou via un pré-chargement planifié.
La gestion de la bande passante repose sur BITS (Background Intelligent Transfer Service), qui régule le débit pour ne pas saturer le lien WAN. Concrètement, un BDP ne stocke que le contenu demandé par les postes qui lui sont rattachés, ce qui limite l’espace disque nécessaire.
Cette approche convient aux petits sites (quelques dizaines de postes) où déployer un serveur physique ou virtuel serait disproportionné. On gagne en coût matériel et en licence, mais on accepte des compromis sur la capacité de traitement simultané.
Point de distribution classique dans Configuration Manager : architecture et rôle serveur
Un point de distribution standard (DP) fonctionne sur un serveur Windows dédié. Le serveur de site pousse le contenu vers le DP via le composant gestionnaire de distribution. Le DP stocke l’intégralité du contenu qui lui est assigné, prêt à être servi à tout moment.
Cette architecture suppose un investissement matériel plus lourd : serveur, stockage dimensionné pour l’ensemble des packages, licences OS serveur. En contrepartie, le DP classique gère un volume de clients et de contenu bien supérieur à un BDP.
Le DP classique peut aussi être configuré en mode « pull » (point de distribution par extraction). Dans ce cas, au lieu de recevoir le contenu poussé par le serveur de site, il le télécharge depuis un autre DP désigné comme source. Ce mécanisme réduit la charge sur le serveur de site lorsqu’on multiplie les points de distribution.
Pull DP et chaînes de distribution : une contrainte de topologie récente
En cascade, on peut chaîner des pull DPs : un DP source alimente un premier pull DP, qui alimente un deuxième, et ainsi de suite. Cette souplesse est tentante pour les architectures multi-site, mais elle introduit un risque de boucle de dépendance.
Configuration Manager intègre désormais un mécanisme de validation via WMI (GetChainedPullDPs dans la classe SMSDistributionPointInfo) qui vérifie qu’un pull DP ne peut pas être configuré comme source d’un DP qui dépend déjà de lui, directement ou indirectement. Les boucles de type DP1 vers DP2 vers DP3 vers DP1 sont bloquées automatiquement.
Cette évolution change la donne pour les administrateurs qui empilaient des pull DPs sans contrôle systématique. Avant de dessiner une topologie en cascade, on vérifie maintenant la chaîne complète de dépendances dans la console.
BDP ou DP classique : critères de choix selon le terrain
Le choix entre un Branch Distribution Point et un DP classique ne se résume pas à une question de budget. Voici les critères opérationnels qui orientent la décision :
- Nombre de postes sur le site distant : en dessous de quelques dizaines de machines, un BDP installé sur un poste de travail couvre le besoin sans infrastructure serveur supplémentaire.
- Volume de contenu à distribuer : si le site reçoit des déploiements d’OS complets ou des packages volumineux, un DP classique avec du stockage dédié évite les goulets d’étranglement sur le disque du poste BDP.
- Bande passante WAN disponible : un BDP avec BITS régule le téléchargement, mais un DP classique en mode pull offre davantage de contrôle sur la planification et les sources multiples.
- Tolérance de panne : un DP sur serveur dédié peut être redondé plus facilement qu’un BDP installé sur le poste d’un utilisateur qui éteint sa machine le soir.
Les retours varient sur la fiabilité d’un BDP dans la durée, notamment quand le poste hôte est sollicité par d’autres tâches. Sur un site critique, un DP classique reste le choix le plus prévisible.
Combiner pull DP et cache peer-to-peer plutôt que multiplier les BDP
Les recommandations d’architecture récentes pour Configuration Manager encouragent une approche hybride. Plutôt que de déployer un BDP sur chaque petit site, on combine un pull DP centralisé avec des technologies de cache peer-to-peer comme BranchCache ou Delivery Optimization.
BranchCache permet aux postes d’un même sous-réseau de partager entre eux le contenu déjà téléchargé. Un seul poste télécharge le package, les autres le récupèrent localement. Delivery Optimization fonctionne sur un principe similaire avec un périmètre configurable par frontières.
Cette combinaison réduit le trafic WAN sans exiger de rôle DP ou BDP sur chaque site. On conserve un pull DP par zone géographique large, et le cache local fait le reste. Pour un réseau avec de nombreuses petites agences, c’est souvent plus simple à maintenir que des dizaines de BDP dispersés.
Le choix final dépend toujours du contexte réseau et du volume de déploiements. Un BDP reste pertinent quand le lien WAN est trop lent pour que le peer-to-peer seul suffise, ou quand les postes du site ne sont pas allumés en même temps. Un DP classique s’impose dès que le nombre de clients ou la criticité du contenu justifie un serveur dédié. L’architecture la plus solide combine souvent les trois approches selon les contraintes de chaque site.
