Virtualisation d`application avec VMware ThinApp

Transcription

Virtualisation d’application avec VMware ThinApp
Cahier Produit Amosdec • Q1 2009 • Numéro 2
Edito
Auriez-vous imaginé ne plus avoir de problématique de déploiement
d’applications, de compatibilité entre applications ou avec les différentes
versions de Windows, de mise à jour, de publication ou de droits des utilisateurs
d’exécuter certaines applications…
Ce cahier produit détaille le produit VMware Thinapp, outil de virtualisation
d’applications.
Merci à Pierre-François Guglielmi, formateur VMware Certified Instructor (VCI), pour la rédaction de
ce cahier produit qui vous détaille tout ce qu’il faut savoir de VMware Thinapp.
N’hésitez pas à nous faire part de vos commentaires : [email protected]
Bonne lecture !
Avec ombre portée
Sans ombre portée
Cahier produit Amosdec
Sommaire
I • Introduction
1
1. Qu’est ce que la virtualisation d’applications?
2. Problématiques et avantages
a. Compatibilité
b. Sécurité
c. Déploiement
1
1
1
2
2
II • La solution VMware ThinApp
3
3
3
4
7
1. De Thinstall à VMware ThinApp
2. Concept de Sandbox
3. Installation
4. Installation d’un package
III • Utilisation avancée - Package.ini
15
1. Nouvelles fonctionnalités
a. AppLink
b. AppSync
2. Paramètres d’isolation
3. Déploiements MSI
4. Streaming
5. Exclusion de fichiers
6. Outils de commandes et outils tiers
a. Thinreg.exe
b. Sbmerge.exe
c. Log Monitor.exe
d. DLL_Dump.exe
15
15
16
17
18
21
21
22
22
22
22
22
I • Introduction
1. Qu’est ce que la virtualisation d’applications?
Le plus souvent dans le monde x86, le terme virtualisation concerne les systèmes, qu’ils soient
serveurs ou postes de travail. Ceci étant d’autres éléments comme le stockage mais aussi les
applications peuvent être virtualisés.
Dans ce cas précis, tout comme on découple le système d’exploitation du matériel lors de la
virtualisation d’un serveur ou d’un poste de travail, la virtualisation d’une application consiste
à décorréler l’application du système d’exploitation sur lequel elle est exécutée, éliminant ainsi
toute installation.
2. Problématiques et avantages
La virtualisation d’applications peut adresser différentes problématiques, parmi lesquelles
compatibilité, sécurité et déploiement.
a. Compatibilité
Certaines applications ne sont pas compatibles entre elles lorsqu’on souhaite les installer sur une
même machine. En effet, lorsqu’un logiciel s’installe, des modifications sont apportées à la base
de registres et des fichiers sont écrits sur le disque système. Parfois même, différentes applications
peuvent apporter leur propre version de DLLs systèmes, écrasant les modifications apportées
par une autre application qui aurait employé le même procédé, la rendant alors inutilisable.
De plus, lors d’une désinstallation, certaines de ces modifications subsistent et les multiples
installations/désinstallations conduisent, au final, à des systèmes d’exploitation moins sains et
qui perdent souvent en performances et en stabilité.
La virtualisation isole les applications entre elles. Elle permet ainsi l’exécution simultanée, sur
une même machine de ces applications nativement non compatibles, mais en plus sans aucune
installation/désinstallation, donc sans modification de la base de registres ou du système de
fichiers. Le système d’exploitation reste alors sain dans le temps.
Dans certains métiers, il est parfois nécessaire, voire obligatoire, d’utiliser la même application
mais dans différentes versions. Le problème est qu’en général la nouvelle version d’une
application remplace l’ancienne, ce qui rend impossible l’exécution de différentes versions de la
même application sur la même machine. Virtualiser les différentes versions permet dans ce cas
de créer des packages isolés qui peuvent être exécutés simultanément sur la même machine.
Toutes ces problématiques de compatibilité et de cohabitation de différentes applications sur
un même système sont d’autant plus contraignantes en environnements publiés tels que Citrix
XenApp ou Microsoft Terminal Services, que des incompatibilités entre applications à publier
conduisent alors à la multiplication des frontaux. Ceci s’avère plus coûteux, plus compliqué à
gérer et à administrer et mène parfois à une sous-utilisation des ressources de ces frontaux.
1
Cahier Produit Amosdec
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit, sans
l’autorisation d’Amosdec est illicite et constitue une contrefaçon.
b. Sécurité
Le principal problème de sécurité qui peut se poser est celui des privilèges nécessaires à l’exécution
d’une application. En l’occurrence, certaines applications nécessitent que l’utilisateur qui les exécute
dispose des privilèges administratifs locaux, c’est-à-dire qu’il soit membre du groupe « Administrateurs
» local sous Windows.
Cela pose un important problème de sécurité face aux dérives liées à ces privilèges : installation de
logiciels personnels ou non sollicités, non validés par l’entreprise qui peut entrainer une baisse de
productivité, installation involontaire de divers malwares ou spywares qui peuvent se propager à
d’autres machines, changements non contrôlés et/ou non souhaités de la configuration du système,
etc… Si l’on en revient aux environnements publiés, de telles applications ne peuvent tout simplement
pas être publiées puisqu’on ne peut pas donner les privilèges administratifs locaux d’un serveur à des
utilisateurs.
La virtualisation des applications présente un intérêt majeur : toutes les applications virtualisées
avec la solution de VMware sont exécutées en «user mode» c’est-à-dire que l’utilisateur dispose
uniquement des privilèges utilisateurs et non des privilèges administrateurs afin de pouvoir exécuter
ces applications virtualisées, ce qui, de plus, les rend alors « publiables ».
c. Déploiement
Le problème de l’hétérogénéité d’un parc informatique en termes de versions de systèmes
d’exploitation peut également se poser ainsi que les contraintes et les enjeux d’une migration de
système d’exploitation.
Si on analyse un parc sur lequel cohabitent Windows 2000, Windows XP et Windows Vista, il faut
pouvoir exécuter les mêmes applications sur toutes ces versions de Windows. Ceci nécessite d’avoir
des versions, parfois différentes, compatibles avec chacune de ces versions d’OS, de les tester, de les
valider, de les déployer et de s’assurer que lorsque l’on veut migrer le système d’exploitation vers une
version plus récente de Windows, cette application continuera de fonctionner correctement.
La problématique de la migration vers Windows Vista est particulièrement délicate car les changements
apportés au système sont très importants. Dans ce type de situation, la virtualisation des applications
permet de passer outre ces contraintes en obtenant un package applicatif qui pourra être exécuté
indifféremment sur les différentes versions de Windows.
2
II • La solution VMware ThinApp
1. De Thinstall à VMware ThinApp
La solution VMware ThinApp 4 est issue du rachat par VMware de la société américaine Thinstall
créée en 1999. Thinstall s’était imposé comme le leader du marché de la virtualisation d’applications
avec sa solution Thinstall Virtualization Suite, avant d’être racheté par VMware début 2008. Cette
solution logicielle répond à toutes les différentes problématiques - compatibilité, isolation, sécurité et
déploiement - évoquées précédemment, tout en étant une solution simple à implémenter puisqu’elle
ne nécessite la mise en place d’aucune infrastructure complexe.
Cette prouesse est rendue possible par l’intégration dans l’en-tête de chaque package d’application
virtualisée, d’un mini système d’exploitation appelé VOS (Virtual Operating System) qui crée
l’interaction entre les données présentes dans le package en termes de fichiers et de base de registres
avec le système de fichiers et la base de registres réels de la machine sur laquelle l’application est
exécutée. Ce VOS pèse environ 400ko ce qui représente un overhead (consommation de ressources)
négligeable. (Fig 1-a)
Fig 1-a
2. Concept de Sandbox
Lorsqu’une application est virtualisée avec ThinApp, l’installation et tous les fichiers et clés de registres
nécessaires au fonctionnement sont encapsulés avec le VOS dans un fichier exécutable. Pour que le
fichier soit exécutable de manière autonome, sans aucun agent, il faut que l’ensemble soit compilé.
Une fois l’opération de compilation réalisée, le fichier exécutable résultant n’est plus modifiable.
3
Néanmoins, le fonctionnement même de l’application nécessite que certaines modifications soient
apportées au fur et à mesure de l’utilisation, que ce soit au niveau du système de fichiers ou de la base
de registres. Ces modifications ne peuvent être apportées ni à l’intérieur même de l’exécutable ni sur
le système réel, puisque l’un des intérêts de la virtualisation d’applications est justement, de ne pas
laisser de trace sur le système de sorte qu’il reste sain et stable dans la durée.
C’est pourquoi VMware ThinApp utilise la notion de Sandbox (répertoire stocké par défaut dans le profil
de l’utilisateur) destinée à accueillir toutes ces modifications en écriture sur les dossiers systèmes et sur
la base de registres. L’application virtualisée est capable d’accéder en lecture aux répertoires systèmes
ainsi qu’à la base de registres, mais aussi en écriture sur les lecteurs réseaux ou les dossiers personnels
non systèmes de l’utilisateur. Par exemple, pour un navigateur internet virtualisé, si l’utilisateur fait une
configuration personnelle, changer la page d’accueil par défaut, cette configuration sera écrite dans
la Sandbox. (Fig 2-a)
Fig 2-a
3. Installation
L’implémentation du produit est extrêmement simple puisqu’aucune infrastructure complexe n’est à
mettre en place :
• pas de serveur de packages
• pas de serveur de streaming
• pas d’agent à déployer sur les postes
• pas de serveur de mise à jour spécifique
• pas de serveur de déploiement spécifique.
Une seule machine virtuelle suffit et là encore sans procédure d’installation complexe.
En effet, VMware recommande l’utilisation de VMware Workstation, fourni avec VMware ThinApp, afin
de créer une machine virtuelle qui sert à capturer les packages d’applications virtualisées. ThinApp
capture l’état du système avant l’installation de l’application à virtualiser, procéde à l’installation, puis
capture une seconde fois l’état du système après l’installation de l’application. ThinApp extrait un
différentiel, au niveau système de fichiers et base de registres, qui est ensuite encapsulé dans un fichier
exécutable unique et autonome.
4
Afin de s’assurer que tous les éléments nécessaires au fonctionnement soient bien capturés, il faut,
pour chaque nouvelle capture d’une application, réaliser les opérations sur un système le plus sain
possible, donc avec le minimum de composants et d’applications installés. (Fig 3-a)
Fig 3-a
Travailler dans un environnement virtualisé est donc particulièrement adapté puisque l’on peut créer
une machine virtuelle saine, dont on capture l’état grâce à la prise d’un snapshot (photographie
système) à froid, permettant ainsi de revenir à un état sain à chaque nouvelle opération de virtualisation
d’applications.
L’installation de VMware ThinApp se fait en lançant le package Microsoft Installer (MSI) fourni par
VMware. Il suffit alors de se laisser guider par l’assistant d’installation. (Fig 3-b)
Fig 3-b
5
Fig 3-c
Fig 3.c : Le « License display name » correspond au nom qui sera affiché dans une petite fenêtre pop-up
en bas à droite de l’écran à chaque lancement de l’application virtualisée.
Fig 3-d
6
Une fois l’installation terminée, on retrouve l’ensemble des fichiers qui composent la VMware ThinApp
Virtualization Suite dans le répertoire C:\Program Files\VMware\VMware ThinApp. (Fig 3-e)
Fig 3-e
Une information est à retenir au sujet de l’installation de ThinApp : la ThinApp Virtualization Suite est
elle-même virtualisée avec ThinApp ! Ceci rend l’application complètement portable et utilisable par
exemple à partir d’un partage réseau ou d’une clé USB, sans aucune installation préalable.
4. Installation d’un package
La création d’un package d’application virtualisée se déroule en quelques étapes simples. On
commence par lancer l’utilitaire «ThinApp Setup Capture». (Fig 4-a et 4-b)
Fig 4-a
7
Fig 4-b
C’est avec cet utilitaire que l’on capture l’installation d’une application dans le but de l’encapsuler dans
un exécutable autonome. On prend alors un premier snapshot de l’état du système en scannant le
système de fichiers ainsi que la base de registres. (Fig 4-c et 4-d)
Fig 4-c
8
Fig 4-d
Puis on installe l’application que l’on souhaite virtualiser. Ici un exemple avec Mozilla Firefox. (Fig 4-e)
Fig 4-e
9
Une fois l’application installée, on peut la lancer une première fois afin de faire une configuration
globale qui sera alors également capturée. Une fois cette étape réalisée, on lance un second snapshot
de l’état du système. (Fig 4-f )
Fig 4-f
Il reste à réaliser quelques étapes de configuration générale du projet, en premier la sélection des
points d’entrée utilisateur (Fig 4-g). En virtualisant, par exemple, Microsoft Office, il est possible de
selectionner comme points d’entrée utilisateur les exécutables de chacun des composants principaux
d’Office, à savoir Word, Excel, PowerPoint, etc…
Fig 4-g
10
A cette même étape, il faut sélectionner un « Primary data container » c’est-à-dire un fichier exécutable
parmi les points d’entrée utilisateur qui contiendra l’ensemble des données, organisées en blocs de
64ko par défaut, qui seront inclues dans le package.
Si plusieurs points d’entrée utilisateur sont sélectionnés, celui désigné comme «Primary data container»
sera le fichier ayant une taille plus importante, tous les autres ne pèsent que quelques kilo-octets et
pointent vers le «Primary data container». Dans le cas où le «ThinApp Setup Capture» estime la taille
finale du package à plus de 200 Mo, un fichier à l’extension .dat est généré et sélectionné comme
«Primary data container». Ceci évite les problèmes d’affichage de l’icône de l’application lorsque le
package est trop volumineux. Le champ «Inventory Name» quant à lui permet de définir le nom qui
sera affiché dans «Ajout/Suppression de programmes» sous Windows si l’application virtualisée est
déployée à partir d’un package MSI ou enregistrée avec l’utilitaire Thinreg.exe. Ce sujet sera abordé
plus en détail un peu plus loin.
Dans l’écran suivant, l’administrateur peut définir des permissions d’exécution, c’est-à-dire qu’il peut
choisir les groupes ou les utilisateurs Active Directory qui seront autorisés à lancer l’application, afin de
la sécuriser et d’en contrôler l’utilisation. Pour tous les autres utilisateurs non autorisés, il est possible
de définir un message qui s’affichera au lancement de l’application et qui les avertira qu’ils n’ont pas
les permissions nécessaires pour l’exécuter. (Fig 4-h)
Fig 4-h
Lors de cette étape, l’administrateur définit l’emplacement de la Sandbox qui, par défaut, se situe dans
le profil de l’utilisateur qui lance l’application. La Sandbox peut être stockée à des emplacements aussi
divers qu’un partage réseau, une clé USB sur laquelle l’application sera stockée ou tout autre répertoire
accessible par l’utilisateur. Ceci est configurable à volonté.
Il faut ensuite configurer le niveau général de l’isolation de l’application. Cette notion fera l’objet d’une
partie dédiée. (Fig 4-i)
11
Fig 4-i
Avant de construire le package de l’application virtualisée, il est nécessaire de choisir un répertoire,
que l’on désigne comme le projet, pour stocker tout le différentiel capturé entre les deux snapshots au
niveau système, soit l’installation complète et la configuration de l’application.
Fig 4-j : deux autres options sont présentées ici :
• la possibilité de créer un package MSI, en plus de l’exécutable autonome, en vue d’un déploiement
simplifié via les «Group Policy» (GPO) Active Directory ou une intégration avec les solutions de
déploiements de logiciels disponibles au sein de l’entreprise
• la possibilité de compresser le package exécutable final afin d’économiser la volumétrie nécessaire
au stockage et au déploiement des packages d’applications virtualisées.
Fig 4-j
12
Le projet est alors créé et stocké à l’endroit indiqué précédemment dans l’assistant. (Fig 4-k)
Fig 4-k
Fig 4-l : dans la vue suivante, l’administrateur peut :
• soit construire le package afin d’obtenir le fichier exécutable autonome résultant, ainsi que le package
MSI le cas échéant, en cliquant sur «Build now».
• soit parcourir le dossier de projet en cliquant sur «Browse project», afin de le personnaliser et de
le configurer plus finement, notamment en s’appuyant sur le fichier principal de configuration du
package : le fichier «package.ini».
Fig 4-l
13
Fig 4-m
Fig 4-n
Lorsque l’on choisit de construire le package, une invite de commande s’affiche et la tâche de création
du package se déroule (Fig 4-n). On trouve le résultat de l’opération dans un répertoire «bin» par
défaut. (Fig 4-o)
Fig 4-o
14
III • Utilisation avancée - Package.ini
Les applications étant toutes différentes, virtualiser chacune d’entre elles est un cas particulier et
nécessite le plus souvent une configuration avancée spécifique. Ceci est bien évidemment possible
à travers l’utilisation du fichier de configuration d’un package. Il s’agit du fichier «package.ini»
situé à la racine du dossier d’un projet. C’est, par exemple, grâce à ce fichier que l’on peut configurer
l’utilisation des nouvelles fonctionnalités apportées à la version 4 de VMware ThinApp, mais aussi
l’isolation, la compression, l’exclusion de certains types de fichiers, etc…
1. Nouvelles fonctionnalités
Avant que Thinstall ne soit rachetée par VMware en 2008, l’outil Thinstall Virtualization Suite était en
version 3.3. Suite à ce rachat le logiciel est passé à la version 4 et a apporté 2 nouvelles fonctionnalités
principales : AppLink et AppSync.
a. AppLink
Comme son nom le laisse supposer, AppLink permet de créer des liaisons entre packages.
Supposons par exemple que l’on veuille virtualiser 10 applications s’appuyant toutes sur la même
version du .Net Framework de Microsoft ou du Java Runtime Environment de Sun. Plutôt que d’inclure
ce composant fondamental pour le fonctionnement des applications dans chacun des packages, ce
qui prend plus de temps et génère des packages plus importants, il est possible, grâce à AppLink :
• de créer un package exécutable autonome du .Net Framework ou du Java Runtime Environment
• de créer les packages des différentes applications à virtualiser, sans y inclure le composant sousjacent
• puis de configurer le «package.ini» du projet afin que l’application charge automatiquement le
package de ce composant lorsqu’elle démarre.
Deux options permettent de configurer AppLink :
;OptionalAppLinks=plugins\*.exe
;RequiredAppLinks=\\server\share\*.exe;c:\abs\path\file.exe
La première permet de préciser les packages qui peuvent être appelés par l’application principale si
elle en a besoin. On peut par exemple l’utiliser pour ajouter des plugins ou mises à jour. Dans le cas d’un
navigateur internet on utilise cette option afin de mettre à disposition de ce dernier des composants
tels qu’un lecteur PDF : les documents PDF se chargent alors directement dans le navigateur ou un
client web Citrix XenApp.
La seconde option permet de préciser les composants indispensables à l’application qui doivent être
chargés. Dans ce cas si le composant spécifié n’est pas présent alors l’application ne démarre pas et
un message d’erreur est affiché.
Dans les deux cas, on peut renseigner un ou plusieurs packages individuellement en précisant leur
chemin et leur nom et en les séparant par un point-virgule s’il y en a plusieurs ou un répertoire complet
contenant des applications virtualisées en mettant l’extension générique *.exe, précédée du chemin
du répertoire. Les chemins peuvent être locaux ou réseaux.
15
Un autre exemple d’utilisation d’AppLink est la mise à jour rapide d’une application comme Microsoft
Office. Lorsqu’un nouveau Service Pack est publié, il suffit de le virtualiser pour en obtenir un package
exécutable que l’on met à disposition de l’Office virtualisé via AppLink. La mise à jour est alors instantanée
et le retour arrière peut être effectué de manière rapide et propre : il suffit de supprimer l’accès au
package du Service Pack pour que le package Office revienne aussitôt à sa version précédente.
b. AppSync
AppSync est une fonctionnalité de mise à jour automatique centralisée des packages ThinApp. Lors de
la construction d’un package avec ThinApp, comme vu précédemment, celui-ci est compilé et donc
non modifiable. Par conséquent, il faut mettre en place des solutions pour pouvoir mettre à jour les
applications lorsque cela est nécessaire. Tout d’abord, il est fortement recommandé de désactiver les
systèmes automatiques de mise à jour natifs des applications car, si on procède à une mise à jour via
ces mécanismes, les données téléchargées et modifiées seront stockées dans la Sandbox. Ceci pose
problème à terme. La solution est donc d’utiliser AppSync.
Dans ce cas, il faut au préalable configurer l’application, à travers son «package.ini», pour lui
indiquer qu’elle doit aller périodiquement vérifier sur un serveur spécifié si une nouvelle version du
package est disponible. Si tel est le cas, le VOS, chargé dans la mémoire de la machine sur laquelle
l’application est lancée, est capable de déterminer les blocs différents et nouveaux par rapport à ceux
présents dans le package lancé. Ces blocs exclusivement, et non l’intégralité du nouveau package,
sont alors téléchargés sur le poste client et un nouvel exécutable prenant en compte les modifications
est créé en local.
Lors du prochain lancement de l’application virtualisée, elle est à jour. Voici les paramètres configurables
pour AppSync :
;-------- AppSync Parameters ---------;AppSyncURL=https://example.com/some/path/PackageName.exe
URL du serveur de fichier ou Web contenant les packages à jour.
;AppSyncUpdateFrequency=1d
Périodicité de la vérification des mises à jour.
;AppSyncExpirePeriod=30d
Délai d’expiration des packages, au terme duquel les packages non mis à jour ne peuvent plus être
lancés.
;AppSyncWarningPeriod=5d
Période avant l’expiration pendant laquelle l’utilisateur est averti que le serveur doit être contacté
pour procéder à la mise à jour.
;AppSyncWarningFrequency=1d
Fréquence de répétition de l’avertissement avant expiration.
;AppSyncWarningMessage=This application will become unavailable for use
in %%remaining_days%% day(s) if it cannot contact its update server.
Check your network connection to ensure uninterrupted service.
Message d’avertissement affiché sur le poste de l’utilisateur pendant la période avant l’expiration.
16
;AppSyncExpireMessage=This application has been unable to contact its
update server for %expire_days% day(s), so it is unavailable for use.
Check your network connection and try again.
Message affiché sur le poste de l’utilisateur une fois le délai de mise à jour expiré.
;AppSyncUpdatedMessage=
Message affiché sur le poste de l’utilisateur lorsque la mise à jour du package a été réalisée avec succès.
;AppSyncClearSandboxOnUpdate=0
Possibilité de vider la Sandbox lors de la mise à jour. Si le paramètre est à 0, la Sandbox conserve les
données qu’elle contient. Si le paramètre est à 1, la Sandbox est vidée.
2. Paramètres d’isolation
Afin que l’application virtualisée puisse lire les fichiers et les clés de registre systèmes réels et écrire
dans leurs équivalents virtuels encapsulés dans le package, il est nécessaire de configurer le bon niveau
d’isolation sur chacun des éléments. ThinApp le configure automatiquement en fonction de différents
critères comme par exemple la création de nouveaux éléments qui n’existaient pas sur le système
avant l’installation de l’application. Dans ce cas le niveau d’isolation est configuré en « full ».
Il existe 3 niveaux d’isolation distincts :
• Full : en cas d’existence d’un fichier système ou d’une clé de registres à la fois sur le système réel et dans le package, seul l’élément inclus dans le package peut être lu et l’écriture se fait dans la Sandbox
• WriteCopy : dans le même cas que précédemment, l’élément présent sur le système peut être lu mais les modifications en écriture sont stockées dans la Sandbox
• Merged : toujours dans le même cas, l’application virtualisée peut lire et écrire l’élément sur le système réel
Pour l’isolation des répertoires, il existe un paramètre général présent dans le «package.ini» et
configuré par défaut pour tous les répertoires du système de fichiers virtuels :
[Isolation]
DirectoryIsolationMode=Merged
On peut également configurer l’isolation individuellement pour chacun des répertoires et sousrépertoires du projet à l’aide du fichier «##Attributes.ini» présent dans chacun de ceux-ci.
17
Pour les clés de registres le niveau d’isolation est précisé en début de ligne dans les fichiers textes de
base de registres présents à la racine du projet. (Fig 2-a et Fig 2-b)
Fig 2-a
Fig 2-b
3. Déploiement MSI
Quand on virtualise une application avec VMware ThinApp, on obtient toujours au moins un package
exécutable autonome, mais on peut également configurer le projet afin qu’un package MSI soit
également généré. Le but est de déployer les packages ThinApp soit via une GPO Active Directory de
déploiement logiciel, soit via une solution de déploiement tierce partie.
18
L’utilisation de packages MSI s’avère très utile pour la simplification des déploiements mais aussi pour
trois raisons principales :
Fig 3-a
• La création automatique des raccourcis de l’application tels que spécifiés dans la figure 3-a.
• L’enregistrement de l’application dans «Ajout/Suppression de programmes» à des fins d’inventaire.
• Les associations de fichiers qui permettent de lancer automatiquement une application en fonction
de l’extension du fichier : Microsoft Word est lancé quand on double-clique sur un fichier .doc. C’est le
paramètre FileTypes qui permet de préciser les extensions de fichiers à associer à l’application.
Ces trois opérations peuvent également être réalisées manuellement ou de manière automatique
sans passer par l’utilisation d’un package MSI grâce à l’utilitaire de ligne de commande
thinreg.exe qui sera couvert un peu plus loin.
Si on choisi que le package MSI soit généré simplement en cochant la case correspondante dans
l’assistant Setup Capture il peut être toutefois nécessaire de le configurer plus finement.
Pour ce faire, c’est encore dans le «package.ini» qu’on peut trouver une section dédiée à cet effet :
;-------- MSI Parameters ---------;Enable MSIFilename if you want to
package.
generate
a
Windows
Installer
MSIFilename=Safari 3.2.3.msi
Nom du package MSI généré.
MSIManufacturer=Amosdec
Nom du fournisseur du package qui apparait dans «Ajout/Suppression de programmes» sous
Windows.
MSIProductVersion=1.0
Version du package.
MSIDefaultInstallAllUsers=1
Si le paramètre est à 1, l’application est déployée pour tous les utilisateurs. S’il est à 0, l’application n’est
déployée que pour l’utilisateur qui lance le MSI.
MSIRequireElevatedPrivileges=1
Ce paramètre s’applique uniquement aux machines sous Windows Vista, si ce dernier est configuré
pour utiliser l’UAC (User Account Control). S’il est à 1, un prompt UAC demandera à l’utilisateur de
valider la demande d’installation.
19
MSIInstallDirectory=Safari 3 (VMware ThinApp)
Nom du répertoire dans lequel le package .exe va être copié sachant que celui-ci est un sous-répertoire
de C:\Program Files\
;MSIProductCode={AA1F7409-4174-0CEA-BB95-8CBADC18FF2F}
MSIUpgradeCode={FE9460B6-CCBD-4A20-3E66-79D4A3F4249C}
Identifiants spécifiques des packages MSI
MSIUseCabs=1
Si ce paramètre est à 1, toutes les données capturées par «ThinApp Setup Capture» dans le projet sont
encapsulées dans une archive .cab elle-même encapsulée dans le MSI.
MSIArpProductIcon=%ProgramFiles%\Safari\Safari.exe
Ce paramètre permet de spécifier l’icône à afficher pour l’application dans «Ajout/Suppression de
programmes» sous Windows.
Depuis la version 4.0.1 de VMware ThinApp il est possible de personnaliser la base de données MSI
afin d’ajuster au mieux les paramètres de déploiement des packages. Ceci se fait en modifiant le
fichier «template.msi» (situé dans le répertoire d’installation de ThinApp) à l’aide d’un outil de
«packaging MSI» spécialisé ou de Orca de Microsoft. (Fig 3-b)
Fig 3-b
Cette méthode est utilisée par exemple pour changer l’emplacement par défaut du déploiement de
l’exécutable, à savoir C:\Program Files\. L’autre méthode pour changer ce chemin est de lancer
le MSI en ligne de commande de cette manière-ci. (Fig 3-c)
Fig 3-c
20
4. Streaming
Une application virtualisée avec ThinApp peut être déployée sur des postes de travail, dans un
environnement Citrix XenApp ou Microsoft Terminal Services, pour être exécutée en local, mais peut
aussi être déposée simplement sur un partage réseau et être lancée à partir de ce dernier : dans ce cas,
le mode d’exécution est le streaming.
Pour bien comprendre ce mode de fonctionnement, il est important de comprendre comment les
données encapsulées dans le package sont organisées. En l’occurrence, toutes ces données sont
organisées en blocs de 64ko par défaut. Ceci est configurable dans le fichier «package.ini», ou
dans les fichiers «##Attributes.ini» pour faire de la configuration individuelle pour chacun des
répertoires du projet, avec le paramètre BlockSize qui se trouve dans la section [Compression].
Les tailles de blocs configurables sont : 64ko, 128ko, 256ko, 512ko ou 1Mo. VMware recommande
néanmoins d’éviter de trop augmenter la taille des blocs, car cela peut ralentir l’exécution de l’application
en mode streaming. Voici un exemple de configuration :
[Compression]
CompressionType=Fast
BlockSize=128
Quand un utilisateur lance un package ThinApp à partir d’un partage réseau, le VOS est d’abord
téléchargé sur le poste puis chargé dans sa mémoire. Le VOS local est désormais capable d’identifier les
blocs nécessaires au lancement de l’application et ne télécharge dans la mémoire du client que ceuxci. Ensuite les blocs correspondants aux différentes fonctionnalités de l’application sont téléchargés
à la demande, au fur et à mesure de l’utilisation. Lorsqu’une DLL applicative est déchargée, les pages
mémoires correspondantes sont également libérées.
5. Exclusion de fichiers
Quand l’utilitaire «ThinApp Setup Capture» construit le projet, il copie tous les fichiers apportés ou
modifiés par l’installation de l’application dans le dossier du projet. Quand on lance la construction
du package, c’est l’ensemble du contenu du dossier de projet qui est encapsulé dans ce package.
Or, l’installation d’une application dépose souvent en cache les fichiers d’installation eux-mêmes ou
des fichiers de logs ou temporaires, inutiles pour l’exécution d’un package d’application virtualisée,
mais qui font grossir la taille du package s’ils ne sont pas supprimés du projet. Au lieu de réaliser
manuellement ce nettoyage, ce qui implique de parcourir l’ensemble des répertoires du projet à la
recherche de ces fichiers, il est possible de configurer des exclusions par type de fichier. Ceci se fait
dans le fichier «package.ini» de la manière suivante :
[FileList]
ExcludePattern=*.msi,*.msp,*.mst,*.tmp
Il est à noter que la section [FileList]n’existe pas par défaut : il faut la créer.
21
6. Outils de commandes et outils tiers
Des outils de ligne de commande sont fournis avec VMware ThinApp. Ils se trouvent dans le répertoire
d’installation. Chacun d’entre eux s’utilise dans des cas bien précis.
a. Thinreg.exe
Cet outil permet simplement de faire avec un package «.exe» ce qu’un package MSI fait
automatiquement, à savoir la création des raccourcis, les associations de fichiers et l’enregistrement
dans «Ajout/Suppression de programmes».
Ceci est très utile par exemple lorsque l’administrateur souhaite mettre à disposition sur des postes
utilisateurs des packages ThinApp situés sur un partage réseau. Les exécutables ne sont alors pas
stockés en local sur le poste de l’utilisateur, mais celui-ci peut s’en servir comme n’importe quelle
application réellement installée : en la lançant à partir d’un raccourci ou en double-cliquant sur un
fichier d’un certain type. Puisqu’il est utilisable en ligne de commande, l’outil est bien évidemment
scriptable.
b. Sbmerge.exe
«Sbmerge.exe» s’avère particulièrement utile quand un projet a été créé, que le package ThinApp a
été généré et qu’il y a de nouvelles modifications à inclure dans la configuration de l’application. Dans
ce cas, il est possible :
• de lancer le package ThinApp
• de faire les modifications directement, qui seront alors stockées dans la Sandbox
• et pour terminer, d’appliquer ces dernières sur le dossier de projet.
Ceci se fait avec «sbmerge.exe» : une fois l’opération réalisée, il ne reste plus qu’à reconstruire le
package, qui prendra en compte la dernière configuration faite.
L’outil s’utilise de la manière suivante :
Sbmerge.exe Apply –ProjectDir
path>
<project_path>
-SandboxDir
<sandbox_
Pour que le succès de la virtualisation d’une application soit total, il est parfois nécessaire de surveiller ce qui
se passe quand le package est exécuté. C’est ce que permettent les outils fournis par VMware, à savoir Log
Monitor et DLL_Dump.
22
c. Log Monitor.exe
«Log Monitor.exe» permet de tracer dans un fichier texte la totalité des exécutions et des appels
systèmes réalisés par le package. Le résultat très détaillé est exploitable uniquement par un ingénieur
système (Fig 6-a).
Fig 6-a
d. DLL_Dump.exe
«DLL_Dump.exe» liste tous les packages ThinApp en cours d’exécution et affiche pour chacun quelles
sont les DLLs chargées par l’application à l’intérieur du package et celles qui existent réellement sur le
système et qui sont chargées par Windows.
Des outils tiers peuvent également être utilisés pour aider à la résolution de problèmes. C’est le cas d’outils
comme «Filemon» et «Regmon» de Sysinternals pour monitorer les activités fichiers et base de registres,
de «Thinstall Helper» de CIS Group, qui permet entre autres de fournir une vue graphique des différents
niveaux d’isolation d’un projet.
En conclusion, ci-dessous quelques liens forts utiles pour vous accompagner dans vos projets de virtualisation
d’applications :
http://www.vmware.com/pdf/thinapp403_manual.pdf
http://www.vmware.com/products/thinapp/related-resources.html
http://blogs.vmware.com/thinapp/2009/05/app-troubleshooting.html
23
Félicitations
Vous êtes prêt à virtualiser vos applications avec VMware ThinApp.
A propos d’Amosdec
Distributeur, grossiste à valeur ajoutée, créé en 1990, AMOSDEC recherche des solutions innovantes
et performantes sur les marchés internationaux et en assure la commercialisation en France au travers
d'un réseau de revendeurs partenaires. La société acquiert l’expertise de ces nouvelles technologies,
puis la transfère à des revendeurs, sélectionnés pour leur haut niveau de compétences et leurs capacités
à traiter les problématiques propres aux architectures du système d’information.
AMOSDEC s'est intéressé très tôt à VMware et a pris en charge sa distribution en France dès 2002.
En moins de 10 ans, Amosdec est devenu un expert dans la virtualisation des infrastructures. Amosdec
dispose de centres de formation répartis sur toute la France. Au cours des années, Amosdec a signé la
distribution de logiciels d’éditeurs proposant un écosystème riche et performant autour de VMware
tant sur le Datacenter que sur le poste de travail : Expand, Leostream, Novell/Platespin, Stonesoft,
Thinprint, Veeam et Vizioncore.
Amosdec développe également son expertise dans le Datacenter virtualisé et complète son offre avec
la distribution des systèmes de stockage NetApp.
Avec plus de 50 collaborateurs entièrement dédiés à la virtualisation et au stockage, Amosdec met
son expertise au service de ses revendeurs partenaires. Il leur propose des outils pour accélérer les
processus de certification et d’acquisition de compétences et met à leur disposition en permanence
ses équipes techniques, commerciales et marketing.
Nous contacter
Amosdec
1, place Victor Hugo
92400 Courbevoie
Tel : 01 41 91 55 55
Fax : 01 41 91 55 96
www.amosdec.com
Le Cahier Technique est diffusé par Amosdec.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit, sans l'autorisation d'Amosdec
est illicite et constitue une contrefaçon.

Virtualisation d`application avec VMware ThinApp

Transcription

Documents pareils

Expert Virtualisation et poste de travail (H/F) - Offre d`emploi

La virtualisation logicielle à l`aide de VMWare et Virtual PC

Bonjour, Il y a quelques jours, vous avez reçu une

La Virtualisation du poste de travail

Exécution d`Internet Explorer 6 sur Windows 7

A B E D C SITUER UN POINT C A D E F B SUR UNE FEUILLE

Cv au format PDF - Christophe Guerville

Process d`enregistrement Safeguard pour les revendeurs IBM