[SCCM] – Contrôle de bande passante entre le site et les points de distribution

Nous allons voir comment gérer dans SCCM la bande passante entre le site principal et les points de distribution.

Le point de distribution y’a pas à dire c’est une belle invention, grâce à eux les clients d’un site distant peuvent télécharger les 400Mo de votre application Framework .Net 45 depuis un point de stockage local, vous évitant ainsi une pénible saturation de votre lien intersites.

Le problème c’est que les 400Mo de votre application doivent malgré tout arriver au moins une fois sur le point de distribution de votre site distant. Heureusement SCCM propose des mécanismes intégrés pour vous permettre d’avoir du contrôle sur la manière dont les contenus sont envoyés vers les points de distribution.

Le contrôle de bande passante

Les points de distribution proposent dans leurs propriétés deux onglets pour le contrôle de la bande passante :

Le Calendrier (Schedule)

Vous pourrez définir ici des autorisations refus de transfert de contenu en fonction de la priorité du contenu.

Chaque élément déployable dispose dans ses propriétés d’un onglet paramètres de distribution qui vous permet de lui assigner une priorité.

En fonction de cette priorité et des créneaux horaires vos packages pourront ou non être transférés entre le site et le DP.

La limitation (Rate Limits)

Cet écran vous propose trois options de transfert :

• Illimité : L’envoi du package utilise la totalité du réseau disponible.
• Pulse Mode : L’envoi est segmenté en blocs dont vous choisissez la taille entre 1 et 256Ko. Vous pouvez ensuite choisir le délai entre l’envoi de chaque blocs entre 1 et 30 secondes.
• Taux de transfert : Vous choisissez les créneaux horaires pendant lesquels vous allouez un pourcentage de taux de transfert. L’envoi sera alors segmenté en unités temporelles, pendant X% du temps l’envoi se fera avec toute la bande passante que SCCM pourra trouver. L’unité de temps est déterminée par SCCM vous n’avez pas de contrôle dessus.

Le contrôle du taux de transfert dans les faits

Un déploiement sans aucune restriction. SCCM fait ici des pointes à presque 50Mo/s. Le taux de transferts est assez irrégulier cela étant dû à la succession de fichiers de tailles variées à transférer.
Taux de transfert à 10%. Après un peu d’hésitation SCCM a estimé le gap entre deux envois à 4 secondes. Pendant le pic SCCM n’a pas le temps de dépasser 1Mo/s.
Mode pulse, blocs de 256Ko toutes les deux secondes.

Les risques du calendrier

Il y a avec ces mécanismes une question qu’il est légitime de se poser et que certains ont souvent subi :

Que se passe-t-il si un package est toujours en cours d’envoi lorsque le calendrier du DP décide de bloquer certaines priorités.

Voici la réponse :

On voit clairement ici qu’à 11h précise le DP bloque le transfert, exactement comme ça configuration le lui ordonne, le log nous montre clairement la coupure et le message d’erreur qui s’ensuit.

Coté console, le contenu est effectivement marqué comme étant en erreur nous avons du coup un beau message d’erreur :

Là où les choses sont vraiment bien faites c’est que le contenu du message n’a strictement aucun rapport avec la cause de l’arrêt du transfert…

En revanche, dès la réouverture de créneau pour le contenu, le transfert reprendra là où il s’est arrêté.

Faites donc attention avec le calendrier, et ne paniquez pas en cas de message d’erreur.

La solution extrême pour les cas extrêmes : Le contenu préparé

Le contenu préparé consiste tout simplement à vous affranchir du réseau pour envoyer vos contenus. Dans ce cas vous créez et distribuez votre application Framework .Net et c’est à vous de vous de choisir le moyen d’envoi du contenu : clé USB, FTP, Pigeon voyageur…

Ce processus à l’avantage de n’avoir aucune empreinte du le réseau si ce n’est l’envoi de quelques métadonnées au DP. Par contre la génération du fichier de contenu ainsi que l’envoi est du coup manuel, l’opération peut donc se révéler fastidieuse ou nécessiter un peu de Scripting.

Le processus est par contre très simple :

Vous activez votre DP pour le contenu préparé.
Vous créez votre application / package / OS…, puis, vous sélectionnez ce que vous voulez envoyer et vous faites « Créer du contenu préparé ».
Laissez-vous guider par l’assistant et créez votre contenu. Notez bien qu’a un moment donné, l’assistant vous demande un point de distribution. Il s’agit du DP qui sera utiliser pour générer le fichier, après tout vous ne travaillez peut-être pas dans le même lieu que le serveur SCCM. Il faut donc avoir déjà distribué votre contenu sur un DP non préparé.
Une fois le fichier créé. Utilisez l’assistant de distribution du contenu et ciblez votre DP. Le fait que le DP soit marqué comme étant pour du contenu préparé fait qu’aucun transfert ne démarre. Par contre désormais le DP est en attente du contenu.
Maintenant à vous de copier le contenu localement sur le DP. Ajoutez aussi « extractcontent.exe » présent dans Bin\x64 (ou x86 selon votre DP) du dossier d’installation de SCCM.
Lancez la commande : Extractcontent.exe /P:<dossier> /S
Une fois la commande terminée, le package est bien sur le DP.

Le cas des DP d’extraction (Pull DP)

Les pull DP sont un cas particulier. Au lieu de prendre leur contenu dans la librairie d’un serveur de site, ils vont se fournir auprès d’un autre DP. Cette solution présente des réels gains en termes d’architecture et de contournement de certaines limitations.

Par contre les pull DP n’ont pas d’onglet « schedule » et « rate limits », si vous souhaitez contrôler leur usage de bande passante il faudra passer par les paramètres BITS du client SCCM comme pour tout autre ordinateur client.

Les logs utiles

Pour monitorer un peu les DP vous pourrez vous baser sur 3 logs :

Coté serveur principal

• Distrmgr.log pour l’installation, configuration des DP. Démarrage et fin des taches de distribution de contenu.
• PkgXferMgr.log pour le détail de chaque job de transfert.

Coté DP

• Dans SMS_DP$\sms\logs vous trouverez smsdpprov.log qui traite de la santé du DP.

Petit bonus, pour savoir sur quel DP un client télécharge son contenu : CAS.log et DataTransferService.log

• SCCM