Un Branch Distribution Point qui cesse de distribuer du contenu génère rarement une alerte explicite dans la console ConfigMgr. Le dysfonctionnement se manifeste côté client : échecs de téléchargement, basculement silencieux vers un DP distant, temps de déploiement qui explosent. Diagnostiquer un Branch Distribution Point exige de croiser les journaux serveur et client, puis de vérifier trois couches distinctes : connectivité réseau, authentification et intégrité du cache local.
Fichiers journaux SCCM à surveiller sur un Branch Distribution Point en panne
La première action consiste à identifier le bon fichier journal. Sur le serveur de site, distmgr.log trace la distribution du contenu vers chaque DP. Une erreur récurrente de type « Failed to create/access the content share » dans ce journal pointe vers un problème de droits NTFS ou de partage SMB sur la machine Branch DP.
Côté Branch DP lui-même, le fichier smsdpprov.log enregistre les opérations du fournisseur WMI local. Un échec d’enregistrement du contenu dans le cache apparaît ici avant d’être visible ailleurs. Sur les versions récentes de ConfigMgr, PullDP.log s’ajoute si le rôle Pull Distribution Point est activé en complément.
Côté client, ContentTransferManager.log et DataTransferService.log révèlent si la machine tente bien de contacter le Branch DP ou bascule sur un autre point de distribution. Un basculement systématique indique que le client considère le Branch DP comme indisponible, même si la machine est en ligne.
Problèmes d’authentification Kerberos et NTLM sur un Branch DP
Un Branch Distribution Point installé sur un poste client ou un petit serveur de proximité est particulièrement exposé aux erreurs d’authentification. Contrairement à un DP standard hébergé sur un serveur membre du domaine correctement géré, le Branch DP fonctionne souvent sur une machine dont le compte ordinateur Active Directory n’est pas toujours synchronisé.
Nous observons fréquemment des échecs Kerberos silencieux : le site tente une connexion authentifiée, échoue, puis retombe en NTLM, qui peut lui aussi être bloqué par une stratégie de groupe restrictive. Le résultat dans distmgr.log est un code d’erreur générique (0x80070005 – accès refusé) qui ne mentionne pas explicitement Kerberos.
Vérifications à effectuer sur l’authentification
- Confirmer que le compte ordinateur du Branch DP n’est pas tombé dans un conteneur « Disabled » ou « Stale » dans Active Directory. Un reset du canal sécurisé (commande
nltest /sc_reset) règle la majorité des cas. - Vérifier que le SPN (Service Principal Name) HTTP est bien enregistré pour le FQDN du Branch DP. Une absence de SPN force un fallback NTLM systématique.
- Contrôler les GPO appliquées à la machine : une politique « Network security: Restrict NTLM » trop agressive bloque le repli NTLM sans que ConfigMgr ne le signale clairement.
Cache de contenu saturé ou corrompu sur le Branch Distribution Point
Le Branch DP stocke le contenu dans un répertoire local dont la taille n’est pas surveillée nativement par ConfigMgr avec la même granularité qu’un DP standard. Un disque saturé est la cause de panne la plus fréquente sur les Branch DP, en particulier sur les machines disposant d’un volume système unique.
La vérification se fait en deux temps. D’abord, contrôler l’espace disque disponible sur le volume hébergeant le partage SCCMContentLib$. Ensuite, valider l’intégrité de la bibliothèque de contenu elle-même à l’aide de l’outil Content Library Explorer (ContentLibraryExplorer.exe), fourni dans le toolkit ConfigMgr.
Corruption de la bibliothèque de contenu
Quand un transfert est interrompu (redémarrage, perte réseau), la bibliothèque de contenu peut se retrouver dans un état incohérent. Le symptôme typique : distmgr.log indique que le package est « already present » sur le DP, mais le client reçoit une erreur de téléchargement. La redistribution depuis la console échoue aussi parce que ConfigMgr considère le contenu comme déjà validé.
Nous recommandons dans ce cas de supprimer puis redistribuer le package concerné plutôt que de tenter une réparation manuelle des fichiers INI de la bibliothèque. Sur un Branch DP avec peu de packages, la redistribution complète reste l’approche la plus fiable.
Connectivité SMB et HTTP entre le site ConfigMgr et le Branch DP
Le serveur de site communique avec le Branch DP via SMB (partage administratif, copie de contenu) et HTTP/HTTPS (enregistrement du DP, rapports d’état). Un pare-feu intermédiaire qui bloque le port 445 coupe la distribution sans générer d’alerte côté console.
Le piège classique : le Branch DP est situé dans un site distant relié par un VPN site-à-site. Les règles de pare-feu autorisent le trafic client (HTTP 80/443) mais omettent le trafic SMB serveur-à-serveur. La distribution échoue, les clients du site distant ne trouvent pas de contenu local, et tout le trafic passe par le WAN vers un DP central.
Points de contrôle réseau
- Tester la résolution DNS du FQDN du Branch DP depuis le serveur de site, et inversement. Une résolution par IP seule empêche l’authentification Kerberos.
- Valider la connectivité sur les ports 445 (SMB), 80 ou 443 (HTTP/HTTPS) et 135 (RPC endpoint mapper) avec un test ciblé depuis le serveur de site.
- Vérifier que le Branch DP est bien rattaché au boundary group correspondant à son sous-réseau. Un DP non associé à un boundary group n’est jamais proposé aux clients, même s’il fonctionne.
Alternatives au Branch DP : Peer Cache et Delivery Optimization
Microsoft oriente désormais la conception vers des Distribution Points standards intégrés au modèle de boundary groups, en combinaison avec des mécanismes de cache pair-à-pair. Peer Cache, disponible nativement dans ConfigMgr, permet à un client qui a déjà téléchargé un package de le servir aux autres clients du même boundary group, sans infrastructure serveur supplémentaire.
Delivery Optimization (intégré à Windows) complète ce dispositif pour les mises à jour et les applications Windows Store. Sur les sites distants avec une bande passante limitée, cette combinaison remplace avantageusement un Branch DP vieillissant tout en réduisant la surface de maintenance.
Avant de passer du temps à diagnostiquer un Branch DP récurrent en erreur, il vaut la peine d’évaluer si la migration vers un DP standard ou l’activation de Peer Cache ne serait pas plus rentable. Un Branch DP qui tombe en panne régulièrement signale souvent un matériel ou un réseau sous-dimensionné pour ce rôle, et aucun correctif logiciel ne compense un défaut d’infrastructure.
