Virtualisation

Mise en route de Microsoft Application Virtualization

Anthony Kinney

Cet article est basé sur une version préliminaire d’App-V. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

En un coup d'œil :

• Architecture de App-V
• Gestion des applications virtuelles
• Utilisation du séquenceur App-V
• Intégration de App-V au Gestionnaire de configuration

Sommaire

Architecture d’App-V
Fonctionnement de l'infrastructure App-V complète
Mise à jour d'applications virtuelles
Séquencement
Version 4.5

Microsoft Application Virtualization (ou App-V) est un sujet qui me tient à cœur. App-V s'appelait auparavant SoftGrid et je suis arrivé chez Microsoft dans le cadre de l'acquisition de l'entreprise qui a créé SoftGrid, Softricity. Je suis très heureux d'avoir l'opportunité d'écrire cet article pour TechNet Magazine, car beaucoup de choses ont changé depuis l'acquisition du logiciel.

La meilleure façon d'aborder App-V est de parler tout d'abord des défis auxquels les professionnels de l'informatique font face sur le plan de l'administration d'entreprise. Un Bureau professionnel est de nos jours encombré d'applications. Avant qu'une application ne soit installée, elle doit faire l'objet de longs tests de régression afin de garantir qu'elle peut coexister avec les autres applications installées sur le système, sans influer sur leur capacité à s'exécuter correctement. L'application doit ensuite faire l'objet d'un ensemble de processus de déploiement avant de pouvoir passer en production. Comme une application est essentiellement uniquement disponible à l'emplacement de son installation, vos utilisateurs sont confinés à des ordinateurs spécifiques. Ceci complique davantage les projets complexes tout en étant essentiels, tels que les migrations de système d'exploitation et d'application, la mise à jour de la sécurité et la planification de récupération après incident.

App-V change tout cela. Au lieu de se composer d'un ensemble complexe d'étapes accaparant des ressources, la gestion de postes de bureau devient avec App-V un processus plus simple et plus automatisé. Vous pouvez facilement déployer, corriger, mettre à jour et mettre fin à des applications avec de meilleurs résultats.

Avec App-V, un utilisateur peut prendre place devant n'importe quel bureau et accéder à ses applications. Les applications sont remises à la demande mais exécutées comme si elles étaient en fait installées localement. Ainsi, il n'est pas nécessaire d'installer les composants de l'application ou de modifier le périphérique hôte.

Cette utilisation de la virtualisation pourrait modifier radicalement la manière dont les professionnels de l'informatique gèrent les bureaux. Ne pas modifier le périphérique hôte et exécuter à la place des applications virtualisées présente de nombreux avantages, dont :

• Moins de conflits d'applications
• Mises à jour plus rapides et plus faciles
• Possibilité d'exécution côte à côte de versions multiples de la même application
• Applications flexibles accompagnant l'utilisateur en ligne et hors connexion
• Tests de régression d'application à application réduits

Architecture App-V

Examinons maintenant ce qui se passe vraiment dans les coulisses de la plate-forme App-V. La plate-forme se compose d'un nombre réduit de composants principaux : un séquenceur, une base de données, des clients, un serveur d'administration, un serveur de diffusion et une console d'administration (voir figure 1).

Figure 1 Disposition d'un environnement App-V (cliquez sur l'image pour l'agrandir)

Le client App-V est au cœur du système App-V. Il existe deux types de clients pouvant être utilisés, le client Terminal Server et le client ordinateur de bureau. Dans les deux cas, le client doit être installé sur chaque bureau et serveur Terminal Server sur lequel vous avez l'intention de déployer des applications virtuelles. Le client occupe relativement peu d'espace disque. Il installe un pilote et possède un composant d'exécution utilisateur visible qui est représenté par un indicateur sur la barre d'état.

Le client rassemble la liste des applications virtuelles depuis le serveur d'administration App-V et affiche les applications virtuelles disponibles. Il prend en charge le lancement de ces applications (lorsqu'il est démarré par l'utilisateur) et la gestion du cache côté client. Le client est également responsable de la gestion de la création de l'environnement d'exécution virtuel et de garantir que chaque environnement s'exécute dans sa propre bulle virtuelle. Cet environnement virtuel inclut plusieurs composants, dont un Registre virtuel, un système de fichiers virtuel et un gestionnaire de services virtuel.

