Comment ça marche ?

Il est important de lister les différentes couches en question, il existe 4 grandes couches :

• Matériel
• Système
• Applicative
• Données et paramètres.

App-V se situe au niveau de la couche Applicative et permet de "virtualiser" celle-ci. App-V permet :

• D’isoler les applications
• De centraliser les permissions
• De préserver l’intégrité du poste client
• De garder une compatibilité entre les applications
• De déployer plus facilement une application
• Mise en conformité du poste client.

App-V permet de créer des bulles applicatives indépendantes du système et de ses paramétrages. Ces bulles sont déployées sur le poste client, le code de l’application s’exécutera en local. La bulle applicative ne sera donc pas installée mais stockée sur une partition fictive (par défaut : Q:\) et s’exécutera dans un environnement "virtualisé", ne touchant ainsi pas aux paramètres système. Ce procédé aide à résoudre des problèmes de compatibilité et de conflits d’accès aux DLLs, registres etc.

Pour résumer, l’administrateur met à disposition sur un serveur un certains nombres d’applications, qu’il va attribuer par des groupes Active Directory qu’il aura mis en place au sein de son organisation. Lorsque le client se connectera au réseau, le client App-V se connectera au serveur pour savoir à quoi il a accès. Il téléchargera la liste des applications et déposera les différentes icônes aux endroits spécifiés par l’administrateur (bureau, menu démarrer etc.) Ceci est totalement transparent pour l’utilisateur.

Lorsque le client voudra utiliser une application pour la première fois, il cliquera sur l’icône. Le client va demander au serveur de lui envoyer la bulle applicative en streaming (le launcher sera envoyer en premier afin de réduire au maximum le temps d’attente ressenti). Lorsque le client aura reçu l’application, il exécutera en local l’ensemble de la bulle applicative envoyée par le serveur (limitant ainsi les interactions avec le système). L’application s’ouvrira sans être installée.

Il est aussi possible de rendre disponible l’application "hors connexion" ou hors réseau),  un client mobile pourra donc exécuter l’application à partir de chez lui (à condition qu’il n’y ait aucune interaction Client-Server sur l’applicatif).

Un processus de mise à jour est possible, si vous déployez une nouvelle version de l’application, le client lors de sa prochaine connexion au réseau, re-téléchargera l’ensemble de l’application. Le processus est similaire, si le client fait face à un problème avec l’application, il lui est possible de la « réparer » (ou retélécharger l’ensemble de la bulle applicative) Ceci est totalement transparent pour l’utilisateur.

Les différentes entités ?

La suite App-V est composée de cinq composants :

• Microsoft Application Virtualization Management Server : C'est l'un des deux types de serveur Application Virtualization à partir duquel un package d'applications séquencées peut être diffusé. Outre le serveur Application Virtualization Management Server prend en charge la mise à niveau active, la gestion des licences et une base de données pouvant être utilisée pour la création de rapports.
  
  Cette entité est composée du serveur de Management, du Web Service Management (ce qui permet d’administrer le serveur), de la console (qui permet de se connecter au Web Service afin d’administrer le serveur). Seul le serveur de management est obligatoire. Il est possible de rajouter le serveur de Management à un groupe de serveurs sur un autre serveur de management afin de gérer l’ensemble des serveurs à partir d’une console de Management.
  
  
• Microsoft Application Virtualization Streaming Server : Qui est chargé d’héberger les packages Application Virtualization en vue de les diffuser sur des clients d’un site. Ce serveur inclut uniquement la fonctionnalité de diffusion. Il n’a donc pas  de console Application Virtualization Management, ni de service Web de gestion Application Virtualization.
  
  
• Microsoft Application Virtualization Sequencer : Qui sert à capturer l’installation des applications pour créer des packages d’applications virtuelles.
  La sortie se compose des icônes de l’application, d’un fichier OSD contenant des informations sur la définition du package, d’un fichier manifeste de package et du fichier SFT regroupant les fichiers de contenu du programme d’application.
  
  
• Microsoft Application Virtualization Client : Qui permet de gérer automatiquement les environnements virtuels pour les différentes bulles applicatives App-V. Il publie les applications sur les postes de travail et gère les connexions avec le serveur App-V. Le client App-V stocke les spécificités utilisateurs et les paramétrages des applications virtuels dans chaque profil utilisateur.
  
  
• Microsoft Application Virtualization Terminal Services Client : Il réside sur un serveur hébergeant un service Terminal Server et permet de communiquer et s’authentifier auprès de Microsoft Virtual Application Server pour recevoir le code d’application et autoriser l’exécution locale d’une application séquencée.

Quoi virtualiser ?

Tout ou presque, vous pouvez tout virtualiser à condition que l’application:

• N’installe pas de drivers (imprimante, usb …)
• N’installe pas de services qui utilisent le Boot-time
• N’utilise pas COM+
• Il est donc tout à fait possible de virtualiser des applications « lourde » (CAO …) comme la suite Corel ou Adobe.

Attention, App-V ne résout pas les problèmes de compatibilité d’application liés au système d’exploitation. Il n’est donc pas possible d’utiliser App-V pour installer une application non compatible avec Vista sur un client Windows Vista. Pour résoudre ce genre de problème, Microsoft a développé MED-V (suite au rachat de Kidaro) qui permet de faire de la virtualisation de système d’exploitation.