serveur de fichiers fera
l’affaire. Il faut quand même prendre en
compte le nombre d’utilisateurs qui installeront
des applications et d’autres facteurs :
bande passante disponible, nombre d’applications
confiées à  un serveur, les autres
services hébergés par le serveur et des
considérations de sécurité. Puis, vous distribuerez
les applications aux serveurs en
conséquence.
La disponibilité des serveurs est une autre considération
importante, particulièrement au fur et à  mesure qu’augmente
le nombre d’utilisateurs qui s’appuient sur les applications
déployées par les stratégies de groupe. Vous pouvez
utiliser Dfs dans Windows 2003 et Win2K Server pour vous
assurer que les shares d’installation d’applications sont disponibles
même si un serveur tombe en panne. Dfs vous permet
de placer un dossier d’installation sur de multiples serveurs
et d’ajouter les dossiers comme des répliques sous la
racine Dfs. Si le serveur est hors service, les utilisateurs pourront
néanmoins installer l’application à  partir de l’une des autres répliques présentes dans la racine. La redirection se
passe automatiquement et est transparente aux yeux des utilisateurs
et des stratégies de groupe, ce qui référence le chemin
UNC (Universal Naming Convention) de la réplique générique
du dossier dans le namespace Dfs, et pas le chemin
cible absolu.
Pour mettre en place un share, créez sur un serveur un
dossier qui agira comme la racine de vos dossiers d’applications,
configurez les permissions sur le document
selon les besoins puis partagez le
dossier. Créez des dossiers d’applications
individuels sous le share, puis copiez les fichiers
du package pour une application
donnée dans son dossier. Pour mieux gérer
l’utilisation des disques, vous pouvez
utiliser la compression NTFS sur les dossiers
share.