Il existe trois options de déploiement d'infrastructure disponibles dans App-V 4.5 : infrastructure complète, infrastructure légère et mode autonome. Lorsque vous déployez une infrastructure complète, le système principal inclut le serveur d'administration App-V et le serveur de diffusion App-V (il s'agit d'un nouveau composant que j'aborderai dans un instant). Le serveur d'administration App-V héberge et livre les applications virtuelles centralisées et met à jour les applications virtuelles lorsque des correctifs ou des mises à jour sont appliqués.

Ce serveur d'administration s'appuie sur SQL Server pour héberger la base de données App-V, qui contient la configuration et les paramètres des applications virtuelles. Vous devez utiliser des groupes Active Directory comme outil d'administration centrale pour configurer et contrôler les autorisations d'accès aux applications virtuelles.

Pour gérer les paramètres et la configuration, la plate-forme App-V fournit un service Microsoft .NET Framework qui peut être chargé sur le même serveur pourvu qu'IIS soit installé. Ce service Web sert de liaison entre la console d'administration App-V, un composant logiciel enfichable Microsoft Management Console (MMC), et la base de données App-V. Les administrateurs peuvent utiliser la console pour publier et administrer des applications virtuelles, affecter des groupes Active Directory et contrôler les paramètres de serveur, ainsi qu'exécuter des rapports sur l'utilisation des applications virtualisées (voir figure 2).

Figure 2 Console d'administration (cliquez sur l'image pour l'agrandir)

L'infrastructure légère comprend le serveur de diffusion App-V, qui donne des possibilités de diffusion comme par exemple la mise à niveau active/de package. Cette option ne nécessite ni Active Directory ni SQL Server, ne possède aucun service de configuration d'ordinateur de bureau et ne dispose pas de capacités d'autorisation et de contrôle. L'infrastructure légère permet cependant aux capacités de diffusion d'être ajoutées à System Center Configuration Manager et à d'autres solutions de déploiement de logiciels d'entreprise (ESD).

En mode autonome, le séquenceur App-V peut créer un fichier MSI qui automatise l'ajout de l'application virtuelle (voir figure 3). Le fichier MSI contient des métadonnées qui permettent à tout système ESD de le reconnaître et de contrôler l'application virtualisée. Ce mode nécessite que le client entre en mode autonome, qui permet uniquement les mises à jour s'appuyant sur MSI des applications virtuelles, la diffusion n'étant pas autorisée dans ce mode. Ce mode donne aux organisations la possibilité d'utiliser les capacités d'isolation d’App-V.

Figure 3 Séquenceur App-V (cliquez sur l'image pour l'agrandir)

Les fichiers MSI sont très flexibles. Ils peuvent s'exécuter de manière complètement autonome avec seulement un client App-V, et ne nécessitent pas de composants serveur. Ceci signifie qu'ils peuvent être déployés manuellement, avec un disque ou à l'aide d'outils de déploiement traditionnels.

Dans App-V 4.5, HTTP et HTTPS sont maintenant des protocoles pris en charge pour la diffusion. Ceci permet d'obtenir de meilleures performances de diffusion avec un protocole plus largement répandu, surtout pour la diffusion sur les environnements de réseau global (WAN) et sur Internet.

Fonctionnement de l'infrastructure App-V complète

Un utilisateur ouvre une session sur un périphérique équipé de l'un des clients (soit un service Terminal Server App-V soit un client ordinateur de bureau) et le client envoie une requête au serveur pour obtenir la liste des applications affectées à l'utilisateur actuel. Le serveur communique avec Active Directory pour déterminer les groupes desquels l'utilisateur est membre et renvoie ensuite la liste des applications au client. Le client commence à créer des publications pour les applications virtuelles qui ont été affectées à cet utilisateur particulier.

Au cours de ce processus de publication, plusieurs opérations sont exécutées :

• Les fichiers de configuration sont copiés
• Les icônes de Bureau sont créées
• Les liens Envoyer à sont créés
• Les dossiers du menu Démarrer sont créés
• Les types de fichiers sont configurés

Ce processus est très rapide et, ce qui est plus important, garantit que l'environnement reflètera exactement ce que prévoit l'utilisateur, sans aucune modification visuelle. Les applications virtuelles agissent comme si elles étaient installées localement, sans, bien entendu, altérer l'ordinateur hôte. Les icônes, au lieu de pointer vers des fichiers exécutables qui résident dans le répertoire des fichiers de programmes, pointent vers le client App-V, qui s'appuie sur un fichier de lanceur (un fichier OSD) pour sa configuration.

Il est important de noter que ce processus possède un impact très réduit sur le réseau car, contrairement aux déploiements de logiciel traditionnels, rien n'est installé. Ceci possède des avantages fantastiques, surtout dans les environnements d'utilisateurs itinérants, car les applications sont disponibles pour l'utilisateur sans que quoi que ce soit ne soit livré avant le lancement d'une application. Cette méthode de publication est également ce qui fournit les fonctionnalités d'application à la demande et fonctionnalités itinérantes d'App-V.

Lorsque l'utilisateur lance une application virtuelle, le client lit un fichier de configuration OSD, qui a été enregistré sur l'ordinateur local. Ceci indique au client le protocole à utiliser pour communiquer avec le serveur d'administration App-V et le serveur sur lequel réside l'application.

Le serveur approprié répond au client en diffusant le seuil de lancement initial, qui constitue généralement 20 à 40% de l'application complète. Une fois que le seuil de lancement a été diffusé (encore une fois, il s'agit de seulement 20 à 40% de l'application), l'application virtuelle est prête à s'exécuter.

La diffusion est vraiment l'un des éléments clés du changement de paradigme introduit avec App-V. Elle peut envoyer juste ce qu'une application nécessite pour qu'elle puisse s'exécuter, sans gaspiller la précieuse bande passante du réseau. Toutes les données remises au client résident dans un fichier de cache local du périphérique et tout lancement ultérieur de l'application est effectué depuis le cache local, éliminant tout trafic réseau supplémentaire.

Une fois la diffusion de l'application virtuelle terminée, le client crée un environnement isolé qui empêche l'application de modifier l'ordinateur local (en d'autres termes, l'application ne laisse aucune trace). Le client permet, cependant, à l'application virtuelle d'accéder au système de fichiers local pour l'enregistrement et la modification des fichiers, et il permet également à l'application d'interagir avec les services locaux (tels que l'impression) pourvu que l'utilisateur possède les autorisations appropriées sur le système local. Mais toute modification apportée par une application virtuelle aux fichiers et au Registre du système local est redirigée vers l'environnement virtualisé afin que le périphérique hôte demeure inchangé.

Lorsque l'application est exécutée, toute fonctionnalité qui n'a pas auparavant été utilisée sera livrée lorsque nécessaire et mise en cache pour les utilisations ultérieures. L'avantage de ceci est que seuls les composants nécessaires pour l'utilisateur sont chargés au lancement initial et les fonctionnalités qui ne sont pas nécessaires n'utilisent pas de ressources réseau (la nouvelle version offre des améliorations en matière de mise en cache côté client permettant une utilisation plus intelligente de la mise en cache et de la diffusion en arrière-plan).

Prenez l'exemple de Microsoft Office Word. Presque tous les utilisateurs utilisent le correcteur orthographique (Je ne pourrais d'ailleurs pas écrire cet article sans lui !). Il ferait donc partie du lancement initial. Mais qu'en est-il de la fonctionnalité d'aide de Word ? Un nombre moindre d'utilisateurs utilise cette fonctionnalité et elle ne nécessite pas d'être livrée au lancement initial. Elle serait plutôt envoyée à un utilisateur la première fois qu'il accède à celle-ci.

Lorsque l'utilisateur a terminé et ferme l'application, le client détruit l'environnement virtuel et enregistre tous les paramètres utilisateur dans un emplacement spécifique à utilisateur afin que l'environnement puisse être conservé et reconstruit au lancement suivant. Le pourcentage de l'application virtuelle qui a été diffusé demeure dans le cache local et est disponible pour le lancement suivant. Si un autre utilisateur ouvre une session sur le même système hôte et lance la même application virtuelle, le nouvel utilisateur profite du fait que l'application est déjà enregistrée dans le cache.

Pour supprimer les publications d'application virtuelle, supprimez simplement l'utilisateur du groupe Active Directory approprié. Pour désinstaller complètement l'application virtuelle d'un bureau, vous pouvez simplement vider le cache. Puisque l'application n'a jamais été vraiment installée localement, il n'y a pas d'invites demandant « Voulez-vous supprimer ce composant partagé » ?

Notez que même si une application virtuelle est enregistrée dans un cache, cela ne signifie pas que tous les utilisateurs y ont accès. Contrairement aux applications installées localement avec lesquelles les utilisateurs peuvent simplement rechercher ou parcourir tous les exécutables auxquels ils n'ont pas le droit d'accéder, il n'existe aucune représentation visuelle ou physique de l'existence de l'application virtuelle, à moins que l'utilisateur n'ait été affecté de droits explicites au travers de groupes Active Directory.

Mise à jour d'applications virtuelles

La mise à jour est effectuée avec un séquenceur. Une fois une application revue pour inclure une mise à jour, elle est placée sur le serveur d'administration App-V en regard de la version précédente. Le serveur avertit alors le client, lors du lancement suivant, qu'une modification a été effectuée. Si la version précédente est toujours utilisée, l'utilisateur continue à avoir accès à cette version jusqu'à ce que l'application virtuelle soit fermée. Au lancement suivant, les différentiels qui composent la mise à jour sont diffusés au client et chargés dans le cache, avec pour résultat une version mise à jour de l'application.

Imaginons que vous disposez de 1 000 utilisateurs exécutant Word 2000. Un administrateur doit mettre à jour Word 2000 (word2K.sft) vers Word 2000 SP3 pour qu'elle copie le fichier word2K.sur la station de séquencement et sélectionne Open for package upgrade dans le séquenceur. En sélectionnant Open for package upgrade, l'administrateur commence à travailler à partir du dernier état de package. Il peut copier alors des DLL, exécuter des mises à jour ou exécuter des correctifs dans l'application virtuelle pour la mettre à jour vers Word 2000 SP3. L'administrateur enregistre ensuite ce package mis à jour.

Le séquenceur lui attribue automatiquement un nouveau nom de fichier, word2K_2.sft, afin d'empêcher l'apparition de noms de fichier en double et d'indiquer la version de séquencement. Ce nouveau package est placé dans le même répertoire que l'ancien package sur le serveur d'administration App-V afin que Word 2000 (word2K.sft) et Word 2000 SP3 (word2K_2.sft) résident dans le même répertoire. L'administrateur utilise alors la console de gestion App-V pour lier ensemble ces deux fichiers SFT.

Côté client, les utilisateurs qui ont une session active Word 2000 sans SP3 ouverte continuent à travailler normalement. Les utilisateurs qui lancent une nouvelle session de l'application après que l'administrateur ait effectué ceci recevront un message indiquant qu'une modification a été détectée. Le client commence alors à diffuser uniquement les modifications du différentiel entre word2K.sft et word2K_2.sft, en mettant automatiquement à jour l'application vers Word 2000 SP3.

En raison de la nature dynamique des applications virtuelles, la restauration est également très facile. Il est simplement nécessaire de revenir à la console de gestion App-V et de supprimer la version récemment ajoutée. Ceci provoque le retour du client à la version précédente au lancement suivant. Pour éviter tout mélange croisé des données de package, le client purge automatiquement le cache et rediffuse le fichier SFT correct. Ceci est un compromis nécessaire lorsque vous considérez ce qui doit être effectué pour restaurer une mise à jour d'application qui a été physiquement installée en utilisant des outils de déploiement de logiciel plus traditionnels.

Pour bénéficier des avantages de App-V, vous devez créer des packages d'applications virtuelles. C'est là que le séquenceur App-V entre en jeu. Toutes connaissances et expérience de l'écriture de scripts et de la création de packages que vous possédez pour les outils de déploiement de logiciel traditionnels faciliteront votre transition vers le séquencement (je devrais par ailleurs mentionner que le séquencement en soi pourrait nécessiter un article complet).

La plupart des solutions de déploiement de logiciel s'appuient sur des scripts qui capturent la façon dont une application s'installe et copient ensuite le processus sur d'autres ordinateurs, éliminant la nécessité d'examiner chaque ordinateur pour installer ou mettre à jour des applications. Une fois l'application installée, les outils de déploiement de logiciel courants n'ont plus à se soucier du package. Vous devez alors installer toute dépendance sur laquelle l'application peut s'appuyer, exécuter d'autres scripts ou des étapes manuelles pour la configuration de l'application conformément à vos besoins.

Le changement fondamental dans App-V est que le processus de séquencement produit une image complète d'une application déjà installée, avec ses dépendances et ses configurations. Celle-ci peut être « lue » par le client App-V sans modifier le périphérique sur lequel elle est lue.

Le séquenceur produit une variété de fichiers, le plus important étant le fichier SFT, qui contient les actifs, les dépendances et les informations de configuration de toute l'application. Dans certains cas, il peut également contenir plusieurs applications. Il n'est pas surprenant que ce fichier soit de taille importante. Il existe des options de compression, mais une connaissance solide de vos performances de réseau et de périphérique est essentielle. Le fichier d'icône (.ico) que crée le séquenceur est utilisé pour publier l'application virtuelle afin qu'elle agisse comme si elle était installée localement.

Le fichier OSD est également très important et ses options sont innombrables. Par défaut, il s'agit d'un fichier XML qui est utilisé pour indiquer au client App-V comment lancer l'application virtuelle. Le fichier OSD peut également être modifié pour configurer et contrôler la manière dont l'application virtuelle se lance et s'exécute. Je vous suggère fortement de lire les documents Sequencing Admin Guide et Sequencing Best Practices pour vous familiariser avec les propriétés et les valeurs disponibles au travers du fichier OSD.

Pour terminer, le nouveau fichier manifest.xml contient des informations de configuration basées sur le package et peut être utilisé pour l'intégration avec des solutions ESD tierces et les déploiements avec MSI. Le séquenceur peut également générer un fichier MSI pour le package d'application virtuelle. Celui-ci peut être utilisé pour charger les applications virtuelles sur les clients autonomes (sans serveur) et au travers d'un système ESD.

Le séquenceur en soi est un outil basé sur Assistant qui vous guide, en tant que créateur de package, au travers du processus d'installation d'une application et de sa transformation en application virtuelle (voir figure 4). La première étape vous permet de configurer des propriétés par défaut pour le package. Ces propriétés, qui sont enregistrées dans le fichier OSD, incluent le nom de package et des commentaires. Certains paramètres avancés vous permettent de spécifier le serveur depuis lequel diffuser, le répertoire de contenu et les systèmes d'exploitation que le package doit prendre en charge.

Figure 4 Assistant de séquencement (cliquez sur l'image pour l'agrandir)

La deuxième étape consiste à installer, configurer et tester l'application. Pendant l'installation, le séquenceur capture toutes les modifications apportées au système local, y compris le système de fichiers, le Registre et le système. Il existe également quelques utilitaires dans cet Assistant permettant, par exemple, l'intégration à Windows Update.

L'étape suivante consiste à configurer les associations de types de fichiers et à spécifier où doivent être placés les raccourcis. Les emplacements standard incluent le menu Démarrer, le bureau et la barre d'outils de lancement rapide, mais vous pouvez également créer des emplacements personnalisés.

Vous devez ensuite lancer l'application et configurer le seuil de lancement initial. Il s'agit de l'étape au cours de laquelle App-V détermine la portion initiale de l'application qui doit être remise au client pour permettre à l'application de commencer.

Pour configurer ce code initial (auquel il est généralement fait référence par le terme Feature Block 1 ou FB1), lancez simplement l'application et utilisez les fonctionnalités les plus courantes dont ont besoin les utilisateurs. Par exemple, lancez Word et démarrez le vérificateur orthographique. Tout fichier, clé de Registre ou DLL appelé par l'application pendant cette phase, est automatiquement désigné comme faisant partie du FB1. Tout fichier, paramètre ou composant non utilisé à ce stade est ajouté au FB2. Lorsque l'application sera par la suite utilisée, le client recevra un mappage du fichier SFT qui indique où commence et s'arrête FB1 et où se trouvent les autres fichiers dans FB2, afin que le client puisse récupérer ces fichiers lorsque ceux-ci sont nécessaires pour l'application.

L'étape finale du processus de séquencement est de garantir que tout est correctement configuré. Le séquenceur affiche la boîte de dialogue de la figure 5, qui représente le SFT et vous permet d'effectuer des modifications ou ajouts finaux au package.

Figure 5 Confirmation et adaptation d'un package final (cliquez sur l'image pour l'agrandir)

Version 4.5

Après deux années de développement, la sortie de App-V 4.5 est prévue pour la fin de l'année. Ceci est la première version du produit publiée par Microsoft et elle promet de relever la barre de la virtualisation d'application en introduisant plusieurs améliorations essentielles, telles que l'interaction d'application virtuelle dynamique, l'évolutivité étendue et une conformité améliorée avec les exigences d'internationalisation et de sécurité de Microsoft.

L'interaction d'application virtuelle dynamique permet aux applications virtualisées d'interagir entre elles. Cette interaction porte le nom de DSC (Dynamic Suite Composition, composition de suite dynamique). DSC ne remplace pas la capacité d'ajouter plusieurs applications à un même package. Elle offre plutôt une nouvelle manière d'intégrer dépendances, middleware et plug-in partagés entre applications virtuelles.

Les administrateurs peuvent spécifier les applications virtualisées pouvant interagir entre elles. Par exemple, supposez que vous disposez de cinq applications Web nécessitant la même version de Java. Dans App-V 4.1, vous deviez ajoutez cette même version de Java à chacun des cinq packages. Supposez que cette version de Java ait besoin d'un correctif. L'administrateur devrait alors installer le correctif dans les cinq packages différents. Avec DSC, Java peut être empaqueté une seule fois et ensuite configuré comme package à utiliser par les cinq applications Web. Par conséquent, l'application d'un correctif à Java nécessiterait seulement que l'administrateur applique un correctif au package Java une seule fois.

Le même scénario s'applique aux middleware et aux plug-ins. J'ai l'intention de bloguer à propos d'autres scénarios pratiques lorsque la date de publication par Microsoft approchera et que les derniers ajouts seront finalisés.

Les améliorations en termes d'évolutivité ont trait à la diffusion comme à l'infrastructure principale. Les composants principaux ont été modifiés pour mieux prendre en charge la mise en cluster et les scénarios de basculement et la diffusion est plus adaptée aux réseaux locaux et globaux. Les améliorations proviennent de plusieurs ajouts essentiels.

Tout d'abord, le nouveau composant de serveur de diffusion (Streaming Server Component) permet la diffusion sans nécessiter une infrastructure principale avec Active Directory et SQL Server. Vous bénéficiez toujours des avantages importants de la livraison à la demande et de la mise à jour centralisée des packages, mais sans les lourdes exigences du back-end. Ceci sera fréquemment utilisé dans les scénarios de succursale et pour l'intégration avec les solutions ESD tierces.

Le client App-V a également fait l'objet de quelques améliorations. Par exemple, le client enregistre maintenant toutes les informations d'utilisation localement afin de pouvoir effectuer un suivi de ces informations que le système soit en ligne ou hors connexion. Le cache de client a également été étendu et amélioré pour obtenir de meilleures performances dans les scénarios dans lesquels l'espace disque est limité. Il existe également maintenant une prise en charge du séquencement d'applications utilisant une langue différente de l'anglais, pour l'exécution d’App-V sur les systèmes d'exploitation différents de l'anglais, et le logiciel a été localisé dans plusieurs autres langues.

Intégration d’App-V au Gestionnaire de configuration

Plusieurs améliorations et nouvelles fonctionnalités de App-V 4.5 ont été conçues pour l'intégration de App-V à SCCM 2007 R2. Comme je l'ai déjà mentionné, la virtualisation et la diffusion offrent certaines capacités pour la livraison d'applications que ne fournissent pas les outils de déploiement de logiciel traditionnels. Je n'insinue pas que App-V remplacera ces outils, mais plutôt que App-V peut compléter et étendre ceux-ci.

Avec cette intégration, vous obtenez toutes les fonctions d'évolutivité, de création de rapports, de reconnaissance de périphériques et de réseau global de SCCM, ainsi que toutes les fonctions de diffusion et d'isolation d’App-V. Voici certains domaines bénéficiant de l'intégration de ces deux technologies :

Livraison d'application L'intégration de SCCM R2 prend en charge toutes les capacités de livraison à la demande, les applications itinérantes, les seuils de lancement initiaux et le déploiement d'applications sans altération du PC client.

Mises à jour Les points de distribution (DP) SCCM peuvent uniquement déployer les modifications de différentiels d'applications virtuelles lorsque les packages sont mis à jour. Ceci introduit la capacité centralisée de restauration en un seul clic d'applications virtualisées vers des versions précédentes.

Administration La version R2 comprend un nouvel Assistant de publication d'application virtuelle qui permet aux administrateurs de déployer des applications virtualisées ainsi que des packages de logiciels traditionnels et publications à partir d'une console unique.

Empaquetage Il n'est plus nécessaire d'empaqueter de nouveau les applications lors de l'intégration d’App-V avec SCCM. Le séquencement initial d'une application doit être effectué en utilisant la séquence App-V hors de SCCM, mais les administrateurs ont la possibilité de mettre à jour des packages existants avec SCCM.

Licences Le suivi des applications virtuelles peut être effectué pour la gestion des licences et les mesures avec des outils existants de SCCM.

BITS SCCM propose une nouvelle méthode pour le déploiement d'applications virtualisées vers App-V à l'aide du protocole BITS normalisé. Bien que les DP SCCM puissent effectuer des diffusions, il existe des cas dans lesquels la diffusion n'est pas la méthode idéale pour déployer les applications virtualisées. En déployant via SCCM, vous disposez de deux options. Vous pouvez utiliser la diffusion standard ou utiliser les fonctionnalités de Qualité de service (QoS) de BITS pour déployer de manière beaucoup plus contrôlée. Ceci est également utile dans les scénarios dans lesquels vous souhaitez charger le cache avant que les utilisateurs ne lancent l'application virtuelle.

Déploiements d'ordinateurs SCCM offre la possibilité de déployer des applications virtualisées vers des ordinateurs spécifiques et continue à prendre en charge l'approche de ciblage à base d'utilisateur de la plate-forme App-V. Ceci peut être avantageux lorsque vous déployez des applications virtuelles sur des ordinateurs portables, des bornes informatiques ou des ordinateurs de laboratoire. Ceci est également pratique pour faciliter le contrôle de licence lorsque votre logiciel est autorisé par périphérique et non par utilisateur nommé.

Évolutivité La nécessité de déploiement de deux outils séparés se chevauchant dans une mesure importante est un souci courant. En intégrant les avantages de l'évolutivité et de réseau global de SCCM aux avantages de l'isolation et de la diffusion d’App-V, vous pouvez utiliser votre SCCM existant, qui prend en charge l'administration et le déploiement, sans ajouter davantage de complexité.

Anthony Kinney est revendeur technique responsable de Microsoft Desktop Optimization Pack. Anthony a rejoint Microsoft en 2006 dans le cadre de l'acquisition de Softricity. Durant ses années chez Softricity, Anthony a écrit et conçu le premier programme de formation pour SoftGrid (qui porte maintenant le nom d’App-V). Vous pouvez le contacter à l'adresse suivante : Anthony.kinney@microsoft.com.