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 : cta@amosdec.fr
Bonne lecture !
edito
Virtualisation d’application avec VMware ThinApp
Cahier Produit Amosdec • Q1 2009 • Numéro 2
Virtualisation d’application avec Vmware ThinApp
Avec ombre portée
Sans ombre portée
Cahier produit Amosdec
I • Introduction
1. Qu’est ce que la virtualisation d’applications?
2. Problématiques et avantages a. Compatibilité
b. Sécurité c. Déploiement
II • La solution VMware ThinApp
1. De Thinstall à VMware ThinApp 2. Concept de Sandbox
3. Installation
4. Installation d’un package
III • Utilisation avancée - Package.ini
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
Sommaire
1
3
15
1 1 1 2 2
3 3 4 7
15 15 16 17 18 21 21 22 22 22 22 22
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.
I • Introduction
1. Qu’est ce que la virtualisation d’applications?
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.
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.
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)
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.
Fig 1-a
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)
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.
Fig 2-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)
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
Fig 3-b
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-c
Fig 3-d
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)
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
Fig 4-a
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-b
Fig 4-c
Puis on installe l’application que l’on souhaite virtualiser. Ici un exemple avec Mozilla Firefox. (Fig 4-e) Fig 4-d
Fig 4-e
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)
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-f
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)
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)
Fig 4-h
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-i
Le projet est alors créé et stocké à l’endroit indiqué précédemment dans l’assistant. (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-k
Fig 4-l
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-m
Fig 4-n
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 sous- jacent
• 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.
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.
;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 suc- cè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 sous- répertoires du projet à l’aide du fichier «##Attributes.ini» présent dans chacun de ceux-ci.
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)
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.
Fig 2-a
Fig 2-b
L’utilisation de packages MSI s’avère très utile pour la simplification des déploiements mais aussi pour trois raisons principales :
• 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 generate a Windows Installer package.
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.
Fig 3-a
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)
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
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 ceux- ci. 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.
4. Streaming
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.
5. Exclusion de fichiers
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.
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.
a. Thinreg.exe
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 <project_path> -SandboxDir <sandbox_
path>
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.
c. Log Monitor.exe
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
«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
Félicitations
Vous êtes prêt à virtualiser vos applications avec VMware ThinApp.
A propos d’Amosdec
Amosdec
1, place Victor Hugo 92400 Courbevoie Tel : 01 41 91 55 55 Fax : 01 41 91 55 96 www.amosdec.com
Nous contacter
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.
