MDT – Intégration d’applications
Sommaire
I. Présentation
Dans ce tutoriel, je vais vous présenter l’intégration des applications dans MDT ou la gestion des installations automatisée des applications.
Installer automatiquement un système Windows, est une chose que le MDT assure plutôt bien. En revanche, l'installation des applications peut rapidement devenir un véritable casse-tête, selon les choix retenus par les éditeurs de logiciels quant à leurs distributions. L'administrateur et/ou le responsable d'un parc informatique doivent pouvoir garantir un état stable et maitrisé des logiciels installés dans son organisation.
De cette problématique est né un nouveau métier : "L'intégrateur d'application". Ses défis résident dans l'identification des solutions pour :
- Automatiser l'installation (et la personnalisation) d'une application
- Maitriser les mises à jour du système et/ou de ces mêmes applications
- Contrôler la cohérence des prérequis ou composants dits "partagés"
- Sans compter, une distribution des pilotes de périphériques nécessaires à l'exploitation optimale du système.
L'objectif est donc de vous présenter les bases et différentes techniques d'intégration d'application au sein d'une solution de déploiement telle que MDT. En gros, l'idée est de vous sensibiliser aux approches que vous pouvez envisager pour intégrer des applications dans vos images de référence (master).
- Au sein de l'image qui sera capturée – On peut envisager l'intervention humaine (du technicien) durant la fabrication), Mais toutes les applications ne supportent pas l'opération de nettoyage que le sysprep va réaliser. Typiquement, on y retrouve des agents réseau, les antivirus, les pilotes (eh oui, quand ils ne sont pas livrés au format .inf, il faut les considérer comme des applications) – Ce choix est particulièrement intéressant dès lors que le temps d'installation de l'application est élevé, mais l'intégration au sein de l'image WIM implique que le cycle de vie ou d'évolution de l'application est faible.
- En post-installation – Sans nul doute, la meilleure approche sous réserve de disposer de la commande d'installation silencieuse 🙂 – Idéalement, essayez de regrouper les applications au sein de bundles MDT (packs métiers, d'usage, etc…) – En effet, contrairement à la séquence d'installation des applications, il est plus facile de définir l'ordre d'installation et les dépendances applicatives au sein d'un bundle.
Pour intégrer des applications dans un processus de déploiement Windows, plusieurs approches, ou combinaisons peuvent être envisagées.
L'approche dépend essentiellement de la technologie de packaging (voir de licensing) fournie par l'éditeur du logiciel.
II. Les principales technologies
A. Les packages MSI
De plus en plus répandue, cette technologie offre de nombreux avantages dont les capacités d'installation / réparation / désinstallation silencieuse. Connue sous l'anglicisme "unattend mode" ou "mode sans assistance", c’est-à-dire automatique, sans intervention humaine.
Ces packages sont parfois fournis sous une forme "encapsulée" telle qu'un programme setup / install.exe. Pour identifier un package MSI, il faudra surveiller le processus MSIEXEC au cœur de cette technologie. On distinguera 2 principaux type de packages :
- Autonome : Tous les fichiers sont inclus dans un fichier .MSI unique
- À plat : Un fichier .MSI contient les directives d'installation alors que les sources sont livrées à part, dans un sous dossier, ou dans une archive telle que "data.cab"
Les principaux commutateurs MSIEXEC à connaitre : (tapez msiexec /? pour tous les autres :-))
- /i ou /package : Indique le nom (chemin complet) du package MSI
- /qb ou /qn : Mode silencieux avec ou sans affichage utilisateur.
- /allusers = 2 : Indique, si applicable, dans quel contexte utilisateur (propre à un ou tous les utilisateurs) l'application doit s'installer.
- /addlocal : Permet d'indiquer la granularité des composants à installer, si applicable
- TRANSFORMS= : Indique le fichier de transformation .MST à utiliser
- /p ou PATCH= : Indique le fichier de correctif ou mise à jour.MSP à utiliser
Vous pouvez utiliser un éditeur gratuit, tel que ORCA ou InstEd pour vérifier (voire modifier) certaines informations de base sur un fichier MSI, voir générer/appliquer un fichier de transformation .MST
Personnellement je vous recommande l'éditeur gratuit "InstED", car ORCA a un fâcheux défaut qui consiste à modifier la date du fichier même si vous annulez les modifications. (Faites une copie préalable à l'ouverture d'un MSI afin de vous mettre à l'abri de ce désagrément)
Les fichiers MST permettent de modifier le comportement d'une installation MSI. Pour rappel, même si cela est techniquement possible, il est fortement déconseillé de modifier directement le contenu d'un MSI. Il existe plusieurs moyens pour créer un fichier de transformation.
- Vous disposez d'un outillage spécialisé tel que Wise Studio, ou AdminStudio/installshield, et dans ce cas je pense que vous n'avez rien à faire ici.
- Votre DAF ne vous a accordé aucun budget, vous pouvez toujours créer un MST de base via l'outil gratuit "Wise Install Tailor".
- Vous pouvez également utiliser ORCA, ou InstEd, mais c'est à mon avis un peu plus délicat, bien que tout à fait faisable.
- L'éditeur fournit un outillage, comme par exemple Adobe Customization Wizard
Exemple de commande (batch) d'installation silencieuse pour Adobe Reader XI avec correctifs v11.0.2 - Les erreurs proviennent souvent des chemins complets qui doivent être explicitement renseignés, à défaut d'être présents dans le répertoire courant.
set CurDir=%~dp0 msiexec.exe /package "%CurDir%\AcroRead.msi"PATCH="%CurDir%\AdbeRdrUpd11001.msp;%CurDir%\AdbeRdrSecUpd11002.msp" TRANSFORMS="1036.mst" /passive
B. Les packages installshield
Bien que plus anciens et en voie de disparition, ces packages sont encore utilisés de nos jours. Ils sont généralement identifiables par l'icône assez typique du programme.
Ces programmes d'installation (typiquement Setup.exe ou Update.exe) supportent généralement un mode silencieux via le commutateur /quiet), mais disposent parfois d'un mode automatisé via un fichier de réponse. C'est dire qu'il suffit de démarrer l'installation en indiquant un fichier ".iss" en paramètre /F1.
Plus d’information sur :
- InstallShield Setup Silent Installation Switches
- Setup.exe and Update.exe Command-Line Parameters
Exemple : En premier lieu, selon le packaging de livraison, vous devez extraire l'intégralité du contenu de l'archive auto-extractible via 7-Zip. Puis lancer le programme d'installation comme suit :
C:\Repack\Appli1\Setup.exe /r /f1" C:\Repack\Appli1\inst.iss"
Vérifiez que l’installation s’est correctement déroulée en éditant le fichier journal "setup.log". Celui-ci doit impérativement contenir une ligne "ResultCode=0".
Le fichier « inst.iss » obtenu par la commande précédente est à conserver. Générez le fichier de réponse pour une désinstallation silencieuse via la commande :
C:\Repack\Appli1\Setup.exe /r /f1" C:\Repack\Appli1\uninst.iss"
Si la désinstallation s’est correctement déroulée, le fichier "uninst.iss" est à conserver.
Facultatif : Supprimer le dossier créé par une éventuelle installation manuelle A priori, n'existe pas si installation silencieuse :
rd /s /q "C:\Program Files (x86)\InstallShield Installation Information\{AC3D865A-0D8C-43C0-8BA7-7EC2D34BFBFE}"
L’installation silencieuse peut être assurée par la commande suivante (en mode administrateur) :
@start /wait %~dp0\Setup.exe /s /f1"%~dp0\inst.iss"
La désinstallation silencieuse peut être assurée par la commande suivante (en mode administrateur) :
@start /wait %~dp0\Setup.exe /s /f1"%~dp0\uninst.iss"
Remarque : Si le fichier de réponse n’a pas été généré, la commande suivante permet de désinstaller le produit, mais demande une confirmation à l'utilisateur. Je n'ai pas trouvé de palliatif pour ce cas de figure.
%~dp0\Setup.exe /M{AC3D865A-0D8C-43C0-8BA7-7EC2D34BFBFE} /uninst
C. Les packages traditionnels ou hérités (legacy)
Les packages réalisés avec des produits tels que "innosetup" ou "Nullsoft Scriptable Install System" sont facilement détectables dès lors que vous ajoutez le commutateur "/?" derrière l'exécutable - Généralement ces packages proposent généralement quelques commutateurs comme :
- /dir: pour stipuler le dossier de destination
- /norestart pour éviter un redémarrage
- /loadinf: pour ajouter un fichier de configuration / de réponse
- /saveinf: pour générer un fichier de configuration / de réponse
- /silent ou /verysilent pour réaliser une installation silencieuse
Mais il existe beaucoup de variantes (cf "Setup Command Line Parameters" ).
Des produits gratuits tels que PDF Creator, UltraVNC ou bien encore VLC utilisent ce type de packaging.
Ces sites peuvent vous apporter des compléments d'information précieux sur les techniques d'installation silencieuses :
- ITNinja (www.itninja.com )
- InstallSite (www.installsite.org )
- Installshield Support (support.installshield.com)
- Dell KACE (www.dell.com/kace )
D. Les packages propriétaires
Lorsque l'application est livrée dans un format propriétaire, qui plus est, sans aucun support d'un mode automatisé,:-( les solutions d'intégration seront implicitement très limitées, avec un coefficient de risque relativement élevé. Au cas par cas, selon les contraintes, on optera généralement pour :
- L'intégration de l'application au sein de l'image WIM (en réalisant l'installation manuelle avant le processus de capture) – sous réserve que l'application en question "résiste" à l'épreuve du nettoyage "sysprep".
- Le "repackaging" que nous allons détailler ci-après
III. Le Repackaging
A. Les risques
Le Repackaging (ou technique de la dernière chance) n'est pas sans risque – En effet, cette technique consiste à utiliser un outil qui va prendre un instantané (snapshot) du système avant puis après l'installation du logiciel.
L'inconvénient majeur de cette technique est qu'elle repose sur une configuration stable et maitrisée du système. En effet, il n'est pas certain que le package obtenu puisse s'installer sur un autre système de version différente, voire parfois même en raison d'une simple différence de service pack ou d'une mise à jour qui pourrait faire échouer l'installation.
J'ajouterais que la technique de packaging par capture souffre de 2 handicaps majeurs :
- Elle peut engranger des polluants d'utilisation (informations annexes et sans rapport avec le produit, généré par les processus et services en cours d'exécution)
- Elle ne tient pas compte des éventuels redémarrages qui ont été nécessaires (Certaines applications ont besoin d'un redémarrage pour achever correctement leur configuration)
Quel que soit le produit retenu, il faudra être particulièrement attentif aux composants complémentaires apportés par l'application, tels que les redistribuables C++ ou autres framework.NET… Il est souhaitable de les considérer comme des packages dépendants, mais distincts et ne pas les inclure dans le package de l'application.
En conséquence, pour effectuer un repackaging par capture dans les meilleures conditions possibles, il est souhaitable de :
- Installer une machine virtuelle avec le socle de référence (composants inclus)
- Désactiver tous les agents, services et autres antivirus susceptibles d'interférer avec le processus de capture. (Windows Update, Defender, etc…)
- Faire un snapshot de la VM avant toute modification. N'hésitez pas à réaliser des snapshots intermédiaires en fonction de la complexité de réalisation.
- N'oubliez pas de supprimer les éventuels fichiers de désinstallation (inutiles si vous avez obtenu un package MSI)
B. Virtualisation d'application ?
Au fil du temps, la technique de repackaging a évolué pour se scinder en 2 approches distinctes :
- Le repackaging "natif" qui consiste à obtenir un package MSI "traditionnel"
- La virtualisation d'application qui consiste à obtenir un package de type 'bac à sable" (sandbox) afin de l'imiter les impacts sur le système et autoriser des instances concomitantes dans certains cas. Parmi ces solutions, on retrouve les leaders du marché :
- Microsoft AppV (Initialement Softgrid)
- VMware Thinapp (Egalement associé à l'offre Landesk)
- Citrix XenApp
- Novell ZAV / Xenocode Virtual Application Studio / Spoon.net
- Et quelques outsiders
- Symantec SVS (Initialement Altiris et Appstream)
- Cameyo (Gratuit)
Mais la virtualisation d'application est loin d'être une panacée. En effet, si cette technologie est prometteuse elle draine cependant quelques contraintes de taille :
- Avantages
- Cohabitation de versions concurrentes d'un même produit (ie Plusieurs JRE dans différentes instances de navigateurs, meilleure isolation avec le système
- Streaming – L'application peut être publiée sur un portail ou un magasin distant et commencer son démarrage avant d'être totalement présente dans le cache local du poste.
- Inconvénients
- Dépendance du système
- Pas de communication transverse ni entrante vers les instances virtuelles (addins, plugins…)
- La prise en charge des objets COM/DCOM n'est pas toujours efficiente
IV. Intégration des applications dans MDT
Maintenant que le décor est planté, passons à la partie "industrialisation" via le MDT. Si vous êtes arrivé jusqu'à l'installation silencieuse de vos applications, leur intégration au sein du MDT sera une formalité.
Premier conseil : Pensez à créer préalablement un dossier dédié contenant les sources nécessaires à l’installation de l’application. Cela facilitera grandement la gestion de vos différents packages.
Lancez la console "Deployment Workbench" puis développez l’arborescence jusqu’à "MDT Deployment Share … Applications" puis effectuez un clic droit "New Application".
Conservez l’option par défaut si les sources doivent être hébergées dans la structure MDT (DeploymentShare). Utilisez la seconde option si vous préférez publier les sources sur un autre serveur de fichier. Cliquez sur "Next"
Entrez le nom de l’application (obligatoire) et ajoutez éventuellement le nom de l’éditeur, la version, la langue. (Ces éléments formeront le nom dossier par défaut des sources de l’application) - Cliquez sur "Next"
Utilisez le bouton "Browse" pour sélectionner le dossier contenant les sources de l’application puis cliquez sur "Next"
Acceptez (ou modifiez) le nom de dossier proposé puis cliquez sur "Next". L’assistant vous demande alors de saisir la ligne de commande (d’installation silencieuse).
Si vous ne l’avez pas sous la main, entrez une commande quelconque ; cette information sera modifiable a posteriori. Cliquez 2 fois sur "Next" puis sur "Finish" une fois l’importation terminée.
Pour vérifier ou modifier les informations d’une application, sélectionnez-la puis faites un clic droit "Propriétés". Sous l’onglet "Details", vous pourrez renseigner cette fameuse ligne de commande magique "Quiet install command" chargée de réaliser l’installation automatique.
Ne vous inquiétez pas, ça peut rapidement dépasser le cadre affiché 🙂
Exemple de commande :
start /l*v "%TEMP%\FoxitReader_InstallLog.txt" MAKEDEFAULT=1 LAUNCHCHECKDEFAULT=0 VIEW_IN_BROWSER=1 STARTMENU_SHORTCUT=1 DESKTOP_SHORTCUT=0
Le principal inconvénient d’une application au sens MDT, est surtout lié au fait qu’il n’y a qu’une seule commande.
C’est une des raisons pour laquelle il est préférable d’utiliser un script (batch ou PowerShell) pour chainer un ensemble de commandes (et homogénéiser vos installations).
Pour l'intégration des applications du marché, et leur intégration dans MDT, je vous conseille d'essayer "setup commander" de Rovabu Software . La version PRO d'évaluation vous sera fournie sur simple demande, et vous permettra de gérer très facilement un catalogue des principales applications courantes, et les intégrer dans des packages d'applications / bundles MDT en quelques clics ….
Voilà pour les bases en matière de packaging et intégration éventuelle dans le MDT.
Je pense vous proposer quelques exemples concrets et retours d’expériences dans un avenir plus ou moins proche. Juste le temps pour moi de réorganiser et réactualiser quelques composants. Je rajouterai le lien ici dès que possible.
To be continued …
Christophe
