Distribute the content for this package to preferred distribution points

Le contenu sera alors automatiquement copié vers ce(s) DP lorsque ce même client en fera la demande la première fois, grâce à l’option « Distribute the content for this package to preferred distribution points ». Le prochain utilisateur du site qui en fera la demande l’aura ainsi à disposition sur le DP local. Ce mode de fonctionnement doit donc permettre de faire des économies d’espace disque sur les « Distribution Point » et de ne copier que ce qui est réellement nécessaire aux utilisateurs des sites distants.

Qu’en est-il vraiment ? Sur le papier, cela paraît simple. Il suffirait de sélectionner pour chaque application et/ou package l’option « Distribute the content for this package to preferred distribution points » et attendre que le premier utilisateur/ordinateur du site demande ce contenu. Cependant il faut considérer plusieurs scénarios et certains vont nécessiter quelques ajustements supplémentaires.

En résumé, lorsqu’un client SCCM essaie de localiser le contenu d’une application/package et que celui-ci n’est pas disponible sur le « Distribution Point » préféré, le « Management Point » capte la demande et crée un fichier .DMD dans le répertoire inboxes\distmgr.box\incoming sur le serveur de site primaire. Ce fichier .DMD contient le PackageID ainsi que le nom du « Distribution Point » qui est concerné. Une fois le fichier traité par le composant « Distribution Manager », la copie du contenu vers le Distribution Point préféré est initiée.

Neil Peterson sur le site blogs.technet.com explique en détail les écueils de l’implémentation de la fonctionnalité « On-Demand Content Distribution ». Nous allons reprendre les scénarios qu’il expose et proposer une solution à celui qui pose problème en prenant comme postulat que le contenu n’est pas disponible sur les DP préférés.

Scénario 1

Ce scénario ne pose pas de souci particulier. Le déploiement échouera car aucun contenu ne sera disponible pour le client SCCM comme attendu.

Scénario 2

Ce scénario est aussi très simple et ne pose pas de problème. Le client ira récupérer le contenu sur un des DP désigné comme « Fallback Source DP ».

Scénario 3

Dans ce scénario, le contenu sera récupéré par le client depuis un des « Fallback Source DP » de la liste envoyée par le « Management Point » et, au même moment, un fichier .DMD va être crée dans le répertoire inboxes\distmgr.box\incoming pour déclencher la copie du contenu vers le(s) DP préférés.

Scénario 4

C’est ce scénario qui va nous poser un souci mais seulement pour un cas particulier. Il faut prendre en compte un paramètre supplémentaire qui est le contexte de déploiement : « Required » ou « Available ». En fonction de celui-ci, les résultats ne seront pas les même.

Pour poser le contexte et comprendre comment implémenter la solution, nous allons décrire l’environnement et le besoin initial. La demande est de ne copier le contenu d’un package/application vers le DP du site distant que lorsque l’utilisateur essaie d’installer un logiciel depuis le catalogue d’applications de SCCM. Pour qu’une application apparaisse dans le portail du catalogue, il faut deux critères obligatoires :

–    Le déploiement est ciblé sur des utilisateurs et non pas des ordinateurs
–    Le contexte de déploiement est : « Available »

Prenons le cas où le déploiement d’une application/package est configuré avec le contexte « Required ». Lorsque le client SCCM fait sa demande de localisation de contenu, si le contenu n’est pas disponible sur le DP préféré du client, il y aura une erreur « Content is not available ». Au même moment, un fichier .DMD apparaîtra dans le répertoire inboxes\distmgr.box\incoming et la copie du contenu vers le DP préféré sera initiée. Le client fera alors une demande de localisation de contenu toutes les heures et lorsque celui-ci sera disponible sur le DP préféré, le client SCCM ira récupérer ce dont il a besoin pour exécuter l’installation de l’application.

En revanche, le cas qui pose problème est lorsque le contexte de déploiement est « Available ». Dans cette situation, quand l’utilisateur essaie de déclencher une installation d’application depuis le catalogue, l’installation échoue et une demande de copie du contenu vers le DP préféré est déclenchée. Mais le client SCCM ne fera pas de nouvelle demande et l’utilisateur devra manuellement réessayer une installation ce qui n’est pas très « user-friendly ».

La raison de ce comportement se trouve certainement dans le fait qu’un déploiement en contexte « Required » possède une option supplémentaire : « Rerun behavior ». Cela permet au client SCCM de relancer une demande toutes les heures tant que l’installation n’a pas réussi.

Hélas, les déploiements en contexte « Available » n’ont pas cette option. Nous allons donc contourner le problème et utiliser les fonctionnalités décrites au début de cet article pour faire en sorte que l’utilisateur qui souhaite installer une application depuis le catalogue, ne reçoive pas de message d’erreur et qu’en même temps, le « On-Demand » soit déclenché pour les clients suivants.

Prenons un exemple d’architecture SCCM 2012 :

(((IMG7051)))

Nous souhaitons que les clients des sites secondaires puissent obtenir le contenu des applications qu’ils installent depuis le portail du catalogue d’applications de SCCM. En même temps, nous ne voulons pas que tous les packages/applications soient copiés sur tous les « Distribution Point ». Nous souhaitons aussi contrôler le chemin réseau parcouru par les clients des sites distants lorsqu’ils récupèrent du contenu. Dès lors, l’utilisation des « Fallback Source Distribution Point » n’est pas adaptée, puisque nous ne pouvons pas choisir ceux qui vont être utilisés par le client SCCM (à moins de n’en mettre qu’un seul).

La solution ? Combiner la fonctionnalité de « On-Demand Content Distribution » avec celle des types de connexion des DP préférés (« Slow » et « Fast »). Cela consiste à proposer au client SCCM des sites distants une alternative lorsque le contenu demandé n’est pas sur son DP préféré mais sans utiliser le « Fallback Source Distribution Point ». Nous allons permettre au client SCCM de télécharger le contenu depuis le DP du site primaire parent.

Comment faire cela ? Ajouter dans chaque « Boundary Group » des sites secondaires SCCM, le DP du site primaire parent en changeant le type de connexion en « Slow ».

Cela permettra au client de récupérer le contenu sur le DP du primaire à la première demande et, lorsque le contenu sera disponible sur le DP préféré de type « Fast », c’est lui qui sera à chaque fois prioritaire sur le DP de type « Slow ».

Cette solution a le mérite de proposer une alternative au « Fallback Source DP » et permet d’utiliser le « On-Demand Content Distribution » pour l’ensemble des scénarios.