Le Branch Distribution Point dans SCCM (Configuration Manager) traîne une réputation ambiguë. Côté théorie, il promet une réduction de la charge réseau en positionnant du contenu au plus près des sites distants. En pratique, nous observons que son utilité a considérablement diminué avec les évolutions récentes de Configuration Manager Current Branch, au point de devenir un piège opérationnel pour les équipes qui le déploient par réflexe.
Logique de fallback client dans Configuration Manager Current Branch
Les versions récentes de Configuration Manager ont profondément remanié la façon dont un client localise du contenu. L’ancienne mécanique d’emplacement de contenu de secours préféré, qui justifiait historiquement la multiplication de petits DP dans chaque agence, a été abandonnée.
Le client Configuration Manager négocie désormais ses sources de contenu de manière plus dynamique. Il interroge les boundary groups, applique les règles de fallback configurées par l’administrateur, et bascule automatiquement vers un DP accessible si le DP local ne répond pas ou ne dispose pas du contenu demandé. Cette logique rend le Branch DP superflu dans la majorité des topologies.
Concrètement, un site distant avec une liaison WAN correctement dimensionnée n’a plus besoin d’un serveur physique local jouant le rôle de DP. Le client sait chercher ailleurs, et les mécanismes de Delivery Optimization ou de BranchCache côté Windows complètent le dispositif sans infrastructure serveur supplémentaire.
Coût de maintenance d’un Branch Distribution Point SCCM
Déployer un Branch DP ne se limite pas à cocher une case dans la console. Chaque DP distant est un rôle de système de site qui exige un socle technique maintenu à jour. À partir de la version 2303, Configuration Manager impose .NET 4.8 et le driver ODBC SQL sur tout serveur hébergeant un rôle de site.
Sur un site central bien administré, ces prérequis passent inaperçus. Sur une dizaine de petits serveurs disséminés dans des agences, la charge de patching et de conformité explose. Nous recommandons de lister les coûts réels avant de provisionner un Branch DP :
- Licence Windows Server (ou allocation de ressources si VM), maintenance du système d’exploitation, mises à jour cumulatives mensuelles
- Surveillance du rôle DP (espace disque pour la bibliothèque de contenu, état de réplication, certificats si HTTPS)
- Gestion des prérequis Configuration Manager lors de chaque montée de version (vérification .NET, ODBC, IIS, WSUS si co-hébergé)
- Intervention sur site en cas de panne matérielle, sans équipe IT locale dans beaucoup d’agences
Ce coût récurrent est rarement mis en balance avec le gain réseau attendu, qui reste souvent marginal face aux alternatives.
Alternatives au Branch DP : BranchCache, Delivery Optimization et Peer Cache
La vraie question n’est pas de savoir si un Branch DP fonctionne (il fonctionne), mais s’il apporte quelque chose que des mécanismes natifs Windows ne couvrent pas déjà.
BranchCache en mode distribué
BranchCache distribué transforme chaque poste client en cache local. Le premier poste qui télécharge un package depuis le DP central met le contenu à disposition des autres postes du même sous-réseau. Aucun serveur local requis. BranchCache couvre le cas d’usage principal du Branch DP sans infrastructure dédiée.
L’activation se fait par GPO et par configuration du DP source (case à cocher dans les propriétés du DP). Le coût opérationnel est quasi nul comparé à un serveur supplémentaire.
Delivery Optimization et Peer Cache ConfigMgr
Delivery Optimization, natif dans Windows, gère le partage de contenu entre pairs pour les mises à jour Windows, les applications du Microsoft Store et les packages ConfigMgr via Microsoft Connected Cache. Peer Cache ConfigMgr étend ce principe aux déploiements applicatifs et aux séquences de tâches.
En combinant ces deux mécanismes, un site distant consomme la bande passante WAN une seule fois par contenu, puis redistribue localement. Le résultat est identique à celui d’un Branch DP, sans serveur à maintenir.
Cas où le Branch Distribution Point reste pertinent
Affirmer que le Branch DP est toujours une mauvaise idée serait excessif. Quelques scénarios justifient encore son existence.
Le premier concerne les sites avec PXE boot pour le déploiement d’OS. Peer Cache et BranchCache ne servent pas une image WinPE sur le réseau. Si vous faites du bare metal sur un site distant, un DP local avec PXE activé reste la seule option sans manipulation physique (clé USB, média préparé).
Le second concerne les liaisons WAN très contraintes (satellite, liaisons à débit inférieur à quelques mégabits) où même un premier téléchargement complet poserait problème. Dans ce cas, un DP préparé (prestaged content) permet d’expédier le contenu sur disque physique plutôt que de saturer le lien.
En dehors de ces deux cas, le Branch DP ajoute de la complexité sans gain proportionnel.
Dimensionnement et configuration si vous déployez quand même un DP distant
Pour les sites qui répondent aux critères ci-dessus, le dimensionnement du serveur DP mérite attention. Les recommandations matérielles dépendent directement du volume de contenu hébergé et de l’activation du PXE.
- Stockage : prévoir un volume dédié à la bibliothèque de contenu (SCCMContentLib), dimensionné à la taille totale des packages distribués plus une marge de rotation
- Mémoire et CPU : un DP standard sans rôle supplémentaire fonctionne avec des ressources modestes, mais l’activation de Microsoft Connected Cache (pour le cache Delivery Optimization côté serveur) augmente la consommation mémoire
- Réseau : si le DP est aussi PXE responder, une carte réseau gigabit minimum sur le VLAN de déploiement, avec les ports DHCP/TFTP ouverts
Configurer le DP en pull distribution point plutôt qu’en mode push classique réduit la charge sur le serveur de site primaire. Le DP distant va chercher le contenu lui-même auprès d’un DP source désigné, ce qui lisse les transferts et évite les timeouts sur les liaisons lentes.
Le Branch Distribution Point dans SCCM répond à un besoin qui existait pleinement dans les architectures ConfigMgr 2007 et 2012. Avec Configuration Manager Current Branch, les mécanismes de cache pair à pair et la logique de fallback rendent ce rôle redondant dans la plupart des topologies. Réservez-le aux sites qui exigent du PXE local ou dont la liaison réseau ne supporte pas un seul transfert initial complet.
