Distribuer du contenu applicatif ou des mises à jour vers des sites distants reste un problème d’architecture réseau récurrent. Le branch distribution point, qu’il soit un rôle SCCM classique ou un cache connecté Microsoft (MCC), occupe une place centrale dans cette mécanique.
Les recommandations récentes de Microsoft déplacent le curseur : la logique de cache se centralise sur MCC couplé à Delivery Optimization (DO), tandis que le branch DP traditionnel voit son périmètre se réduire. Reste à déterminer où, physiquement et logiquement, positionner ce relais dans l’infrastructure.
Cache réseau en site distant : pourquoi le branch distribution point ne suffit plus seul
Le rôle de distribution point dans SCCM (ou son successeur Microsoft Endpoint Configuration Manager) a longtemps été la réponse par défaut pour alimenter les postes d’une filiale sans saturer le lien WAN. Un serveur local stocke les packages, les images système, les mises à jour, et les distribue sur le LAN.
Ce modèle fonctionne, mais il impose un serveur dédié (ou semi-dédié) par site, avec sa maintenance, ses droits, son espace disque. Multiplier les branch DPs « légers » sur chaque petit site crée une dette opérationnelle : synchronisation du contenu, surveillance de la réplication, gestion des certificats.
Les guides récents recommandent de centraliser la logique de cache sur MCC plutôt que de déployer un DP par emplacement. MCC agit comme un cache transparent à la demande pour le contenu téléchargé via Delivery Optimization. Le contenu ne transite qu’une fois par le WAN, puis le serveur MCC le sert localement aux autres postes du site.
MCC et Delivery Optimization : le nouveau socle de cache pour sites distants
Microsoft Connected Cache s’installe sur un point de distribution Configuration Manager existant ou sur une VM dédiée toujours disponible sur le site. Son fonctionnement diffère du branch DP classique sur un point fondamental : il ne stocke pas un catalogue de packages prérépliqués, il met en cache le contenu à la volée, à mesure que les clients le demandent via DO.
Ce cache est séparé du contenu du point de distribution. Même si MCC et le rôle DP partagent le même serveur, les deux pools de données restent distincts. Concrètement, un poste client qui télécharge une application Win32 via Intune ou une mise à jour Windows peut la récupérer depuis le cache MCC local, sans solliciter le WAN une seconde fois.
Deployment rings pour lisser la charge WAN
Déployer du contenu sur un site distant sans précaution revient à créer un pic de trafic WAN au moment où tous les postes demandent le même fichier simultanément. Les recommandations actuelles préconisent d’encadrer la diffusion par des deployment rings : un premier anneau restreint de « seeders » peuple le cache MCC, puis des anneaux successifs récupèrent le contenu localement.
Cette approche suppose que le cache soit déjà alimenté avant que la majorité des postes ne lance le téléchargement. Le dimensionnement du premier ring dépend de la bande passante WAN disponible et de la taille du contenu distribué.
Découverte dynamique du cache par DHCP : option 235 et limites connues
Placer un serveur MCC sur chaque site ne résout pas tout si les postes ne savent pas quel cache interroger. La découverte du serveur MCC passe par l’option DHCP 235, qui pointe vers le FQDN du cache local. Un poste qui obtient son bail DHCP récupère automatiquement l’adresse du cache correspondant à son emplacement réseau.
Ce mécanisme évite de configurer manuellement chaque client ou de maintenir des GPO par site. En revanche, des retours terrain sur les infrastructures SCCM signalent que Microsoft déconseille l’usage d’options DHCP pour certains rôles réseau sensibles, notamment le routage PXE/boot, où les IP helpers au niveau des routeurs restent préférés.
La coexistence de l’option 235 pour MCC et d’autres options DHCP personnalisées mérite une validation sur chaque infrastructure. Les retours divergent sur ce point selon la complexité du réseau et le nombre de scopes DHCP gérés.
- L’option DHCP 235 doit pointer vers le FQDN du serveur MCC, pas vers une IP fixe, pour faciliter la bascule en cas de migration ou de panne.
- Sur les sites avec plusieurs VLANs, chaque scope DHCP doit porter l’option 235 correspondant au cache local du segment.
- Les environnements qui utilisent déjà des options DHCP personnalisées (PXE, téléphonie IP) doivent vérifier l’absence de conflit d’options.
Placement physique du cache : critères de décision pour chaque type de site
Le choix de l’emplacement d’un branch distribution point ou d’un serveur MCC dépend de paramètres concrets qui varient d’un site à l’autre. Un site distant de vingt postes connecté par un lien MPLS à faible débit n’a pas les mêmes besoins qu’un campus régional de plusieurs centaines de machines relié par fibre noire.
Sites avec serveur local existant
Si un serveur physique ou une VM tourne déjà sur le site (contrôleur de domaine, serveur d’impression), ajouter le rôle MCC sur cette machine est l’option la plus directe. Le cache partage les ressources du serveur existant, ce qui réduit le coût matériel. Le point d’attention reste l’espace disque : MCC stocke le contenu DO de façon indépendante du rôle DP éventuel.
Sites sans infrastructure locale
Pour les petits sites sans serveur, deux options se présentent. La première : compter uniquement sur le peering DO entre postes clients, sans cache serveur. Les postes qui ont déjà téléchargé un contenu le partagent avec leurs voisins sur le même sous-réseau. La seconde : déployer un micro-serveur ou un NUC dédié au rôle MCC, ce qui suppose un investissement matériel modeste mais une gestion supplémentaire.
Les données disponibles ne permettent pas de fixer un seuil universel de nombre de postes au-delà duquel un cache serveur devient rentable. Le facteur déterminant reste le ratio entre la taille des contenus distribués et la bande passante WAN du site.
- Un site avec un lien WAN inférieur à quelques dizaines de Mbps et des déploiements fréquents de packages volumineux justifie un cache MCC local.
- Un site avec un lien fibre haut débit et peu de postes peut se contenter du peering DO sans serveur dédié.
- Les sites hybrides (postes cogérés Intune + SCCM) bénéficient le plus de MCC, car le cache couvre à la fois les apps Win32 Intune et les mises à jour Windows.
Branch distribution point SCCM ou MCC : deux rôles, deux logiques de placement
Le branch DP SCCM et MCC ne sont pas interchangeables. Le DP classique réplique un catalogue défini par l’administrateur : seuls les packages explicitement distribués vers ce DP sont disponibles localement. MCC, lui, met en cache tout contenu transité via DO, sans action manuelle de distribution.
Dans une infrastructure en transition vers Intune et la cogestion, MCC couvre un spectre plus large que le DP traditionnel. Les appareils uniquement cloud (inscrits dans Intune sans client Configuration Manager) peuvent aussi profiter du cache MCC, ce qui n’est pas le cas d’un branch DP SCCM classique.
Conserver un branch DP reste pertinent pour les scénarios qui ne passent pas par DO : déploiement d’images OS via PXE, séquences de tâches lourdes, packages legacy non compatibles DO. Sur ces cas d’usage, le DP local reste le seul mécanisme de cache côté serveur.
La stratégie de cache la plus robuste combine les deux rôles sur le même serveur physique pour les sites qui le justifient, en séparant clairement les volumes de stockage. Pour les sites plus modestes, MCC seul couplé au peering DO remplace avantageusement un branch DP dédié, à condition que les déploiements OS ne fassent pas partie des besoins du site.
