Publier ou assigner des applications

des utilisateurs sans
qu’elles soient obligatoires.
Quand vous publiez une application,
vous pouvez spécifier une catégorie la concernant (nous verrons
plus loin comment définir des catégories). Si vous spécifiez
des catégories, elles apparaissent également dans l’applet
Add or Remove Programs, comme le montre la figure 1,
et servent à  organiser les applications en groupes logiques.
Ainsi, vous pourriez placer Microsoft Office, Office Visio, et
d’autres applications associées à  Office dans un groupe
Office ; AutoCAD d’Autodesk et d’autres applications de nature
graphique dans un groupe CAO/Ingénierie/Graphiques ;
et ainsi de suite. Ce genre de catégorisation aide les utilisateurs
à  trouver les applications qui les intéressent et qu’ils
souhaitent installer.
Les applications assignées fonctionnent différemment
des applications publiées. Quand vous assignez une application,
elle apparaît dans le menu Start de l’utilisateur comme
si elle était déjà  installée. Puis, quand l’utilisateur démarre
l’application pour la première fois, Setup effectue une installation
JIT (just-in-time) de l’application à  partir du share
d’installation réseau, comme il le fait quand vous installez
une application localement et choisissez l’option Install On
First Use. Windows 2003 ajoute la possibilité d’installer automatiquement
les applications assignées quand l’utilisateur se
connecte pour la première fois : l’installation initiée par l’utilisateur
n’est donc plus nécessaire. Il vaut donc mieux assigner
que publier les applications que les utilisateurs doivent
obligatoirement posséder.
En déterminant quelles applications sont à  publier et lesquelles
sont à  assigner à  des groupes d’utilisateurs spécifiques,
vous constaterez peut-être que votre AD (Active
Directory) a besoin d’être un peu réaménagé pour permettre
le déploiement d’applications. Ainsi, si tous les utilisateurs
d’un département ont besoin des mêmes applications
et si vos OU (organizational units) AD ne sont pas
alignées avec des départements, il vous faudra peut-être
créer des OU et ajuster les membres des OU en conséquence.
Ce faisant, vous pourrez créer des GPO (Group
Policy Objects) qui déploieront les applications aux utilisateurs
selon les besoins. Vous pouvez utiliser des GPO au niveau
domaine pour déployer les applications dont tout le
monde a besoin. La restructuration du namespace AD n’est
de mise que pour des namespaces qui sont actuellement
non structurés. Pour des namespaces structurés, il vaut
mieux utiliser le filtrage des groupes de sécurité des GPO
pour contrôler le déploiement.
Après avoir décidé qui recevra quelles applications et
comment, vous serez prêts à  démarrer la mise en place des
serveurs et des shares pour rendre les packages applicatifs
disponibles. Les stratégies de groupe utilisent Windows
Installer pour installer les applications ; donc la première
étape dans la mise à  disposition des applications consiste à 
obtenir ou à  créer le package Installer. Si l’application est
prépackagée comme un fichier .msi et si votre déploiement
n’a pas besoin de modifications, comme l’ajout des fichiers custom ou des changements des options d’installation, vous
pouvez vous contenter de copier les fichiers source à  partir
du CD-ROM de l’application vers le share cible sur le serveur.
Mais, souvent, vous devrez personnaliser ou créer le package
Installer. De nombreuses applications tierce partie –
dont WinINSTALL de OnDemand Software, InstallShield de
InstallShielf Software et Wise for Windows Installer de Wise
Solutions – vous permettent de créer de nouveaux packages
Windows Installer ou de repackager les existants. Microsoft
offre Visual Studio Installer en téléchargement gratuit, mais il
nécessite un produit VS (Visual Studio) existant pour fonctionner.
WinINSTALL LE 2003 de OnDemand Software est
une option gratuite aux fonctions limitées.
Pour de simples applications, il vous suffit de packager
leurs fichiers dans un fichier .msi. Pour des installations plus
complexes, comme Microsoft Office, vous pouvez créer un fichier
de transformation pour spécifier un ensemble d’exceptions
en tant que valeurs par défaut du
package. Par exemple, vous pourriez créer
un fichier de transformation pour installer
un sous-ensemble des applications Office,
spécifier le lieu de l’installation et définir
d’autres options d’installation. Les fichiers
de transformation sont particulièrement
utiles pour cibler un ensemble de fichiers
source d’applications pour de multiples
groupes d’utilisateurs qui ont besoin d’options
d’installation différentes. Vous devez
créer un fichier .msi pour servir tous les utilisateurs puis appliquer
des transformations pour adapter l’installation aux
groupes individuels.
Chaque application de packaging a ses forces et ses faiblesses.
Si vous n’avez pas déjà  un packager, prenez le temps
de télécharger des copies d’évaluation et de les tester pour
trouver celle qui vous convient le mieux. Quand vous vous
sentirez à  l’aise dans le repackaging des applications et la
création des transformations, vous pourrez commencer à 
mettre en place les points de distribution pour vos applications.