Octobre 2008 Octobre 2008
Virtualisation: Introduction de Hyper-V dans Windows Server 2008
L'introduction de Hyper-V fait de la virtualisation une solution encore plus irrésistible pour les environnements informatiques. Obtenez une présentation du marché de virtualisation d'aujourd'hui et voyez comment Hyper-V améliore la facilité de gestion, la fiabilité et la sécurité de virtualisation Rajiv Arunkundram
Virtualisation: Gérez vos environnements virtuels avec VMM 2008
System Center Virtual Machine Manager fournit une interface consolidée pour la gestion de votre infrastructure virtuelle. La dernière version ajoute la prise en charge de Windows Server 2008 Hyper-V, ainsi que des ordinateurs virtuels VMware. Explorez les nouvelles fonctionnalités et découvrez comment utiliser VMM pour centraliser vos tâches de gestion. Edwin Yuen
Virtualisation: Mise en route de Microsoft Application Virtualization
Microsoft Application Virtualization (App-V) vous permet de livrer des bureaux virtualisés aux systèmes clients de toute votre entreprise. Ceci simplifie l'administration des systèmes et permet de détacher les employés de leur bureau. Examinez le fonctionnement d'App-V et découvrez comment le déployer dans votre entreprise. Anthony Kinney
Virtualisation: Haute disponibilité pour Hyper-V
Consolider les serveurs sur un nombre réduit d'ordinateurs physiques a de nombreux avantages. Cependant, la planification de vos systèmes pour qu'ils soient hautement disponibles est extrêmement importante. Voici un guide pour utiliser le clustering de basculement Windows Server 2008 pour que vos ordinateurs virtuels Hyper-V atteignent une haute disponibilité. Steven Ekren
Virtualisation: Sauvegarde et récupération après incident pour la virtualisation des serveurs
La virtualisation apporte des changements considérables à la récupération après incident. Voici une introduction à la façon dont la plate-forme de virtualisation s'intègre à votre plan de récupération après incident, ainsi qu'un examen plus détaillé des options et considérations de sauvegarde et restauration pour Windows Server 2008 Hyper-V. Adam Fazio
Virtualisation: Outils essentiels pour la planification de votre infrastructure virtuelle
Votre infrastructure est-elle prête pour la virtualisation ? Microsoft Assessment and Planning Toolkit, outil d'évaluation d'infrastructure à l'échelle du réseau, peut vous aider à mieux comprendre votre infrastructure informatique et à déterminer si vos systèmes sont prêts pour la mise à niveau ou la migration vers une variété de technologies, y compris la virtualisation. Jay Sauls et Baldwin Ng
Columns
Le mot du rédacteur en chef: Un monde virtualisé: | Lettres: Les lecteurs ont la parole: | Boîte à outils: Nouveaux produits pour les professionnels de l’informatique:
Forum aux questions SQL: Journaux de transactions de taille importante, conditions d'utilisation de Repair et bien plus encore: Dans cet article, Paul Randal répond aux questions de sauvegarde et de restauration, examine les différences entre envoi de journaux et mise en miroir de base de données et explique pourquoi la fonction Repair devrait seulement être utilisée en dernier recours.Paul S. Randal | Coup de projecteur sur les utilitaires: Offline Virtual Machine Servicing Tool: Les ordinateurs virtuels stockés hors connexion ne reçoivent pas automatiquement les mises à jour nécessaires pour garantir leur sécurité et leur conformité. Cela peut poser un risque pour l'ensemble de votre environnement informatique. Découvrez comment Offline Virtual Machine Servicing Tool vous permet d'automatiser le processus de mise à jour des ordinateurs virtuels.Peter Skjøtt Larsen et Suveen Kumar Reddy Vuppala | Windows PowerShell: La puissance des profils: Avez-vous déjà souhaité que Windows PowerShell se lance avec un environnement de travail adapté à vos besoins ? Don Jones vous démontre comment vous pouvez utiliser des profils pour personnaliser le shell de Windows PowerShell.Don Jones
Hé, vous le scripteur !: Derniers mots célèbres: Les scripteurs entament une discussion sur Socrate et reviennent sur l'interrogation d'un fichier XML. Cette fois-ci, cependant, le fichier XML est structuré de sorte qu'au lieu de nœuds enfants, des valeurs de propriété supplémentaires sont configurées comme attributs.Les scripteurs Microsoft | Histoires de Bureau: Personnalisation des Services de déploiement Windows: Wes Miller examine les Services de déploiement Windows, et vous montre comment personnaliser et configurer WDS pour répondre aux besoins de votre organisation.Wes Miller | Vigilance sécurité: Les 10 lois immuables de la sécurité revisitées, 1ère partie: Cela fait environ 8 ans que « Les 10 lois immuables de la sécurité » ont été publiées, et de nombreuses choses ont changé depuis lors. Ce mois-ci, Jesper Johansson inaugure une série en trois parties dans laquelle il analyse les lois à la lumière de la situation actuelle pour voir si elles restent valables.Jesper M. Johansson
Sur le terrain: Code barres couleur haute capacité: Gavin Jancke a développé un nouveau code barres, utilisant des couleurs et des triangles, qui a une capacité de données beaucoup plus élevée que les codes barres noirs et blancs traditionnels. Examinez ces codes barres de couleurs haute capacité.Gavin Jancke | La vie secrète de Windows: Travaillez plus dur, pas plus intelligemment: Raymond Chen examine la relation entre les bogues et les erreurs, et explique pourquoi il est important qu'un programmeur souffre avant de produire des résultats.Raymond Chen


Virtualisation
Introduction de Hyper-V dans Windows Server 2008
Rajiv Arunkundram
En un coup d'œil :
  • Définition de la virtualisation
  • Trois architectures de virtualisation
  • Hyperviseur micro-kernelisé vs hyperviseur monolithique
  • Utilisation de Hyper-V

Sommaire
Le marché de la virtualisation de serveurs
Fonctionnement de la virtualisation de serveurs
Types de solutions de virtualisation
Hyperviseur Windows
Partition parente
Architecture de partage de périphérique
Composants d'intégration
Ensemble de fonctionnalités Hyper-V
Évolutivité
Haute disponibilité
Sécurité
Facilité de gestion
Conclusion
La virtualisation a donné lieu à de nombreuses discussions, dont la plupart était spécifique à la virtualisation de serveurs. Il s'agit d'une des tendances les plus passionnantes du secteur. Une tendance qui, d'ici les prochaines années, pourrait modifier la manière dont les systèmes informatiques sont déployés. La virtualisation de serveurs modifiera non seulement la manière dont les administrateurs et les architectes informatiques envisagent l'utilisation des serveurs et du système mais elle concernera également les processus et les outils utilisés pour gérer ce que deviendra certainement un environnement de plus en plus dynamique.
La virtualisation existe depuis un certain temps, mais la technologie est en constante évolution. En fait, le mot lui-même, en fonction des personnes, prend une signification différente. Cependant, au sens le plus large, la virtualisation consiste à faire abstraction d'une couche de la pile de technologie de la couche suivante, telle que le stockage des serveurs ou le système d'exploitation des applications. Faire abstraction des différentes couches permet ainsi d'activer la consolidation et améliorer la facilité de gestion.
En tant que concept, la virtualisation s'applique au stockage, aux réseaux, aux serveurs, aux applications et à l'accès. Lorsque vous regardez le stockage et les réseaux, l'objectif de virtualisation est d'agréger une série de périphériques différents si le pool total des ressources fonctionne et agit comme une entité unique. Par exemple, vous pouvez configurer une solution de stockage de 40 To au lieu d'un ensemble de 20 périphériques de stockage de 2 To chacun. Mais avec les autres composants, la virtualisation agit en sens inverse. Elle vous aide à transformer un système unique pour qu'il apparaisse comme s'il existait plusieurs systèmes. L'exemple le plus commun est la virtualisation de serveurs, où vous hébergez plusieurs environnements et instances du système d'exploitation sur un serveur unique.
Microsoft a approché la virtualisation à différents niveaux, s'étendant du bureau au centre de données avec des solutions pour la virtualisation de serveurs, la virtualisation d'applications, la virtualisation de présentation et la virtualisation de bureau. Le thread commun à tous ces niveaux est la gestion avec Microsoft System Center. Pour cet article, je me concentre sur le composant de virtualisation de serveurs et surtout, sur la manière dont Hyper-V, une fonctionnalité clé de Windows Server 2008, s'intègre à un centre de données dynamique.

Le marché de la virtualisation de serveurs
Tout d'abord, je pense qu'il serait utile de regarder ce qui existe dans l'environnement d'aujourd'hui et dans quelle direction va le marché. En fonction de ce que vous lisez, certains analystes estiment que 5 à 9 % de tous les serveurs physiques actuellement vendus sont utilisés en tant qu'hôtes de virtualisation. Vous pourriez considérer qu'il s'agit d'une grande partie des systèmes dans un marché où plus de neuf millions de serveurs physiques sortent chaque année. Mais une chose est sûre : Les opportunités sur le marché sont incroyables à mesure que les clients sont de plus en plus nombreux à se familiariser avec la virtualisation et à souhaiter l'utiliser.
Il est important de noter où la virtualisation est adoptée. Les clients d'entreprise ont certainement été les premiers en matière de testeurs et de premiers convertis. Cependant, les petites et moyennes entreprises déploient également la virtualisation. L'adoption de la virtualisation touche les différents types de charges de travail, des applications et de la gestion professionnelles au Web et aux messages électroniques.
Mais alors, pourquoi autant de bruit autour de la virtualisation ? Il existe quelques facteurs et notamment, le calendrier. Quelques facteurs clés du secteur ont été simultanés, aidant à pousser l'adoption de la virtualisation. Ces facteurs incluent le passage à l'informatique 64 bits, aux processeurs multicœurs et même au lecteur d'informatique durable pour améliorer l'utilisation du système.
Les systèmes deviennent de plus en plus importants et ils nécessitent une technologie telle que la virtualisation pour tirer pleinement partie de la puissance du système. Mais bien que cette technologie fondamentale (et la loi de Moore) ait été constamment en tête en termes de production de capacités de traitement supplémentaires utilisables par les systèmes, nous sommes désormais également conscients de l'impact environnemental, des exigences de puissance et des coûts de refroidissement.
Tous ces facteurs, en plus de la justification facile du retour sur investissement lors de l'adoption de la virtualisation, devraient accélérer l'adoption de la virtualisation dans les petites et grandes entreprises. Et nous, professionnels informatiques, pouvons nous attendre à ce que les principaux acteurs continuent à investir dans cette technologie dans les prochaines années et à améliorer les fonctions et fonctionnalités.

Fonctionnement de la virtualisation de serveurs
En terme général, la virtualisation de serveurs vous permet de prendre un périphérique physique unique et d'installer (et d'exécuter simultanément) deux environnements de systèmes d'exploitation ou plus qui sont potentiellement différents et ont des identités, des piles d'applications différentes, et ainsi de suite. Hyper-V est une technologie de virtualisation basée sur l'hyperviseur 64 bits de nouvelle génération qui propose des capacités de plate-forme fiables et évolutives. Avec System Center, cette technologie propose un ensemble unique d'outils de gestion intégrés pour les ressources physiques et virtuelles.
Tout ceci travaille à réduire les coûts, améliorer l'utilisation, optimiser l'infrastructure et autoriser l'entreprise à configurer de nouveaux serveurs rapidement. Pour vous aider à mieux comprendre l'architecture Hyper-V, je vais d'abord jeter un coup d'œil aux différents types de solutions de virtualisation.

Types de solutions de virtualisation
Il y a essentiellement trois architectures générales utilisées pour la virtualisation de serveurs, comme illustré à la figure 1. Les différences fondamentales résident dans la relation entre la couche de virtualisation et le matériel physique. Par couche de virtualisation, j'entends la couche logicielle appelée le Moniteur d'ordinateur virtuel (à ne pas confondre avec Virtual Machine Manager). C'est cette couche qui fournit la capacité de créer plusieurs instances isolées qui partagent les mêmes ressources matérielles sous-jacentes.
Figure 1 Les trois architectures de virtualisation (cliquez sur l'image pour l'agrandir)
L'architecture de moniteur d'ordinateur virtuel de type 2 est illustrée par les ordinateurs virtuels Java. Ici, l'objectif de la virtualisation consiste à créer un environnement d'exécution au sein duquel le processus peut exécuter un ensemble d'instructions sans compter sur le système hôte. Dans ce cas, l'isolation est pour différents processus et elle autorise une application unique à s'exécuter sur différents systèmes d'exploitation sans devoir s'inquiéter des dépendances des systèmes d'exploitation. La virtualisation de serveurs n'appartient pas à cette catégorie.
Le moniteur d'ordinateur virtuel de type 1 et les moniteurs d'ordinateur virtuel hybrides sont les deux approches les plus utilisées à l'heure actuelle. Le moniteur d'ordinateur virtuel hybride représente une étape où le moniteur d'ordinateur virtuel s'exécute à côté du système d'exploitation hôte et permet de créer des ordinateurs virtuels. Exemples de moniteur d'ordinateur virtuel hybride : Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation et VMware Player. Notez que bien que ces types de solutions soient excellents pour un scénario client où vous n'exécutez que des ordinateurs virtuels de temps en temps, les moniteurs d'ordinateurs virtuels ajoutent des frais considérables et ne sont donc pas adaptés aux charges de travail intensives en ressources.
Dans une architecture de moniteur d'ordinateur virtuel de type 1, la couche de moniteur d'ordinateur virtuel s'exécute directement sur le matériel. Ceci est souvent appelé la couche d'hyperviseur. Cette architecture a été conçue au début des années 60 par IBM pour les systèmes de macroordinateur et a été récemment mise à disposition sur les plates-formes x86/x64 avec une gamme de solutions, y compris Windows Server 2008 Hyper-V.
Il existe des solutions disponibles sur lesquelles l'hyperviseur est une partie intégrée au micrologiciel. Cependant, il s'agit simplement d'une option de package et elle ne modifie pas réellement la technologie sous-jacente.
Si vous regardez les moniteurs d'ordinateurs virtuels de type 1, vous verrez qu'il y a deux façons principales d'organiser les solutions d'hyperviseur : micro-kernelisé vs monolithique. Ces deux approches, comme illustré à la figure 2, sont les véritables moniteurs d'ordinateurs virtuels de type 1. Ils ont l'hyperviseur directement installé sur le matériel physique.
Figure 2 Les deux façons d'organiser les solutions d'hyperviseur (cliquez sur l'image pour l'agrandir)
L'approche d'hyperviseur monolithique héberge l'hyperviseur/le moniteur d'ordinateur virtuel dans une couche unique qui comprend la plupart des composants requis, comme le noyau, les pilotes de périphérique et la pile E/S. Il s'agit de l'approche utilisée par les solutions telles que VMware ESX et les systèmes de macroordinateurs traditionnels.
L'approche micro-kernelisée utilise un hyperviseur spécialisé très léger qui exécute uniquement les tâches fondamentales pour s'assurer de l'isolation de la partition et la gestion de la mémoire. Cette couche n'inclut ni la pile E/S ni les pilotes de périphérique. Il s'agit de l'approche utilisée par Hyper-V. Dans cette architecture, la pile de virtualisation et les pilotes de périphériques spécifiques au matériel sont situés dans une partition spécialisée appelé la partition parente.

Hyperviseur Windows
Pour s'assurer qu'il existe une séparation importante entre les divers systèmes d'exploitation, il suffit de créer des processeurs virtuels, une mémoire, des minuteurs et des contrôleurs d'interruptions. Les systèmes d'exploitation utilisent ces ressources virtuelles comme ils utiliseraient leurs homologues physiques.
L'hyperviseur Windows, faisant partie d'Hyper-V, exécute les tâches suivantes :
  • Il crée des partitions logiques.
  • Il gère la planification de la mémoire et du processeur pour les systèmes d'exploitation invité.
  • Il fournit des mécanismes afin de virtualiser les entrées/sorties et communiquer entre les partitions.
  • Il applique les règles d'accès à la mémoire.
  • Il applique la stratégie pour l'utilisation du processeur.
  • Il expose une interface de programmation simple connue comme l'hyperappel.
Étant donné qu'il utilise l'approche micro-kernélisée, l'hyperviseur Windows est assez petit (d'une taille inférieure à 1 Mo). Cette empreinte minimale aide à améliorer la sécurité globale du système.
Pour exécuter Hyper-V, vous devez impérativement disposer d'un système x64 avec les technologies Intel VT ou AMD-V. La technologie x64 permet d'accéder à un espace d'adresses plus important et prend en charge les systèmes avec plus de mémoire, permettant ainsi un plus grand nombre d'ordinateurs virtuels sur un système hôte unique. Intel VT et AMD-V sont des solutions de virtualisation assistées par matériel qui fournissent une couche ultra-privilégiée dans l'architecture en anneau permettant de garder l'environnement d'exécution de l'hyperviseur séparé du reste du système. Ils permettent également à Hyper-V d'exécuter un système d'exploitation invité sans aucune baisse des performances d'émulation significatives.

Partition parente
Hyper-V se compose d'une partition parente, qui est essentiellement un ordinateur virtuel avec un accès privilégié ou spécial. Il s'agit du seul ordinateur virtuel avec un accès direct aux ressources matérielles. Tous les autres ordinateurs virtuels, connus comme des partitions invitées, passent par la partition parente pour accéder à leur périphérique.
L'existence de la partition parente est assez transparente. Lorsque vous commencez à installer Hyper-V, vous devez d'abord installer Windows Server 2008 Édition x64 sur le système physique. Vous devez ensuite atteindre le gestionnaire de serveur, activer le rôle Hyper-V et redémarrer le système. Une fois le système redémarré, l'hyperviseur Windows est chargé, puis le reste de la pile est converti pour devenir la partition parente.
La partition parente dispose du clavier, de la souris, de l'affichage vidéo et des autres périphériques associés au serveur hôte. Elle n'a pas le contrôle direct sur les minuteurs ou les contrôleurs d'interruptions que l'hyperviseur utilise.
La partition parente contient un fournisseur de Windows Management Instrumentation (WMI) pour faciliter la gestion de tous les aspects de l'environnement virtualisé, ainsi qu'une pile de virtualisation qui exécute les tâches associées au matériel pour les partitions enfants. De plus, tout pilote de fabricant de matériel nécessaire pour le matériel système hôte est contenu dans la partition parente et tout pilote créé pour les éditions x64 de Windows Server 2008 fonctionneront également dans la partition parente.

Architecture de partage de périphérique
Un des composants architecturaux innovants d'Hyper-V est la nouvelle architecture de partage de périphérique qui prend en charge les périphériques émulés et synthétiques dans chaque système d'exploitation invité. L'émulation de périphérique est utile pour prendre en charge les systèmes d'exploitation plus anciens avec des pilotes de périphérique conçus pour les générations de matériel plus anciennes. Par exemple, Hyper-V comprend une émulation de la carte réseau Intel 21140, qui était appelée carte réseau DEC 21140 lorsque la plupart des systèmes d'exploitation les plus anciens étaient livrés.
Généralement, l'émulation de périphérique est lente, elle n'évolue pas facilement et ne se déploie pas bien. Mais l'émulation est toujours importante parce qu'elle vous permet d'exécuter la plupart des systèmes d'exploitation x86 sur Hyper-V. Étant donné que la virtualisation est désormais passée d'une technologie de niche pour les tests et le développement à une technologie essentielle pour les environnements de production, les utilisateurs nécessitent de meilleures performances afin d'exécuter des charges de travail plus importantes. Les périphériques émulés ne satisfont plus ces demandes croissantes.
Une autre solution consiste à utiliser les périphériques synthétiques Hyper-V. Les périphériques synthétiques sont des périphériques virtuels directement mappés aux périphériques physiques. Contrairement aux périphériques émulés, les périphériques synthétiques n'émulent pas le matériel hérité. Avec le modèle de partage de matériel Hyper-V, les systèmes d'exploitation invités pris en charge peuvent interagir directement avec les périphériques synthétiques qui peuvent ne pas avoir d'homologues physiques. Ces systèmes d'exploitation utilisent les clients de service virtuel (VSC), qui servent de pilotes de périphérique dans le système d'exploitation invité.
Au lieu d'accéder directement au matériel physique, les VSC utilise le VMBus, qui est un bus en mémoire ultra-rapide, pour accéder aux fournisseurs de service virtuel (VSP) dans la partition parente. Les VSP de partition parente gèrent alors l'accès au matériel physique sous-jacent, comme illustré à la figure 3. Un avantage principal des périphériques synthétiques réside dans le fait que les performances des périphériques synthétiques sur le VMBus sont plus proches des performances des périphériques matériels non virtualisés.
Figure 3 VSC utilise le VMBus pour accéder à VSP, qui gère alors l'accès au matériel physique sous-jacent (cliquez sur l'image pour l'agrandir)

Composants d'intégration
Hyper-V a été créé pour fournir des limites nettes entre les diverses instances s'exécutant sur un ordinateur. Pour activer l'interaction entre le système d'exploitation invité et le système d'exploitation hôte et fournir une fonctionnalité supplémentaire aux systèmes d’exploitation invités pris en charge, Hyper-V fournit des composants d'intégration.
Les composants d'intégration Hyper-V prennent en charge les fonctionnalités suivantes :
  • Synchronisation temporelle
  • Service de cliché instantané de volume
  • Fonctionnalité d'interrogation
  • Arrêt de l'invité
  • Échange de paires clé-valeur (utilisé pour accéder au registre d'un système d'exploitation invité)
  • Identification du système d'exploitation
Ensemble de fonctionnalités Hyper-V
Il va sans dire que plus la plate-forme de virtualisation agit comme le serveur physique, plus il devient facile pour les entreprises de déployer et compter sur les charges de travail virtuelles. À mon avis, il existe quatre zones clés sous lesquelles vous pouvez afficher les différentes fonctionnalités de la plate-forme de virtualisation.
Aujourd'hui, la plupart des solutions de virtualisation basées sur l'hyperviseur sont proches les unes des autres en termes de fonctions et fonctionnalités. À mesure que la technologie évolue, le coût total de possession (TCO) et la simplicité d'utilisation deviendront les facteurs de distinction clés. Et les solutions de gestion verront des investissements et un développement continus pour permettre d'atteindre un environnement informatique dynamique, dans lequel l'infrastructure est suffisamment flexible pour s'adapter aux besoins de l'entreprise. Quant aux modèles et stratégies, ils permettront d'aider l'automatisation et la gestion.

Évolutivité
À l'aide de l'architecture d'hyperviseur micronoyau, Hyper-V a une très faible surcharge du processeur, laissant assez d'espace pour virtualiser les charges de travail. En permettant aux ordinateurs virtuels de profiter de fonctionnalités et de matériel puissants, comme la technologie multicœurs, l'accès au disque amélioré et une mémoire accrue, Hyper-V améliore l'évolutivité et les performances de la plate-forme de virtualisation.
Associé au reste des possibilités de Windows Server 2008, Hyper-V permet de consolider la plupart des charges de travail (y compris les charges de travail 32 bits et 64 bits) sur un système unique. Et il peut aider à équilibrer l'adoption de la technologie 64 bits avec une prise en charge continue pour les charges de travail 32 bits déjà utilisé dans votre environnement.
Le fait que Hyper-V nécessite un système hôte 64 bits avec la virtualisation assistée par matériel permet d'assurer que le système hôte aura accès à un grand pool de ressources mémoire. Hyper-V peut prendre en charge jusqu'à 1 To de mémoire sur l'hôte, avec jusqu'à 64 Go de mémoire par ordinateur virtuel. Ceci est primordial pour ceux qui souhaitent virtualiser des charges de travail gourmandes en mémoire, telles qu’Exchange Server et SQL Server.
Hyper-V prend en charge également jusqu'à 16 processeurs logiques sur le système hôte, rendant Hyper-V évolutif à la plupart des systèmes deux ou quatre prises avec plusieurs noyaux. Vous pouvez également créer un ordinateur virtuel avec jusqu'à quatre processeurs virtuels pour prendre en charge les charges de travail qui nécessitent ou profitent de capacités multiprocesseur.
Le fait de consolider les serveurs via Hyper-V permet également d'activer ces serveurs pour utiliser la prise en charge de mise en réseau robuste, y compris les stratégies VLAN, Traduction d'adresses réseau (NAT) et Protection d’accès réseau et Protection de l'accès réseau (NAP) (quarantaine). Et en tant que fonctionnalité Windows Server 2008, Hyper-V fonctionne bien avec les autres fonctionnalités Windows Server, telles que BitLocker et Windows PowerShell.

Haute disponibilité
La haute disponibilité est un scénario dans lequel Hyper-V et les possibilités de clustering hôte fonctionnent ensemble pour aider la continuité de l'activité d'adresse et les besoins de récupération après incident. La continuité de l'activité est la capacité de réduire les périodes d'indisponibilité prévues et non prévues. Ces périodes incluent le temps perdu en travaux de routine, tels que la maintenance et la sauvegarde, de même que les interruptions de courant imprévues.
La récupération après incident est un élément important de la continuité de l'activité. Les catastrophes naturelles, les attaques malveillantes et les problèmes de configuration, même simples, tels que les conflits de logiciel, peuvent paralyser des services et des applications jusqu'à ce que les administrateurs résolvent les problèmes et restaurent les données. Une entreprise fiable et une stratégie de récupération après incident permettre une perte de données minimale et des fonctionnalités de gestion distantes puissantes.
Lorsque vous observez la haute disponibilité, vous devez considérer trois catégories différentes : les périodes d'indisponibilité prévues, les périodes d'indisponibilité non prévues et les sauvegardes. La protection des périodes d'indisponibilité prévues est généralement nécessaire pour aider à déplacer les ordinateurs virtuels du système hôte pour que vous puissiez exécuter la maintenance matérielle ou appliquer des correctifs au système hôte ou à la plate-forme de virtualisation (pouvant nécessiter un éventuel redémarrage).
La plupart des organisations planifient les périodes de maintenance. Ce que vous souhaitez vraiment faire ici, c'est minimiser ou éliminer la période dans laquelle les ordinateurs virtuels ne seront pas disponibles tandis que le système hôte est arrêté pour maintenance. Avec la fonctionnalité de migration rapide, vous pouvez migrer rapidement un ordinateur virtuel en cours d'exécution d'un nœud physique vers un autre en quelques secondes. Ainsi, vous pouvez conserver vos ordinateurs virtuels disponibles pour la production tout en effectuant la maintenance sur l'hôte d'origine. Une fois la maintenance effectuée, vous pouvez utiliser la migration rapide pour faire revenir les ordinateurs virtuels au système hôte d'origine.
Les périodes d'indisponibilité non prévues correspondent aux périodes d'indisponibilité imprévues. En réalité, ceci peut être catastrophique. Mais ceci peut être dû au fait qu'une personne a tout simplement débranché accidentellement un cordon d'alimentation et forcé l'interruption d'un serveur. Bien que cette probabilité soit infime, au cours des années j'ai rencontré plusieurs administrateurs lors de conférences (dont Tech•Ed, VMworld pour n'en citer que quelques-unes) qui avaient des histoires relatives à des serveurs accidentellement éteints par un collègue.
Avec Hyper-V, vous pouvez configurer un cluster hôte pour les différents systèmes hôte et configurer tous les ordinateurs virtuels en tant que ressources de cluster pouvant effectuer alors le basculement sur un système différent au cas où un des hôtes échoue. Pendant ce temps, la fonctionnalité de clustering multi-site Windows Server 2008 permet de configurer un cluster géographiquement dispersé. Ainsi, si votre principal centre de données échoue, vous pouvez récupérer les différents ordinateurs virtuels vers un centre de données distant.
Ceci est également pratique pour protéger toutes vos succursales. Un des avantages de la prise en charge des périodes d'indisponibilité non prévues avec Hyper-V réside dans le fait qu'elle est agnostique au système d'exploitation invité, ce qui signifie qu'elle peut étendre ses avantages haute disponibilité aux ordinateurs virtuels Linux et aux versions antérieures de Windows Server pour protéger et récupérer ces systèmes.
À mesure que vous observez les périodes d'indisponibilité non prévues, il est important de noter que la récupération est équivalente à la mise hors tension du système et au redémarrage, ce qui signifie que vous aurez perdu toutes les informations d'état. Ceci peut devenir, ou non, un problème en fonction de la charge de travail que vous exécutez sur l'ordinateur virtuel. C'est pourquoi il est important d'observer la sauvegarde dans le contexte de haute disponibilité.
Hyper-V permet d'effectuer des sauvegardes de chaque ordinateur virtuel ou d'utiliser chaque VSS pour effectuer des sauvegardes cohérentes de tous les ordinateurs virtuels VSS lors de leur exécution. Avec VSS, vous pouvez configurer des sauvegardes pour qu'elles surviennent aux intervalles choisis sans avoir un impact sur la disponibilité de charge de travail de production tout en vous assurant que vous disposez d'une planification de sauvegarde en continu pouvant aider à récupérer aisément l'état en cas de périodes d'indisponibilité non prévues. Pour plus d'informations sur les solutions de haute disponibilité avec Hyper-V, voir l'article « Haute disponibilité pour Hyper-V » par Steven Ekren dans ce numéro de TechNet Magazine (technet.microsoft.com/magazine/cc837977).

L'architecture d'hyperviseur micro-kernélisée est conçue pour réduire la surface d'attaque et améliorer la sécurité, surtout lorsque Hyper-V est implémenté en tant que rôle Server Core. Server Core est une option d'installation de Windows Server 2008. L'hyperviseur ne contient pas de code tiers ou de pilotes de périphérique, promouvant une base plus stable, légère et sûre pour les ordinateurs virtuels en cours d'exécution. Hyper-V fournit aussi une sécurité puissante basée sur les rôles avec l'intégration d'Active Directory. Et Hyper-V permet aux ordinateurs virtuels de profiter des fonctionnalités de sécurité au niveau matériel, tels que execute disable (NX) bit, permettant d'augmenter encore un peu plus la sécurité des ordinateurs virtuels.
Hyper-V a traversé le cycle de développement de sécurité (SDL) comme le reste des composants Windows Server et l'analyse et la modélisation des menaces ont été effectués pour garantir que Hyper-V soit une plate-forme de virtualisation extrêmement sécurisée. À mesure que vous déployez Hyper-V, assurez-vous de suivre les méthodes recommandées pour déployer Windows Server 2008 ainsi que les méthodes recommandées pour Hyper-V. Incluez Active Directory ainsi que les solutions d'antivirus et anti-programme malveillant à votre planification. Et utilisez les possibilités d'administration déléguée pour vous assurer d'utiliser les privilèges d'accès administratifs appropriés pour les hôtes Hyper-V.

Facilité de gestion
Il est facile de passer d'un petit problème d'extension de serveur à une extension d'ordinateurs virtuels massive. Il existe un risque en raison de la facilité du déploiement sur les ordinateurs virtuels. Et avec la mobilité accrue des ordinateurs virtuels, vous avez également la responsabilité supplémentaire de savoir où s'exécutent les différents ordinateurs virtuels, de suivre leurs contextes de sécurité, et ainsi de suite.
Heureusement avec Hyper-V, vous ne devez pas créer une infrastructure de gestion séparée pour votre environnement virtuel. Elle s'intègre aux outils de gestion Microsoft, à System Center Virtual Machine Manager et à Microsoft System Center Operations Manager, ainsi qu'aux outils de gestion de parties tierces. Ceci vous permet de gérer vos ressources physiques et virtuelles à partir d'une seule console. Pour plus de détails sur System Center Virtual Machine Manager 2008, voir l'article d'Edwin Yuen, « Gérez vos environnements virtuels avec VMM 2008 » dans ce numéro de TechNet Magazine (technet.microsoft.com/magazine/cc836456). Pendant ce temps, la prise en charge de Windows PowerShell facilite l'automation des tâches.
Hyper-V fournit également des ordinateurs virtuels avec une capacité sans précédent pour utiliser le matériel disponible. Étant donné que tous les pilotes certifiés WHQL (Windows Hardware Quality Lab) peuvent s'exécuter dans la partition parente, Hyper-V fournit une compatibilité accrue pour les pilotes et périphériques, facilitant la gestion des différents pilotes qui s'exécutent dans votre environnement.

Conclusion
Comme je l'ai mentionné précédemment, la gestion va devenir un domaine clé de développement et de différenciation. Vous verrez certainement une activité accrue dans ce domaine dans les années à venir. En général, cette période va réellement devenir passionnante à mesure que la virtualisation va devenir standard. Si vous n'avez pas encore essayé Hyper-V ou si vous souhaitez des informations supplémentaires, visitez microsoft.com/Hyper-V.
Rajiv Arunkundram est responsable de produit senior chez Microsoft et se concentre sur la virtualisation de serveurs dans la division Marketing de Windows Server. La principale responsabilité de Rajiv consiste à travailler avec les clients et les partenaires pour les aider à comprendre la stratégie de virtualisation et les solutions de Microsoft d'un point de vue technique et commercial.


Virtualisation
gérez vos environnements virtuels avec VMM 2008
Edwin Yuen

Cet article est basé sur une version préliminaire de Virtual Machine Manager 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.
En un coup d'œil :
  • Prise en charge des ordinateurs virtuels VMware
  • Scripts et automation basés sur Windows PowerShell
  • Gestion centralisée et consolidée
  • Procédures d'installation

Sommaire
Présentation de Virtual Machine Manager 2008
Intégration avec System Center
Installation de Virtual Machine Manager 2008
Ajout d'hôtes VMware ESX
Migration de VMotion
Conclusion
L'an dernier, Microsoft a lancé System Center Virtual Machine Manager 2007, qui fournit une interface consolidée pour la gestion d'une infrastructure virtuelle exécutant Microsoft Virtual Server 2005. Aujourd'hui, une nouvelle version de Virtual Machine Manager (VMM) vient de sortir pour coïncider avec la publication du nouvel hyperviseur Windows Server 2008 Hyper-V. System Center Virtual Machine Manager 2008 gère non seulement les installations Microsoft Virtual Server 2005 et Windows Server 2008 Hyper-V, mais sa prise en charge a également été étendue aux serveurs VMware Infrastructure 3 (ESX/ESXi). Avec VMM, vous disposez désormais d'une interface de gestion intégrée qui fonctionne avec l'ensemble de votre infrastructure virtuelle, y compris les systèmes Microsoft et VMware.
VMM prend en charge toutes les tâches de virtualisation traditionnelles, telles que les déploiements d'ordinateurs virtuels rapides à partir de modèles et d'ordinateurs virtuels préconfigurés, les conversions physique vers virtuel (P2V), une bibliothèque centralisée d'objets d'infrastructure virtuels et même la conversion virtuel vers virtuel (V2V) d'ordinateurs virtuels VMware (fichiers de configuration VMX plus disques virtuels VMDK) en ordinateurs virtuels Hyper-V. De plus, l'intégration de VMM au reste de la famille System Center simplifie la gestion des systèmes physiques et virtuels.
Dans cet article, j'examinerai VMM 2008 et les nouvelles fonctionnalités qu'il propose aux administrateurs informatiques. Je m'intéresserai ensuite aux exigences et étapes de l'installation de VMM. Enfin, je regarderai de plus près comment utiliser certaines des nouvelles fonctionnalités de VMM 2008.

Présentation de Virtual Machine Manager 2008
System Center Virtual Machine Manager 2008 est une application autonome qui permet la gestion centralisée à l'échelle de l'entreprise des ordinateurs virtuels fonctionnant sous Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 et serveurs VMware Infrastructure 3 (ESX/ESXi). Avec d'autres produits System Center, VMM assure une gestion de bout en bout de l'infrastructure physique et virtuelle. La figure 1 illustre la disposition architecturale de Virtual Machine Manager.
Figure 1 Architecture de System Center Virtual Machine Manager 2008 (cliquez sur l'image pour l'agrandir)
Comme les personnes familières de VMM 2007 le remarqueront, VMM 2008 compte considérablement plus d'interfaces vers le système VMM (voir la figure 1). Les cadres dans le coin supérieur gauche représentent VMM 2008 ; les cadres dans le coin supérieur droit représentent System Center Operations Manager 2007 et les systèmes et interfaces gérés sont montrés dessous. Les cadres rouges indiquent les serveurs de gestion, les cadres bleus montrent les entrées de système et les cadres verts représentent les systèmes hôtes gérés avec leurs objets gérés indiqués en jaune.
Le cadre rouge dans le coin supérieur gauche représente le service de serveur Virtual Machine Manager 2008. Au-dessus se trouvent les différentes interfaces avec le service ; la console Administrateur, l'interface Windows PowerShell et le portail Web libre-service avec accès utilisateur délégué. Windows Powershell constitue la base pour tout accès au serveur VMM. La console Administrateur de VMM est entièrement basée sur Windows PowerShell, si bien que vous pouvez simplement créer des scripts Windows PowerShell, qui seront exécutés par le service serveur VMM. Ainsi, l'API publique pour VMM 2008 est Windows PowerShell et tout programme peut exploiter VMM en utilisant Windows PowerShell. L'intégration du contrôleur de mise à disposition de postes de travail XenDesktop de Citrix à Virtual Machine Manager, qui s'effectue entièrement via Windows PowerShell, en est un parfait exemple.
VMM est pris en charge par une base de données SQL Server 2005 ou SQL Server 2008, en version complète ou en version SQL Server Express Edition si aucune autre base de données n'est disponible. Bien que le diagramme montre Operations Manager et Virtual Machine Manager pointant vers SQL Server, les deux programmes ne partagent pas de base de données. Ils fonctionnent simplement tous les deux sur la même version de SQL Server. La véritable intégration entre Virtual Machine Manager et Operations Manager s'effectue via un connecteur disponible via VMM. Ce connecteur permet à VMM et à Operations Manager de partager des données, ce qui amène les informations de virtualisation dans Operations Manager et les données d'Operations Manager vers VMM pour traitement.
La moitié inférieure du diagramme représente les hôtes gérés. VMM 2008 gère toujours les hôtes d'ordinateurs virtuels Virtual Server 2005 R2 SP1 ainsi qu'un partage de bibliothèque centralisée, comme dans VMM 2007. Il convient de noter que dans VMM, le partage de bibliothèque n'est pas un serveur ou magasin de fichiers spécial. Il s'agit simplement d'un partage de fichiers Windows géré par VMM. Vous pouvez gérer la bibliothèque via VMM ou vous pouvez copier et supprimer facilement les fichiers depuis le partage de fichiers et laisser VMM découvrir les modifications. Vous pouvez également avoir plusieurs bibliothèques, ce qui est utile pour les jeux de serveurs délégués et pour les serveurs situés dans des bureaux distants.
VMM 2008 a désormais la possibilité de gérer les hyperviseurs Hyper-V et ESX. La gestion des hôtes Hyper-V s'effectue via Windows Remote Management (WinRM) et l'interface Windows Management Instrumentation (WMI). En fait, lorsqu'un hôte Hyper-V potentiel est ajouté, si le rôle Hyper-V n'est pas activé dans Windows Server 2008, VMM peut activer automatiquement ce rôle pour l'administrateur. Cette fonctionnalité est également disponible pour les hôtes Virtual Server pour les systèmes Windows Server 2003.
La gestion des hôtes VMware VI3 ESX s'effectue en fait par un serveur VMware VirtualCenter. VMM 2008 interface avec VirtualCenter via l'API de services Web de VirtualCenter. Ainsi, un serveur VirtualCenter est requis pour la gestion de VMware, et la plupart des installations d'entreprise de VMware ont au moins un serveur VirtualCenter. Ce qui fait la spécificité de VMM 2008, c'est sa capacité à gérer plusieurs serveurs VirtualCenter. VMM peut ajouter plusieurs serveurs VirtualCenter, permettant ainsi à un administrateur de regrouper l'infrastructure VMware toute entière et de disposer d'une vue d'entreprise unique, ce qui n'était pas possible auparavant.
En tant que membre de la famille de produits System Center, VMM utilise l'interface de style System Center ou Outlook dans la console Administrateur. La console Administrateur de VMM n'est pas un composant logiciel enfichable MMC ; il s'agit d'une toute nouvelle application créée à l'aide de Microsoft .NET Framework, par dessus Windows PowerShell 1.0. En fait, comme mentionné précédemment, toute action dans la console Administrateur appelle la commande Windows PowerShell associée, donc l'interface utilisateur utilise en réalité Windows PowerShell. Toute commande ou fonction exécutée dans la console Administrateur peut être effectuée via la ligne de commande dans Windows PowerShell.
Chaque Assistant de la console Administrateur possède un bouton Afficher le script qui affiche le script Windows PowerShell associé à la commande en instance d'exécution, ce qui offre un excellent point de départ pour apprendre à utiliser Windows PowerShell, puisqu'il est lié à VMM. Nouvelle fonctionnalité de VMM 2008, l'action Afficher le script ouvre ces scripts dans le Bloc-notes, et vous pouvez les modifier facilement directement depuis VMM. Vous pouvez également facilement enregistrer les scripts modifiés, que vous pouvez ensuite réutiliser depuis la bibliothèque VMM, une autre nouvelle fonctionnalité de VMM 2008. Les applets de commande de VMM 2007 ont été mises à jour pour VMM 2008, y compris la prise en charge pour les serveurs VMware. Les mêmes applets de commande fonctionnent sur les plates-formes de virtualisation, de sorte que les applets de commande telles que New-VM fonctionnent sur les systèmes Microsoft et VMware. Les administrateurs informatiques peuvent ainsi utiliser un jeu d'applets de commande pour gérer les hôtes Virtual Server, Hyper-V et VMware ESX.
Virtual Machine Manager 2008 a été conçu pour offrir trois principaux avantages aux administrateurs informatiques :
  • Maximisation des ressources
  • Augmentation de la souplesse
  • Exploitation des compétences existantes
Plusieurs fonctions et fonctionnalités favorisent ces avantages. Tout d'abord, VMM contribue à maximiser vos ressources en intégrant la gestion de votre infrastructure virtuelle entière, quel que soit l'hyperviseur. En intégrant les systèmes Microsoft et VMware, VMM 2008 présente une vue unique de tous les hôtes et ordinateurs virtuels, comme illustré à la figure 2, et permet aux administrateurs de filtrer et d'afficher leurs systèmes par paramètres, tels que hôte, système d'exploitation, propriétaire, date d'ajout et ainsi de suite.
Figure 2 La console VMM affiche la gestion intégrée Microsoft et VMware (cliquez sur l'image pour l'agrandir)
VMM permet également de maximiser les ressources système par une consolidation facile des serveurs avec des conversions telles que P2V et V2V. P2V vous permet de consolider vos ordinateurs physiques existants en ordinateurs virtuels sans devoir réinstaller ces ordinateurs. C'est particulièrement utile pour convertir des ordinateurs dont le matériel est peu sollicité ; vous pouvez ainsi maximiser les ressources en plaçant plusieurs ordinateurs à faible utilisation du matériel sur un seul et même matériel physique. P2V est une fonctionnalité intégrée de VMM et ne nécessite pas de logiciel ni de serveur supplémentaire. Pour VMM 2008, la prise en charge d'un plus grand nombre de systèmes physiques a été ajoutée, notamment des hôtes Windows Vista, Windows Server 2008 et x64. La fonctionnalité P2V de VMM est un excellent compagnon des outils de planification tels que l'outil Microsoft Assessment Planning (MAP) (auquel Baldwin Ng et Jay Sauls consacrent un article dans ce numéro de TechNet Magazine), qui aide à identifier les candidats à la consolidation des serveurs.
Si vous possédez déjà des ordinateurs virtuels au format VMDK de VMware, VMM vous permet d'utiliser V2V pour convertir vos VMDK existants au format VHD. Il s'agit d'un processus hors connexion : l'ordinateur virtuel VMware doit est arrêté pendant que le processus V2V convertit le véritable fichier VMDK en un VHD. Vous pouvez également convertir un ordinateur virtuel VMware en cours d'exécution en utilisant la fonction P2V. Ce peut être un peu déroutant, mais il est important de se rappeler que les ordinateurs virtuels sont tout d'abord des ordinateurs, avant d'être virtuels. Comme tous les autres systèmes voient les ordinateurs virtuels comme des ordinateurs en cours d'exécution, il en sera de même pour la fonctionnalité P2V de VMM, qui vous permet de convertir un ordinateur virtuel en cours d'exécution sur tout logiciel de virtualisation en un Microsoft VHD.
VMM offre aux administrateurs informatiques une plus grande souplesse grâce à plusieurs fonctionnalités. L'une des fonctionnalités clés de VMM réside dans la migration des ordinateurs virtuels d'un hôte à l'autre, ce qui peut aider à maintenir une disponibilité élevée et à optimiser le serveur. Avec les hôtes Hyper-V, VMM 2008 prend en charge la migration rapide, qui peut déplacer un ordinateur virtuel entre des hôtes Hyper-V en n'entraînant que quelques secondes d'indisponibilité. Cela nécessite un cluster Windows Server 2008 et un stockage partagé, mais VMM contribue à faciliter la gestion et la configuration.
Avec un hôte ESX VMware, VMM 2008 prend également en charge VMware VMotion, la fonctionnalité de VMware qui déplace les ordinateurs virtuels sans aucune indisponibilité perceptible par l'utilisateur. Des hôtes VMware ESX compatibles avec VMotion sont nécessaires, de même qu'un cluster et un back-end SAN tel que Migration rapide. Dans la suite de cet article, j'explorerai un VMotion utilisant VMM 2008.
Enfin, VMM 2008 peut migrer un ordinateur virtuel Virtual Server 2005 existant sur un hôte Hyper-V en effectuant automatiquement toutes les mises à niveau et conversions nécessaires à la migration.
Dans le cadre d'un déploiement d'ordinateur virtuel (y compris les migrations décrites ci-dessus) démarré par des conversions ou de nouveaux déploiements, VMM utilise un processus nommé Intelligent Placement pour déployer les ordinateurs virtuels sur les hôtes. Il utilise également Intelligent Placement pour interroger tous les hôtes d'ordinateurs virtuels qu'il gère, récupère plusieurs paramètres sur la disponibilité des ressources de ces hôtes puis renvoie une liste pondérée d'hôtes recommandés sur lesquels vous pouvez déployer l'ordinateur virtuel. Comme vous pouvez le voir à la figure 3, Intelligent Placement prend en charge les hôtes Microsoft et VMware, avec leurs configurations de stockage. Intelligent Placement dans VMM 2008 est conscient à la fois de la plate-forme et de la configuration. Ainsi, il ne recommande que les hôtes qui correspondent à plate-forme hôte correcte ; uniquement les hôtes qui sont en cluster si une disponibilité élevée est nécessaire, et uniquement les hôtes compatibles x64 pour les ordinateurs virtuels x64.
Figure 3 Intelligent Placement analyse tous les hôtes disponibles (cliquez sur l'image pour l'agrandir)

Intégration avec System Center
L'une des fonctionnalités clés de VMM 2008 réside dans l'intégration avec System Center Operations Manager 2007. Si VMM 2007 avait une intégration limitée avec Operations Manager, VMM 2008 comprend un connecteur de produit pour Operations Manager qui augmente considérablement la fonctionnalité de l'intégration. Via son intégration avec Operations Manager, VMM fournit des rapports Operations Manager consolidés depuis la console Administrateur, ainsi que grâce à une nouvelle fonctionnalité appelée Performance and Resource Optimization (PRO).
PRO permet à VMM 2008 de créer des alertes appelées Conseils PRO et même d'exécuter des remèdes automatisés en fonction des paramètres de contrôle d'Operations Manager. La figure 4 illustre des exemples de Conseils PRO. En utilisant un pack d'administration compatible avec PRO (pack PRO), VMM 2008 peut exécuter des actions automatisées telles que des migrations d'ordinateur virtuel et la création de nouveaux ordinateurs virtuels sur la base des paramètres de performance de l'hôte, de l'hyperviseur, du matériel et même de la charge de travail.
Figure 4 Les Conseils PRO fournissent des alertes et des solutions pour les problèmes dans l'infrastructure virtuelle (cliquez sur l'image pour l'agrandir)

Installation de Virtual Machine Manager 2008
Pour installer System Center VMM 2008, plusieurs conditions s'appliquent. Tout d'abord, le serveur VMM 2008 nécessite Windows Server 2008 x64. Le serveur ne s'installe pas sur Windows Server 2003 ni sur les versions x86 de Windows Server 2008. La console Administrateur et les autres composants peuvent toujours être installés sur Windows Server 2003 et Windows XP ou Windows Vista (dans le cas de la console), avec les mêmes configuration requise et procédures d'installation que VMM 2007.
Deuxièmement, VMM 2008 requiert une installation sur un domaine Active Directory pour son modèle de sécurité. VMM 2008 prend en charge la gestion des hôtes du réseau de périmètre (non joints à un domaine), notamment le P2V des systèmes extérieurs au domaine, ce qui est nouveau pour VMM 2008. L'un des avantages liés à l'utilisation de Windows Server 2008 comme plate-forme d'installation réside dans le fait que de nombreux composants requis de VMM (tels que .NET Framework 3.0, WinRM et Windows PowerShell 1.0) sont déjà intégrés. Enfin, VMM 2008 nécessite Windows Automated Installation Kit (WAIK) 3.0, bien que le programme d'installation VMM 2008 comprenne les fichiers d'installation.
Bien que je recommande que, dans un environnement de production, chaque composant VMM soit installé sur un serveur de production séparé, j'évoquerai l'installation sur serveur unique. Le matériel recommandé pour une installation de serveur VMM est un serveur à processeur x64 avec vitesse d'horloge de 2,8 GHz ou supérieure et au moins 2 Go de mémoire RAM. Puisqu'il s'agit d'une installation sur serveur unique avec base de données SQL locale, 7 Go d'espace disque sont nécessaires. Notez que si une base de données distante est utilisée, seul 1 Go est requis pour l'installation de VMM à proprement parler. 80 Go d'espace disque supplémentaires sont recommandés pour l'installation de la bibliothèque locale.
Comme mentionné précédemment, VMM fonctionne sur une installation Windows Server 2008 x64. Les logiciels suivant sont également nécessaires : .NET Framework 3.0, Windows PowerShell 1.0, WinRM et IIS 6.0 ou version ultérieure pour le portail libre-service. L'Analyseur MSXML 6.0 Microsoft est également requis, mais il est inclus à .NET Framework 3.0.
Lorsque vous démarrez l'installation de VMM, cinq options vous sont proposées : le serveur Virtual Machine Manager, la console Administrateur, le portail libre-service et l'agent local, ainsi que la possibilité de configurer le pack d'administration Operations Manager. Comme indiqué, j'installerai tous les composants sur un ordinateur unique, en commençant par le serveur VMM. Une fois l'installation démarrée, les premiers écrans vérifient la configuration requise pour le système.
Outre les exigences mentionnées précédemment, l'ordinateur doit être sur un domaine. L'installation du serveur VMM active automatiquement les fonctions intégrées. Vous n'aurez donc pas à les activer manuellement.
Après avoir lancé le programme d'installation, je recommande d'utiliser l'option Windows Update pour vous assurer que VMM 2008 est à jour. Le programme d'installation examine alors les options, principalement pour l'installation de la base de données SQL. Pour cet exemple, j'utiliserai SQL Server 2005 Express Edition.
Ensuite, l'Assistant vous demande d'identifier l'emplacement de la bibliothèque centralisée. Il peut s'agir d'un répertoire local sur le serveur VMM (et un partage sera créé pour ce répertoire) ou d'un partage de fichiers existant. L'emplacement par défaut est C:\ProgramData\Virtual Machine Manager Library Files.
Les attributions de port sont ensuite traitées. Ici, je configure le port pour la connexion de la console Administrateur au service serveur central de VMM (8100 par défaut) ; le port utilisé par WinRM pour effectuer les fonctions de gestion (80 par défaut) ; et le port utilisé par le Background Intelligent Transfer Service (BITS) pour transférer des fichiers aux hôtes d'ordinateurs virtuels (443 par défaut). Une fois toutes ces informations entrées, un écran de résumé s'affiche et l'installation du serveur peut se terminer.
Ensuite, j'installe la console Administrateur, dont la configuration requise est similaire à celles du serveur VMM. La seule option de configuration disponible autre que le répertoire d'installation est la confirmation du port de communications utilisé pour se connecter au service de serveur VMM. Ce port doit être le port 8100, comme dans la configuration de l'installation du serveur VMM.
À la fin de l'installation, vous avez la possibilité de créer un raccourci sur le Bureau pour la console Administrateur et d'ouvrir la console lorsque vous fermez le programme d'installation. Je vous recommande de sélectionner les deux. La première fois que vous ouvrez la console Administrateur, vous êtes invité à vous connecter au serveur. Avec l'installation sur serveur unique, localhost sur le port 8100 est correct et il suffit d'appuyer sur Entrée pour démarrer la console.
Enfin, j'installe le portail libre-service. Le portail libre-service nécessite les logiciels suivants : IIS 6.0 ou 7.0, .NET Framework 3.0 et Windows PowerShell 1.0. (Windows Powershell est nécessaire car le portail libre-service n'est qu'une autre interface avec les services VMM centraux qui utilisent Windows PowerShell). Pour Windows Server 2008, vous devez activer le rôle IIS avant de commencer l'installation de VMM 2008. Vérifiez également que les services de rôle IIS suivants sont activés :
  • Fonctionnalités HTTP courantes (Contenu statique, Document par défaut, Exploration de répertoire, Erreurs HTTP)
  • Développement d'applications (ASP.NET, extensibilité .NET, extensions ISAPI, filtres ISAPI)
  • Sécurité (Filtrage des requêtes)
  • Compatibilité de gestion IIS 6.0
Si ces services de rôle sont activés, l'installation réussit la vérification de la configuration requise et l'installation continue. Pendant l'installation, les options de configuration concernent uniquement les ports utilisés par le portail libre-service. Le premier, le port permettant de se connecter au service VMM central, est 8100, comme pour la console Administrateur. Le second est le port destiné à l'exécution du portail. Il s'agit par défaut du port 80, mais dans de nombreuses configurations, ce port est déjà pris et le programme d'installation de VMM vous en avertit si c'est le cas. Si nécessaire, modifiez le port en choisissant un port ouvert, comme 8080. Le programme d'installation crée ensuite un site Web appelé accueil du portail libre-service de Microsoft System Center Virtual Machine Manager 2008. La configuration peut être modifiée dans le Gestionnaire de serveur.
Une fois l'installation d'IIS terminée, vous pouvez simplement ouvrir le site Web en allant sur localhost:8080 dans Internet Explorer. Si vous êtes invité à entrer des informations d'authentification lors de l'ouverture du site Web, cela est dû aux paramètres de sécurité d'Internet Explorer. Le portail libre-service doit s'exécuter dans le contexte intranet dans Internet Explorer. Vous devrez peut-être ajouter le serveur VMM à la liste de sites intranet dans Internet Explorer. Une fois ces configurations terminées, vous serez prêt à créer et à utiliser les ordinateurs virtuels compatibles libre-service dans VMM 2008.

Ajout d'hôtes VMware ESX
Bien que VMM 2008 compte de nombreuses nouvelles fonctionnalités, la fonctionnalité la plus attendue est sans doute l'ajout de la prise en charge de la gestion des hôtes VMware ESX. Avec cette prise en charge, VMM est désormais capable de gérer l'infrastructure virtuelle de la majorité des services informatiques d'entreprise.
Le processus d'ajout d'hôtes ESX dans Virtual Machine Manager 2008 est assez simple. Comme je l'ai indiqué précédemment, VMM 2008 gère les hôtes VMware via un serveur VirtualCenter, qui doit être la version 2.0.1 ou 2.5. Pour ajouter les serveurs VMware ESX dans la console de gestion, ajoutez simplement le serveur VirtualCenter en utilisant l'action Ajouter un serveur VMware VirtualCenter située dans le coin supérieur VirtualCenter du volet Actions.
Après avoir lancé l'Assistant, entrez le nom d'ordinateur du serveur VirtualCenter avec le compte administrateur pour le serveur VirtualCenter. VMM ajoute les hôtes ESX, y compris la structure de Groupe d'hôtes existante de VirtualCenter, à l'interface VMM. Cette tâche peut prendre plusieurs minutes, mais vous pouvez en vérifier l'évolution à partir du menu Travaux VMM.
Une fois tous les serveurs importés, vous devriez voir la même structure de serveur hôte VMware ESX dans VMM que dans VirtualCenter. Pour ajouter un autre serveur VirtualCenter, répétez simplement le processus. Une fois la structure d'hôte ajoutée à VMM, vous pouvez ajouter des serveurs non VMware dans la même structure de groupe. Bien entendu, les serveurs non VMware ne sont pas affichés dans VirtualCenter.
Bien que VMM 2008 utilise VirtualCenter pour gérer les hôtes ESX, il doit pouvoir accéder directement aux hôtes ESX eux-mêmes pour certaines fonctions, telles que V2V, l'enregistrement de l'état et le clonage d'ordinateurs virtuels depuis les hôtes ESX. Ainsi, après avoir ajouté le serveur VirtualCenter dans VMM, les hôtes apparaissent comme OK (Limité). Pour activer la gestion complète, ouvrez la page Propriétés des hôtes ESX individuels dans VMM et indiquez les informations d'identification d'hôte appropriées pour gérer directement les serveurs.

Migration de VMotion
Lorsque la gestion de VMware dans Virtual Machine Manager 2008 est abordée, il est immanquablement demandé si VMM peut exécuter VMotion et d'autres fonctions de VirtualCenter. Et comme VMM utilise VirtualCenter pour la gestion de VMware, la réponse à cette question est oui !
D'un point de vue fonctionnel, VMM traite VMotion comme toute autre migration. Pour démarrer un VMotion, sélectionnez tout d'abord l'ordinateur virtuel que vous voulez déplacer, puis sélectionnez l'option Migrer l'ordinateur virtuel du volet Actions sur le côté droit de VMM. Lorsque vous avez fait cela, VMM affiche la fenêtre Intelligent Placement pour cet ordinateur virtuel et présente les hôtes de destination possibles, avec un type de transfert Live, comme illustré à la figure 5. Intelligent Placement peut vous aider à sélectionner les hôtes de destination appropriés pour vos ordinateurs virtuels. Notez qu'il s'agit du même processus que l'exécution d'une migration rapide à l'aide d'hôtes Hyper-V.
Figure 5 VMotion utilisant Intelligent Placement (cliquez sur l'image pour l'agrandir)
Sélectionnez l'hôte de destination pour l'ordinateur virtuel, dans ce cas c'est le serveur appelé cqaesxi003.contoso.com, et cliquez sur Suivant. La dernière fenêtre de résumé, illustrée à la figure 6, affiche l'action demandée.
Figure 6 Fenêtre de résumé de VMotion (cliquez sur l'image pour l'agrandir)
Comme mentionné précédemment, chaque Assistant de VMM possède un bouton Afficher le script qui peut afficher le script Windows PowerShell pour une tâche dans le Bloc-notes. Cela nous donne l'occasion de voir comment Windows PowerShell dans VMM 2008 fonctionne avec VMware. Voici le script pour cette action :
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Trois commandes simples exécutent le VMotion pour ce système. Dans mon exemple, je déplace l'ordinateur virtuel MyVM du serveur VMware cqaesxi003.contoso.com au serveur cqaesxi001.contoso.com. La première commande identifie l'ordinateur virtuel devant être migré via VMotion. Comme vous pouvez le voir, dans cette ligne de commande, j'attribue la valeur d'ordinateur virtuel à la variable $VM :
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
La deuxième commande sert à identifier le système d'hôte ESX de destination pour l'ordinateur virtuel. Dans cette ligne, j'attribue la variable $VMHost à l'hôte ESX cqaesxi003.contoso.com :
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
Enfin, j'utilise la commande Move-VM pour déplacer l'ordinateur virtuel. Voici les paramètres et la ligne de commande complète pour Move-VM :
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
Conformément à la philosophie de gestion hétérogène de Virtual Machine Manager, vous pouvez voir que la commande n'est pas spécifique à un fournisseur ou à un logiciel. Pour terminer le VMotion, entrez cette commande :
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Elle indique à VMM d'exécuter Move-VM, contre l'ordinateur virtuel dans $VM, en déplaçant vers le système d'hôte dans $VMHost, et d'exécuter la tâche de façon asynchrone. Une fois que la tâche démarre, le processus entier peut être contrôlé à partir de la fenêtre Tâches dans VMM. À nouveau, cette même commande de base peut être utilisée pour des migrations rapides sur les clusters Hyper-V et même les hôtes non-cluster, en utilisant un transfert basé sur LAN.
Comme vous le voyez, System Center Virtual Machine Manager 2008 a développé les meilleures fonctions et fonctionnalités de Virtual Machine Manager 2007 avec de nouvelles plates-formes de gestion et de nouvelles fonctionnalités. En passant en revue le processus d'installation et quelques fonctionnalités, j'espère avoir montré à quel point il est facile de gérer plusieurs hyperviseurs dans VMM 2008.
VMM 2008 est conçu pour être le logiciel de gestion consolidé pour la virtualisation, unifiant les systèmes physiques et virtuels de Microsoft et de VMware. Avec cette nouvelle version de Virtual Machine Manager, les administrateurs de VMware, les administrateurs de Microsoft Virtual Server 2005 et les nouveaux administrateurs de Hyper-V peuvent tous profiter d'un outil unique, d'une interface d'écriture de script unique et, plus important, d'un processus de gestion unique pour leur infrastructure virtuelle.

Edwin Yuen est responsable de produit technique pour System Center Virtual Machine Manager au sein de la division Windows Enterprise Management. Edwin a rejoint Microsoft en juillet 2006, dans le cadre de l'acquisition de Softricity. Edwin possède également 13 années d'expérience en tant que consultant technique dans le contexte commercial et gouvernemental. Il est titulaire d'un diplôme en ingénierie électrique de l'université Johns Hopkins.


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.


Virtualisation
Haute disponibilité pour Hyper-V
Steven Ekren
En un coup d'œil :
  • Consolider les serveurs avec Hyper-V
  • Garantir la haute disponibilité des ordinateurs virtuels
  • Définir un basculement Windows Server 2008

Sommaire
Haute disponibilité
Hôtes et invités
Disponibilité d'invité
Rendre les ordinateurs virtuels hautement disponibles
Conditions requises
Procédure de haute disponibilité
Considérations
La virtualisation de serveurs est sur le point de changer les services informatiques d'entreprise, notamment grâce à l'alliance de Hyper-V et Windows Server 2008. La consolidation des serveurs sur un nombre réduit d'ordinateurs physiques a de nombreux avantages en matière d'économies de ressources et de coûts, mais deux facteurs clés doivent être pris en considération lors du processus de planification. Les utilisateurs ont de plus en plus d'attentes concernant la disponibilité de leurs logiciels, y compris les outils et les applications métier comme les plates-formes de messagerie et de collaboration. De plus, les problèmes ou les défaillances des serveurs peuvent avoir un impact bien plus important sur les opérations. Windows Server 2008 et Hyper-V fournissent des solutions qui peuvent être implémentées pour fournir une haute disponibilité d'ordinateurs virtuels ainsi que des charges de travail hébergées sur les ordinateurs virtuels.

Haute disponibilité
La disponibilité signifie que les utilisateurs peuvent accéder à un système pour travailler. Avec la haute disponibilité, les utilisateurs s'attendent désormais à toujours pouvoir accéder au système, parce que ce dernier a été conçu et implémenté pour garantir la continuité opérationnelle.
La haute disponibilité d'Hyper-V est atteinte avec l'utilisation de la fonctionnalité de cluster de basculement Windows Server 2008. La haute disponibilité a un impact sur les interruptions de service prévues et imprévues et le clustering avec basculement peut augmenter de manière significative la disponibilité des ordinateurs virtuels dans ces deux catégories.
Les ordinateurs virtuels peuvent être gérés par le cluster de basculement et ce dernier peut être utilisé dans les ordinateurs virtuels pour contrôler et déplacer les charges de travail hébergées dans l'ordinateur virtuel. Je vais décrire ces deux scénarios de configuration plus en détails, mais une grande partie de cet article portera sur la gestion des ordinateurs virtuels. Cependant, avant de commencer, vous devriez jeter un coup d'œil à l'encadré « Termes Hyper-V utiles ».

Hôtes et invités
Étant donné qu'il existe plusieurs systèmes d'exploitation s'exécutant sur un système Hyper-V, savoir quelle couche ou quel système d'exploitation est abordé(e) ou reste transparent(e) peut s'avérer une tâche extrêmement ardue. J'utilise le terme « invité » pour me référer au système d'exploitation et à l'environnement dans un ordinateur virtuel Hyper-V qui s'exécute sur une partition enfant. J'utilise le terme « hôte » pour indiquer l'ordinateur physique, qui est géré par le système d'exploitation sur la partition parente Hyper-V.
La disponibilité hôte répond aux problèmes qui surviennent lors du scénario « mettre tous ces œufs dans un même panier » que la consolidation des serveurs peut entraîner. Le cluster de basculement Windows Server 2008 peut être configuré sur la partition parente Hyper-V (hôte) pour que les partitions enfant Hyper-V (ordinateurs virtuels ou invités) puissent être contrôlées pour le bon fonctionnement et déplacées d'un nœud de cluster à l'autre. Cette configuration dispose des avantages clés suivants :
  • Si l'ordinateur physique sur lequel Hyper-V et l'ordinateur virtuel s'exécutent doit être mis à jour, modifié ou redémarré, alors les ordinateurs virtuels peuvent être déplacés vers d'autres nœuds du cluster. Les ordinateurs virtuels peuvent alors être replacés une fois que l'ordinateur physique est remis en marche.
  • Si l'ordinateur physique sur lequel Hyper-V et les ordinateurs virtuels s'exécutent échoue (en raison d'une défaillance de carte mère) ou est dégradé de manière significative, les autres membres du cluster de basculement Windows prennent possession des ordinateurs virtuels et les mettent automatiquement en ligne.
  • Si l'ordinateur virtuel échoue, il peut être redémarré sur le même serveur Hyper-V ou déplacé vers un autre serveur Hyper-V. Étant donné que ceci est détecté par le cluster de basculement Windows Server, il effectuera automatiquement les étapes de récupération en se basant sur les paramètres dans les propriétés de ressource de l'ordinateur virtuel. Les interruptions de service sont réduites en raison de l'automatisation de détection et de récupération.
La figure 1 représente ce qui pourrait arriver dans de telles situations. Tout d'abord, l'ordinateur virtuel 2 réside sur l'hôte A, ensuite l'ordinateur virtuel 2 est déplacé sur l'hôte B. Notez que le nœud qui détient le numéro d'unité logique (LUN) 2 du stockage SAN passe de l'hôte A à l'hôte B lors de ce déplacement. Pour vous assurer que votre solution haute disponibilité satisfait vos besoins de disponibilité, considérez soigneusement l'emplacement des ordinateurs virtuels. Vous devez penser en termes de capacité et de performances.
Figure 1 Un ordinateur virtuel et le déplacement de son stockage vers un nouvel hôte (cliquez sur l'image pour l'agrandir)
La capacité des nœuds doit être suffisante pour héberger tous les ordinateurs virtuels et permettre à un nombre x de nœuds d'échouer ou d'être retirés de la participation du cluster actif. (X représente le nombre de nœuds souhaité que le cluster va tolérer de perdre tout en étant toujours capable d'héberger tous les ordinateurs virtuels.) Lorsque vous effectuez ce choix, vous pouvez décider de mettre certains nœuds qui n'hébergent pas régulièrement d'ordinateurs virtuels en réserve. Vous pouvez également étaler les ordinateurs virtuels sur tous les nœuds, garantissant ainsi que chaque nœud dispose d'une capacité supplémentaire suffisante pour pouvoir prendre possession et démarrer les ordinateurs virtuels si un nombre x de nœuds venait à échouer.
Pour des raisons de performances quotidiennes, il peut être souhaitable d'étaler les ordinateurs virtuels sur tous les nœuds du cluster. Si les nœuds sont en réserve et n'hébergent pas les ordinateurs virtuels, alors les nœuds hébergeant les ordinateurs virtuels auront plus de ressources utilisées. Cela peut réduire les performances des ordinateurs virtuels ainsi que la partition de gestion. L'étalage des ordinateurs virtuels sur les nœuds réduit la charge que chaque nœud porte et peut fournir de meilleures performances pour les ordinateurs virtuels et les partitions de gestion. Mais ceci peut rendre la planification plus difficile. Le logiciel de gestion, tel que System Center Virtual Machine Manager 2008, peut aider à fournir des calculs sur la capacité de défaillance des nœuds et le placement des ordinateurs virtuels.

Disponibilité d'invité
La disponibilité d'invité porte sur la mise à disposition de la charge de travail qui s'exécute sur un ordinateur virtuel de haute disponibilité. Les charges de travail communes comprennent les serveurs d'impression et de fichiers, les applications IIS et métier. L'analyse des besoins et des solutions haute disponibilité pour les charges de travail dans les ordinateurs virtuels est identique à l'analyse sur les serveurs autonomes. La solution dépendra de la charge de travail spécifique.
Certaines charges de travail peuvent atteindre une haute disponibilité via l'équilibrage de la charge réseau (NLB) Windows, qui permet à plusieurs serveurs de faire partie d'un pool avec un nom de réseau commun. Les clients font une demande de connexion avec ce nom de réseau virtuel et la connexion est effectuée sur un des nœuds du cluster NLB. Un scénario typique qui utilise la mise en cluster NLB crée des batteries de serveurs Web avec IIS, où chaque système individuel dispose d'IIS avec les mêmes pages Web et le même accès aux mêmes données. NLB fournit l'équilibrage de la charge ainsi que la possibilité de supprimer des serveurs de l'appartenance pour la maintenance ou en cas de problèmes avec le serveur. Il fournit donc un niveau de haute disponibilité. Si un ordinateur virtuel Hyper-V exécute Windows Server 2008 (ou une version précédente de Windows Server comprenant NLB), l'invité peut être membre d'un cluster NLB avec d'autres invités sur un ou plusieurs hôtes Hyper-V identiques ou différents.
Les invités qui exécutent Windows Server 2008 peuvent utiliser la fonctionnalité de cluster de basculement Windows pour fournir une haute disponibilité pour leurs charges de travail. Il existe plusieurs avantages à l'utilisation du clustering avec basculement Windows dans un invité (mise en clusters d'invité) :
Surveillance de l'intégrité de la charge de travail Le cluster de basculement Windows dispose d'un moniteur de ressource qui appelle la DLL de ressource associée au cluster. Chaque ressource dispose de la surveillance de l'intégrité qui teste l'application ou le service géré(e) par la ressource pour s'assurer qu'il(elle) fonctionne correctement. Ces vérifications sont généralement appelées vérifications isAlive/looksAlive. Si la ressource échoue à un de ces appels, la ressource elle-même échoue. En fonction de la manière dont les propriétés sont configurées, la ressource peut tenter de redémarrer le service ou l'application ou elle peut être transférée vers un autre nœud dans le cluster de basculement Windows.
Maintenance d'ordinateur virtuel Si la configuration des ordinateurs virtuels doit être modifiée, ou si le système d'exploitation ou les besoins logiciels doivent être mis à jour ou modifiés, la charge de travail peut être transférée vers un autre nœud du cluster et l'ordinateur virtuel s'arrête ou est mis à jour avec une interruption minimale pour les utilisateurs finaux.
Maintenance de l'ordinateur hôte Si l'ordinateur physique hébergeant un ordinateur virtuel Hyper-V nécessite une maintenance ou des mises à jour logicielles et que les autres membres du cluster de basculement Windows se trouvent sur des hôtes Hyper-V différents, la charge de travail de l'ordinateur virtuel peut être transférée vers un autre nœud du cluster et l'ordinateur virtuel peut être arrêté pour accommoder les modifications ou redémarré à partir du serveur physique.
Défaillance de l'ordinateur hôte ou virtuel S'il y a une défaillance de l'hôte Hyper-V physique ou de l'ordinateur virtuel invité, les autres nœuds du cluster de basculement Windows détecteront que le membre de cluster ne répond plus ou ne participe plus au cluster et les nœuds restants mettront en ligne les applications ou les services qui s'exécutaient sur l'ordinateur virtuel en échec.

Termes Hyper-V utiles
Vous trouverez ci-après une liste de termes qui aident à définir les composants ou fonctions d'un système Hyper-V hautement disponible (cluster hôte).
Partition parente Tous les systèmes d'exploitation qui s'exécutent sur un serveur hyperviseur disposent de ressources matérielles qui incluent la RAM, l'UC et les autres composants système. Dans Hyper-V, il est souvent fait référence à la partition qui gère la configuration de l'hyperviseur et des ressources système comme la partition parente. Lorsque le rôle Hyper-V est configuré et que le serveur a redémarré, l'installation de Windows Server 2008 qui était le système d'exploitation natif sur le système devient le système d'exploitation dans la partition parente du serveur Hyper-V.
Partition enfant Un environnement isolé sur un serveur Hyper-V qui est configuré pour maintenir un système d'exploitation invité et fournir des ressources matérielles à ce système d'exploitation.
Hôte Hyper-V Le serveur physique qui héberge Hyper-V et le système d'exploitation s'exécutant dans la partition parente.
Ordinateur virtuel Hyper-V Les informations de configuration Hyper-V et les données qui sont utilisées pour démarrer et exécuter une partition enfant Hyper-V. Ceci comprend les informations de configuration pour créer la partition enfant et les fichiers VHD ou les disques relais qui contiennent ses données.
Disque relais Un périphérique de stockage qui est exposé dans la gestion des disques en tant qu'un disque physique attribué pour une utilisation exclusive par un invité Hyper-V. L'invité Hyper-V monte le disque et l'utilise comme un périphérique de stockage connecté localement.
Disque dur virtuel (VHD) Un fichier connecté par une partition enfant Hyper-V exposée au système d'exploitation en tant qu'un périphérique de stockage (disque). Le fichier .vhd est situé sur un périphérique de stockage monté par la partition parente et peut être un périphérique de stockage attaché direct ou le stockage connecté via un SAN, NAS ou SMB.
Rendre les ordinateurs virtuels hautement disponibles
Configurer un ordinateur virtuel pour être hautement disponible revient à suivre pas à pas l'Assistant Rôle de haute disponibilité sous la gestion de cluster de basculement. Les ordinateurs virtuels Hyper-V ont plusieurs composants clés qui doivent être considérés lorsqu'ils sont gérés comme hautement disponibles. Observons certains des concepts importants et des conditions requises générales.
Nœuds de cluster de basculement Chaque serveur physique qui fait partie d'un cluster de basculement est appelé un nœud. Pour la mise en clusters hôte, le service de cluster de basculement s'exécute dans Windows Server 2008 sur la partition parente du système Hyper-V. Ceci permet aux ordinateurs virtuels qui s'exécutent dans les partitions enfants sur les mêmes serveurs physiques d'être configurés comme des ordinateurs virtuels hautement disponibles. Les ordinateurs virtuels qui sont configurés pour la haute disponibilité s'afficheront comme des ressources dans la console de gestion de cluster de basculement.
Stockage haute disponibilité Les ordinateurs virtuels hautement disponibles peuvent être configurés pour utiliser des disques durs virtuels, des disques relais et des disques de différenciation. Pour activer le mouvement des ordinateurs virtuels entre les nœuds de cluster de basculement, le stockage doit avoir lieu. Il apparaît comme des disques dans la gestion de disque auxquels vous pouvez accéder par n'importe quel nœud qui pourrait héberger l'ordinateur virtuel. Ceci est géré par le service de cluster de basculement. Les disques relais devraient être ajoutés au cluster de basculement en tant que ressources disque et les fichiers VHD doivent être sur les disques qui sont ajoutés au cluster de basculement en tant que ressources disque.
Ressource d'ordinateur virtuel Il s'agit d'un type de ressource de cluster de basculement qui représente l'ordinateur virtuel. Lorsque la ressource d'ordinateur virtuel est mise en ligne, une partition enfant est créée par Hyper-V et le système d'exploitation dans l'ordinateur virtuel est démarré. La fonction hors connexion de la ressource d'ordinateur virtuel supprime l'ordinateur virtuel d'Hyper-V sur le nœud où il était hébergé et la partition enfant est supprimée de l'hôte Hyper-V. Si l'ordinateur virtuel est interrompu, arrêté ou mis en état enregistré, cette ressource passera à l'état hors connexion.
Ressource de configuration d'ordinateur virtuel Il s'agit d'un type de ressource de cluster de basculement utilisé pour gérer les informations de configuration d'un ordinateur virtuel. Il existe une ressource de configuration d'ordinateur virtuel pour chaque ordinateur virtuel. Une propriété de cette ressource contient le chemin vers le fichier de configuration qui contient toutes les informations nécessaires pour ajouter l'ordinateur virtuel à l'hôte Hyper-V. L'accès au fichier de configuration est nécessaire pour le démarrage d'une ressource d'ordinateur virtuel. Étant donné que la configuration est gérée par une ressource séparée, la configuration d'une ressource d'ordinateur virtuel peut être modifiée même si l'ordinateur virtuel est hors connexion.
Groupe d'applications et services d'ordinateur virtuel Pour qu'un service ou qu'une application puisse être hautement disponible via le clustering avec basculement, plusieurs ressources doivent être hébergées sur le même nœud de cluster de basculement. Pour s'assurer que ces ressources sont toujours sur le même nœud et qu'elles interagissent de manière appropriée, les ressources sont mises dans un groupe auquel le cluster de basculement Windows Server 2008 se réfère en tant que « Service ou application ». La ressource d'ordinateur virtuel et la ressource de configuration d'ordinateur virtuel pour un ordinateur virtuel se trouvent toujours dans le même groupe Services ou applications. Il existe également une ou plusieurs ressources de disques physiques (ou d'autre type de stockage) contenant des fichiers de configuration ou VHD ou des disques relais dans un groupe Services ou applications.
Dépendances de ressources Vous devez vous assurer que la ressource de configuration d'ordinateur virtuel est mise en ligne avant la mise en ligne de la ressource d'ordinateur virtuel (démarrage) et que la ressource de configuration d'ordinateur virtuel est mise hors connexion après la mise hors connexion de la ressource d'ordinateur virtuel (arrêt). Le fait de définir les propriétés de la ressource d'ordinateur virtuel pour qu'elle dépende de la ressource de configuration d'ordinateur virtuel assure la mise en ligne/hors connexion de cette commande. S'il existe une ressource de stockage qui contient le fichier pour la ressource de configuration d'ordinateur virtuel ou la ressource d'ordinateur virtuel, alors la ressource doit devenir dépendante sur cette(ces) ressource(s) de stockage. Par exemple, si l'ordinateur virtuel utilise les fichiers VHD sur le disque G: et le disque H:, la ressource d'ordinateur virtuel doit dépendre de la ressource de fichier de configuration, de la ressource pour le disque G: et de la ressource pour le disque H:.

Conditions requises
Voici les trois conditions requises pour que les ordinateurs virtuels Hyper-V deviennent hautement disponibles à l'aide de la fonctionnalité de cluster de basculement Windows Server 2008 :
  1. 1. La fonctionnalité de cluster de basculement Windows Server 2008 doit être configurée pour chaque nœud du cluster. Pour plus d'informations sur la configuration et la gestion des clusters de basculement, voir l'encadré « Ressources Hyper-V ».
  2. 2. Le rôle Hyper-V doit être installé. Les mises à jour Hyper-V doivent être installées et le rôle configuré pour chaque nœud du cluster de basculement (voir également l'encadré « Ressources Hyper-V »). Hyper-V dispose d'un package de mise à jour qui installe les composants de serveur Hyper-V et un autre qui installe la console de gestion Hyper-V. Une fois la mise à jour installée pour les composants serveur Hyper-V, le rôle peut être ajouté via le gestionnaire de serveur ou ServerManagerCMD.
  3. 3. Vous devez avoir partagé le stockage disponible avec les ordinateurs virtuels. Le stockage peut être géré par le cluster de basculement en tant qu'un type de ressource de disque physique intégré ou vous pouvez utiliser une solution tierce pour gérer le stockage partagé. Bien sûr, la solution tierce doit prendre en charge les clusters de basculement Windows Server 2008.

Procédure de haute disponibilité
Voyons maintenant comment une solution de haute disponibilité est configurée. La première étape consiste à configurer un ordinateur virtuel. Sur un des nœuds du cluster de basculement avec le rôle Hyper-V installé, configurez un ordinateur virtuel avec le gestionnaire Hyper-V (voir la figure 2). Ceci peut être un nouvel ordinateur virtuel configuré manuellement ou vous pouvez importer un ordinateur préexistant. Les disques durs virtuels doivent se situer sur un disque géré par le cluster de basculement Windows Server 2008 actuellement en ligne sur le nœud sur lequel l'ordinateur virtuel est configuré.
Figure 2 Configuration d'un ordinateur virtuel (cliquez sur l'image pour l'agrandir)
Placez maintenant l'ordinateur virtuel à l'état arrêté à l'aide de l'état arrêt, mise hors tension ou enregistrement. Seuls les ordinateurs virtuels à l'état arrêté peuvent être configurés pour la gestion par le cluster de basculement.
Ouvrez la console de Gestion du cluster de basculement (affiché à la figure 3) sur n'importe quel serveur qui exécute le rôle Cluster de basculement Windows Server 2008 ou sur un client Windows Vista exécutant les Outils d'administration de serveur distant. Connectez-vous au cluster de basculement en choisissant l'action Gérer un cluster... puis en sélectionnant un nœud ou le nom de cluster, ou en sélectionnant l'option de connexion au cluster sur le nœud sur lequel la console s'exécute.
Figure 3 Un ordinateur virtuel dans la Gestion du cluster de basculement (cliquez sur l'image pour l'agrandir)
À partir de la console de Gestion du cluster de basculement, sélectionnez l'action Configurer un service ou une application.... Cette opération ouvre l'Assistant Haute disponibilité qui vous guide tout au long de la configuration des services, applications ou ordinateurs virtuels pour qu'ils soient gérés par le cluster de basculement. Sur la page Sélectionner un service ou une application de l'assistant, choisissez Ordinateur virtuel, puis Suivant.
La page Sélectionner l'ordinateur virtuel affiche tous les ordinateurs virtuels configurés sur n'importe quel nœud du cluster de basculement. Sélectionnez un ordinateur virtuel, puis sélectionnez Suivant. La page Confirmation de l'assistant affiche tous les avertissements ou erreurs. À cette étape, la configuration de l'ordinateur virtuel est vérifiée pour s'assurer qu'il peut être configuré en tant qu'une ressource hautement disponible et que les nœuds pourront l'héberger. Si vous sélectionnez Suivant ici, l'ordinateur virtuel s'ajoute au cluster de basculement en tant qu'une ressource hautement disponible.
La page Résumé fournit des informations sur les résultats d'ajout de l'ordinateur virtuel en tant qu'une ressource hautement disponible, y compris tous les avertissements. Un bouton Afficher le rapport peut vous montrer les détails des tâches qui ont été effectuées pour rendre l'ordinateur virtuel hautement disponible, ainsi que tous les avertissements ou erreurs. Enfin, sélectionnez Terminer pour fermer l'assistant Haute disponibilité.
Comme affichée à la figure 3, la console de Gestion de cluster de basculement répertorie un objet avec le nom par défaut de l'ordinateur virtuel (x) dans le volet gauche sous le nom de cluster et Services ou applications. Choisissez l'ordinateur virtuel dans cette arborescence et les ressources qui font partie du groupe Services ou applications s'afficheront dans le volet central de la console. Si tout autre ordinateur virtuel avait ses fichiers sur le même stockage que celui choisi, il serait également ajouté au groupe. L'ordinateur virtuel et les ressources de configuration d'ordinateurs virtuels s'afficheront pour chaque ordinateur virtuel placé dans le groupe.
Le volet d'informations pour le groupe Services ou applications affiche les informations État, Alertes, Propriétaires favoris et Propriétaire actuel pour le groupe. Le nœud Propriétaire correspond au nœud sur lequel l'ordinateur virtuel est actuellement configuré ou s'exécute. Sélectionnez l'option Move Virtual Machine(s) to another node action (Déplacer l'ordinateur virtuel vers une autre action de nœud) pour que l'ordinateur virtuel soit mis hors connexion, puis mis en ligne sur un autre nœud. Il est bon de placer un ordinateur virtuel sur chaque nœud pouvant l'héberger dans le cluster de basculement pour vérifier que le placement est réussi et que l'ordinateur virtuel démarrera et s'exécutera.

Ressources Hyper-V
  • Description de la mise à jour pour la version finale de la technologie Hyper-V pour Windows Server 2008
  • Hyper-V Step-by-Step Guide: Hyper-V and Failover Clustering (Guide étape par étape Hyper-V : test Hyper-V et clusters de basculement)
  • Présentation du clustering avec basculement Windows Server 2008 (Chuck Timon, TechNet Magazine, juillet 2008)
  • (L'hôte NLB ne converge pas comme prévu sur les ordinateurs virtuels Windows Server 2008 Hyper-V)
  • Webcasts sur les clusters Windows 2008
  • Stratégie de support Microsoft pour les clusters à basculement Windows Server 2008
Considérations
Vous trouverez ici quelques points importants à garder à l'esprit lorsque vous configurez des ordinateurs virtuels pour une haute disponibilité :
Stockage Si les ordinateurs virtuels disposent des fichiers VHD sur le même disque partagé, même s'ils sont situés sur des volumes différents sur le même disque, ils seront placés dans le même groupe Service ou application. Un des avantages du partage de disque réside dans le fait qu'il permet une meilleure utilisation de l'espace de stockage partagé disponible.
Cependant, en contrepartie, à chaque fois qu'un ordinateur virtuel est déplacé, que ce soit en raison d'une récupération automatisée à partir d'un problème avec l'ordinateur virtuel ou en raison d'un choix de l'administrateur, tous les ordinateurs virtuels du groupe seront déplacés.
Lettres de lecteurs et GUID Les volumes peuvent être créés sans lettre de lecteur attribuée. Les ordinateurs virtuels peuvent utiliser ces volumes et les volumes peuvent être gérés par le cluster de basculement. Si une ressource disque a des volumes qui utilisent des GUID au lieu de lettres de lecteur, le GUID sera affiché dans la gestion de cluster. Lorsque vous créez des ordinateurs virtuels et spécifiez le chemin des disques durs virtuels, il est très important de vous assurer que le GUID dans le chemin correspond au GUID qui s'affiche dans la gestion de cluster pour le volume. S'il ne correspond pas, l'ordinateur virtuel risque de ne pas pouvoir démarrer (en ligne) sur les autres nœuds du cluster de basculement.
Il existe plusieurs situations qui peuvent entraîner une non-correspondance du GUID. Si un volume a été mis en ligne sur les nœuds avant qu'ils aient été ajoutés en tant que ressource disque gérée par un cluster de basculement, le volume peut avoir un GUID différent sur chaque nœud. Il est également possible qu'un volume ait plusieurs GUID sur un nœud unique. Lorsqu'un disque est ajouté à un cluster de basculement en tant qu'une ressource disque physique, les GUID de volume utilisés sur le nœud ayant les disques en ligne seront indiqués dans les propriétés pour la ressource disque.
Les GUID pour les volumes seront ajoutés à un nœud lorsque la ressource disque est mise en ligne. Ceci garantit que le GUID que le cluster de basculement a indiqué pour le volume est un chemin valide sur n'importe quel nœud mettant le disque en ligne. Ce nœud peut avoir d'autres GUID déjà associés au même volume. Par conséquent, un utilisateur pourrait rechercher un GUID valide pour le volume sur ce nœud, mais il ne s'agit pas du même GUID que celui utilisé par le cluster de basculement pour le volume sur les autres nœuds. Symptôme de ce problème : une ressource d'ordinateur virtuel, en général la ressource Configuration, n'a pas réussi à être mise en ligne et affiche un message d'erreur indiquant que le chemin n'est pas valide. Le chemin du message d'erreur montre que le GUID n'est pas le GUID géré par le cluster pour le volume.
Points de montage Les volumes qui sont montés dans un dossier dans un autre volume, au lieu de se voir attribués une lettre de lecteur ou l'utilisation d'un GUID, sont valides et peuvent être utilisés avec Hyper-V et les clusters de basculement. Étant donné que le volume monté et le volume qui héberge le point de montage doivent être sur le même nœud de cluster de basculement, tous les disques doivent impérativement faire partie du point de montage dans le même groupe Service ou application du cluster de basculement.
Si les volumes sont sur les mêmes disques, ceci n'est évidemment pas un problème. Cependant, ceci devient un véritable problème si les volumes sont sur des disques différents. Il est également évident, mais toujours bon d'être mentionné, que le volume monté et l'hôte du point de montage doivent être un stockage partagé configuré pour une gestion par le cluster de basculement.
Disques de différenciation Tous les fichiers VHD qui font partie des disques de différenciation doivent être sur le stockage partagé dans le même groupe Services ou applications que l'ordinateur virtuel à l'aide de disques de différenciation. Dans sa configuration la plus simple, un disque de différenciation implique deux disques durs virtuels. Un disque dur virtuel est le parent et possède un ensemble de données utilisé comme une base de données. L'autre disque dur virtuel est un enfant associé au parent.
Lorsqu'il est utilisé en premier, le disque de différenciation s'affiche comme le parent. Si les données sont situées sur le parent, il est lu par ce disque dur virtuel. Toutes les écritures arrivent sur le disque dur virtuel enfant. Si les données sont situées sur l'enfant, une lecture pour ces données référencerait alors le disque dur virtuel enfant.
Si un ordinateur virtuel est configuré pour que le disque dur virtuel enfant soit sur le stockage partagé mais que le disque dur virtuel parent ne soit pas sur le stockage partagé dans le même groupe ou sur un périphérique de stockage attaché localement, alors l'ordinateur virtuel ne démarrera pas (en ligne) s'il est transféré sur un autre nœud. L'Assistant Haute disponibilité doit effectuer une vérification pour s'assurer que la configuration est correcte dans l'ordinateur virtuel et fournit un message d'erreur s'il détecte ce problème, mais il est bon de noter les exigences nécessaires au cas où la configuration de l'ordinateur virtuel ait changé.

Steven Ekren est responsable de programme principal au sein de l'équipe Cluster de basculement Windows Server et haute disponibilité. Steven a passé 12 ans chez Microsoft Support où il a aidé les utilisateurs d'entreprise à implémenter et dépanner les clusters de basculement Windows Server et les technologies de virtualisation y compris Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server et Microsoft Virtual PC.


Virtualisation
Sauvegarde et récupération après incident pour la virtualisation des serveurs
Adam Fazio
En un coup d'œil :
  • Considérations relatives à la planification de la récupération après incident
  • Solutions haute disponibilité pour la récupération après incident
  • Sauvegarde et restauration avec Windows Server BackupItem

Sommaire
Introduction à la planification de la récupération après incident
Récupération après incident et virtualisation
Conversion physique vers virtuel
Instantanés d'ordinateur virtuel
Sauvegarde Hyper-V
Sauvegarde Windows Server
Sauvegarde d'ordinateurs virtuels avec Sauvegarde Windows Server
Considérations
Restauration d'ordinateurs virtuels avec Sauvegarde Windows Server
Data Protection Manager
Sauvegardes par script
DiskShadow
Conclusion
À mesure que la technologie de virtualisation de serveur évolue et que son adoption par l'industrie augmente, les entreprises lui reconnaissent des avantages qui vont bien au-delà de la justification la plus courante de la virtualisation : des coûts d'infrastructure réduits et une plus grande agilité informatique. L'étape suivante consiste à utiliser la plate-forme de virtualisation comme moyen de permettre ou d'améliorer les stratégies de récupération après incident.
Pourquoi la préparation de la récupération après incident constitue-t-elle toujours l'un des sujets les plus critiques auxquels est confrontée l'industrie informatique ? D'après certaines études, les entreprises perdent en moyenne entre 80 000 et 90 000 USD par heure pendant les interruptions de service, et très peu d'entreprises victimes d'une perte de données catastrophique arrivent à survivre à long terme. Cet article propose une introduction à la récupération après incident à l'aide de la plate-forme de virtualisation de Microsoft, ainsi qu'un examen plus détaillé des options et considérations de sauvegarde et restauration pour Windows Server 2008 Hyper-V.

Introduction à la planification de la récupération après incident
La récupération après incident est le processus de restauration des services critiques en cas d'interruption et doit faire partie de la stratégie de continuité des activités de chaque entreprise, qui définit la façon dont l'entreprise continuera à fonctionner pendant ou après un incident. Cette stratégie constitue la pierre angulaire de toute initiative de récupération après incident.
Certains fournisseurs affirment que leur technologie d'automatisation de la récupération après incident réduit ou élimine la nécessité d'un plan détaillé soigneusement préparé. Certes, l'automation peut améliorer les délais de récupération et réduire la dépendance par rapport à l'intervention humaine, mais arrêtons-nous un instant pour communiquer un message d'intérêt général : la seule technologie ne suffit pas à atténuer les effets d'un incident. Les personnes et les processus sont toujours aussi importants que les technologies.
En fait, il est presque impossible de sélectionner les technologies adaptées sans connaître, au préalable, toutes les contraintes et tous les objectifs qui découlent du processus de planification de la récupération après incident. Je ne propose pas, dans cet article, de définir tout un plan de récupération après incident mais je voudrais mettre l'accent sur les éléments nécessaires pour sélectionner les bonnes technologies et les bonnes implémentations. Examinons donc rapidement quelques composants essentiels d'un plan de récupération après incident.
Définition et hiérarchisation des services Quels éléments définissent l'ensemble du service que vous essayez de protéger et quelle est leur importance pour l'organisation ? La figure 1 montre des exemples de services d'entreprise qui seraient probablement inclus dans tout plan de récupération après incident.
Figure 1 Exemple de définition et de hiérarchisation des services
Service | Composants principaux | Dépendances | Utilisation métier | SLA
Site Web public | Équilibreur de charge réseau, trois serveurs Web, deux serveurs de base de données | DNS, réseau, pare-feu, répertoire, stockage SAN (Storage Area Network) | Achat de produits et suivi des commandes ; eCommerce ; portail de support client ; informations d'entreprise | 99.99%
Système financier | Deux serveurs de base de données, un serveur d'applications | DNS, réseau | Enregistrement des revenus de l'entreprise, conformément aux lois et à la réglementation | 99.99%
Système de messagerie électronique | Trois serveurs de messagerie électronique, un serveur Web | DNS, réseau, pare-feu, répertoire | Communication d'entreprise ; support client | 99.5%
Une fois les services définis, vous pouvez commencer à identifier les systèmes et dépendances à cibler et les types de stratégies de récupération après incident correspondantes. Après avoir examiné la totalité des services et dépendances, vous pourriez décider de considérer d'autres niveaux de fonctionnalité RI étant donné qu'une solution de récupération après incident commune à tous les services stratégiques serait trop chère et complexe.
Accord de niveau de service (SLA) Un SLA est un accord ou contrat entre le fournisseur de services (informatiques) et le client (l'organisation) qui définit les objectifs de disponibilité pour un service donné. Ces SLA peuvent être interminables ou simples et brefs ; par exemple : « Le système de messagerie électronique sera disponible 99,95 % du temps durant les heures de travail et 98 % du temps en dehors des heures de travail, à l'exclusion des périodes de maintenance planifiées ; la disponibilité sera mesurée mensuellement ». En général, les SLA sont divisés en niveaux qui peuvent être attribués aux services informatiques et qui sont mesurés sur une période prédéfinie.
Accord de niveau d'exploitation (OLA) Les OLA décrivent les accords entre différents groupes informatiques qui travaillent dans le cadre d'un SLA, notamment le processus et les temps de réponse pour la livraison de leurs services. Supposez que vous ayez un site Web stratégique avec une cible SLA de 99,99 % mais que la base de données dont dépend son contenu n'est disponible qu'à 95 %. L'objectif de l'OLA est de clarifier ces différences et d'aligner les équipes informatiques sur le même objectif.
Objectifs de point de récupération (RPO) et Objectifs de temps de récupération (RTO) Un RTO définit la durée de non disponibilité d'un service avant l'existence d'une rupture de la continuité, tandis qu'un RPO définit le niveau de perte de données que l'organisation considère acceptable. Ainsi, si un service a un SLA de 99 % mesuré mensuellement, son RTO correspond à 7 heures, 18 minutes. Si vous combinez cela à un RPO de 24 heures, par exemple, vous pouvez alors définir précisément vos techniques et calendriers de sauvegarde.
Stratégies de conservation des données Les stratégies de conservation des données d'une organisation spécifient la durée pendant laquelle les sauvegardes doivent être conservées et l'endroit où elles doivent être stockées. Ces stratégies sont généralement régies par les lois et la réglementation en vigueur.
Catégorisation des données Vous devez également considérer la nature des données. Si vous classez vos données par catégories, vous ne tarderez pas à découvrir que les données ne nécessitent pas toutes le même niveau de considération en matière de récupération après incident. Par exemple, une base de données unique peut avoir des exigences de disponibilité différentes de celles d'un Active Directory doté de plusieurs contrôleurs de domaine contenant chacun un réplica du répertoire. De même, les données de serveur de fichiers peuvent avoir des procédures de restauration très différentes de celles des données CRM.
Scénarios d'incident Il est important de définir tous les scénarios que vous souhaitez inclure dans vos plans puisque chacun de ces scénarios aura des procédures de restauration, un impact commercial et des coûts différents. Il est prudent d'examiner tous les scénarios possibles puis de choisir ceux que vous voulez cibler lorsque vous établissez un plan de récupération après incident pour votre environnement :
  • Perte d'un site entier
  • Perte d'un centre de données unique
  • Perte d'un système (défaillance de système d'exploitation ou de matériel)
  • Perte de données (suppression ou corruption de données)
  • Perte d'une dépendance critique
Il est évident que les considérations liées à la récupération de la perte d'un site tout entier sont très différentes de celles qui concernent un seul système. Il est également important de définir les seuils de récupération en fonction de vos SLA. Par exemple, supposons qu'un site entier soit hors connexion en raison d'une sérieuse défaillance réseau d'un FAI. Si le SLA lié au service concerné est de 8 heures pour la restauration du service et 48 heures pour la restauration des données, vous exécuterez peut-être les procédures de basculement de service vers votre site de sauvegarde mais pas nécessairement le processus de récupération des données, car vous vous attendriez à revenir au site de production assez rapidement.
Pfffiou ! Et nous n'avons même pas abordé la technologie ! L'importance de la planification ne doit pas être sous-estimée. Une implémentation de la récupération après incident sans un plan bien précis est souvent vouée à l'échec.

Récupération après incident et virtualisation
Maintenant que nous avons cerné les principes de base de la récupération après incident, quel rôle la virtualisation y joue-t-elle ? De nombreuses entreprises rendent compte de délais de restauration de service en minutes pour les serveurs virtualisés au lieu de jours ou de semaines pour les serveurs physiques. Dans la mesure où l'ensemble du système d'exploitation du serveur n'est plus qu'un jeu de fichiers et n'a aucun lien avec le matériel physique sous-jacent, de nouvelles possibilités se présentent en matière de récupérabilité.
L'un des théories très en vogue aujourd'hui veut qu'il est possible d'atteindre certains ou tous les objectifs de récupération après incident grâce aux solutions de haute disponibilité. L'idée est que si vous avez des nœuds de cluster à des emplacements physiques séparés et que les données sont synchronisées entre les sites, en cas de défaillance, le nœud passif peut reprendre les opérations et vous pouvez effectuer une récupération en temps quasi-réel.
Cela est vrai, mais si vous vous souvenez des incidents que nous avions définis plus haut, il est clair que cette solution ne s'applique pas à tous les scénarios. Il vous faut une combinaison de technologies pour vous préparer à tous les scénarios, et ceci inclut généralement des sauvegardes régulières d'un certain type. La haute disponibilité ne protège pas contre toutes les interruptions de service possibles, et elle n'élimine pas complètement la nécessité de recourir à une certaine forme de stratégie de sauvegarde.
La haute disponibilité avec Hyper-V nécessite une préparation minutieuse de la couche de stockage car il s'agit là d'un facteur critique à l'exécution du processus de récupération. Par exemple, un cluster Hyper-V à 2 nœuds avec stockage partagé a toujours le sous-système et les données de stockage comme point de défaillance unique, même si les nœuds de cluster sont dans un centre de données séparé.
Cependant, vous devez savoir que le même cluster Hyper-V à 2 nœuds avec stockage non partagé peut survivre à une perte de stockage ou de données sur l'un ou l'autre des nœuds. Ce scénario nécessite des technologies de réplication pour maintenir la synchronisation du stockage et introduit également des complexités (voir figure 2).
Figure 2 Cluster Hyper-V multisites (Cliquez sur l'image pour l'agrandir)
Il existe des développements très intéressants dans le domaine de la réplication et synchronisation des données, mais Microsoft ne s'y intéresse pas actuellement. La page Clusters multisites de Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) propose une présentation intéressante des partenaires. Le catalogue Windows Server (voir windowsservercatalog.com) est une autre ressource qui répertorie les fournisseurs de stockage proposant des technologies de réplication certifiées pour Windows Server 2008.
Comme vous le voyez, il existe de nombreuses configurations de haute disponibilité et de stockage à envisager. C'est pour cela que vous devez définir vos exigences métier et leur permettre de déterminer vos exigences techniques, et non pas le contraire.

Conversion physique vers virtuel
La virtualisation offre clairement une agilité de récupération unique, mais qu'en est-il des systèmes physiques qui ne sont pas de bons candidats à la virtualisation ? System Center Virtual Machine Manager (SCVMM) inclut la possibilité d'exécuter des conversions P2V (physique vers virtuel) de serveurs Windows en cours exécution, dont le résultat est un ordinateur virtuel Hyper-V amorçable qui est une réplique identique du serveur source physique. Vous pouvez désormais répliquer cet ordinateur virtuel de la même façon que ses homologues virtualisés dans les campus ou dans tout le pays et obtenir des délais de récupération similaires.
Cette approche est différente de la restauration sans système d'exploitation traditionnelle en ce sens que votre emplacement de récupération n'a plus besoin du même nombre ou type de systèmes physiques que votre emplacement de production. Vous pouvez donc utiliser à volonté votre matériel de récupération et le déployer en fonction de l'impact de l'incident.
Bien que SCVMM n'inclut pas de planificateur pour les conversions P2V puisque la GUI s'exécute entièrement sur Windows PowerShell, vous pouvez facilement en écrire le script à l'aide de l'applet de commande New-P2V. En fait, tous les assistants de SCVMM afficheront le code qu'ils utilisent pour effectuer une tâche, et vous pouvez copier le code d'un test P2V dans votre environnement et le modifier pour une future utilisation automatisée. La figure 3 reproduit un exemple de code ; vous pouvez exécuter l'assistant P2V de SCVMM dans votre environnement pour obtenir un script Windows PowerShell unique et personnalisable.
Figure 3 Code produit par l'assistant P2V de SCVMM
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Instantanés d'ordinateur virtuel
Bien qu'il ne s'agisse pas techniquement d'une sauvegarde, un instantané d'ordinateur virtuel fournit un point (dans le temps) auquel vous pouvez revenir en utilisant des disques de différenciation et une copie du fichier de configuration de l'ordinateur virtuel. Si l'incident implique une suppression de données accidentelle dans l'ordinateur virtuel, cet instantané peut être considéré comme une fonctionnalité de la récupération après incident car l'ordinateur virtuel peut être renvoyé à l'instantané, annulant ainsi les dommages. (Nous jetterons un coup d'œil sur le service de cliché instantané de volume (VSS) plus tard).

Sauvegarde Hyper-V
Sauvegardes basées sur l'hôte L'un des avantages intéressants que propose la virtualisation de serveur réside dans la possibilité de ne plus sauvegarder individuellement les systèmes virtualisés. Maintenant que ces systèmes sont de simples fichiers qui résident sur le système de fichiers d'un hôte, il vous suffit de sauvegarder les fichiers et le tour est joué, n'est-ce pas ? Euh, pas vraiment ! Comme il s'agit d'ordinateurs actifs consistant en données en mémoire, données sur disque, configurations système et fichiers ouverts, il y a certaines choses dont vous devez tenir compte. Alors, comment pouvons-nous garantir la cohérence des données de sauvegarde étant donné tous ces éléments amovibles ?
L'une des améliorations considérables dans l'histoire de la sauvegarde Windows Server est apparue dans Windows Server 2003 avec l'arrivée de VSS, qui fournit un jeu standard d'API extensibles que les enregistreurs VSS (c'est-à-dire des crochets dans les applications et les services qui permettent d'obtenir des clichés instantanés cohérents) utilisent pour créer des sauvegardes de fichiers ouverts et d'applications. À l'aide du service, des fournisseurs et des enregistreurs VSS, l'application de sauvegarde peut générer une copie instantanée d'un volume très rapidement, copie que l'application reconnaît et qu'elle peut traiter de façon appropriée.
Hyper-V est fourni avec son propre enregistreur VSS qui permet aux éditeurs de logiciels de créer des solutions de sauvegarde de grande qualité. L'enregistreur permet aux applications de sauvegarde d'effectuer des sauvegardes VSS basées sur l'hôte d'ordinateurs virtuels en cours d'exécution. Si le système d'exploitation qui s'exécute dans l'ordinateur virtuel est doté des composants d'intégration Hyper-V ainsi que du service VSS (disponible dans Windows XP SP1 et Windows Server 2003 et versions ultérieures), la sauvegarde basée sur l'hôte se fera comme si elle avait été exécutée dans l'invité ; la sauvegarde sera exécutée avec l'ordinateur virtuel en cours d'exécution et les données seront cohérentes (voir figure 4).
Figure 4 Sauvegarde VSS (Cliquez sur l'image pour l'agrandir)
Toutefois, si le système d'exploitation invité ne prend pas en charge les composants d'intégration ou VSS, le processus de sauvegarde nécessite que l'ordinateur invité soit mis dans un état enregistré et qu'un instantané VSS basé sur l'hôte soit pris des fichiers de données de l'ordinateur virtuel qui peuvent être utilisés pour la récupération ponctuelle. Les instantanés VSS de l'état enregistré provoqueront un certain ralentissement de l'ordinateur virtuel (généralement limité à entre 5 et 10 minutes), et des procédures de sauvegarde sur bande complètes interviennent sur la copie VSS des données.
Sauvegardes basées sur l'invité Dans un environnement physique, les serveurs et les applications doivent être sauvegardés individuellement, et ces sauvegardes peuvent se poursuivre dans un centre de données virtualisé. Dans cette situation, les mêmes considérations doivent être prises en compte lors de la sauvegarde d'un ordinateur virtuel, notamment les exigences en matière de capacité réseau pour les sauvegardes réseau et l'impact des performances sur le système durant la fenêtre de sauvegarde. Avec les sauvegardes basées sur l''invité, vous pouvez choisir d'avoir, dans l'hôte, une carte réseau physique dédiée liée à un réseau virtuel que tous les invités utilisent.

Sauvegarde Windows Server
Windows Server 2008 inclut Sauvegarde Windows Server (WSB), qui est compatible avec VSS et peut être utilisé pour exécuter des sauvegardes Hyper-V basées sur l'hôte et l'invité de vos ordinateurs virtuels. Comme il est doté de toutes les fonctionnalités VSS, Sauvegarde Windows Server peut exécuter des sauvegardes basées sur l'hôte de vos ordinateurs virtuels en cours d'exécution, ce qui est, bien sûr, préférable.
Toutefois si vous avez des ordinateurs virtuels qui ne sont pas dotés des composants d'intégration, VSS ne sera pas utilisé. Dans ce cas, vous avez deux possibilités. Vous pouvez continuer à utiliser WSB pour sauvegarder un ordinateur virtuel qui n'est pas doté des composants d'intégration, ce qui signifie que l'état de l'ordinateur virtuel sera enregistré et que la sauvegarde prendra ensuite les disques virtuels et les fichiers de configuration de l'ordinateur virtuel.
Cependant, cette méthode risque de ne pas convenir avec une application telle qu'Exchange car cette dernière ne saura pas qu'une sauvegarde a été exécutée et les journaux d'application ne seront pas tronqués. De plus, le service sera interrompu sur l'ordinateur virtuel et la durée de cette interruption variera en fonction du temps que prendra la sauvegarde.
Une sauvegarde peut également être exécutée depuis l'ordinateur virtuel de la même façon que si ce dernier était un ordinateur physique, à l'aide soit de NTBackup soit de WSB, selon le système d'exploitation de l'ordinateur virtuel. Voyons comment utiliser WSB pour les invités pris en charge qui sont dotés des composants d'intégration.

Sauvegarde d'ordinateurs virtuels avec Sauvegarde Windows Server
Hyper-V n'inscrit pas automatiquement son enregistreur VSS pour une utilisation avec Sauvegarde Windows Server (WSB). Vous devez ajouter manuellement la clé de Registre et la valeur indiquées à la figure 5 pour que WSB prenne en charge une sauvegarde Hyper-V. Vous pouvez les ajouter via la ligne de commande, comme suit :
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
Figure 5 Clé et valeur pour l'inscription de l'enregistreur VSS d'Hyper-V
Chemin | Clé de registre ou valeur | Type
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | Clé | N/A
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | Valeur | REG_SZ (Hyper-V, par exemple)
Ceci ne nécessite pas un redémarrage car WSB recherche cette clé/valeur durant l'exécution de la sauvegarde. La commande suivante indiquera si l'entrée a été définie :
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
Voici comment installer WSB. Cliquez sur Démarrer | Gestionnaire de serveur. Dans le volet de gauche, cliquez sur Fonctionnalités puis sur Ajouter des fonctionnalités dans le volet de droite. Sur la page Sélectionner les fonctionnalités, développez Fonctionnalités de la Sauvegarde Windows Server et cochez les cases Sauvegarde Windows Server et Outils de ligne de commande. À présent, procédez comme suit pour configurer votre sauvegarde :
  1. Allez dans Démarrer | Outils d'administration | Sauvegarde Windows Server.
  2. Si vous sauvegardez un hôte distant, choisissez Connexion à un autre ordinateur et entrez l'hôte Hyper-V.
  3. Choisissez Sauvegarde unique ou Planification de sauvegarde.
  4. Sélectionnez Configuration de sauvegarde—Serveur entier ou Personnalisé. Si vous choisissez Personnalisé, assurez-vous que vous disposez de tous les volumes qui contiennent des données liées à l'ordinateur virtuel que vous sauvegardez, y compris les données de configuration, les disques virtuels et les instantanés de l'ordinateur virtuel.
  5. Choisissez l'emplacement où vous souhaitez enregistrer la sauvegarde.
  6. Choisissez Complète VSS ou Sauvegarde de copie. Pour les sauvegardes basées sur l'hôte où aucune autre sauvegarde n'a lieu avec les ordinateurs virtuels, choisissez Sauvegarde complète VSS.
  7. Une fois que vous avez confirmé les détails, sélectionnez Sauvegarde.
Considérations
  • Vous devez sauvegarder tous les volumes liés à un ordinateur virtuel, y compris les disques durs virtuels, les fichiers de configuration de l'ordinateur virtuel et les instantanés.
  • Si vous créez une Planification de sauvegarde, vous devez utiliser un volume local dédié qui sera formaté et exclusivement utilisé par WSB. À l'inverse, si vous exécutez une Sauvegarde unique, vous pouvez enregistrer la sauvegarde sur un volume local non dédié, un périphérique amovible ou un partage réseau.
  • Si les composants d'intégration ne sont pas installés dans l'ordinateur virtuel qui est sauvegardé, WSB enregistrera l'état de l'ordinateur virtuel en cours d'exécution pour garantir la cohérence des données de sauvegarde.
  • Une fois la sauvegarde terminée, le jeu de sauvegarde est portable et peut être utilisé avec n'importe quel hôte Hyper-V.
Restauration d'ordinateurs virtuels avec Sauvegarde Windows Server
Bien que Sauvegarde Windows Server (WSB) ait la possibilité de restaurer des fichiers individuels, cette fonctionnalité n'utilise pas VSS et pourrait donc créer une restauration incohérente si l'ordinateur virtuel était en cours d'exécution lors de la sauvegarde. Pour restaurer des ordinateurs virtuels en cours d'exécution, vous devez restaurer les volumes entiers.
Pour ce faire, vous devez aller dans Démarrer | Outils d'administration | Sauvegarde Windows Server et, dans le Volet Actions, sélectionner Récupérer. Choisissez le serveur à partir duquel vous souhaitez récupérer les données (celui qui renferme les données sauvegardées WSB) puis choisissez la date à partir de laquelle vous voulez restaurer ces données. À présent, vous pouvez sélectionner le type de récupération.
C'est à ce moment que vous devez prendre une décision. Si vous avez besoin de la totalité de l'ordinateur virtuel, y compris sa configuration, ses instantanés et ses disques virtuels (dans le cas d'une défaillance complète de l'hôte, par exemple), sélectionnez Restauration de l'application puis Hyper-V, comme illustré à la figure 6. Dans ce cas, vous ne pouvez pas choisir de restaurer des fichiers individuels. Vous devrez restaurer tout ce qui est inclus dans ce jeu de sauvegarde. Notez que cette opération ne remplacera pas les données de configuration Hyper-V et d'ordinateurs virtuels existantes qui ont été modifiées depuis la sauvegarde.
Figure 6 Restauration d'une sauvegarde Hyper-V (Cliquez sur l'image pour l'agrandir)
Si vous n'avez besoin que du VHD lui-même et que les données de configuration et les instantanés de l'ordinateur virtuel sont intègres, vous pouvez sélectionner Fichiers et dossiers et choisir le fichier VHD qu'il vous faut. Notez que ce processus n'utilise pas l'enregistreur VSS ; l'ordinateur virtuel aurait dû être sauvegardé en tenant compte de cela, c'est-à-dire avec son état enregistré dès le départ.
Si vous avez subi une perte de système et de données totale et devez récupérer l'hôte Hyper-V lui-même, y compris le système d'exploitation Windows Server 2008 et tous les ordinateurs virtuels qui y sont exécutés, vous devez démarrer sur l'Environnement de récupération Windows et exécuter votre restauration à partir de là. Vous pouvez le faire à partir du disque d'installation de Windows Server 2008 ou d'une partition de disque préconfigurée.

Data Protection Manager
Nous avons jeté un coup d'œil sur les étapes et considérations de sauvegarde et de restauration des hôtes et invités Hyper-V à l'aide de la Sauvegarde Windows Server, un programme fiable, gratuit et intégré. Toutefois, ce programme n'est pas une solution de protection des données d'entreprise. C'est là qu'intervient Data Protection Manager (DPM) 2007 SP1. DPM SP1, dont la sortie est prévue pour la fin de l'année 2008, prend en charge Hyper-V et offre des fonctionnalités incontournables :
  • Console de gestion unique pour tous les hôtes et invités Hyper-V.
  • Protection des données continue, avec une prise d'instantanés basés sur VSS à intervalles de maximum 15 minutes qui n'inclut que les éléments qui ont été modifiés au cours du processus.
  • Détection de cluster Hyper-V qui permet à la sauvegarde de suivre l'ordinateur virtuel lorsqu'elle se déplace entre les nœuds de cluster.
•Réplication de serveur DPM à serveur DPM.
  • Prise en charge des sauvegardes sur disque et sur bande (disque à disque, disque à bande ou disque à disque à bande).
  • Fonctionnalités de sauvegarde et de restauration sur tout le spectre des données, qui inclut les hôtes et invités Hyper-V, les sauvegardes VSS sans agent d'invités en cours d'exécution, la prise en charge de la restauration d'ordinateurs virtuels individuels, les données de cluster de basculement et les meilleures fonctionnalités spécifiques aux applications pour SQL Server, Exchange, SharePoint, Hyper-V et Virtual Server.
  • Scripts avant et après la sauvegarde.
Si vous utilisez actuellement une solution de sauvegarde d'un fournisseur tiers, attendez-vous à la publication de mises à jour pour cette application ; en effet, la plupart des fournisseurs travaillent d'arrache-pied pour essayer de mettre des solutions basées sur l'hôte Hyper-V sur le marché.

Sauvegardes par script
Sauvegarde Windows Server inclut une interface de ligne de commande, WBadmin.exe, ainsi qu'un jeu d'applets de commande Windows PowerShell utilisables avec les scripts. Lorsque vous utilisez ces applets de commande, les mêmes règles de sauvegarde que celles que j'ai décrites précédemment s'appliquent, avec la nécessité d'inscrire l'enregistreur VSS d'Hyper-V manuellement dans le Registre.
La figure 7 propose quelques commandes WBAdmin. Pour une documentation WBAdmin complète, voir go.microsoft.com/fwlink/?LinkId=124380. Comme vous le voyez, il n'y a rien dans WB​Admin qui permette de configurer la stratégie de sauvegarde elle-même, mais il existe un composant logiciel enfichable Windows PowerShell qui permet de gérer ces paramètres. Vous pouvez voir si ce composant logiciel enfichable est inscrit à l'aide de la commande suivante :
Get-PSSnapin -Registered
Figure 7 Commandes WBAdmin
Commandes WBAdmin | Description
ENABLE BACKUP | Active ou modifie une sauvegarde quotidienne planifiée.
DISABLE BACKUP | Désactive des sauvegardes quotidiennes planifiées en cours d'exécution.
START BACKUP | Exécute une sauvegarde.
STOP JOB | Met fin à la sauvegarde ou récupération en cours d'exécution.
GET VERSIONS | Répertorie les détails des sauvegardes récupérables depuis un emplacement spécifique.
GET ITEMS | Répertorie les articles contenus dans la sauvegarde.
START RECOVERY | Exécute une récupération.
GET STATUS | Signale l'état de la tâche en cours d'exécution
GET DISKS | Répertorie les disques qui sont actuellement en ligne.
START SYSTEMSTATERECOVERY | Exécute une récupération de l'état du système.
START SYSTEMSTATEBACKUP | Exécute une sauvegarde de l'état du système.
DELETE SYSTEMSTATEBACKUP | Supprime la ou les sauvegardes de l'état du système.
Vous pouvez également utiliser le code suivant pour charger un composant logiciel enfichable appelé Windows.ServerBackup :
Add-PSSnapin windows.serverBackup
Une fois le composant chargé, vous avez accès aux applets de commande Windows PowerShell pour Sauvegarde Windows Server, comme illustré à la figure 8. Pour une description plus détaillée de chaque applet de commande, exécutez la commande suivante :
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
Figure 8 Applets de commande de Sauvegarde Windows Server
Applet de commande | Description
Add-WBBackupTarget | Ajoute une cible de sauvegarde à la stratégie de sauvegarde.
Add-WBVolume | Ajoute un volume à la stratégie de sauvegarde.
Get-WBBackupTarget | Obtient les cibles de sauvegarde d'une stratégie.
Get-WBDisk | Obtient tous les disques.
Get-WBPolicy | Obtient la stratégie de sauvegarde actuelle.
Get-WBSchedule | Obtient le calendrier des sauvegardes de la stratégie.
Get-WBSummary | Obtient l'historique et le résumé de la sauvegarde.
Get-WBVolume | Obtient tous les volumes.
New-WBBackupTarget | Crée une nouvelle cible de sauvegarde.
New-WBPolicy | Crée une nouvelle stratégie vide
Remove-WBBackupTarget | Supprime une cible de sauvegarde de la stratégie.
Remove-WBPolicy | Supprime la stratégie de sauvegarde.
Remove-WBVolume | Supprime un volume de la stratégie.
Set-WBPolicy | Enregistre l'objet WBPolicy pour créer une sauvegarde planifiée.
Set-WBSchedule | Définit la planification sur la stratégie de sauvegarde.

Il existe un autre utilitaire intégré à Windows Server 2008 qui peut également utiliser l'enregistreur VSS d'Hyper-V et ajouter une certaine flexibilité à vos options de scripts. DiskShadow.exe permet de prendre un cliché instantané qui peut être monté en tant que lecteur, ce qui permet aux administrateurs d'effectuer une sauvegarde plus sélective qu'avec Sauvegarde Windows Server. Il est également important de vous rappeler que DiskShadow n'accepte pas les entrées de pipeline Windows PowerShell ; au lieu de cela, les commandes doivent lui parvenir via un script qui ressemblera à ce qui suit :
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
Ce script supprime d'abord tout cliché instantané existant du lecteur C: puis garantit que le cliché instantané persiste une fois DiskShadow exécuté. Ensuite, il crée un bloc transactionnel ; si l'une des étapes échoue, le processus tout entier échoue. Dans ce bloc, DiskShadow vérifie que l'enregistreur Hyper-V est chargé puis ajoute le lecteur C: à la liste des lecteurs à sauvegarder.
Le lecteur C: obtiendra un GUID servant à l'identifier, et ce GUID sera enregistré dans une variable d'environnement appelée « MyShadow ». Cette opération terminée, le cliché instantané est créé.
La sauvegarde est exposée en tant que lecteur X: à l'aide de la variable d'environnement. Diverses opérations peuvent être effectuées avec les données du lecteur X: et DiskShadow peut ensuite être exécuté à nouveau avec Unexpose X: pour supprimer le lecteur.
Notez que la restauration d'ordinateurs virtuels Hyper-V qui ont été sauvegardés via DiskShadow est actuellement un processus manuel (l'ordinateur virtuel doit être recréé, les instantanés ne sont pas conservés, et ainsi de suite). Bien que ce processus comporte des inconvénients évidents, les données sont protégées.
La récupération après incident peut s'avérer un processus ardu et apparemment sans fin. Toutefois, la virtualisation de serveur offre de nouvelles possibilités grâce aux technologies et au point d'entrée à coût réduit qui en découle. Microsoft propose non seulement la virtualisation mais un écosystème tout entier. Ensemble, la plate-forme de virtualisation de serveur et la famille System Center offrent des solutions plus holistiques face aux défis toujours plus complexes auxquels font face les organisations, y compris la récupération après incident.
J'aimerais remercier James O'Neill pour sa contribution à cet article.

Adam Fazio a commencé à travailler pour Microsoft Consulting Services il y a plus de 2 ans et opère actuellement auprès de la clientèle issue du secteur public américain. Il a travaillé dans le secteur informatique pendant plus de 10 ans, participant à plusieurs projets d'infrastructure et d'opérations de centres de données pour de nombreuses entreprises classées dans Fortune 100 ainsi que pour des start-ups Internet. Il est actuellement responsable du support technique pour le programme Virtualization Rapid Deployment chez Microsoft.


Virtualisation
Outils essentiels pour la planification de votre infrastructure virtuelle
Jay Sauls et Baldwin Ng
En un coup d'œil :
  • Contrôle des coûts
  • Inventaire des ordinateurs
  • Détermination de l'utilisation de l'UC, des E/S disque et du réseau

Sommaire
Présentation de l'outil
Sachez ce que vous possédez
Détermination de l'utilisation actuelle
Recommandations pour la sélection élective de serveur
Configuration d'ordinateur virtuel
Contraintes de sélection élective
Étude des possibilités
Exigences
Conclusion
La virtualisation n'est pas une nouvelle technologie, mais elle est actuellement en pleine explosion dans de nombreux nouveaux domaines, bien au-delà de la virtualisation de plate-forme d'origine développée par IBM dans les années 1960. L'une des raisons majeures de cette croissance rapide est le potentiel que représentent les technologies de virtualisation pour le contrôle des coûts dans les centres de données et tous les services informatiques. Avec l'augmentation des coûts d'énergie et la nécessité grandissante de services informatiques supplémentaires dans votre entreprise, vous luttez peut-être pour suivre la croissance de serveur tout en essayant de limiter les coûts opérationnels. La virtualisation peut vous aider. Microsoft et d'autres fabricants de logiciels ont développé de nouvelles technologies, y compris la virtualisation de serveur, de bureau et d'application, qui rendent les ressources virtuelles plus largement disponibles.
Dans cet article, nous examinerons un ensemble d'outils pouvant vous aider dans vos projets de virtualisation, Microsoft Assessment and Planning Toolkit (MAP), qui fait partie de la famille des accélérateurs de solutions Microsoft. Que sont les accélérateurs de solutions ? Pour simplifier, il s'agit d'outils d'automation et de recommandations nécessaires pour quasiment tout projet informatique. Les accélérateurs de solutions sont des ressources de référence gratuites qui vous aident à planifier de manière proactive, livrer et contrôler votre infrastructure informatique, des postes de bureau aux serveurs, du physique au virtuel.
Conçus en collaboration avec des experts du secteur et testés dans de véritables environnements clients, les accélérateurs de solutions offrent précisément le niveau de recommandations et d'automation nécessaire pour obtenir des performances supérieures et créer une infrastructure informatique inter-produits, sans avoir à réinventer la roue. Ces ressources répondent aux inquiétudes essentielles d'entreprises de toute taille, telles que l'évaluation et la planification d'infrastructure, la virtualisation, la communication et la collaboration, ainsi que la sécurité et la conformité.

Présentation de l'outil
Disponible depuis peu, MAP Toolkit 3.1 (voir figure 1) est un outil d'évaluation d'infrastructure sur l'ensemble du réseau, conçu pour vous aider à obtenir rapidement une compréhension fondamentale de vos serveurs et postes de bureau, ce qui inclut déterminer s'ils sont prêts pour une mise à niveau ou une migration vers des technologies telles que Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 et SQL Server.
Figure 1 Microsoft Assessment and Planning Toolkit 3.1 (cliquez sur l'image pour l'agrandir)
Comme l'indique la figure 2, MAP génère automatiquement les rapports et les propositions d'évaluation de la préparation, en économisant une grande quantité de travail que vous devriez autrement effectuer vous-même. MAP Toolkit 3.1 prend en charge les scénarios de postes de bureau et de serveur, y compris l'évaluation des ordinateurs de bureau pour la mise à niveau vers Windows Vista et la planification du déploiement de Microsoft Application Virtualization.
Figure 2 Exemple de proposition de migration généré automatiquement (cliquez sur l'image pour l'agrandir)
Pour la planification de virtualisation de serveur, trois fonctionnalités essentielles de l'outil peuvent vous aider à déterminer si vos ordinateurs physiques constituent de bons candidats : inventaire de serveur, rassemblement des mesures de performances et recommandations de sélection élective de virtualisation. Examinons un scénario montrant comment vous pouvez utiliser ces fonctionnalités pour créer une image détaillée de votre environnement actuel et planifier la transition vers la virtualisation.

Sachez ce que vous possédez
De nombreuses grandes entreprises possèdent un type d'infrastructure d'administration de serveur en place, tel que System Center Operations Manager. Certains environnements sont gérés de manière moins active. Si vous travaillez dans un environnement dans lequel vous ne savez pas vraiment quels sont les serveurs en place ou ce qu'ils exécutent, la fonctionnalité d'inventaire de serveur peut vous aider à obtenir rapidement un aperçu clair. L'inventaire de serveur peut découvrir les ordinateurs de votre environnement en utilisant Active Directory, un balayage des plages d'adresses IP ou en important simplement une liste d'ordinateurs à partir d'un fichier brut. Comme l'indique la figure 3, vous pouvez également utiliser conjointement de multiples méthodes de découverte (l'analyse Active Directory et le balayage d'adresse IP, par exemple) pour trouver les ordinateurs qui devraient être dans Active Directory mais ne le sont pas.
Figure 3 Choix de la méthode de découverte d'ordinateurs (cliquez sur l'image pour l'agrandir)
Lorsque des ordinateurs sont découverts, MAP Toolkit 3.1 tente de se connecter à chacun d'entre eux et de récupérer plus de 50 catégories de données via Windows Management Instrumentation (WMI). Plusieurs types de rapports différents peuvent être créés à partir de ces données. Pour la consolidation des serveurs avec la virtualisation, nous nous intéressons principalement aux rapports créés lorsque vous sélectionnez l'option de migration des rôles et services spécifiques vers Windows Server 2008.
Même si vous n'effectuez pas immédiatement une migration vers Windows Server 2008, les deux rapports que crée ce scénario sont précieux pour déterminer le type de matériel de votre environnement (y compris le type de processeur et sa vitesse, la taille des disques et la mémoire installée), ainsi que les rôles de logiciel que vous avez affectés à chaque serveur (serveurs DNS, contrôleurs de domaine et serveurs Terminal Services).
Ces rapports vous sont fournis sous la forme de classeurs Microsoft Excel. Il est par conséquent facile d'utiliser les outils de tri et de filtrage d'Excel pour identifier avec précision les ordinateurs de votre environnement qui constitueraient de bons candidats à la virtualisation.
Les rapports d'inventaire de serveur fournissent des données sur plusieurs attributs que vous pouvez prendre en compte pour le choix des serveurs à virtualiser. Par exemple, vous pouvez vouloir garantir que les ordinateurs que vous virtualisez exécutent un système d'exploitation pris en charge par la plate-forme de virtualisation Hyper-V. Dans le classeur Excel WS2008HardwareAssessment créé par le processus d'inventaire de serveur, sous l'onglet Server Inventory, vous pouvez examiner les colonnes Current Operating System et Service Pack pour trouver les systèmes qui nécessitent d'être mis à niveau.

Détermination de l'utilisation actuelle
L'étape suivante de la recherche de candidats de virtualisation consiste à mesurer le degré d'utilisation des ordinateurs physiques. L'Assistant Performance Metrics Wizard de MAP Toolkit 3.1 (voir figure 4) enregistre des compteurs de performances pour une liste d'ordinateurs que vous avez identifiés comme candidats à la virtualisation. utilisation de l'UC, des E/S disque et du réseau sont capturés pour examen ultérieur.
Figure 4 Assistant Performance Metrics Wizard (cliquez sur l'image pour l'agrandir)
Cette partie de l'outil a été conçue pour observer des ordinateurs sur une période assez longue (jusqu'à un mois), ce qui vous procure une certaine flexibilité dans la manière de l'utiliser. Si vous avez déjà une bonne idée des circonstances des pointes d'utilisation de votre environnement (vous pouvez par exemple posséder une fenêtre de traitement par lots hebdomadaire), vous pouvez configurer l'Assistant pour qu'il ne s'exécute que pendant quelques heures aux alentours de cette période. Cependant, si vous ne savez pas précisément quand se produit le pic d'utilisation ou si vous aimeriez observer de nombreux ordinateurs possédant des pics d'utilisation différents, vous pouvez configurer l'Assistant pour qu'il s'exécute pendant plusieurs jours ou semaines afin d'enregistrer des données sur vos ordinateurs. Ceci permet à l'outil d'identifier automatiquement les pics d'utilisation à partir d'un plus grand jeu de données.
En utilisant les informations de vos inventaires précédents, accédez aux fonctions de tri et de filtrage d'Excel pour créer une liste des ordinateurs que vous aimeriez surveiller. L'Assistant Performance Metrics Wizard acceptera cette liste sous la forme d'un fichier brut, avec un nom d'ordinateur par ligne. Copiez la liste des noms d'ordinateurs depuis Excel dans un nouveau fichier texte vide dans le Bloc-notes et enregistrez-le. Lorsque vous y êtes invité, importez ce fichier dans l'Assistant et définissez l'heure de fin de la période de recueil des mesures de performances. L'Assistant entrera en mode de collecte de données et rassemblera toutes les cinq minutes des compteurs de performances des ordinateurs spécifiés.
Lorsque l'Assistant Performance Metrics Wizard se termine, il crée un rapport Excel détaillé répertoriant tous les ordinateurs observés et toutes les mesures de performances pour les différentes catégories d'utilisation : UC, disque physique, disque logique et réseau. Grâce à ces informations, vous pouvez peaufiner votre liste de candidats à prendre en considération pour la virtualisation.
Vous pouvez cibler des ordinateurs avec faible taux d'utilisation et envisager de consolider plusieurs d'entre eux comme ordinateurs virtuels (VM) sur un hôte unique ou combiner ces informations avec les données d'inventaire pour trouver les ordinateurs qui possèdent des services stratégiques nécessitant une haute disponibilité. La virtualisation peut être utilisée pour fournir des capacités de récupération après incident améliorées pour les environnements à haute disponibilité. Une fois votre analyse effectuée, vous pouvez passer à l'étape finale de création de recommandations de sélection élective d'ordinateurs virtuels.

Recommandations de sélection élective de serveur
L'Assistant Server Virtualization and Consolidation Wizard vous permet de spécifier la configuration d'un éventuel ordinateur hôte de virtualisation sur le plan de l'UC, du réseau, du sous-système de disque et de la mémoire. À l'aide des données de performances recueillies par l'Assistant Performance Metrics Wizard, l'Assistant Server Virtualization and Consolidation Wizard calcule un bon mappage des invités aux hôtes d'ordinateurs virtuels, en garantissant que chaque hôte est bien utilisé sans risquer une surutilisation lors des pointes d'utilisation.
Lorsque l'Assistant Server Virtualization and Consolidation Wizard se termine, il produit une feuille de calcul Excel détaillée avec un mappage suggéré des invités d'ordinateurs virtuels aux hôtes physiques. Pour chaque ordinateur virtuel et hôte, le rapport affiche les utilisations d'E/S disque, E/S réseau et UC prévues. Lorsque les ordinateurs virtuels invités sont ajoutés aux ordinateurs hôtes durant le processus d'adaptation, de nouveaux ordinateurs hôtes sont alloués lorsque les hôtes précédents ont atteint leur capacité. Pour chaque nouvel hôte, un message est affiché indiquant pourquoi un nouvel hôte a dû être alloué.
Si plusieurs de vos hôtes reçoivent le même message, il peut être souhaitable de réexécuter l'Assistant Placement Wizard avec une configuration d'hôte différente pour essayer d'augmenter le nombre d'invités affectés à chaque hôte. Par exemple, si plusieurs de vos hôtes affichent le message indiquant qu'ils ont atteint la limite de mémoire, vous pourriez essayer de réexécuter l'Assistant et spécifier une plus grande quantité de mémoire RAM pour la configuration d'hôte. Ceci devrait augmenter le nombre d'invités pouvant être affectés à chaque hôte.

Configuration d'ordinateur virtuel
Chaque page de l'Assistant Server Virtualization and Consolidation Wizard vous permet de configurer un composant majeur de la configuration de l'ordinateur hypothétique qui sera utilisé pour modéliser la capacité de l'ordinateur hôte de l'ordinateur virtuel. Des modèles sont fournis pour Virtual Server 2005 R2 et Hyper-V et il vous sera demandé de choisir la technologie de virtualisation à utiliser sur la première page de l'Assistant (voir figure 5).
Figure 5 Sélection de la technologie de virtualisation à utiliser pour les recommandations de sélection élective (cliquez sur l'image pour l'agrandir)
Des modèles pour plusieurs familles d'UC AMD comme Intel sont fournis sur la page de configuration de l'UC. Si aucun modèle n'est disponible pour votre UC, choisissez le modèle qui s'en rapproche le plus. Vous pouvez configurer sur cette page le nombre de processeurs physiques, de noyaux et d'hyperthreads par noyau. Notez que si vous choisissez Hyper-V pour votre plate-forme de virtualisation, vous pourrez uniquement choisir parmi les UC 64 bits (voir figure 6).
Figure 6 Configuration d'UC hôte (cliquez sur l'image pour l'agrandir)
La troisième page de l'Assistant vous permet de configurer un sous-système disque en termes de nombre de lecteurs de disque et de technologie RAID pour calculer l'espace disque total disponible sur l'hôte ainsi que la valeur du débit du sous-système disque. La valeur du débit est fournie automatiquement en fonction de la technologie d'interface et de la vitesse RPM (Reliability and Performance Monitor) choisie.
Dans MAP Toolkit 3.1, aucune prise en charge directe des solutions de disque de Réseau de zone de stockage (SAN) et de Stockage à connexion réseau (NAS) n'est fournie. Pour une approximation, choisissez la technologie de disque SCSI et configurez un niveau RAID similaire à votre configuration SAN, avec des disques de vitesse similaire. Cette approximation doit être suffisamment proche pour vous aider à effectuer votre planification d'initiale.

Contraintes de sélection élective
Lorsque les ordinateurs virtualisés invités sont mappés aux hôtes physiques, six facteurs sont pris en considération pour évaluer si un invité trouvera ou non place dans les capacités restantes d'un ordinateur hôte :
  • Utilisation d'UC
  • Utilisation du réseau
  • Utilisation du sous-système d'E/S disque
  • Mémoire
  • Espace disque
  • Prise en charge du système d'exploitation d'invité sur la technologie de virtualisation spécifiée
Les utilisations d'UC, de réseau et de sous-système de disque sont relativement simples. Les utilisations mesurées sur le candidat invité de virtualisation physique sont converties en une utilisation équivalente sur l'ordinateur hôte de virtualisation, ajoutée ensuite à l'utilisation existante de l'hôte. Si le total d'utilisation résultant de tous les invités affectés à cet hôte pour cette ressource est inférieur au seuil limite, l'invité est alors affecté à l'hôte. Si ce n'est pas le cas, l'invité n'est pas placé et d'autres invités sont essayés afin de voir si l'un d'entre eux peut correspondre.
Par exemple, supposez que vous ayez rassemblé les mesures de performances d'un ordinateur avec une UC Pentium 4 1,2 GHz dont l'utilisation relevée est de 32 %. Si vous configurez un hôte de virtualisation avec une UC Intel Xeon 5300 quadricœur, l'utilisation d'UC mesurée de l'ordinateur invité d'origine sera extrapolée en une utilisation prévue équivalente sur l'ordinateur hôte. Cette nouvelle utilisation sera inférieure à la valeur mesurée à l'origine, en raison de l'architecture plus récente d'UC, de la vitesse d'horloge d'UC différente et de l'ajout de noyaux supplémentaires.
Réciproquement, si vous avez configuré un ordinateur hôte avec une UC moins puissante que celle de l'invité, l'utilisation prévue sera plus élevée une fois extrapolé à l'hôte. Dans chacun des cas, la nouvelle utilisation de l'UC extrapolée sera utilisée pour calculer l'utilisation générale de l'ordinateur hôte lorsque des invités lui sont affectés.
Il est utile d'aborder brièvement la manière dont l'utilisation de la mémoire et celle de l'espace disque sont calculées. La quantité totale de mémoire physique installée sur chaque invité de virtualisation potentiel est réservée sur l'ordinateur hôte. Une petite quantité de mémoire (512 Mo) est réservée par ailleurs pour l'hôte. Lorsque la mémoire totale sur l'hôte est épuisée en raison de l'affectation des invités plus la charge représentée par l'hôte, plus aucun invité de virtualisation ne peut être placé sur cet ordinateur hôte.
L'espace disque est géré de manière similaire : La quantité totale d'espace disque physique installée sur chaque invité de virtualisation potentiel est réservée sur l'ordinateur hôte. 50 Go d'espace disque sont par ailleurs réservés pour l'utilisation de l'hôte de virtualisation. Une fois que l'utilisation totale de disque de tous les invités affectés à l'hôte plus l'espace réservé pour l'hôte lui-même atteint la taille spécifiée dans la configuration de l'hôte, plus aucun invité ne peut être affecté.
En fonction de la plate-forme de virtualisation choisie, des vérifications seront effectuées pour garantir que le système d'exploitation s'exécutant sur l'ordinateur invité est bien pris en charge par la plate-forme de virtualisation. Par exemple, les systèmes d'exploitation 64 bits ne sont pas pris en charge comme invités sur Virtual Server 2005 R2, et ils ne seront donc pas placés si vous choisissez cette technologie de virtualisation.

Étude des possibilités
En exécutant plusieurs fois l'Assistant Server Virtualization and Consolidation Wizard, il est facile de comparer les résultats des différents choix de matériel pour l'ordinateur hôte de virtualisation. Chaque fois que vous exécutez l'Assistant, vous pouvez choisir des options d'UC, de disque et de mémoire différentes pour trouver la solution qui sera la meilleure pour votre environnement.
Faites attention à la colonne Last Placement Failed Reason de l'onglet Consolidation Recommendations du classeur Excel de consolidation des serveurs. Ces raisons vous donneront des indices quant aux raisons pour lesquelles aucun ordinateur supplémentaire n'a pu être placé sur un hôte particulier. Si la même raison apparaît pour plusieurs hôtes, comme une utilisation de mémoire d'invité dépassant la mémoire disponible sur l'hôte, l'augmentation de la quantité de mémoire de la configuration de l'hôte peut réduire le nombre total d'hôtes nécessaires.

Configuration requise
L'un des avantages de MAP Toolkit 3.1 est qu'il ne nécessite pas d'installation de logiciel sur les ordinateurs inventoriés. Toutes les opérations sont effectuées à distance. Cependant, il existe quelques facteurs devant être pris en compte pour que tout fonctionne correctement.
Pour que l'Assistant Inventory Wizard et l'Assistant Performance Metrics Wizard puissent effectuer leur travail, quelques ports TCP doivent être ouverts sur l'ordinateur cible et être accessibles depuis l'ordinateur sur lequel MAP Toolkit est installé. Le guide de mise en route détaille ces exigences. En bref, les ports d'authentification, DCOM et WMI doivent être ouverts sur les ordinateurs inventoriés. Si des pare-feu sont installés sur le réseau entre l'ordinateur exécutant MAP Toolkit 3.1 et les cibles de l'inventaire, ces pare-feu doivent également être configurés pour autoriser la transmission de ce trafic.
MAP Toolkit 3.1 a été conçu pour les environnements d'inventaire comptant jusqu'à 100 000 ordinateurs et pour recueillir des mesures de performances pour un maximum de 3 000 ordinateurs à la fois. Par défaut, cet outil installera une instance privée de SQL Server 2005 Express Edition. En raison de la taille limite de 4 Go pour les fichiers de base de données dans SQL Server Express, cette configuration vous permet d'effectuer seulement l'inventaire d'à peu près 20 000 ordinateurs avant d'atteindre la taille de fichier limite définie par SQL Server Express. Pour travailler avec plus d'ordinateurs pendant l'inventaire, certains paramètres par défaut doivent être modifiés.
Pour travailler dans de plus grands environnements, vous devrez utiliser une version complète de SQL Server, telle que SQL Server 2005 Standard Edition. Avant de pouvoir installer MAP Toolkit, installez une nouvelle instance de SQL Server 2005 et nommez-la « MAPS ». Exécutez ensuite normalement le programme d'installation de MAP Toolkit sur le même ordinateur. MAP Toolkit nécessite une instance locale de SQL Server, et le programme d'installation détectera automatiquement une instance « MAPS » locale du serveur de base de données et s'installera dans celle-ci, au lieu d'installer SQL Server Express Edition.
Pour les environnements encore plus grands, vous pouvez utiliser la fonctionnalité d'évolution horizontale, qui permet à de multiples ordinateurs assistants sur lesquels MAP Toolkit est installé d'exécuter un grand inventaire en coopération et de stocker toutes les données rassemblées dans une base de données centrale unique. Cette configuration nécessite également l'utilisation de SQL Server Standard Edition pour éviter la taille maximale de fichier de 4 Go.
Reportez-vous au guide de mise en route (Getting Started) pour plus de détails sur la manière d'installer cet outil dans cette configuration et de modifier les chaînes de connexion de base de données de manière appropriée pour ce mode. La fonctionnalité d'évolution horizontale peut également être utilisée pour placer SQL Server sur un ordinateur différent de celui sur lequel est installé MAP Toolkit.

Conclusion
Les accélérateurs de solutions tels que Microsoft Assessment and Planning Toolkit ont pour but d'effectuer tout le travail lourd de vos projets informatiques afin que n'ayez pas à le faire. MAP Toolkit a économisé à de nombreux utilisateurs des centaines d'heures de planification informatique pour les déploiements d'Hyper-V. Êtes-vous prêt à l'essayer ?
Si c'est le cas, vous pouvez télécharger gratuitement Microsoft Assessment and Planning Toolkit sur microsoft.com/map ou vous procurer d'autres accélérateurs de solutions sur microsoft.com/vsa. Nous vous encourageons également à visiter le blog de l'équipe MAP Toolkit sur blogs.technet.com/mapblog pour trouver plus de conseils et consulter les vidéos de démonstration.

Jay Sauls est responsable de programme senior dans le groupe Solution Accelerators de Microsoft, où il a travaillé à la conception et la mise en œuvre d'outils tels que Windows Vista Hardware Assessment et Microsoft Assessment and Planning Toolkit. Auparavant, Jay a travaillé dans d'autres équipes produit de Microsoft, dont Microsoft Commerce Server, Microsoft BizTalk et System Center Capacity Planner.

Baldwin Ng est responsable de produit senior pour l'équipe Microsoft Solution Accelerators Core Engineering. Ses projets actuels incluent Microsoft Assessment and Planning Toolkit et Virtualization Solution Accelerators. Baldwin a plus de 16 années d'expérience du développement et de la gestion de produit dans l'informatique, le commerce électronique et les services Internet sans fil, chez Microsoft, Corbis et Alltel. Il blogue fréquemment sur blogs.technet.com/MAPBLOG.


Le mot du rédacteur en chef Un monde virtualisé
Joshua Hoffman

La virtualisation n'a rien de nouveau. Ce n'est sans doute pas la façon la plus enthousiaste de démarrer l'article de ce mois-ci, mais c'est vrai. Le concept de virtualisation (séparant un système d'exploitation des ressources matérielles sous-jacentes) existe depuis environ 1967, avec l'introduction du système d'exploitation CP/CMS d'IBM. Pourtant, bien que le concept soit bien établi, beaucoup de choses ont changé au cours des 40 dernières années.
En 2008, nous atteignons un point de basculement dans la virtualisation informatique. Alors que la nécessité d'une réduction des coûts, d'une simplification de la gestion et de l'établissement de pratiques informatiques viables a convergé avec des processeurs plus puissants multicœurs et une nouvelle technologie d'hyperviseur, il est temps pour la virtualisation de passer au premier plan. C'est à ce sujet que se consacre ce numéro de TechNet Magazine. Vous y trouverez des articles détaillant la toute nouvelle plate-forme Hyper-V dans Windows Server 2008, des outils pour gérer un environnement virtuel, des techniques pour déployer des applications virtuelles et bien plus encore.
Sur une note plus personnelle, je souhaite exprimer toute la gratitude du personnel entier de TechNet Magazine aux contributeurs Greg Stemp et Jean Ross, les célèbres scripteurs Microsoft. Vous serez sans doute surpris d'apprendre que les scripteurs Microsoft ne sont pas, en fait, des types en blouses blanches avec de grosses têtes courant dans les couloirs de Microsoft avec une éprouvette dans une main et un script dans l'autre. En fait, ces trois dernières années, Greg et Jean ont rédigé la rubrique Hé, vous le scripteur ! de TechNet Magazine qui leur a valu une renommée mondiale. Hé, vous le scripteur ! est non seulement la rubrique la plus populaire que nous publions, mais elle a remporté des récompenses et reçu le plus grand nombre d'acclamations et de courriers électroniques de lecteurs.
C'est pour toutes ces raisons et beaucoup plus (notamment le fait que nous les aimons beaucoup) que nous sommes très tristes, ici à TechNet Magazine, de dire au revoir à Greg et Jean ce mois-ci. Hélas, comme cela arrivera aux meilleurs d'entre nous, Greg et Jean vont découvrir de nouveaux horizons. Heureusement, ils continueront à errer dans les couloirs de Redmond, dispensant leur talent aux utilisateurs de Microsoft. Nous leur souhaitons donc bonne chance et nous espérons qu'ils nous feront l'honneur de réapparaître dans nos pages un jour.
En attendant, Dean Tsaltas, un ancien étudiant scripteur, a gentiment accepté de reprendre le flambeau de Hé, vous le scripteur ! pour le moment tandis que nous recherchons la prochaine génération de scripteurs. Dean nous rejoindra le mois prochain pour sonder les profondeurs de Windows Management Instrumentation. Ne la manquez sous aucun prétexte ! —Joshua Hoffman

Merci aux experts techniques Microsoft suivants : Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace et Jim Truher.


Lettres Les lecteurs ont la parole

Administration de base de données SQL
Chapeau pour votre article « SQL Server : Astuces pour une maintenance de base de données efficace » du numéro d'août 2008 (disponible sur technet.microsoft.com/magazine/cc671165). Enfin un article de la section SQL s'adressant à nous « administrateurs de base de données involontaires » qui devons seulement nous assurer qu'une certaine application nommée SQL Server s'exécute et est sauvegardée.
Sur la page suivante, vous avez poursuivi par « Administration de Windows : Prenez le pouls de votre serveur » (technet.microsoft.com/magazine/cc718984). C'était génial. J'ai déchiré ces articles du magazine pour les conserver, chose que nous ne pouvons pas faire avec les magazines électroniques. Je me réfèrerai fréquemment à ces deux articles. Continuez comme ça.
Nous sommes heureux de savoir que vous avez apprécié ces deux articles. Il est toujours agréable d'apprendre que nos articles sont utiles. Nous ne refuserons jamais des louanges expansives, ne vous arrêtez pas là ! N'hésitez pas à nous envoyer quelques mots sur les autres sujets abordés dans les numéros à venir. Nous souhaitons toujours recevoir les commentaires de nos lecteurs.
—Joshua Hoffman, rédacteur en chef

ImageX et Windows PE
Merci pour votre article sur le déploiement d'anciens systèmes d'exploitation avec ImageX et Windows PE (« Double amorçage avec Windows XP et Windows PE 2.0 » de février 2008, technet.microsoft.com/magazine/cc194422). J'avais découvert le potentiel de ces outils l'an dernier et ai commencé à essayer ceux-ci pour remplacer l'outil de création d'images qu'utilise mon entreprise (Acronis Snap Deploy). J'ai réussi à tout faire fonctionner comme je le voulais il y a environ six mois et il s'agit maintenant du seul outil de création d'images que nous utilisons.
J'ai par la suite lu votre article et ai remarqué votre conseil sur l'ajout de l'option bootsect.exe /n52. Je n'avais jamais entendu parler de cette option auparavant. La seule chose que nous faisons avant d'appliquer les images est de nettoyer le disque dur en utilisant DiskPart avec le script inclus (commands.txt). Nous n'avons pas rencontré de problème pour l'instant, mais ceci pourrait-il représenter un problème à l'avenir ?
Au tout début, cette commande était nécessaire. Mais j'ai été informé par un membre de notre équipe après la publication de cet article qu'elle n'est plus nécessaire, car le code de démarrage contient maintenant une logique faisant en sorte qu'il essaie de trouver le code de gestionnaire de démarrage de style nouveau et, s'il n'est pas trouvé, il essaie NTLDR avant d'échouer. Par conséquent, elle peut être omise sans problème.
—Wes Miller, chroniqueur, Histoires de Bureau

Environnement d'images de test
J'ai lu un article de votre rubrique Histoires de bureau concernant l'implémentation d'images à l'aide de l'outil ImageX et l'activation de la multidiffusion avec les services de déploiement Windows (Windows Deployment Services) ou WDS (« Double amorçage avec Windows XP et Windows PE 2.0 »). Je souhaite monter un environnement de test et aimerais connaître les outils nécessaires. Dois-je installer Windows Server 2008 pour mettre en œuvre une multidiffusion ? Par ailleurs, pour les images en miroir, est-il nécessaire d'utiliser ImageX pour l'installation du Déploiement 4 ou le Kit d’installation automatisée (Windows AIK) et WDS ?
Pour utiliser la multidiffusion avec WDS, Windows Server 2008 doit être installé. Les composants de multidiffusion ne sont pas disponibles (et ne seront pas disponibles) pour Windows Server 2003.
Le déploiement 4 n'est pas nécessaire pour utiliser la multidiffusion. Pour l'utiliser, vous devez vous procurer Windows Server 2008, ainsi que la version publiée du WAIK pour Windows Server 2008. Cette version du WAIK est la première à contenir les éléments nécessaires à la multidiffusion vers Windows PE.
—Wes Miller

Multidiffusion WDS
J'ai essayé d'utiliser ImageX pour cloner des images vers et depuis des ordinateurs. J'ai rapidement fait face à un problème : ImageX ne prend pas en charge les transmissions de multidiffusion. Je veux effectuer la même opération à l'aide de serveurs WDS avec transmissions de multidiffusion. Est-ce possible ? Il semble que la commande Wdsmcast puisse faire l'affaire. Comment un client WDS peut-il informer un serveur WDS de l'image qu'il doit télécharger ?
C'est exact, ImageX ne peut pas en soi gérer la multidiffusion. Vous devez utiliser Wdsmcast (dans Windows Server 2008 WAIK) pour spécifier la transmission à laquelle se connecter (une fois qu'elles ont été démarrées sur le serveur). Le livre blanc « Utilisation du serveur de transport » contient des informations utiles sur la connexion avec Wdsmcast (technet.microsoft.com/library/cc725964). Consultez la section « Comment connecter un serveur client à un espace de noms avec Wdsmcast.exe ».
—Wes Miller

Nous contacter Vous avez quelque chose à dire ? Envoyez-nous un message électronique à tnmag@microsoft.com ou visitez notre blog à l'adresse blogs.technet.com/tnmag.


Boîte à outils Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Tous les prix ont été confirmés le 19 août 2008 et sont sujets à modification. Les opinions exprimées dans cet article sont celles de l'auteur et ne reflètent pas nécessairement les opinions de Microsoft.

Emportez vos applications avec vous
PortableApps.com
PortableApps.com
En tant que professionnel de l'informatique, vous passez probablement souvent d'un ordinateur à l'autre. Ce faisant, vous regrettez probablement de ne pas avoir vos propres applications, outils et documents à portée de main. L'une des façons de répondre à ces besoins consiste à démarrer avec une plate-forme de lancement comme celle proposée par PortableApps.com. Sur son site, vous trouverez la Plate-forme PortableApps.com gratuite et Open Source, de même que plusieurs applications portables qui peuvent s'exécuter uniquement à partir d'un lecteur flash USB, d'une carte mémoire, d'un disque dur portable ou d'un lecteur de musique numérique.
Vous y trouverez également une Suite PortableApps.com. Ce téléchargement pratique inclut un lot d'applications portables et la plate-forme de base, le tout dans un programme d'installation unique. Il existe deux versions de la suite. Suite Light inclut Mozilla Firefox, Thunderbird et Sunbird avec l'antivirus ClamWin, Pidgin pour la messagerie instantanée, le lecteur de PDF Sumatra, le gestionnaire de mot de passe KeePass, l'application de traitement de texte AbiWord, un lecteur audio et quelques jeux simples. Suite Standard inclut toutes ces applications ainsi que la suite office OpenOffice.org qui comprend Writer, Calc, Impress, Base et Draw.
Par ailleurs, il existe d'autres applications Open Source qui ont été rendues « portables » sur le site, en l'occurrence FileZilla pour FTP, PuTTY pour telnet et SSH, WinSCP pour SFTP et SCP, PNotes et Task Coach pour les listes rapides, 7-Zip pour l'archivage, une invite de commande, Eraser pour le nettoyage des fichiers, InfraRecorder pour la gravure de CD/DVD, WinDirStat pour la visualisation du contenu d'un disque, winMd5Sum pour la vérification de fichiers et WinMerge pour les différences de répertoires et de fichiers. (Les lecteurs de ma chronique Boîte à outils ont peut-être remarqué que j'ai traité plusieurs de ces applications dans de précédents articles).
Il y a également une communauté d'utilisateurs très active qui travaille sur des versions portables d'utilitaires réseau tels que WinPCap et Wireshark. (Ces deux outils peuvent vous aider énormément dans vos tâches d'administration et de dépannage). Les forums proposent même un endroit dédié aux suggestions d'applications à rendre portables.
Ces applications sont autonomes et se trouvent sur le périphérique de stockage que vous utilisez. Si elles écrivent dans le Registre ou nécessitent un accès « hors-disque », elles doivent tout renvoyer à l'état pré-exécution à la sortie. En outre, vous pouvez exécuter les applications sans la plate-forme PortableApps.com ; en effet, ces applications sont encapsulées dans leurs propres programmes d'installation spécialement à cet effet. Cela mis à part, vous aurez probablement besoin des fonctionnalités de la plate-forme, et la Suite est un point de départ idéal pour commencer un environnement personnalisé que vous pouvez transporter avec vous.
La plate-forme PortableApps.com est configurée pour l'exécution automatique. Ainsi, lorsque vous insérez votre lecteur Flash USB ou portable dans l'ordinateur hôte Windows, vous obtenez l'option qui vous permet d'exécuter l'application de la plate-forme. Une fois que vous lancez la plate-forme, une icône de barre d'état système s'affiche. En cliquant sur cette icône, vous affichez un menu qui ressemble au menu Démarrer de Windows. Ce lanceur d'application fournit des liens rapides vers toutes vos applications portables ainsi que des liens les dossiers de votre lecteur portable, un indicateur montrant la quantité d'espace disponible sur votre lecteur, un utilitaire de sauvegarde des documents se trouvant sur le lecteur, un outil de recherche et un lien qui vous aidera à installer les nouvelle applications portables. Vous pouvez personnaliser cette interface et choisir une langue d'interface parmi les plus de 30 langues disponibles.
Après vous être familiarisé avec la plate-forme, vous serez peut-être curieux de savoir comment modifier une application pour la rendre portable. Le site Web et son forum de développement d'applications portables vous aideront à le faire. Tout compte fait, il s'agit d'un très chouette jeu d'outils dans un package portable.

Prix : Gratuit.
PortableApps vous permet d'emporter vos outils avec vous

Dépannage de systèmes distants
TeamViewer
teamviewer.com
Qu'il s'agisse de rechercher les pannes dans des applications, de présenter des démonstrations de produits et des didacticiels ou tout simplement d'essayer de comprendre la question d'un utilisateur, rien ne vaut de s'asseoir devant l'ordinateur en question. Toutefois, dans la pratique, cette option n'est pas souvent possible. Dans ce cas, il existe une autre solution, celle qui consiste à utiliser un outil qui vous permettra « d'être là » sans y être physiquement présent. TeamViewer, de TeamViewer GmbH, vous aidera à réussir ce tour de magie.
Cet utilitaire est doté d'un processus d'installation simple qui vous permet de vous connecter rapidement à une machine distante. TeamViewer prend en charge quatre principaux modes d'opération : Le mode de support distant qui vous permet de contrôler l'ordinateur distant et d'effectuer ainsi votre dépannage, d'aider l'utilisateur dans les opérations de fonctionnement et de maintenance et de le guider tout au long d'une activité. Le mode de présentation qui vous permet d'afficher votre bureau sur le système de l'utilisateur distant afin de démontrer une activité ou de donner une présentation. Le mode de transfert de fichiers qui vous permet de transférer des fichiers entre les deux ordinateurs sans réellement partager les bureaux. Et enfin, le mode VPN qui vous permet de créer un réseau privé virtuel immédiat entre vous et l'ordinateur hôte (ce mode utilise l'option d'installation de l'adaptateur VPN de TeamViewer).
Sur le plan de la sécurité, l'application utilise un échange de clés RSA et le chiffrement de session AES 256 bits. L'échange de clés vous garantit qu'aucun « intermédiaire » entre vous et l'utilisateur (y compris les serveurs de routage de TeamViewer) ne pourra intercepter le flux de données. Par ailleurs, lorsque vous vous connectez à une session Supporter (Supporter est le terme utilisé pour décrire la personne hébergeant la session), un ID de session et un mot de passe sont créés et l'utilisateur distant doit les entrer afin de pouvoir se connecter. Au cas où vous souhaiteriez vous connecter à un ordinateur qui n'est pas soumis à contrôle humain (par exemple, pour gérer vos serveurs), vous pouvez installer TeamViewer comme service système afin de pouvoir continuer à transférer aisément des fichiers, utiliser les fonctionnalités de contrôle à distance, créer un VPN ou même redémarrer l'ordinateur distant.
Le module QuickSupport de TeamViewer (ou module client) est une autre fonctionnalité intéressante, particulièrement si vous envisagez d'utiliser l'application pour le support ou les présentations. Il s'agit d'un exécutable relativement petit dont l'exécution ne nécessite pas d'installation de logiciel ou de droits d'installation sur l'ordinateur distant. L'utilisateur final devra simplement double-cliquer sur le fichier exe et entrer l'ID de session et le mot de passe et vous pourrez alors connecter votre session à l'ordinateur.
TeamViewer est doté d'options de configuration très utiles. Vous pouvez optimiser le nombre de couleurs partagées sur le périphérique d'affichage, supprimer le papier peint distant de l'affichage ou choisir de garder Windows Vista Aero Glass activé. En outre, vous pouvez ajuster le paramètre qualité/vitesse général à votre guise. Par ailleurs, vous pouvez choisir d'autoriser diverses fonctionnalités, notamment le contrôle à distance, le transfert de fichiers, les connexions VPN, les entrées de clavier et souris à distance, le transfert du contrôle entre l'hôte local et l'hôte distant et l'affichage de l'écran distant.
Vous pouvez enregistrer des sessions à des fins d'audit ou pour une lecture ultérieure. Et si vous ne voulez pas passer par les serveurs de TeamViewer, en raison peut-être de votre configuration de sécurité, vous pouvez faire en sorte que TeamViewer n'utilise que les connexions au réseau local pour se router.
L'édition Premium, qui prend en charge un nombre illimité d'installations Supporter, inclut également une édition Portable que vous pouvez mettre sur un CD ou sur un lecteur flash USB et emporter avec vous. L'édition Premium inclut également TeamViewer Manager qui enregistre les détails des sessions et vous permet d'enregistrer les détails des partenaires. Ces deux fonctionnalités sont très pratiques pour le suivi, l'envoi de rapports et la facturation de vos clients. TeamViewer est également disponible pour Mac OS X et prend en charge l'accès multiplates-formes, ce qui vous permet de rester sur votre ordinateur Windows tout en vous connectant à un ordinateur MAC.

Prix : Gratuit pour une utilisation non commerciale. Édition Business : à partir de 699 USD pour une seule installation Supporter. Édition Premium : 1 399 USD pour un nombre illimité d'installations Supporter.
Connexion à un système distant avec TeamViewer

Critique
End-to-End Network Security: Defense-in-Depth
La sécurité réseau d'aujourd'hui intègre plusieurs couches de technologies proactives afin de réduire l'exposition aux incidents et de limiter les risques d'infraction provenant de l'intérieur ou de l'extérieur de l'infrastructure réseau. End-to-End Network Security: Defense-in-Depth (Cisco Press, 2007) d'Omar Santos vous aidera à faire face aux complexités sans cesse croissantes liées à la défense votre réseau.
Pour des raisons évidentes, ce livre fait l'éloge des produits Cisco, mais il n'en fournit pas moins bon nombre d'informations d'ordre général sur la sécurité, ce qui en fait une excellente référence pour tout professionnel réseau ou administrateur système s'intéressant à la sécurité de l'infrastructure.
Le livre commence par une présentation des technologies de sécurité réseau, des pare-feu et VPN aux systèmes de détection et de prévention des intrusions et de gestion des identités. Il décrit ensuite une méthodologie de contrôle des incidents de sécurité à six étapes : préparation, identification (des menaces de sécurité), classification (des menaces de sécurité), vérification, réaction et compte-rendu.
Le livre considère ensuite une infrastructure de sécurité proactive qui utilise une variété de périphériques et d'outils, notamment IDS/IPS, NAC, AAA, SNMP, Syslog et les VLAN. Par la suite, il examine la méthode de défense approfondie de Cisco, se penche sur les réseaux sans fil, la téléphonie IP, la sécurité des centres de données et essentiellement sur la sécurité IPv6 puisqu'elle concerne les solutions Cisco pour les domaines de sécurité réseau. Le livre se termine par trois études de cas qui abordent des solutions de sécurité conçues pour des petites, moyennes et grandes entreprises réelles.

Prix : 49,50 USD (vente directe).

Analyse des ID de périphériques
PCIDatabase.com
PCIDatabase.com
Vous est-il jamais arrivé de mettre à niveau un système, de vous retrouver avec un ou deux périphériques inconnus dont les descriptions ne vous donnent aucune indication autre que « Périphérique PCI » et de vous demander comment diable obtenir un pilote ou identifier le périphérique sans arracher le couvercle de votre ordinateur et utiliser une lampe de poche pour y voir plus clair ? Ou peut-être avez-vous essayé d'identifier le chipset sous-jacent d'un périphérique connu ? Figurez-vous qu'il existe un service gratuit qui peut vous aider dans ce genre de tâches : PCIDatabase.com !
Cette base de données utilisateur vous permet d'effectuer des recherches par noms de fournisseurs et ID de périphériques pour trouver plus d'informations. Il vous suffit d'ouvrir le Gestionnaire de périphériques, de cliquer avec le bouton droit sur le périphérique en question et de sélectionner Propriétés, de choisir l'onglet Détails puis de sélectionner la propriété ID de matériel. Vous verrez une série de chaînes contenant quelques valeurs hexadécimales précédées de « VEN_ » (fournisseur) et « DEV_ » (périphérique).
Le site propose des liens vers plusieurs ressources qui vous aideront à découvrir s'il existe des pilotes pour le périphérique qui vous intéresse (bien sûr, n'oubliez pas de consulter aussi le site Web du fabricant).
Autre fonctionnalité très intéressante que vous trouverez à PCIDatabase.com : si vous recherchez un fournisseur particulier, vous obtenez une page comprenant l'adresse du siège, les numéros de téléphone, les sites Web applicables, les contacts, l'ID hexadécimal du fournisseur pour les périphériques PCI et une liste de tous les périphériques du fournisseur que le site connaît. Et puisque le site propose un support offert par les utilisateurs, il vous encourage également à y ajouter vos propres connaissances.

Prix : Gratuit.
Obtenez des informations sur les fournisseurs et les périphériques sur PCIDatabase.com (Cliquez sur l'image pour l'agrandir)

Logiciel d'audit et d'inventaire
CCS Network Inventory
crowcanyon.com
La possibilité de savoir ce qui est installé sur les ordinateurs clients sans avoir à quitter votre bureau peut vous faire gagner beaucoup de temps. Et n'oubliez pas que le suivi des actifs fait partie de vos responsabilités. Crow Canyon Systems peut vous aider à faire tout cela grâce à sa solution CCS Network Inventory.
Cette application est un outil d'inventaire et d'audit sans agent qui analyse les postes de travail de votre réseau LAN, en recueillant des informations sur le matériel, le logiciel, le service et les données utilisateur. Comme CCS Network Inventory n'utilise pas d'agent distant, votre contexte d'exécution a besoin de RPC, du service Explorateur d'ordinateurs, du service Registre distant, du partage de fichiers et d'imprimantes et de l'accès partagé aux ordinateurs que vous souhaitez inventorier (tout comme la plupart des autres produits d'inventaire sans agent).
L'application vous permet d'utiliser d'autres informations d'identification pour ses requêtes, ce qui est utile lorsque votre analyse recouvre plusieurs domaines. Après avoir installé l'application, vous pouvez analyser une plage d'adresses IP, utiliser la découverte Windows Network, importer une liste d'ordinateurs ou spécifier manuellement une liste de postes de travail Windows à inventorier.
Le travail d'audit de CCS Network Inventory consiste principalement à recueillir des informations sur les logiciels : quelles applications sont installées, quels correctifs ont été appliqués, quel système d'exploitation et quel Service Pack sont installés sur l'ordinateur et même quelles polices sont installées. En termes de configuration de l'ordinateur, vous pouvez voir les services et autres processus qui sont exécutés, les dossiers qui sont partagés, les mappages de lecteurs, les variables d'environnement, les comptes utilisateur, les tâches planifiées, les commandes de démarrage et les protocoles réseau exécutés. Et en ce qui concerne le matériel, vous pouvez voir les détails des moniteurs connectés, des imprimantes, des disques durs (ainsi que leurs tailles et leurs partitions), des lecteurs de CD et DVD, des processeurs, de la mémoire, etc. Vous pouvez en outre configurer des analyses personnalisées pour les valeurs de Registre, les nombres de fichiers (par exemple, qui a le plus de mp3) et l'espace libre sur les lecteurs.
Toutes ces informations sont stockées dans la base de données personnalisée de l'application et peuvent être ensuite utilisées pour créer des rapports. CCS Network Inventory fournit un certain nombre de rapports prédéfinis servant à visualiser et transporter les données utilisées pour l'audit et les rapports. Si les informations des rapports prédéfinis et des requêtes n'incluent pas tout ce dont vous avez besoin, vous pouvez utiliser l'outil SQL Query Builder intégré pour écrire et exécuter une requête plus détaillée ou spécifique sur les données.
Il est généralement conseillé de prendre régulièrement des instantanés de l'environnement pour voir les modifications. CCS Network Inventory vous permet de voir ces modifications en comparant deux instances des bases de données d'informations. Par exemple, vous pouvez comparer l'analyse actuelle à une analyse prise il y a un an pour voir combien de postes de travail sont passés à Windows Vista, combien d'entre eux ont bénéficié d'une mise à jour de leurs composants matériels au cours de l'année dernière ou quels utilisateurs ont continué à exécuter des logiciels non pris en charge après qu'ils en aient été avertis.
Au moment où nous rédigeons cet article, CCS Network Inventory ne prend pas entièrement en charge Windows Server 2008, mais il prend en charge les autres versions de Windows jusqu'à Windows Vista.

Prix : À partir de 235 USD pour jusqu'à 25 nœuds.
Gestions d'actifs distants avec CCS Network Inventory

Écrire à Boîte à outils Si vous souhaitez voir votre outil ou utilitaire préféré figurer dans l’un de nos articles, veuillez écrire à l’auteur à l’adresse tntools@microsoft.com.

Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste. Il est constamment à la recherche d’outils innovants destinés à faciliter les opérations, l'assurance qualité et le développement pour les professionnels de l’informatique.


Forum aux questions SQL Journaux de transactions de taille importante, conditions d'utilisation de Repair et bien plus encore
Paul S. Randal

Q J'ai remarqué un comportement étrange des sauvegardes que j'espère que vous pourrez expliquer. De temps à autres, nous sauvegardons notre base de données de production de 62 Go pour actualiser les données utilisées par nos développeurs d'applications. Nous supprimons toujours l'ancienne copie avant de restaurer la nouvelle. La copie restaurée possède la même taille que la base de données de production et les données semblent identiques, mais le processus de restauration est beaucoup plus long que le processus de sauvegarde. Que se passe-t-il ? Pourquoi la restauration prend-elle beaucoup plus de temps que la sauvegarde ?
R Il n'y a vraiment rien d'étrange. En fonction des circonstances, il s'agit généralement du comportement prévu. La différence de temps requise par une sauvegarde par rapport à une restauration provient des étapes que chaque processus doit exécuter.
La sauvegarde d'une base de données comprend deux étapes. Elle effectue essentiellement des E/S de lecture de la base de données et des E/S d'écriture sur le périphérique de sauvegarde :
Étape de sauvegarde 1 Lire toutes les données allouées depuis les fichiers de données et les écrire sur le périphérique de sauvegarde.
Étape de sauvegarde 2 Lire un journal des transactions et l'écrire sur le périphérique de sauvegarde.
La taille exacte de journaux des transactions nécessaire peut varier grandement, mais il s'agit essentiellement de la taille requise pour pouvoir récupérer la base de données restaurée à un moment déterminé. (J'ai donné une explication plus approfondie de ceci dans un message de blog à l'adresse sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx.)
Restaurer une base de données, d'autre part, peut comprendre jusqu'à quatre étapes. Le travail impliqué est en outre plus compliqué que de simples E/S de lecture et écriture :
Étape de restauration 1 Si les fichiers de base de données n'existent pas, créez-les.
Étape de restauration 2 Lire toutes les données et le journal des transactions à partir de la sauvegarde et les écrire dans les fichiers de base de données correspondants.
Étape de restauration 3 Exécuter la phase REDO de la récupération sur le journal des transactions.
Étape de restauration 4 Exécuter la phase UNDO de la récupération sur le journal des transactions.
Le temps total écoulé pour les deux étapes de la sauvegarde doit être à peu près identique au temps requis pour l'étape de restauration 2 (en supposant qu'elle dispose de matériel similaire et d'un serveur sans activité utilisateur). L'étape 1 de la restauration peut être longue si les fichiers de données sont de taille importante et doivent être remis à zéro (ce qui est le comportement de SQL Server 2000 et le comportement par défaut de SQL Server 2005).
Pour empêcher ceci, ne supprimez pas les fichiers existants avant de démarrer la restauration. Vous pouvez également activer l'initialisation instantanée afin que les fichiers soient créés très rapidement (vous trouverez plus d'informations à ce sujet à l'adresse msdn.microsoft.com/library/ms175935.aspx).
Les étapes 3 et 4 de la restauration exécutent la récupération de la base de données restaurée pour la rendre cohérente du point de vue des transactions. Il s'agit du processus qu'une base de données traverserait également pendant la récupération après incident. La durée nécessaire à cette récupération dépendra de la taille du journal des transactions devant être traitée. Par exemple, si une transaction de longue durée était active au moment auquel a été effectuée la sauvegarde, tout le journal des transactions pour cette transaction est dans la sauvegarde et doit être restauré.

Q J'essaie de choisir entre l'envoi de journaux et la mise en miroir de base de données pour fournir une copie redondante de notre base de données de production. Je m'inquiète de la taille du journal des transactions qui devra être envoyée entre les serveurs, en particulier pour les opérations de reconstruction d'index que nous effectuons chaque nuit. J'ai entendu dire que la mise en miroir envoie les commandes de reconstruction au lieu du journal des transactions et que la reconstruction est effectuée sur le miroir. Est-ce vrai ? Ceci devrait faire de la mise en miroir une solution meilleure que l'envoi de journaux avec le modèle de récupération BULK_LOGGED, n'est-ce pas ?
R Ce que vous avez entendu dire n'est pas vrai. La mise en miroir de base de données s'effectue en envoyant les véritables enregistrements de journal des transactions de la base de données principale vers le serveur de miroir, où ils sont « réeffectués » dans la base de données de miroir. Aucune traduction et aucun filtrage de type quelconque n'interviennent, pas plus qu'un type quelconque d'interception de commandes T-SQL pour une base de données en miroir.
La mise en miroir de base de données prend uniquement en charge le modèle de récupération FULL (complet), ce qui signifie qu'une opération de reconstruction d'index sera toujours entièrement enregistrée dans le journal. En fonction de la taille des index concernés, ceci pourrait signifier qu'une quantité significative de journal des transactions est produite et provoquer à son tour un gros fichier journal sur la base de données principale et une bande passante de réseau substantielle pour envoyer les enregistrements de journal au miroir.
Vous pouvez considérer la mise en miroir de base de données comme un envoi en temps réel de journaux (ce qui en fait était le nom utilisé pour cette fonctionnalité très tôt durant le développement de SQL Server 2005). Avec l'envoi de journaux, les sauvegardes du journal des transactions de la base de données principale sont périodiquement expédiées au serveur secondaire et restaurées sur la base de données secondaire.
L'envoi de journaux prend en charge les modèles de récupération FULL et BULK_LOGGED. Pour une opération de reconstruction d'index dans une base de données à envoi de journaux avec modèle de récupération FULL, la quantité de journal des transactions produite sera identique à celle produite pour une base de données mise en miroir. Cependant, dans le scénario de base de données avec envoi de journaux, les données sont envoyées à la base de données redondante dans une sauvegarde de journal (ou un ensemble de sauvegardes de journal) au lieu d'un flux continu.
Si le modèle de récupération BULK_LOGGED est utilisé dans la base de données à envoi de journaux pendant que l'index est reconstruit, seule une taille minimale de journal des transactions sera produite. Cependant, la sauvegarde suivante du journal des transactions contiendra également toutes les étendues de fichier de données qui ont été modifiées par l'opération de reconstruction d'index à enregistrement minimum dans le journal. Ceci signifie que les sauvegardes de journal couvrant la reconstruction d'index dans le modèle de récupération BULK_LOGGED auront presque exactement la même taille que ceux couvrant la reconstruction d'index dans le modèle de récupération FULL.
Par conséquent, la quantité d'informations nécessitant d'être envoyée à la base de données redondante est presque exactement la même pour un index reconstruit sur une base de données en miroir et sur une base de données à envoi de journaux. La véritable différence réside dans la manière dont les informations sont envoyées : en continu ou par lots.
Il existe de nombreux autres facteurs à prendre en compte pour le choix parmi ces deux approches (beaucoup trop de facteurs pour les aborder dans un seul article du Forum aux questions SQL). Vous devez observer dans quelle mesure ces facteurs correspondent à vos exigences (comme la limite de perte de données acceptable et le temps d'indisponibilité admissible) avant de prendre une décision.

Q J'exécute SQL Server 2005 et l'une de mes bases de données possède un journal des transactions qui n'arrête pas de grossir. La base de données est en mode de récupération complet et j'effectue des sauvegardes de journal des transactions. Je pensais que ceci devait empêcher le journal des transactions de grossir. Que se passe-t-il exactement ici ?
R Vous avez raison, la prise de sauvegardes de journal des transactions en mode de récupération complet est essentielle. Cependant, il existe d'autres facteurs qui peuvent contribuer à la croissance du journal des transactions. Cela dépend entièrement de ce qui fait que le journal des transactions est nécessaire (ou actif). Les autres facteurs courants (mis à part un manque de sauvegardes de journal des transactions) qui peuvent provoquer votre problème incluent la réplication, la mise en miroir de base de données et une transaction active.
La réplication effectue une lecture asynchrone de vos enregistrements de journal des transactions et charge ensuite les transactions à répliquer dans une base de données de distribution séparée. Tous les enregistrements de journal des transactions qui n'ont pas encore été lus par la tâche de lecteur de journal de réplication ne peuvent pas être libérés. Si votre charge de travail produit beaucoup d'enregistrements de journal des transactions et que vous avez défini un intervalle important pour la fréquence d'exécution du lecteur de journal de réplication, de nombreux enregistrements peuvent s'accumuler et provoquer l'augmentation de la taille du journal des transactions.
Si vous exécutez une mise en miroir de base de données asynchrone, il peut exister une accumulation des enregistrements de journal des transactions qui n'ont pas été envoyés de la base de données principale au miroir (qui ont appelé la file d'attente SEND de mise en miroir de base de données). Les enregistrements de journal des transactions ne peuvent pas être libérés tant qu'ils n'ont pas réussi à être envoyés. Avec un taux élevé de génération d'enregistrements de journal des transactions et une bande passante limitée sur le réseau (ou d'autres problèmes de matériel), l'accumulation peut grossir énormément et provoquer une augmentation de la taille du journal des transactions.
Pour terminer, si un utilisateur démarre une transaction explicite (comme l'utilisation d'une instruction BEGIN TRAN) et effectue ensuite une modification (telle qu'une instruction DDL ou une action d'insertion/mise à jour/suppression), les enregistrements de journal des transactions générés doivent être conservés jusqu'à ce que l'utilisateur valide ou restaure la transaction. Ceci signifie que tous les enregistrements de journal des transactions suivants produits par les autres transactions ne peuvent pas non plus être libérés, car le journal des transactions ne peut pas être libéré de manière sélective. Si cet utilisateur, par exemple, rentre chez lui après sa journée de travail sans terminer la transaction, le journal des transactions continue à grossir car de plus en plus d'enregistrements de journaux des transactions sont générés sans pouvoir être libérés.
Vous pouvez découvrir pourquoi le journal des transactions ne peut pas être libéré en interrogeant la vue de catalogue de système sys.databases et en examinant la colonne log_reuse_wait_desc comme ceci :
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
Si la raison s'avère être une transaction active, vous pouvez utiliser l'instruction DBCC OPENTRAN pour obtenir plus d'informations sur la transaction :
DBCC OPENTRAN ('dbname')

Q J'ai entendu dire que REPAIR_ALLOW_DATA_LOSS devrait uniquement être utilisé en dernier recours pour une récupération après altération. La restauration depuis les sauvegardes devrait être utilisée à sa place. Pouvez-vous m'expliquer pourquoi Repair pour SQL Server 2005 ne devrait pas être utilisé et pourquoi il est inclus dans le produit, considérant à quel point il est « dangereux » ?
R Pour commencer, j'ai en fait écrit Repair pour SQL Server 2005. Le problème avec REPAIR_ALLOW_DATA_LOSS (que j'appellerai simplement Repair à partir de maintenant) est que son fonctionnement n'est pas clair. Le nom de l'option Repair a été choisi pour indiquer que son exécution peut mener à une perte de données de la base de données. La manière dont la fonctionnalité répare habituellement une structure de base de données endommagée consiste à supprimer la structure endommagée et à corriger ensuite la base de données qui a référencé ou était référencée par la structure supprimée. Repair est véritablement prévu pour être une méthode de dernier recours pour rendre la base de données cohérente. Il n'a pas pour objectif essentiel de sauvegarder les données de l'utilisateur. Repair ne s'efforce pas de supprimer les données de l'utilisateur, mais il ne s'efforce pas non plus de les enregistrer.
Ceci peut sembler être une méthode irresponsable pour la conduite des réparations, mais lorsque Repair nécessite d'être utilisé, il offre la méthode la plus rapide et la plus fiable de réparation de l'altération. La vitesse a une importance essentielle dans une situation de récupération après incident et l'exactitude est absolument nécessaire. Il est presque impossible de créer des algorithmes de réparation plus complexes pouvant en toute certitude fonctionner rapidement et correctement dans tous les cas. Il existe certains algorithmes complexes dans le code de réparation pour résoudre par exemple le problème se posant lorsque la même page ou étendue est allouée à deux index, mais l'algorithme se compose essentiellement de Repair plus quelques corrections.
Il existe cependant certains problèmes avec Repair dont vous devez être conscient :
  • Repair ne prend pas en compte les contraintes de clé étrangère lors de la suppression des structures endommagées et peut donc supprimer des enregistrements d'une table possédant une relation de clé étrangère avec une autre table. Il n'existe aucun moyen de déterminer si ceci s'est produit sans exécuter DBCC CHECKCONSTRAINTS après avoir exécuté Repair.
  • Repair ne prend pas en compte (et n'a pas la possibilité de le faire) la logique métier inhérente ou les relations de données définies au niveau de l'application qui pourraient être mises en défaut par la suppression de certaines données. Encore une fois, il n'existe aucune possibilité de déterminer si quoi que ce soit est en défaut, à moins d'exécuter la vérification de cohérence personnalisée intégrée à l'application.
  • Certaines opérations de Repair ne peuvent pas être répliquées. L'exécution de Repair sur une topologie à distributeur ou pair à pair peut introduire des incohérences dans la topologie, ce qui doit être corrigé manuellement.
Pour ces raisons, il est toujours judicieux d'effectuer une récupération après altération en utilisant une sauvegarde au lieu d'exécuter Repair. Repair est toutefois proposé dans le produit car il est toujours possible de se retrouver dans une situation dans laquelle la base de données est endommagée, il n'existe aucune sauvegarde et vous devez trouver un moyen de remettre en ligne la base de données rapidement.

Q Je viens juste de commencer dans une nouvelle société en tant qu'administrateur de bases de données et j'ai la responsabilité de plusieurs applications et de leurs bases de données principales. L'une des applications offre de très mauvaises performances durant les mises à jour. J'ai fait une enquête et j'ai découvert que les tables utilisées par l'application possèdent chacune un nombre important d'index. Après m'être renseigné autour de moi, il semble que l'ancien administrateur de base de données avait l'habitude d'ajouter un index à chaque colonne de table, plus certaines combinaisons. J'ai du mal à croire que tous ces index sont nécessaires. Comment déterminer ceux que je peux abandonner sans incident ? Nous utilisons SQL Server 2005.
R Le nombre important d'index est sans doute le facteur ayant la plus grande responsabilité dans la médiocrité des performances, comme vous l'avez déduit. Chaque fois qu'une ligne est insérée, mise à jour ou supprimée de la table, des opérations correspondantes doivent être effectuées dans chaque index non mis en cluster. Ceci ajoute une charge importante en termes d'E/S, d'utilisation d'UC et de génération du journal des transactions.
Dans SQL Server 2000, le seul moyen de déterminer les index qui étaient utilisés était d'utiliser le profilage et d'examiner les diagrammes de requêtes. Il existe une nouvelle vue dans SQL Server 2005, la vue de gestion dynamique (DMV), qui effectue un suivi de l'utilisation des index : sys.dm_db_index_usage_stats.
Cette vue effectue un suivi de chaque utilisation d'index (et de la manière dont il a été utilisé) depuis que la base de données dont il fait partie a démarré. Les statistiques de toutes les bases de données sont perdues lorsque SQL Server est arrêté et les statistiques de chaque base de données sont perdues lorsque cette base de données est fermée ou détachée. Le principe de cette manipulation est que, si un index n'apparaît pas dans le résultat, il n'a pas été utilisé depuis le démarrage de la base de données.
Une approche simple de suivi de l'utilisation des index consiste à effectuer des instantanés périodiques du résultat de la vue DMV et de comparer les instantanés. Ce que de nombreuses personnes négligent est qu'il faut effectuer un suivi de l'utilisation des index au cours d'un cycle d'activité complet. Si vous avez uniquement pris un instantané pour une seule journée, vous trouverez peut-être plusieurs index non utilisés. Mais si ces index sont utilisés, imaginons, pour permettre une exécution beaucoup plus rapide des rapports de fin de mois, ils ne devraient probablement pas être supprimés. Si un index n'a véritablement pas été utilisé au cours d'un cycle d'activité complet, vous pouvez alors probablement l'abandonner, récupérer l'espace et améliorer les performances.
Pour obtenir un code simple que vous pouvez utiliser pour prendre des instantanés périodiques du DMV, consultez mon article de blog à l'adresse sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx.

Paul S. Randal est directeur général de SQLskills.COM et MVP SQL Server. Paul a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Expert de la récupération après incident, de la haute disponibilité et de la maintenance de base de données, Paul présente fréquemment des conférences. Vous trouverez son blog à l'adresse SQLskills.com/blogs/paul.


Coup de projecteur sur les utilitaires Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen et Suveen Kumar Reddy Vuppala

Sommaire
Le cauchemar de la sécurité
En coulisses
Entretien de l'infrastructure
Utilisation de l'outil
À venir
Virtualiser une charge de travail informatique signifie simplement utiliser un ordinateur virtuel pour détacher la charge de travail du matériel sous-jacent. Les services informatiques modernes trouvent les ordinateurs virtuels utiles dans de nombreuses situations, notamment pour :
Déplacer les charges de travail Vous pouvez facilement utiliser les ordinateurs virtuels pour augmenter ou diminuer la bande passante de charge de travail de plusieurs installations, en fonction de l'évolution de votre demande de consommation, sans devoir réaliser la modification matérielle correspondante.
Développer et tester des applications Il est possible de créer plusieurs ordinateurs virtuels représentant chaque configuration qu'une application est supposée prendre en charge, sans avoir besoin d'un matériel dédié.
Mettre à niveau les logiciels Vous pouvez utiliser les ordinateurs virtuels pour mettre une nouvelle version d'un package logiciel en ligne lorsque vous mettez la précédente version hors ligne, tout cela sur le même matériel.
Distribuer les logiciels Les ordinateurs virtuels peuvent être utilisés comme unités de distribution pour une application métier ayant une combinaison cohérente de logiciels dans un package prétesté.

Le cauchemar de la sécurité
L'un des avantages de l'utilisation des ordinateurs virtuels réside dans le fait que vous pouvez les stocker dans un état hors connexion comme des images d'ordinateur virtuel. Ensuite, lorsque vous en avez besoin, vous pouvez « réveiller » ces ordinateurs virtuels et les déployer beaucoup plus rapidement que vous ne pourriez déployer le matériel équivalent.
Cependant, maintenir un nombre croissant d'environnements informatiques en attente hors connexion présente un défi en termes de maintenance. De nombreux mécanismes de mise à jour logicielle dépendent du fait que les systèmes sont en ligne pour vérifier les mises à jour ou les recevoir automatiquement.
Lorsqu'un ordinateur virtuel n'est pas en ligne, il ne s'agit que d'un fichier dans un ordinateur et, en conséquence, il ne peut pas interagir avec un mécanisme de mise à jour. Un ordinateur virtuel qui a été mis en ligne après avoir été hors connexion pendant quelques mois peut ainsi devenir une menace pour le réseau ou être menacé par le réseau.
Il ne s'agit pas simplement de manquer les mises à jour du système d'exploitation. Des profils de virus ou des applications obsolètes peuvent rendre l'ordinateur virtuel vulnérable ou non conforme aux normes de l'entreprise.
Pour aider les clients à relever le défi du maintien des ordinateurs virtuels hors connexion à jour, l'équipe Microsoft Solution Accelerator a créé Offline Virtual Machine Servicing Tool. Cet outil fonctionne avec System Center Configuration Manager (SCCM) 2007, Windows Server Update Services (WSUS) 3.0 et System Center Virtual Machine Manager (VMM) 2007 pour orchestrer la mise à jour des ordinateurs virtuels stockés. La figure 1 montre un rendu conceptuel de l'outil et comment il se connecte aux divers composants externes.
Figure 1 Fonctionnement de Offline Virtual Machine Servicing Tool (cliquez sur l'image pour l'agrandir)
Pour rendre les ordinateurs virtuels disponibles pour les mises à jour, l'outil utilise VMM pour les déployer temporairement sur des hôtes de maintenance. Comme une configuration d'hôte de maintenance possède généralement le processeur et la mémoire nécessaires pour exécuter plusieurs ordinateurs virtuels en même temps, l'outil peut gérer les ordinateurs virtuels par lots.
Aussitôt que les ordinateurs virtuels sont actifs sur les hôtes de maintenance, SCCM ou WSUS peut leur fournir les mises à jour nécessaires. Une fois les mises à jour appliquées, l'outil utilise VMM pour remettre les ordinateurs virtuels hors connexion. (Notez que l'outil prend uniquement en charge les ordinateurs virtuels gérés par VMM).

En coulisses
Offline Virtual Machine Servicing Tool utilise Windows Workflow Foundation (WF) pour orchestrer le processus de mise à jour d'un ordinateur virtuel. Le processus compte plusieurs étapes de décision : il commence par choisir le système de gestion des mises à jour approprié, sélectionne l'hôte de maintenance disponible suivant approprié pour l'ordinateur virtuel, s'assure que la mise à jour a eu lieu et, enfin, gère les exceptions.
L'utilisation d'une solution basée sur Windows WF a donné à l'équipe de développement une grande flexibilité pour modifier et faire évoluer le processus. Elle offre également aux utilisateurs une solution robuste pouvant être adaptée pour répondre à leurs besoins spécifiques ; aux jointures critiques du processus, des étapes pré- et post flux de travail intégrées permettent une certaine personnalisation.
L'outil utilise Windows PowerShell pour implémenter les tâches individuelles sous le niveau du flux de travail, ce qui correspond parfaitement à l'API Windows PowerShell proposée par VMM. Et l'interface utilisateur basée sur Microsoft .NET Framework ressemble aux produits System Center. Les nouveaux utilisateurs devraient ainsi se sentir en terrain connu.

Entretien de l'infrastructure
L'un des principes fondamentaux de l'entretien de l'infrastructure consiste à configurer la sécurité réseau pour protéger les ordinateurs virtuels pendant le processus de mise à jour. Dans la version 1.0 de l'outil, cet objectif est réalisé en utilisant un réseau privé virtuel (VPN) auquel VMM et le système de mise à jour approprié (WSUS ou SCCM) se connectent. L'infrastructure la plus appropriée pour une bibliothèque VMM est un réseau SAN (Storage Area Network) connecté à Fibre Channel, qui permet un transfert rapide d'images d'ordinateur virtuel aux hôtes de maintenance.
Tous les ordinateurs virtuels doivent faire partie du même domaine, c'est-à-dire un domaine qui utilise Active Directory et DNS. Des serveurs séparés peuvent être dédiés à VMM, WSUS, SCCM et à la bibliothèque VMM, mais des combinaisons de serveurs virtuels peuvent également être utilisées pour des environnements plus petits. Inutile de dire que les hôtes de maintenance doivent être des serveurs physiques.

Utilisation de l'outil
Après avoir configuré l'infrastructure d'entretien, vous devez vérifier que certains paramètres sont appropriés avant que l'outil puisse démarrer. Assurez-vous que VMM gère tous les ordinateurs virtuels appropriés, que le client de mise à jour approprié est installé sur chaque ordinateur virtuel et que les packages de mise à jour nécessaires sont configurés dans WSUS ou SCCM. Vous pouvez éventuellement vous assurer que les groupes d'hôtes de maintenance sont configurés dans VMM, mais ce n'est pas obligatoire.
Lorsque vous êtes prêt, démarrez Offline Virtual Machine Servicing Tool, qui comprend ses propres étapes de configuration. Vous devrez désigner le serveur VMM et le serveur WSUS ou SCCM approprié puis spécifier quel groupe d'hôtes de maintenance utiliser (si les hôtes de maintenance sont groupés) et quels hôtes de maintenance de ce groupe utiliser (voir la figure 2). Il est possible de configurer des groupes d'ordinateurs virtuels à gérer, mais c'est facultatif.
Figure 2 Configuration de Offline Virtual Machine Servicing Tool (cliquez sur l'image pour l'agrandir)
Après avoir configuré l'outil, créez les tâches d'entretien. Une tâche d'entretien contient toutes les informations que l'outil utilise pour gérer les ordinateurs virtuels spécifiques, y compris l'utilisation de WSUS ou de SCCM pour les mises à jour ; les emplacements du serveur VMM et du serveur WSUS ou SCCM ; les identités des ordinateurs virtuels à gérer ; le type (et l'identité, si approprié) du réseau à utiliser pour le processus ; les identités des hôtes de maintenance à utiliser ; les informations d'authentification de compte nécessaires pour accéder aux ordinateurs virtuels, au serveur VMM et au serveur WSUS ou SCCM ; et, enfin, la planification de l'exécution de la tâche d'entretien (exécution immédiate ou à une date et une heure spécifiques).
Si vous spécifiez une date et une heure pour la tâche d'entretien, le planificateur de tâches Windows détermine quand la démarrer. Pendant l'exécution de la tâche d'entretien, Offline Virtual Machine Servicing Tool suit la séquence suivante pour chaque ordinateur virtuel :
  • Sélectionner le prochain ordinateur virtuel dans la bibliothèque VMM.
  • Interroger VMM pour déterminer l'hôte de maintenance le plus approprié.
  • Déployer l'ordinateur virtuel sur l'hôte de maintenance.
  • S'assurer que l'ordinateur virtuel se connecte au bon réseau.
  • Démarrer l'ordinateur virtuel.
  • S'assurer que le client de mise à jour approprié est installé sur l'ordinateur virtuel.
  • Déclencher le processus de mise à jour.
  • Attendre la fin du processus de mise à jour.
  • Arrêter l'ordinateur virtuel.
  • Enregistrer l'ordinateur virtuel dans la bibliothèque VMM.
Le temps nécessaire pour mettre à jour une bibliothèque d'ordinateurs virtuels varie considérablement, en fonction du nombre et de la capacité des hôtes de maintenance, de la vitesse d'accès du stockage de la bibliothèque VMM et de la nature des mises à jour.
Notez que la version actuelle (1.0) d’Offline Virtual Machine Servicing Tool ne prend pas en charge la protection de l'accès réseau (NAP), qui est une façon vraiment intéressante de protéger du réseau les ordinateurs virtuels. De plus, elle ne prend pas en charge la technologie Hyper-V de Windows Server 2008, ni l'utilisation de Windows Server 2008 comme système d'exploitation client.
De nouvelles versions de SCCM, WSUS et VMM seront bientôt disponibles et une version 2.0 d’Offline Virtual Machine Servicing Tool les prendra en charge ainsi que Hyper-V et l'utilisation de Windows Server 2008 sur le client. L'outil prendra également en charge la NAP pour l'isolation de réseau. Vous pouvez télécharger Offline Virtual Machine Servicing Tool sur technet.microsoft.com/cc501231.

Peter SkjØtt Larsen est responsable produits senior chez Microsoft. Avant de rejoindre Microsoft, Peter travaillait dans l'architecture et le développement de systèmes logiciels opérationnels de télécommunications et la normalisation et le développement des services sans fil.
Suveen Kumar Reddy Vuppala est ingénieur de développement logiciel senior chez Microsoft. Ces sept dernières années, il a travaillé à la conception et au développement de solutions de déploiement et d'outils de surveillance en temps réel pour Microsoft.


Windows PowerShell La puissance des profils
Don Jones

Sommaire
Shells, hôtes et profils
Vous utilisez votre profil ?
Créer une console personnalisée
Autres astuces de profils
Précautions d'utilisation des profils
Si vous lisez régulièrement cette rubrique, vous savez déjà que Windows PowerShell prend en charge un système de profils. Il s'agit essentiellement de scripts de shell, avec une extension de fichier .ps1, qui s'exécutent automatiquement lorsque le shell démarre. Ils offrent une excellente façon de définir par exemple des alias personnalisés. Vous pouvez faire en sorte que chaque fois que le shell s'exécute, le profil définisse automatiquement vos alias, en les rendant disponibles chaque fois que vous utilisez le shell.
Le shell définit quatre profils différents :
  • Un s'appliquant à tous les shells et tous les utilisateurs de l'ordinateur.
  • Un s'appliquant à tous les utilisateurs, mais uniquement au shell Microsoft PowerShell.
  • Un s'appliquant à l'utilisateur actuel et à tous les shells.
  • Un s'appliquant à l'utilisateur actuel et uniquement au shell Microsoft PowerShell.
Le concept de « tous les shells » peut porter quelque peu à confusion. Cette terminologie a pour origine certains concepts de développement des débuts de Windows PowerShell qui n'ont pas été véritablement inclus dans le produit final. Aujourd'hui, le terme « tous les hôtes » serait probablement plus approprié.

Vidéo
Don Jones vous démontre comment vous pouvez créer des profils pour personnaliser le shell de Windows PowerShell.

Shells, hôtes et profils
En fait, Windows PowerShell se compose d'un ensemble d'assemblys de Microsoft .NET Framework. J'aime faire référence à cette partie du shell comme au moteur de Windows PowerShell, car elle contient les fonctionnalités que vous considérez généralement comme étant Windows PowerShell. Il n'existe toutefois aucune méthode intégrée permettant aux humains d'interagir avec ce moteur. Pour que vous puissiez en fait utiliser le shell, le moteur doit être chargé par une application d'hébergement (ou hôte).
L'application powershell.exe que vous avez probablement l'habitude d'exécuter constitue un tel hôte. L'application gpowershell.exe incluse avec le CTP Windows PowerShell 2.0 constitue un autre hôte. Cette relation entre hôtes et shells n'est pas aussi simple que je l'ai décrite ici, mais mon explication simplifiée couvre le comportement que vous constatez.
Il est important de comprendre que si vous interagissez avec le shell via une interface de ligne de commande à base de texte, vous utilisez probablement l'hôte powershell.exe. Ceci est vrai même si vous avez lancé le shell en utilisant un raccourci installé par une autre application, comme Exchange Management Shell. Exchange Management Shell n'est pas un autre shell ou une autre application d'hébergement. Il s'agit simplement de l'hôte powershell.exe normal lancé en utilisant un raccourci qui spécifie un ensemble de composants logiciels enfichables et de scripts à précharger. Ces composants logiciels enfichables activent la fonctionnalité d'administration d'Exchange dans le shell. Vous utilisez toutefois toujours le même shell.
Les emplacements (sur Windows Vista) des profils pour l'hôte powershell.exe sont les suivants :
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Ceci correspond à tous les utilisateurs de l'ordinateur et tous les shells.
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Ceci correspond à tous les utilisateurs de l'ordinateur, mais seulement pour le shell Microsoft.PowerShell.
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Ceci correspond à l'utilisateur actuel seulement et à tous les shells.
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Ceci correspond à l'utilisateur actuel seulement et seulement au shell Microsoft.PowerShell.
Ces profils ne sont pas créés par défaut. Ils existent seulement si vous les créez.
Chaque application d'hébergement est responsable du chargement et de l'exécution du profil correct. Si une application particulière d'hébergement « décide » de ne pas charger de profils du tout, elle n'est pas obligée de le faire. L'exécution de profil n'est pas effectuée automatiquement par le moteur de Windows PowerShell.
La manière la plus facile de prendre note de tout ceci est de simplement ouvrir le shell, taper $profile et appuyer sur Entrée. Cela vous donnera le chemin complet que le shell tente d'utiliser pour ce que je considère comme le profil « principal » (qui est le profil par utilisateur et spécifique au shell). Vous pouvez ensuite créer ou modifier ce script et il s'exécutera chaque fois que le shell démarrera.

Utilisation de votre profil
L'une des utilisations courantes d'un profil consiste à définir des alias personnalisés, comme je l'ai suggéré précédemment. Vous pouvez également ajouter des PSDrives personnalisés (il s'agit essentiellement de lecteurs mappés qui existent entièrement au sein de Windows PowerShell). Une utilisation moins courante consiste à créer une sorte de super shell qui peut effectuer toute tâche d'administration dont vous pourriez avoir besoin, en fonction des logiciels que vous utilisez dans votre environnement. Pour expliquer véritablement le concept de super shell, je dois tout d'abord vous donner un peu d'informations d'arrière-plan.
Le groupe de produit de Microsoft qui crée Windows PowerShell est responsable de beaucoup d'autres technologies d'administration essentielles, dont Microsoft Management Console (MMC). MMC est une bonne analogie pour décrire comment fonctionne Windows PowerShell. Lorsque vous exécutez mmc.exe, vous démarrez avec une console vide qui ne vous est pas d'une grande utilité. Vous ajoutez des composants logiciels enfichables MMC pour créer une console fonctionnelle.
Une fois que votre console a été configurée de la façon dont vous le souhaitez, vous enregistrez la console dans un fichier avec une extension de fichier .msc. Ce fichier de console enregistré vous permet de recharger rapidement votre console personnalisée à tout moment.
Au lieu de créer des consoles MMC personnalisées, beaucoup d'administrateurs s'appuient sur les consoles qui sont installées avec les produits qu'ils administrent. Exchange Server, par exemple, crée une console qui contient seulement le composant logiciel enfichable Exchange Server. Utilisateurs et ordinateurs Active Directory est une autre console créée au préalable et qui contient un seul composant logiciel enfichable.
Windows PowerShell fonctionne de manière très similaire. L'icône Exchange Management Shell installée avec les outils d'administration d'Exchange Server 2007 est en fait un raccourci vers powershell.exe avec des instructions pour le chargement d'un fichier de console. Les fichiers de console de shell ont une extension de nom de fichier .psc1 et contiennent une liste de composants logiciels enfichables à précharger (tout comme un fichier .msc contient une liste de composants logiciels enfichables que MMC charge au préalable pour vous). Cependant, vous n'êtes pas limité à l'utilisation de ces consoles de shell créées au préalable. Vous pouvez créer une console personnalisée, tout comme vous pouvez le faire avec MMC et utiliser celle-ci pour accomplir toutes vos tâches d'administration. Les profils jouent un rôle essentiel pour rendre ceci possible.

Création d'une console personnalisée
Pour créer une console personnalisée, vous devez commencer par rechercher le nom complet de chaque composant logiciel enfichable avec lequel vous voulez travailler. Assurez-vous que tous les outils d'administration nécessaires sont installés sur votre ordinateur. Ensuite, dans Windows PowerShell, exécutez Get-PSSnapin –registered. Ceci répertoriera tous les composants logiciels enfichables disponibles et inscrits, sans être pour autant chargés. Créez ou modifiez ensuite le profil Windows PowerShell approprié. Ajoutez les commandes Add-PSSnapin pour charger chaque composant logiciel enfichable devant toujours être disponible. Ceci pourrait inclure des composants logiciels enfichables pour Exchange Server, des produits System Center et des composants logiciels enfichables de tiers, tels que PowerShell Community Extensions. Enregistrez ensuite votre profil (n'oubliez pas de signer numériquement le profil si votre stratégie d'exécution de PowerShell le nécessite) et fermez le shell. Rouvrez le shell et il chargera automatiquement tous les composants logiciels enfichables répertoriés dans votre profil.
Une autre technique consiste à charger tous vos composants logiciels enfichables dans le shell (en utilisant Add-PSSnapin et les noms des composants logiciels enfichables) et à exécuter ensuite Export-Console pour créer un fichier de console .psc1 contenant tous les composants logiciels enfichables que vous utilisez actuellement. Vous pouvez ensuite utiliser ce fichier de console .psc1 pour créer un nouveau raccourci Windows PowerShell spécifiant le paramètre PSConsolefile et votre fichier .psc1 personnalisé. Ce raccourci utiliserait alors votre console, en chargeant automatiquement tous les composants logiciels enfichables spécifiés.

Autres astuces de profils
J'utilise mon profil Windows PowerShell pour exécuter plusieurs autres tâches utiles chaque fois que le shell démarre. Voici ce qui se produit lorsque le shell démarre sur mon système :
  1. J'exécute Get-Credential à partir de mon compte d'administrateur de domaine, en enregistrant le résultat dans une variable nommée $cred. Ceci rend $cred disponible dans tout le shell. Je peux ensuite le passer au paramètre -credential de diverses applets de commande, telle que l'applet de commande Get-WmiObject. Puisque $cred contient le mot de passe, je peux utiliser ces applets de commande sans être invité à entrer un mot de passe.
  2. J'exécute Cd C:\ afin que le shell démarre dans la racine du lecteur C: de mon ordinateur.
  3. J'exécute New-Alias of Out-File pour créer un alias nommé « of ». J'effectue ceci pour pouvoir ensuite utiliser « of » au lieu de « Out-File ». J'utilise beaucoup cette méthode et posséder un alias court défini est très pratique.
J'essaie de créer une clé de test dans le lecteur HKLM: du shell, qui représente la partie HKEY_LOCAL_MACHINE du Registre. Si une erreur survient, je sais alors que le shell a été lancé sans privilèges élevés. J'ai habituellement besoin des privilèges élevés pour le travail que j'effectue et ceci est juste une façon rapide pour moi de savoir d'avance si je dispose de privilèges élevés avant de commencer une tâche importante.
Je définis une fonction personnalisée nommée Ping-Address acceptant un nom d'ordinateur ou une adresse IP et renvoyant une valeur True ou False, si un ping de l'ordinateur peut ou non être effectué. J'utilise beaucoup cette fonction dans mon travail. Comme elle est définie dans mon profil, elle est globalement disponible dans mon shell.

Applet de commande du mois : Get-WmiObject
Un observateur attentif aura remarqué que j'aborde une applet de commande que j'ai déjà présentée, mais je souhaite vous faire découvrir une petite surprise qu'elle propose. J'observe souvent les administrateurs essayant de récupérer des informations Windows Management Instrumentation (WMI) depuis de multiples ordinateurs dont les noms sont répertoriés dans un fichier texte, en utilisant cette technique :
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
Bien que cette technique fonctionne, vous n'avez pas vraiment besoin de celle-ci car Get-WmiObject peut accepter un tableau de noms d'ordinateurs pour le paramètre -computerName. Pour obtenir le même résultat, vous pouvez utiliser seulement ceci :
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Placer la commande Get-Content entre parenthèses force le shell à exécuter la commande et à placer les résultats (un tableau de noms d'ordinateur) dans le paramètre -computerName.
Précautions d'utilisation des profils
N'oubliez pas que powershell.exe n'est pas la seule application qui charge les profils de Microsoft.PowerShell ou all-shells. De nombreux environnements de développement intégré (IDE) fournissent la prise en charge de Windows PowerShell, dont PrimalScript de SAPIEN Technologies, PowerGUI de Quest Software, et PowerShell Plus de ShellTools, qui chargent également ces mêmes profils pour offrir une expérience équivalente à l'hôte powershell.exe.
Un gros profil chargeant de nombreux composants logiciels enfichables peut provoquer un démarrage plus lent de ces applications, car le moteur de Windows PowerShell doit exécuter de nombreuses instructions avant d'être prêt pour l'application d'hébergement. En fait, même powershell.exe peut nécessiter beaucoup de temps pour démarrer si vous avez un très gros script de profil à exécuter.
Les composants logiciels enfichables qui définissent des applets de commande avec les mêmes noms peuvent également provoquer des collisions. Par exemple, si deux composants logiciels enfichables définissent une applet de commande nommée Get-User, Windows PowerShell n'exécutera aucune des applets de commande jusqu'à ce que vous utilisiez le nom complet de l'applet de commande pour spécifier celle que vous voulez. Ce nom complet peut être très complexe, car les noms de composants logiciels enfichables peuvent être très longs. Lorsque je rencontre ce problème, je renonce d'ordinaire simplement à l'idée d'avoir ces deux composants logiciels enfichables chargés simultanément. Je charge plutôt seulement celui que j'utilise le plus dans mon profil et utilise alors un shell séparé et « neuf » lorsque j'ai besoin de charger et d'utiliser l'autre composant logiciel enfichable.
Les profils Windows PowerShell peuvent offrir une commodité supplémentaire substantielle au shell. Mais souvenez-vous que s'ils sont modifiés à des fins nuisibles par un logiciel malveillant, les profils peuvent également causer beaucoup de dégâts. Vous pouvez protéger votre profil en le signant numériquement et configurer Windows PowerShell pour qu'il utilise sa stratégie d'exécution AllSigned, ou modifier les autorisations de fichier de NTFS de vos profils (tous) pour que votre compte utilisateur normal ne puisse pas les modifier.

Don Jones est l'auteur de Windows PowerShell : TFM and VBScript, WMI, and ADSI Unleashed. Vous pouvez le contacter par l’intermédiaire du site Web PowerShellCommunity.org.


Hé, vous le scripteur ! Derniers mots célèbres
Les scripteurs Microsoft

Socrate, célèbre philosophe grec (mort en 399 av. J.-C., juste avant la naissance de notre Rédacteur en chef), est peut-être mieux connu pour la citation suivante : « Une vie sans examen ne vaut pas la peine d’être vécue ». La plupart des gens connaissent cette citation. Récemment, toutefois, les scripteurs ont découvert que Socrate n'avait jamais affirmé qu'« une vie sans examen ne vaut pas la peine d’être vécue ». Il s'avère en fait qu'un scribe du Moyen-Âge a mal traduit les paroles du philosophe il y a plusieurs centaines d'années. Voici ce que Socrate a réellement dit : « Un fichier XML sans examen ne vaut pas la peine d’être possédé ».
Voilà enfin une citation philosophique qui a du sens ! Le format XML est de plus en plus répandu ces jours-ci ; une recherche rapide effectuée sur l'un des ordinateurs de test des scripteurs a permis de découvrir plus de 500 fichiers XML utilisés par divers systèmes ou applications.
Inutile de dire que de grandes quantités de données très importantes sont maintenant stockées au format XML. Et c'est très bien. Sauf si ces données ne font l'objet d'aucun examen. Malheureusement, il en va souvent ainsi, ne serait-ce que pour la raison suivante : la plupart des gens ne savent absolument pas pas comment examiner un fichier XML. En particulier, ils n'ont aucune idée de la façon d'interroger et d'effectuer des recherches sur ce fichier XML.
Remarque : Au cas où vous ne connaîtriez pas bien vos philosophes grecs, Socrate aimait discuter de tout, mais il était plutôt partisan du moindre effort ; en fait, Xanthippe, sa femme, disait qu'il était « un bon à rien ». On comprend donc pourquoi les scripteurs ont un petit faible pour Socrate.
Bien sûr, certains d'entre vous diront : « Un instant ! Les scripteurs n'ont-ils pas déjà abordé le sujet de la recherche de fichiers XML dans un article précédent (« La chasse aux voitures... et le XML » à technet.microsoft.com/magazine/cc162506) ? Dans ce cas, pourquoi reviennent-ils sur ce sujet maintenant ? Les scripteurs sont-il si paresseux qu'ils sont prêts à écrire le même article plusieurs fois » ?
Eh bien, croyez-le ou non, nous sommes encore plus paresseux que cela ! Toutefois, ce n'est pas la raison principale pour laquelle nous revenons sur ce sujet. Dans notre article précédent, nous avons examiné l'utilisation d'un fichier XML structuré comme le code de la figure 1, où chaque valeur de propriété représente un seul nœud dans le fichier.
Figure 1 Fichier XML avec nœuds seulement
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
Toutefois, et comme nous l'on gentiment fait remarquer certaines personnes, ce n'est pas la seule façon de structurer les fichiers XML. Dans l'exemple précédent, chaque ordinateur du fichier a son propre nœud ; chacun de ces nœuds a à son tour plusieurs nœuds enfants (système d'exploitation, département et nom). Cependant, il est également possible de construire un fichier XML dans lequel les nœuds individuels n'ont pas de nœuds enfants ; au lieu de cela, des valeurs de propriété supplémentaires sont configurées en tant qu'attributs. Exactement comme le fichier de la figure 2 !
Figure 2 Fichier XML avec attributs
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
Cela pose-t-il un problème ? Eh bien, en fait, oui ! Le script que nous vous avons montré il y a longtemps, dans un vieux numéro, ne fonctionnera pas avec un fichier XML structuré comme à la figure 2. C'est tout simplement impossible ! Et ça, c'est un vrai problème parce qu'un grand nombre d'entre vous ont besoin de pouvoir lire ce type de fichier XML.
Il vous suffisait de le demander. Et aussi d'attendre un an et demi, le temps que nous nous attelions enfin à résoudre ce problème.
Avant de continuer, examinons notre fichier XML de plus près. Dans ce cas, nous avons un fichier avec un nœud principal appelé HARDWARE ; chaque ordinateur individuel existe en tant que nœud enfant de HARDWARE. En outre, chacun de ces nœuds a une paire d'attributs : os (utilisé pour stocker le nom du système d'exploitation installé sur l'ordinateur) et department (utilisé pour stocker le nom du service qui possède l'ordinateur).
Supposons, par exemple, que nous aimerions obtenir une liste de tous les ordinateurs qui exécutent Windows XP. Pouvons-nous le faire à l'aide d'un script ? Bien sûr que oui :
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Voyons ce que nous avons là. Pour commencer, nous créons une instance de l'objet Microsoft.XMLDOM ; comme son nom l'indique, il s'agit de l'objet qui nous permet d'utiliser les fichiers XML. Une fois que nous avons créé l'objet, nous définissons la propriété Async sur False ; cela dit au script que nous voulons charger le document d'une manière synchrone et non pas asynchrone. Pourquoi le script s'en soucie-t-il ? Pour être honnête, il n'en a probablement cure ; après tout, les scripts (comme les scripteurs) sont des objets inanimés.
Toutefois, vous devez vous en soucier, vous. Si nous chargions le document de manière asynchrone, le script continuerait à s'exécuter même si le document n'avait pas été entièrement chargé. Et cela n'irait pas du tout : imaginez les problèmes qui pourraient survenir si vous essayiez d'exécuter une tâche sur un document qui n'existe pas encore. Le chargement asynchrone d'un fichier XML garantit que le fichier sera entièrement chargé avant le démarrage du script.
Étrange coïncidence, nous en sommes maintenant au point où nous allons charger notre fichier XML, ce que nous faisons en appelant la méthode Load et en ouvrant le fichier C:\Scripts\HARDWARE.xml qui nous amène à cette ligne de code :
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
Nous utilisons ici la méthode SelectNodes pour interroger le fichier XML et indiquer au script les nœuds XML que nous voulons récupérer. Remarquez la syntaxe, qui, il est vrai, est un peu inhabituelle.
Pour commencer, nous devons spécifier le chemin dans le fichier XML. Notre fichier XML a un nœud de premier niveau appelé HARDWARE, suivi par une série de nœuds de deuxième niveau appelés COMPUTER. Chacun de ces nœuds de deuxième niveau représente un enregistrement unique dans notre fichier de données XML. C'est pourquoi notre requête selectNodes commence ainsi :
//HARDWARE/COMPUTER
À ce stade, nous rencontrons la construction suivante :
[@os='Windows XP']
Cette section de la requête est identique à une clause WHERE dans une requête SQL standard. Avec SQL, nous pourrions utiliser une requête de base de données identique à la suivante pour récupérer une liste de tous les ordinateurs exécutant le système d'exploitation Windows XP :
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
Avec la méthode SelectNodes nous faisons quelque chose de similaire : nous souhaitons récupérer une liste de tous les ordinateurs où l'attribut du système d'exploitation (@os) est égal à Windows XP, et pour indiquer qu'il s'agit d'une clause WHERE, nous incluons la clause toute entière entre crochets.
Remarque : ce type de requête est appelé requête XPath. Pour en savoir plus sur XPath, consultez l'article à l'adresse msdn.microsoft.com/library/ms256115.aspx.
Comme je le disais donc, c'est bizarre, mais ça marche. Mais qu'en serait-il si nous voulions obtenir une liste de tous les ordinateurs qui appartiennent au service Finances ? Ce n'est pas très compliqué : notre appel à selectNodes ressemblerait à ceci :
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
Là aussi, notre clause WHERE est incluse entre crochets, nous faisons précéder le nom d'attribut (department) de l'arobase (@) et nous indiquons la valeur qui nous intéresse.
Facile, non ?
Après avoir appelé la méthode selectNodes, nous pouvons renvoyer les noms d'ordinateur simplement en effectuant une boucle à travers la collection de valeurs renvoyées et en renvoyant la propriété Text, comme suit :
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Et qu'elle genre d'informations pourrions-nous recevoir ? À vrai dire, nous espérons recevoir des informations de ce type :
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
En d'autres termes, ce sont les noms de tous les ordinateurs qui exécutent toujours Windows XP qui sont renvoyés.
Notez que vous n'êtes pas obligé de ne renvoyer que le nom de l'ordinateur ; dans la mesure où le nom de l'ordinateur est la valeur par défaut de chaque nœud, c'est la valeur que nous recevons si nous référençons la propriété Text.
Nous pourrions également spécifier exactement les valeurs d'attribut que nous souhaitons récupérer. Par exemple, jetons un coup d'œil sur cette boucle For Each modifiée :
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
Comme vous le voyez, dans cette boucle, nous continuons à renvoyer la valeur de la propriété Text ; cependant, nous avons également ajouté cette ligne de code :
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
Dans ce cas, nous utilisons la méthode getNamedItem pour récupérer la valeur de l'attribut department ; nous renvoyons ensuite la propriété Text de cet attribut. Voilà comment nous pouvons spécifier les valeurs d'attribut que nous renvoyons (et ne renvoyons pas) à l'écran. (Remarquez aussi que nous avons ajouté une commande Wscript.Echo pour placer une ligne vide entre les enregistrements). À l'exécution ce script, nous devrions recevoir ce qui suit :
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
Et oui, vous pouvez écrire des requêtes plus complexes si vous le souhaitez. Par exemple, supposons que vous souhaitiez avoir une liste de tous les ordinateurs exécutant Windows XP ou Windows Vista. Dans SQL, vous obtenez cette liste en écrivant une requête OR. Et devinez un peu ? Vous faites exactement la même chose lorsque vous interrogez un fichier XML :
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
Vous voyez ce que nous venons de faire ici ? Dans une seule paire de crochets, nous avons fourni deux critères : @os='Windows XP' ou @os='Windows Vista'. C'est tout ce que nous devons faire, et nous obtiendrons ainsi un rapport qui ressemble à la figure 3.
Figure 3 Résultat de la requête OR
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
Si vous réexaminez le fichier XML, vous verrez que les ordinateurs exécutant Windows XP ou Windows Vista sont inclus dans la sortie ; les ordinateurs exécutant Windows Server 2003 ou Windows Server 2008 ne sont pas inclus dans la sortie, ce qui est tout à fait normal.
Vous avez une question ? Vous aimeriez écrire une requête plus limitée qui renvoie seulement les ordinateurs qui s'exécutent Windows XP et qui appartiennent au service Finances ? Comme vous l'avez peut-être deviné, c'est très facile : il vous suffit d'écrire une requête AND comme suit :
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
Vous recevez ainsi le jeu de données suivant :
atl-ws-002
Finance
Pourquoi y a-t-il seulement un élément dans notre rapport ? Exactement : c'est parce que le service Finances ne possède qu'un seul ordinateur qui exécute Windows XP.
Nous espérons que nous vous avons tous aidés à traiter ce type de fichier XML. S'il s'avère qu'il existe un autre type de fichier XML quelque part, hé bien, bonne chance !
Comme nous avons commencé cet article avec une citation célèbre, nous aimerions le conclure par une autre citation, celle de l'empereur Guillaume II, qui nous est chère à nous autres, scripteurs : « Par la présente, je renonce pour toujours au trône de Prusse et à celui de l'Allemagne impériale qui lui est associé. ».
Les scripts embrouillés du Dr. Scripto
Le défi mensuel qui teste non seulement votre capacité à résoudre des énigmes, mais également vos compétences d'écriture de scripts.

Octobre 2008 : VBScript Faites le plein
Pour résoudre cette énigme, il vous suffit de remplir chaque ligne avec le nom d'une fonction VBScript. Ensuite, remettez les lettres des carrés bleus dans l'ordre pour trouver un autre nom de fonction.

RÉPONSE :
Les scripts embrouillés du Dr. Scripto
Réponse : Octobre 2008 : VBScript Faites le plein

Les scripteurs—Greg Stemp et Jean Ross—travaillent pour Microsoft.


Histoires de Bureau Personnalisation des Services de déploiement Windows
Wes Miller

Sommaire
Remplacer ce que vous avez
Coup d'œil sur la pile
Programme de démarrage réseau
Fournisseur PXE WDS
Démon TFTP
Magasin de données de configuration de démarrage
Windows PE
Serveur de transport
Multidiffusion personnalisée
Conclusion
Cela fait trois mois que j'explore les Services de déploiement Windows (WDS) et leurs origines, suivies par une présentation, puis par un examen plus détaillé de certains sujets avancés tels que WDSUtil et la multidiffusion. Dans ce dernier article de la série, nous allons voir où et comment personnaliser et configurer WDS pour répondre aux besoins de votre organisation. La plupart des outils Microsoft sont conçus avec une certaine souplesse de configuration. Toutefois, c'est en les mettant à l'épreuve que vous découvrez si ces outils répondent effectivement à vos besoins ou si, comme c'est souvent le cas, ils doivent être légèrement adaptés à vos scénarios.

Remplacer ce que vous avez
Ces derniers temps, les lecteurs me posent souvent la question suivante : « Je possède x (une technologie de déploiement existante). Les services WDS sont-ils compatibles avec x et disposent-ils de fonctionnalités similaires » ? Avec l'obsolescence des services ADS (Automated Deployment Services), une question encore plus intéressante serait : « Comment puis-je effectuer un déploiement et une reconfiguration rapides de serveurs, et WDS peut-il le faire pour moi » ?
Bien que WDS n'ait pas été conçu comme un remplacement exact pour ADS et qu'il lui manque en fait quelques composants clés pour être considéré comme un vrai remplaçant, avec quelques efforts, vous pouvez utiliser WDS à la place d'ADS. De même, si certaines fonctions de WDS ne fonctionnent pas pour vous, vous verrez qu'un grand nombre de ses composants peuvent être remplacés, avec un niveau de complexité et d'ingénierie variable. Jetons un coup d'œil sur le déploiement via WDS et examinons les composants que vous pourriez vouloir personnaliser ainsi que la manière de le faire.

Coup d'œil sur la pile
La figure 1 illustre les composants dans le processus de déploiement de WDS. Chacune de ces étapes peut être personnalisée dans une certaine mesure. J'ai utilisé des couleurs différentes pour chaque étape afin de refléter ce que je crois être la complexité (généralement les compétences de développement) du processus de remplacement ou de personnalisation de cette étape. Plus le bleu est foncé, plus l'étape risque d'être difficile à personnaliser.
Figure 1 Complexité de la personnalisation de WDS
Le degré de complexité de la personnalisation de chaque étape, dépend, bien sûr, des compétences de votre équipe (développement ou script) et de votre connaissance de WDS, du format WIM (Windows Imaging Format), d'Active Directory ou de toute autre technologie que vous souhaitez intégrer, telle que SQL ou ADSI. Examinons chacune de ces étapes ; réfléchissez à la façon dont vous voudriez les personnaliser et les méthodes que vous utiliseriez.

Programme de démarrage réseau
Je doute que vous ayez besoin de créer des Programmes de démarrage réseau (NBP) personnalisés pour remplacer ceux qui existent sur WDS, mais il est possible que vous ayez à le faire. WDS inclut des NBP destinés à être utilisés avec des systèmes sans affichage (généralement les serveurs) ou des systèmes où vous pouvez ou non appeler F12, et ainsi de suite. Ces NBP sont préconfigurés dans Active Directory avec WDSUtil, ou vous pouvez remplacer Startrom.com par le NBP que vous voulez utiliser pour tous les systèmes qui ne sont pas préconfigurés (par exemple, si tous vos systèmes sont sans affichage ou si vous ne voulez jamais utiliser F12).
Malheureusement, les documents qui peuvent vous aider à créer votre propre NBP ne sont pas très nombreux (voir msdn.microsoft.com/library/bb870970.aspx pour plus d'informations). Un NBP est un tout petit exécutable de 16 bits comportant des restrictions sévères et nécessitant des connaissances de programmation spécifiques. Je recommande généralement l'utilisation des NBP existants qui sont fournis avec WDS, à moins que vous ne tentiez de satisfaire à une exigence bien particulière et ne disposiez d'une équipe de développement possédant les compétences appropriées.

Fournisseur PXE WDS
Avec les services d'installation à distance (RIS), les commentaires que nous recevions de nos clients nous faisaient souvent part de leur souhait d'utiliser un autre magasin de données qu'Active Directory pour leurs informations, notamment SQL Server. Avec WDS, la conception inclut une infrastructure enfichable pour les fournisseurs PXE (Pre-Boot eXecution Environment). Cela signifie que dans vos tâches de développement, vous pourriez utiliser un autre magasin de sauvegarde, en plus d'Active Directory, pour les informations sur PXE.
WDS comprend son propre fournisseur qui utilise Active Directory ; désormais, SCCM (System Center Configuration Manager) se connecte également à WDS et implémente son propre fournisseur. La documentation liée à l'écriture de votre propre fournisseur est rare, et les exemples de code ne sont pas faciles à trouver non plus (bien que le SDK Windows propose un peu de documentation et quelques exemples). Il s'agit donc d'une tâche plutôt complexe. À moins d'avoir des exigences bien particulières pour cet aspect du processus de démarrage, je vous conseille encore une fois de ne pas utiliser de fournisseur PXE personnalisé.

Démon TFTP
Il arrive parfois que les clients aient déjà investi dans leur propre démon TFTP (Trivial File Transfer Protocol) avant l'arrivée de WDS. Puisque les serveurs PXE ne fonctionnent pas bien ensemble, cela signifie souvent qu'il faut se contenter d'un seul serveur.
D'après mon expérience, les clients prennent généralement un démon TFTP existant, souvent un démon TFTP de type Linux, et lui font démarrer d'autres systèmes d'exploitation. Avec l'infrastructure RIS originale, vous ne pouviez pas le faire. Toutefois, avec l'avènement du démarrage RAMDisk, cette opération est devenue possible, et peut toujours être exécutée avec des images de démarrage de type WDS.
N'oubliez pas, cependant, que vous vous aventurez dans un domaine où Microsoft, n'assure aucun support technique, et qui peut causer des problèmes qui seront difficiles à diagnostiquer. En outre, avec le démon TFTP amélioré de WDS, il est possible que vous vous éloigniez des bonnes performances. Dans l'idéal, je vous conseille d'utiliser le démon TFTP de WDS existant et d'essayer d'utiliser les délais d'expiration de PXE, la préconfiguration et/ou les bords du réseau pour déterminer quel client démarre depuis quel serveur PXE au lieu d'essayer de forcer un serveur existant à s'ajuster à cette opération.

Magasin de données de configuration de démarrage
Avec RIS, il n'était jamais possible, au niveau du démarrage, de spécifier ce qui devrait être démarré ; il fallait toujours passer par l'Assistant de sélection du système d'exploitation (OSC) et sélectionner une option (installation, Windows PE ou autre). Comme WDS utilise un chargement complet pour lancer le réseau, il prend également en charge la personnalisation du magasin de données de configuration de démarrage (BCD) servi aux clients. Les données BCD par défaut de chaque architecture résident sous RemoteInstall\Boot\<arch>\Default.bcd, <arch> étant l'architecture spécifique du système démarré.
Vous pouvez personnaliser ces données BCD pour chaque client, et le client les utilisera pour démarrer. Vous pouvez, par exemple, configurer une entrée de BCD pour démarrer l'installation, une autre pour exécuter l'environnement WinRE (Windows Recovery Environment) et une autre pour exécuter un test de mémoire ; vous pouvez également configurer une entrée d'installation entièrement automatisée comme défaut et une entrée manuelle (ou expérience d'installation personnalisée) comme option sélectionnable par l'utilisateur. (Pour plus d'informations, consultez l'article « Comment modifier le magasin BCD à l'aide de Bcdedit » à l'adresse go.microsoft.com/fwlink/?LinkId=115267.)

Bien sûr, l'essentiel du travail de WDS intervient dans Windows PE ; par conséquent le réglage de Windows PE pour répondre à vos besoins spécifiques peut être un élément important pour un environnement personnalisé. Par défaut, WDS fournit un modèle d'installation très standard qui inclut l'environnement d'installation complet. Cette solution peut parfois ne pas être adaptée à vos besoins en matière de déploiement. Dans ce cas, vous pouvez créer votre propre image de démarrage Windows PE. Commençons par le début.
En plus d'utiliser les données BCD pour indiquer quelle image utiliser, vous pouvez spécifier cette image en personnalisant l'objet MAO (machine account object) d'un ordinateur dans Active Directory. Dans RIS, un attribut MAO spécifique stockait chaque élément (quels fichiers SIF Startrom et Unattend utiliser). Avec WDS, ils sont stockés en tant que paires nom-valeur sous l'entrée netBootMirrorDataFile. Par exemple, l'image de démarrage et le fichier Unattend qui doit être utilisé par un ordinateur donné sont stockés dans cette entrée. La forme des entrées est une liste de paires nom-valeur délimitée par des points-virgules. Les entrées servant à modifier l'image de démarrage et le fichier Unattend sont BootImage et UnattendFilePath, respectivement.
Bien sûr, vous pouvez choisir d'ignorer l'environnement d'installation existant et de créer le vôtre. Peut-être avez-vous besoin d'une plus grande souplesse de configuration, d'une automation plus poussée ou d'une génération automatisée par SQL Server. Vous souhaiterez peut-être faire ce que certains clients ont fait avec RIS et Windows PE et créer votre propre front-end pour l'installation. Quel que soit l'environnement d'installation que vous écrivez, vous devez réaliser les tâches suivantes :
  • Recueillir les informations propres à chaque utilisateur ou à chaque ordinateur. Ces informations peuvent provenir des entrées utilisateurs, de SQL Server ou d'un fichier texte, par exemple.
  • Copier et appliquer une image d'installation au système client. Cette tâche peut être accomplie en utilisant directement l'installation, en utilisant ImageX pour appliquer une image d'un partage réseau, ou à l'aide de la multidiffusion (copier tout simplement l'image et l'appliquer via ImageX).
  • Fournissez un fichier Unattend (tel qu'Unattend.xml ou sysprep.inf, en fonction de la version Windows déployée) pour terminer l'installation.
  • Automatisez toutes les étapes de migration post-installation que vous souhaitez effectuer (ou toute étape d'application de rôles dans le cas de Windows Server 2008).
ADS a lancé le concept de séquence de tâches qui permet d'attribuer des étapes répétables à un ou plusieurs ordinateurs. Étant donné qu'ADS n'était pas destiné à être utilisé avec Windows XP, vous ne pouviez pas l'utiliser pour déployer le système d'exploitation. Toutefois, les séquences de tâches ADS ne sont en fait que des scripts structurés, et vous pouvez effectuer les mêmes étapes en utilisant un processus d'installation personnalisé.
Je suis fan de Microsoft SQL Server depuis longtemps (depuis la sortie de SQL Server 6.5), donc mon instinct est de créer une telle structure en utilisant SQL. Pour cela, il faut bien sûr ajouter les fonctionnalités SQL à votre build de Windows PE. En outre, vous pourriez soit écrire votre propre GUI, application HTML (HTA) ou exécutable compilé, soit utiliser WSH (Windows Script Host) pour exécuter un environnement d'installation minimaliste à ligne de commande uniquement. HTA ou WSH doivent également être ajoutés à Windows PE pour pouvoir être utilisés.
Le degré de complexité de la conception de votre propre environnement d'installation dépend entièrement de vos compétences et de votre imagination. J'ai vu des systèmes tout à fait élégants qui ont été définis uniquement à l'aide de SQL et WSH ou HTA, compétences relativement faciles à acquérir. Il est très important, toutefois, de ne pas oublier les contraintes que j'ai mentionnées dans les articles précédents :
  • Windows PE n'est doté d'aucun sous-système Windows on Windows (WOW), si bien que vous devez compiler une fois pour chaque architecture que vous envisagez de prendre en charge.
  • Vous ne pouvez pas utiliser Visual Basic 6.0 si vous devez déployer via Windows PE x64 ou IA64.
  • Vous pouvez utiliser Visual Studio 2005 ou 2008 pour créer des applications, mais vous devez créer une application Visual C++ non gérée, vu qu'il n'existe aucune version Microsoft .NET Framework prise en charge sur Windows PE.
  • En outre, sans .NET Framework, vous ne pouvez pas utiliser Windows PowerShell pour l'automation.
Il va de soi que vous pouvez également utiliser un utilitaire d'imagerie tiers via WDS si vous voulez écrire votre propre environnement d'installation. Le format WIM et ImageX peuvent probablement répondre aux exigences de la plupart des scénarios de déploiement, mais votre outil d'imagerie existant peut lui-même répondre aux exigences de certains d'entre eux.
De même, certains scénarios peuvent nécessiter un partitionnement personnalisé, par exemple si vous déployez Windows Vista avec BitLocker, si vous créez des systèmes Windows XP et stockez les données de profil sur un deuxième volume, ou si vous déployez un système Windows Server et souhaitez créer un volume séparé sur le même disque pour la journalisation. Chacun de ces scénarios nécessite l'automation de DiskPart, qui, comme dans les versions précédentes, peut être effectuée en envoyant à DiskPart un script (n'importe quel format de fichier) contenant les commandes que vous voulez exécuter et se terminant par exit, pour quitter DiskPart.
Il n'est pas facile de créer votre propre environnement d'installation dans la mesure où vous reconstruisez en fait l'exécutable d'installation (ou reflétez au moins ses fonctionnalités) et où la conception et la génération peuvent demander un travail considérable. Cela se résume, toutefois, au nombre de fonctionnalités que vous voulez y intégrer par défaut et à ce que vous y intégrez (HTA ou WSH ou un langage de programmation compilé).

Serveur de transport
Si vous n'utilisez pas la plupart des fonctionnalités de WDS (telles qu'Active Directory) ou si vous construisez votre propre solution personnalisée complète, le serveur de transport peut répondre à vos besoins sans imposer des conditions dont vous ne voulez pas. Le tableau de la figure 2 (reproduite du document « Utilisation du serveur de transport » disponible à l'adresse go.microsoft.com/fwlink/?LinkID=115298) décrit ce qui est inclus dans le cadre du rôle de serveur de transport de WDS.
Figure 2 Serveur de déploiement et serveur de transport
 | Serveur de déploiement | Serveur de transport
Configuration requise pour le serveur | Nécessite les Services de domaine Active Directory (ADDS), le protocole DHCP (Dynamic Host Configuration Protocol) et les services DNS (Dynamic Name Services) dans l'environnement. | Ne nécessite pas d'autres serveurs dans l'environnement.
PXE | Prend en charge le démarrage PXE avec le fournisseur PXE par défaut. | Un fournisseur PXE n'est pas s'installé et vous devez donc créer un fournisseur PXE personnalisé.
Serveur d'image | Inclut le serveur d'image des Services de déploiement Windows. | N'inclut pas le serveur d'image des Services de déploiement Windows.
Méthode de transmission | Permet la monodiffusion et la multidiffusion. | Permet uniquement la multidiffusion.
Outils de gestion | Est géré à l'aide du composant logiciel enfichable MMC des Services de déploiement Windows ou de l'outil de ligne de commande WDSUTIL. | Est uniquement géré par l'outil de ligne de commande WDSUTIL.
Application sur l'ordinateur client | Utilise le client Services de déploiement Windows (principalement Setup.exe et les fichiers qui l'accompagnent), Wdsmcast.exe (qui est inclus dans le Kit d’installation automatisée de Windows) ou une application de multidiffusion personnalisée. | Utilise uniquement Wdsmcast.exe ou l'application personnalisée.
Lorsque je dis que ce serveur de transport est un élément compliqué à implémenter, je ne parle pas du rôle lui-même qui est, bien sûr, facile à déployer (voir figure 3). C'est l'implémentation d'une installation personnalisée autour du serveur de transport qui nécessite beaucoup de travail. L'utilisation du rôle de serveur de transport supprime de fait une grande partie de la convivialité intégrée à WDS en tant que rôle.
Figure 3 Le serveur de transport peut être utile dans les scénarios de déploiement personnalisés (cliquez sur l'image pour l'agrandir)

Multidiffusion personnalisée
Que vous utilisiez ou pas le rôle de serveur de transport, mais surtout si vous l'utilisez, je vous conseille d'utiliser la multidiffusion si vous effectuez un déploiement de plusieurs systèmes. ADS propose une fonctionnalité de multidiffusion très puissante que vous pouvez dupliquer en utilisant WDS avec la multidiffusion. WDS propose la multidiffusion toute seule, mais si vous créez votre propre solution personnalisée, vous pouvez profiter de la multidiffusion en utilisant WDSMCast, comme je l'ai mentionné le mois dernier (voir figure 4). N'oubliez pas que vous devez transférer les fichiers d'image devant être déployés avant de les appliquer. En général, cela signifie que vous avez besoin de suffisamment d'espace disque local pour stocker l'image avant de l'appliquer.
Figure 4 Exécution de WDSMCast (Cliquez sur l'image pour l'agrandir)

Conclusion
WDS est suffisamment puissant, à lui seul, pour répondre aux attentes de nombreuses organisations. Mais si vous souhaitez créer votre propre solution, une solution qui va au-delà des limites de WDS, rien ne vous en empêche. Tout dépend de votre imagination, de votre calendrier et de vos compétences techniques.

Wes Miller est responsable de produit technique pour CoreTrace (CoreTrace.com) à Austin au Texas. Il travaillait auparavant chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


Vigilance sécurité Les 10 lois immuables de la sécurité revisitées, 1ère partie
Jesper M. Johansson

En 2000, Scott Culp a publié un article intitulé « Les 10 lois immuables de la sécurité ». C'est l'un des meilleurs articles sur la sécurité que j'aie jamais lu. Les informations qui y étaient présentées restent fondamentales pour tout travail en rapport avec la sécurité informatique et je vous recommande d'y jeter un coup d'œil (et même de l'imprimer) si ce n'est déjà fait. Il est disponible sur microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
Cet article a engendré diverses réactions. Certaines personnes ont fait remarquer sarcastiquement qu'il s'agissait pour Microsoft d'une façon d'éviter de corriger ce qui était perçu comme des problèmes sérieux. D'autres l'ont considéré comme LE document fondateur sur la sécurité et l'ont plagié sans vergogne du fait de son importance. Toutefois, certaines de mes réactions préférées sont celles où les personnes ont été inspirées et ont créé leurs propres listes, comme celle disponible sur edgeblog.net/2006/10-new-immutable-laws-of-it-security.
Au cours des huit années écoulées depuis la publication de cet article, il s'est passé beaucoup de choses dans le domaine de la sécurité. Pratiquement tous les vers un tant soit peu importants ont été mis en circulation. Nous sommes entrés dans un état de guerre de l'information (avec son crime organisé, ses entités politiques, etc.). De nouveaux mots et expressions font désormais partie du vocabulaire courant, notamment phishing (hameçonnage), pharming (détournement de site), botnet (réseau de zombies), logiciel espion et contrefaçon de requête intersite. Nous disposons désormais de certains des rootkits les plus sophistiqués jamais créés sur Windows. Nous avons de nouvelles versions de système d'exploitation dédiées, en grande partie, à la sécurité et d'autres systèmes d'exploitation qui ignorent toujours la sécurité.
L'ingénierie sociale s'est transformée en menace majeure. Les violations de données, comme lorsqu'un grand magasin a divulgué les numéros de 94 millions de cartes de crédit, font régulièrement la une des journaux (et pourtant les gens continuent à faire leurs courses dans ces magasins). Les gouvernements des États-Unis et du Royaume-Uni ont, collectivement, réussi à égarer les informations personnelles d'un pourcentage considérable des habitants du monde occidental (et pourtant les gens continuent à communiquer des informations personnelles à ces gouvernements). Et une énorme dose de comédie sécuritaire s'est immiscée dans nos vies, et dans nos aéroports.
Je pense qu'il est temps de jeter un nouveau coup d'œil à ces lois. Étant donné toutes les modifications survenues dans la première partie de ce siècle, pouvons-nous toujours prétendre que ces lois sont immuables ? Si elles le sont, si elles ont survécu aux 8 dernières années, on peut se risquer à dire qu'elles survivront aux 10 prochaines.
Dans cette série en trois parties, j'examinerai de façon critique chacune des 10 lois. Ce mois-ci, je traite des lois 1 à 3. Le mois prochain, je m'intéresserai aux lois 4 à 7. Et je consacrerai la dernière partie aux lois 8 à 10, en ajoutant quelques réflexions et commentaires qui semblent raisonnables au vu de ce qui s'est passé depuis que les lois ont été écrites en 2000.
Loi 1 : Si une personne malintentionnée peut vous persuader d'exécuter son programme sur votre ordinateur, ce n'est plus votre ordinateur.
Cette loi indique clairement que tout logiciel que vous exécutez sur un ordinateur peut prendre le contrôle de cet ordinateur. Lorsque les lois immuables ont été rédigées, les systèmes d'exploitation proposés par Microsoft étaient Windows 98, Windows Me et Windows NT 4.0. Aujourd'hui nous avons Windows Vista et Windows Server 2008.
Sur Windows 98 et Windows Me, tout logiciel que vous exécutiez disposait du contrôle total de l'ordinateur. Windows NT 4.0 bénéficiait d'un modèle de sécurité sous-jacent très solide, mais si vous l'exécutiez en tant qu'Administrateur, vous réduisiez son modèle d'isolation à celui de Windows 98 et Windows Me. Il était possible d'exécuter Windows NT 4.0 en tant que non-administrateur, mais cela était assez pénible et très peu d'organisations le faisaient (vous pourriez probablement compter le nombre total d'organisations à l'avoir fait sur les dix doigts de vos mains).
Imaginons que vous exécutiez véritablement Windows NT 4.0 en tant que non-administrateur. La loi 1 était-elle vraie lorsqu'elle a été écrite ? La réponse est oui. Tout d'abord, Windows NT 4.0 recelait un grand nombre de failles importantes. Par exemple, certaines autorisations auraient pu être plus strictes, notamment sur les objets de noyau et dans le Registre. De plus, de nombreux types d'attaques n'avaient pas encore été découverts, mais les experts s'attendaient à leur arrivée. Par exemple, en 1999 les gens ne s'étaient pas rendu compte que l'exécution des processus en tant qu'utilisateur bénéficiant d'un accès élevé sur le bureau interactif pouvait compromettre l'ordinateur. Ce n'est qu'en 2002, lorsque Chris Paget a publié son livre blanc sur les attaques destructrices, « Exploiting the Win32 API », que ce fait a été couramment admis (seclists.org/bugtraq/2002/Aug/0102.html).
Microsoft avait-il prévu les attaques destructrices lorsque la Loi 1 a été rédigée ? Non, pas vraiment. Microsoft a simplement reconnu un fait : il n'existe que très peu de vraies limites de sécurité pouvant empêcher une application exécutée sur un ordinateur de prendre le contrôle de cet ordinateur.
Windows Vista et Windows Server 2008 sont distantes de Windows NT 4.0 de deux générations. Ont-ils invalidé la Loi 1 ? Est-ce le cas d'autres systèmes d'exploitation ? Ça dépend. Il existe certainement des limites de sécurité plus solides dans les nouveaux systèmes d'exploitation et il existait des systèmes d'exploitation expérimentaux en 2000 qui avaient des limites de sécurité appropriées. Cependant, ces limites sont toujours rares. Par exemple, la sécurité d'accès au code dans Microsoft .NET Framework est une limite de sécurité. Elle est spécifiquement conçue pour empêcher le code exécuté dans le bac à sable d'affecter le système d'exploitation sous-jacent.
Les Iframes d'Internet Explorer fournissent une autre limite de sécurité. Mais les Iframes n'affectent pas l'accès au système d'exploitation lui-même, uniquement l'accès entre les éléments de contenu sur une page Web. Le mode protégé d'Internet Explorer, illustré à la figure 1, est une limite de sécurité au niveau système d'exploitation. Son but est d'empêcher le code exécuté dans un navigateur d'affecter le système d'exploitation sous-jacent, sans action de l'utilisateur. Il en existe quelques autres, telles que les comptes d'utilisateur standard, qui sont censés empêcher un compte utilisateur d'affecter le système d'exploitation sous-jacent ou un autre utilisateur.
Figure 1 Internet Explorer 7 utilise une limite de sécurité nommée Mode protégé (cliquez sur l'image pour l'agrandir)
Il est extrêmement important de comprendre ce que signifie l'expression « limite de sécurité ». Cela ne signifie pas qu'un mur inviolable garantit une isolation imperméable et indéfinie. L'expression signifie que le fournisseur du logiciel, Microsoft par exemple, est s'engage à remédier à toute violation de cette limite au moyen d'un correctif de sécurité. Les logiciels comporteront toujours des bogues et nous continuerons sans aucun doute à découvrir de nouvelles violations que les fournisseurs de logiciels continueront à corriger. Au fil du temps, ils devraient améliorer leurs logiciels pour empêcher ces vulnérabilités d'apparaître. Cela peut être considéré comme la confirmation que la Loi 1 est toujours valable.
Cependant, je dois aborder un dernier point crucial. Vous avez peut-être remarqué la phrase « sans action de l'utilisateur » utilisée ci-dessus. La Loi 1 ne concerne pas vraiment les défauts ou les vulnérabilités des logiciels. En réalité, elle concerne plutôt les vulnérabilités des personnes ! L'expression clé est « vous persuader ». Si une personne malintentionnée peut vous persuader d'exécuter son programme, elle peut probablement vous persuader de le faire dans un contexte qui, à dessein, donne au programme des privilèges élevés.
Même si vous n'avez pas de privilèges d'administrateur, ce n'est pas important. En tant qu'utilisateur standard, vous avez toujours accès à de nombreuses informations croustillantes : vos fichiers bancaires, lettres d'amour, photos, vidéos et données professionnelles confidentielles. Toutes ces données sont potentiellement intéressantes pour un attaquant et elles peuvent toutes être lues sans privilège élevé. Du point de vue des informations que vous gérez sur votre ordinateur, l'exécution d'un programme malveillant transmet tout ce que vous faites à l'attaquant. Donc, si vous définissez « votre ordinateur » comme « les données que vous gérez sur votre ordinateur », vous pouvez ignorer toute discussion sur les privilèges et simplement conclure que la Loi 1 reste valable.
Même sans couper les cheveux en quatre à propos de la définition de votre ordinateur, la Loi 1 semble avoir résisté à l'épreuve du temps. La Loi 1 vise à établir le fait que vous, en tant qu'opérateur d'un ordinateur, devez assumer la responsabilité des logiciels que vous exécutez sur cet ordinateur. Si vous installez un pilote malveillant ou un codec vidéo diabolique, vous avez transmis le contrôle intégral de cet ordinateur à un criminel !
Bien que les fournisseurs de logiciels puissent faire beaucoup pour empêcher les violations accidentelles, ce qui est l'objet des limites de sécurité, l'exécution intentionnelle d'un logiciel malveillant déjoue généralement toutes ces mesures de protection. C'est pourquoi parallèlement aux procédés qui garantissant que les utilisateurs n'ont pas l'autorisation d'exécuter des tâches administratives, l'éducation des utilisateurs est primordiale. On peut par conséquent dire sans risque que la Loi 1 reste vraie aujourd'hui, mais probablement avec une légère modification de la définition de votre ordinateur.
Loi 2 : Si une personne malintentionnée peut modifier le système d'exploitation de votre ordinateur, ce n'est plus votre ordinateur.
À première vue, cette loi semble assez simple. Il va de soi que si la personne malintentionnée peut modifier le système d'exploitation sur votre ordinateur, vous ne pouvez plus faire confiance à l'ordinateur. Mais le concept de système d'exploitation a changé au fil de l'évolution des besoins informatiques. Il y a de nombreuses années, j'ai rédigé la définition de l'expression « système d'exploitation » pour The Blackwell Encyclopedia of Management (managementencyclopedia.com). Cette définition parlait d'un système d'exploitation gérant l'accès aux périphériques d'entrée et de sortie, l'accès au matériel et ainsi de suite. Je n'ai jamais reçu d'exemplaire de cette encyclopédie et ma contribution originale n'est pas entrée dans l'histoire, mais je suis certain de ne pas avoir mentionné qu'un système d'exploitation inclut un jeu de solitaire, un système d'entrée pour Tablet et des transcodeurs vidéo.
Comme l'informatique est devenue de plus en plus complexe, les systèmes d'exploitation se sont développés pour prendre en charge bien plus de fonctionnalités. Pour compliquer le problème, les OEM incluent souvent leur propre assortiment de logiciels complémentaires, qui vont généralement d'outils vaguement utiles à des outils franchement nuisibles. En outre, certains de ces logiciels supplémentaires dupliquent des fonctionnalités déjà intégrées au système d'exploitation central.
Par exemple, une installation par défaut de Windows Server 2008 Édition Entreprise occupe plus de 5 gigaoctets. Windows Vista Édition Intégrale comprend plus de 58 000 fichiers, représentant plus de 10 gigaoctets. Et le système d'exploitation n'est pas constitué que de fichiers. Il y a les paramètres de configuration, des milliers d'entre eux ; et il y a des démons ou services.
Tout cela fait partie du système d'exploitation. Il s'agit d'un terme collectif qui inclut tous les fichiers, tous les paramètres de configuration et tous les services, ainsi que tous les objets d'exécution (sémaphores, canaux nommés, points de terminaison RPC) créés par les fichiers et paramètres de configuration. Même des constructions aussi abstraites que l'heure du système et certains types de données, comme les contenus de journaux d'événements, doivent être considérées comme éléments à part entière du système d'exploitation.
Étant donné la façon dont le système d'exploitation s'est développé et a évolué, est-il vrai que la modification de l'un de ces fichiers rend l'ordinateur non fiable ? La réponse directe est non. Par exemple, Windows Vista est équipé d'edlin.exe, l'ancien éditeur de ligne de MS-DOS. Je n'en ai pas la preuve, mais je parierais un triple moka qu'edlin.exe n'a été invoqué que deux fois sur toutes les copies installées de Windows Vista depuis la sortie de ce système d'exploitation. Et les deux fois, c'était il y a environ trois minutes, lorsque j'essayais de me rappeler la syntaxe. Si quelqu'un modifie edlin.exe ou un autre fichier que personne n'utilise jamais, cela signifie-t-il vraiment que votre ordinateur n'est plus votre ordinateur ?
Edlin.exe fait indiscutablement partie du système d'exploitation, mais si personne n'exécute jamais le fichier, comment sa modification peut-il compromettre votre ordinateur ? La réponse est, bien sûr, qu'elle ne le peut pas. La modification d'un élément du système d'exploitation qui n'est jamais utilisé ne compromet pas votre ordinateur. Et de nombreux éléments du système d'exploitation ne sont jamais utilisés.
Toutefois, la réponse indirecte est néanmoins oui. Il ne suffit pas de savoir si quelqu'un exécute un fichier pour voir si sa modification peut compromettre votre ordinateur. Le problème est plus subtil que cela. Jetons un coup d'œil à la liste de contrôle d'accès (ACL) pour edlin.exe, illustrée à la figure 2.
Figure 2 L'ACL pour edlin.exe est très restrictive (cliquez sur l'image pour l'agrandir)
L'ACL pour edlin.exe est très restrictive. Seul le service TrustedInstaller a le droit de modifier cet exécutable. C'est très important : cela signifie qu'il y a un effet indirect pour une personne malintentionnée modifiant ce fichier sur votre ordinateur. La modification d'edlin.exe signifie que ce n'est plus votre ordinateur. En l'occurrence, c'est le fait que l'utilisateur malintentionné a la possibilité de modifier edlin.exe qui est primordial. Si la personne malintentionnée peut modifier ce fichier, elle peut modifier n'importe quel fichier, ce qui signifie que vous ne pouvez plus faire confiance à votre ordinateur.
Le système d'exploitation se protège lui-même. Les services sont protégés contre les modifications non autorisées. Les paramètres de configuration sont protégés contre les modifications non autorisées. Les fichiers sur le disque sont protégés contre les modifications non autorisées. Même les sémaphores et les points de terminaison RPC utilisés par le système d'exploitation sont protégés contre les modifications non autorisées. Si un attaquant peut modifier l'un de ces objets protégés, il peut tous les modifier et, très probablement, l'a déjà fait.
Il s'agit là d'un point critique. Avec plusieurs des lois immuables, ce n'est pas l'acte de faire quelque chose qui signifie que votre ordinateur est compromis. La seule chose qui compte, c'est que quelqu'un a la possibilité de faire quelque chose. C'est là un point qui ne doit pas être négligé. Pour chaque aspect de la sécurité informatique, vous devez toujours vous rappeler que la capacité est souvent bien plus importante que l'action réellement effectuée.
Si un ordinateur est grand ouvert sur Internet et n'est pas protégé pendant des mois, est-il toujours digne de confiance ? Non. Cet ordinateur doit être considéré comme compromis. Vous ne pouvez faire confiance à aucun élément d'un système pouvant avoir été compromis. (Je disais déjà la même chose il y a cinq ans dans mon article « Au secours ! Je me suis fait pirater. Que faire ? » disponible à l'adresse technet.microsoft.com/library/cc512587.) Si vous avez affaire à un adversaire compétent, un système compromis peut même ne pas présenter de signes de sa compromission. Le système peut paraître parfaitement normal.
Sans aucun doute, la Loi 2 reste valable. Si un attaquant a la possibilité de modifier un objet protégé sur votre ordinateur, ce n'est plus votre ordinateur. N'oubliez pas, c'est la possibilité de modifier ces objets qui compte, pas le fait qu'ils l'ont été ou non.
Loi 3 : Si une personne malintentionnée dispose d'un accès physique non restreint à votre ordinateur, ce n'est plus votre ordinateur.
Cette loi était critique en 2000. De nombreuses personnes ne comprenaient pas vraiment ce que vous pouviez faire en disposant de l'accès physique à un système. En fait, même certaines administrations publiques qui auraient dû être bien informées n'ont pas saisi l'importance de ce point. À cette époque, les directives de sécurité recommandaient de désactiver l'option Autoriser l'arrêt sans connexion. Lorsque cette option est désactivée, le bouton Arrêter... à l'écran d'ouverture de session est grisé. La théorie était que pour arrêter l'ordinateur, l'utilisateur doit d'abord ouvrir une session. En conséquence, un enregistrement d'audit indiquerait qui arrête le système.
C'est un mauvais raisonnement digne d'une étude de cas. Pour avoir accès au bouton Arrêter... à l'écran d'ouverture de session, vous devez vous trouver devant la console. Et si vous vous trouvez devant la console et que vous voulez vraiment arrêter l'ordinateur, vous pouvez utiliser le gros bouton rond à l'avant de l'ordinateur, voire le cordon d'alimentation. Système arrêté. Aucun suivi d'audit.
Windows 2000 comporte un paramètre de sécurité appelé Autoriser le retrait sans ouverture de session préalable, et cette option est toujours disponible dans Windows Vista, comme illustré à la figure 3. Le principe était le même. Pour retirer un portable de sa station d'accueil, il est nécessaire d'ouvrir au préalable une session sur le système.
Figure 3 Pourquoi ne pas voler l'ordinateur et la station d'accueil ? (cliquez sur l'image pour l'agrandir)
La valeur réelle de ce paramètre en termes de sécurité est extrêmement douteuse. Je pense que la théorie était que si quelqu'un pouvait accéder au portable et le détacher, cette personne pouvait aussi bien voler l'ordinateur. Je ne volerais jamais un portable, mais si je devais le faire, cette mesure préventive ne me dissuaderait pas. Je m'emparerais probablement du portable et de la station d'accueil. Et puis tant qu'à faire, je volerais également le câble réseau et le cordon d'alimentation. Vous parlez d'une mesure de sécurité inutile !
La question de l'accès physique a été réellement reconnue lorsque Petter Nordahl-Hagen a créé son Offline NT Password & Registry Editor. Sa création n'était qu'un disque de démarrage Linux avec un pilote de système de fichiers NTFS expérimental qui permettait l'accès en lecture et en écriture à un volume NTFS. Le logiciel sur le disque de démarrage était conçu pour monter le Registre sur l'ordinateur local et écrire un nouveau mot de passe pour le compte d'administrateur dans la ruche du SAM (software asset management). Il vous suffisait de disposer d'un accès physique au système pendant une à deux minutes.
C'est exactement pour des outils comme cela que la Loi 3 a été écrite. En fait, l'outil de Nordahl-Hagen a été utilisé dans de nombreuses démonstrations. Malheureusement, le grand public n'en a pas eu connaissance. J'ai personnellement utilisé cet outil dans certaines démonstrations, mais j'ai arrêté parce que je me suis lassé que l'on me demande « Comment nous assurer qu'aucun de nos utilisateurs ne connaît un tel outil ? » et « Que fait Microsoft pour résoudre ce problème ? ». Une grande partie de l'industrie informatique ne voulait simplement pas accepter ou comprendre que l'accès physique prendrait le dessus sur tout le reste.
Dans cet environnement, la Loi 3 était très importante. Pourtant les critiques l'ont assaillie sans pitié. Elle a été ridiculisée et présentée comme une tentative par Microsoft d'éviter de corriger tout problème pouvant être lié, même de loin, à l'accès physique. En fait, la Loi 3 a été utilisée à plusieurs reprises pour ignorer les rapports de vulnérabilité, y compris le piratage avec Offline NT Password & Registry Editor. Cependant, il n'est possible de bloquer les attaquants qui ont un accès physique au système que d'une seule façon : en s'assurant qu'ils ne peuvent accéder à rien.
C'est là que se trouve le défaut de la cuirasse de la Loi 3. Depuis que les lois ont été écrites, la technologie de chiffrement de disque complet est devenue une solution viable. Avec le chiffrement complet du disque dur, plus justement dénommé chiffrement de volume complet, un volume entier (ce qui est appelé partition dans d'autres systèmes d'exploitation) peut être chiffré. Donc, si le volume de démarrage entier (en d'autres termes, le volume sur lequel réside le système d'exploitation) est chiffré, la question que nous devons nous poser est la Loi 3 reste-t-elle valable ?
La réponse est oui, très probablement. Tout d'abord, les clés de déchiffrement doivent être stockées quelque part. Le lieu le plus simple où mettre les clés, et l'option par défaut dans BitLocker, est dans une puce de module de plateforme sécurisée dans l'ordinateur. Ainsi, l'ordinateur démarre sans assistance. Une fois l'ordinateur démarré, un attaquant ingénieux et bien subventionné, disposant du contrôle physique permanent sur l'ordinateur, peut l'attaquer de plusieurs façons. Comme l'ordinateur peut maintenant être connecté à un réseau arbitraire, il est possible d'attaquer le système par le réseau.
L'attaquant peut, par exemple, lire ou écrire la mémoire au moyen d'un dispositif d'accès direct à la mémoire (DMA), tel qu'un lecteur flash USB. Lorsque l'ordinateur est en cours d'exécution, tous les paris s'annulent s'il s'agit d'un attaquant avec accès physique à cet ordinateur.
Si les clés ne sont pas stockées sur l'ordinateur lui-même, l'attaque dépend du fait que l'attaquant peut obtenir ou deviner les clés. Si un code PIN est utilisé pour démarrer l'ordinateur, l'attaquant peut probablement deviner le code avec relativement peu d'effort. Si les clés sont stockées dans ou dérivées d'un périphérique matériel séparé, comme un lecteur flash USB ou un mot de passe à utilisation unique, l'attaquant doit avoir accès à ce périphérique séparé. Il existe certainement des moyens d'obtenir ces clés ou de rendre la vie très difficile pour la personne qui y a accès, bien que l'effort requis soit probablement plus important.
Vous pouvez également interpréter la Loi 3 d'une façon légèrement différente : « Si l'attaquant dispose d'un accès physique à votre ordinateur, c'est probablement que l'ordinateur a été volé et, donc, il est peu probable que vous le retrouviez ». De ce point de vue, ce n'est vraiment plus votre ordinateur. Et de ce point de vue, l'attaquant peut ne même pas se soucier de pouvoir ou non accéder aux données situées sur votre ordinateur. Cependant, ce n'est vraiment pas l'esprit de la Loi 3. En effet, elle signifiait que l'attaquant avait accès aux données sur votre ordinateur et pas juste à l'ordinateur.
Tout bien considéré, la Loi 3 s'applique toujours. Il est vrai que certaines technologies disponibles aujourd'hui sont parviennent à arrêter de nombreux attaquants avec accès physique et ainsi à réduire le nombre d'attaquants capables d'accéder aux données d'un ordinateur protégé par une mesure de sécurité. Cela dit, les capacités de l'attaquant définissent toujours ce que l'attaquant peut faire, et de nouvelles technologies répondent à plusieurs des 10 lois immuables, dans une certaine mesure. Mais l'accès physique offre toujours des façons, bien qu'elles soient plus complexes, de pénétrer dans un système.
Jusqu'à présent, les lois immuables de la sécurité s'avèrent très résilientes, à la fois face aux avances technologiques et au temps. Parmi les 3 premières, la Loi 3 est sur le terrain le plus instable, mais elle reste néanmoins valable dans certains cas. C'est, toutefois, celle qui a les atténuations les plus facilement disponibles et robustes en place. Je reviendrai dans les deux prochains numéros de TechNet Magazine pour continuer cette discussion et déterminer si les Lois 4 à 10 sont toujours immuables.

Jesper M. Johansson est architecte de logiciels, chargé des problèmes de sécurité logicielle et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.


Sur le terrain Code barres couleur haute capacité
Gavin Jancke

Nous connaissons tous si bien les codes barres qu'ils passent souvent inaperçus. Ils sont quasiment omniprésents dans la vie quotidienne, depuis les emballages alimentaires aux étiquettes d'expédition. Les codes barres 1D qui sont apparus sur le marché de détail en 1974 étaient constitués de barres verticales de largeurs variables et comportaient 12 chiffres. Les codes barres ont évolué à mesure que la puissance informatique a augmenté et les codes barres en deux dimensions noirs et blancs (codes matrice) ont été développés à la fin des années 80, marquant une densité des données passant de quelques chiffres à quelques centaines d'octets.
En 2003, j'ai commencé à travailler sur un projet de carte d'identification biométrique à l'épreuve des contrefaçons pour Microsoft Research. Je devais stocker non seulement le texte cryptographique, notamment nom et âge, mais aussi des modèles d'empreintes digitales ou d'analyses d'iris. Pour stocker toutes les données nécessaires, le code barres noir et blanc existant aurait été plus grand que la carte d'identification; il fallait donc trouver une nouvelle approche.
J'ai dû déterminer comment stocker plus d'une partie des informations par symbole, ce qui était la norme pour les codes barres noirs et blancs en 2 dimensions. En utilisant des couleurs plutôt que le noir et blanc, je pouvais passer à deux ou trois éléments de données à l'aide de quatre et huit couleurs, respectivement.
J'ai expérimenté également avec les formes de symboles pour voir s'ils pouvaient être plus serrés sans compromettre leur enregistrement au moment de la numérisation. Au début les hexagones semblaient prometteurs, mais les formes s'amalgamaient et l'ordinateur ne pouvait pas les discerner assez clairement.
J'ai fini par me décider pour les triangles parce qu'ils s'entrecoupent proprement dans un espace compressé, tout en retenant leur identité de formes distinctes. En utilisant des rangées de triangles de plusieurs couleurs, je pouvais faire passer la capacité de densité en 3D.
Il fallait tenir compte d'un grand nombre de variables. Un des plus grands défis dans le travail avec la couleur est la diversité des spécifications d'impression et des conditions d'éclairage. Bien que la couleur puisse être facilement perceptible à l'œil nu (au moins pour ceux qui ne sont pas daltoniens), elle n'est pas aussi clairement perceptible pour un ordinateur.
J'ai utilisé plusieurs approches différentes pour faire en sorte que le logiciel puisse lire la couleur avec précision. J'ai créé une palette toute petite, presque invisible à l'intérieur du code barres qui contenait les couleurs de référence existant dans le code barres. Ceci fournissait un mécanisme d'étalonnage qui spécifiait exactement ce que constitue un rouge particulier, par exemple. J'ai essayé également des techniques plus avancées comme des algorithmes regroupant les couleurs personnalisés et légers qui tirent parti de la théorie de l'espace colorimétrique pour classer les couleurs dans des ensembles. Les deux approches fonctionnent tout aussi bien et se complètent.
L'un de mes objectifs pour ce projet était d'écrire un programme qui permettrait aux téléphones portables de lire les codes barres. Avec les téléphones portables, on doit tenir compte de la pauvreté de l'éclairage et des lentilles à distance focale floues et fixes. Il importait également de réaliser tout cela sur des processeurs de téléphones portables basés sur des entiers et relativement lents, de sorte que l'équipe devait trouver une théorie solide sur la façon de détecter le code barres dans l'image tout en touchant le moins de pixels possible. La numérisation devait fonctionner dans une plage de qualités de lecture, telles que des panneaux LCD net bien éclairés ou des caractères flous en éclairage réduit.
L'algorithme final décode les images de codes barres sur des trames d'appareil en temps réel plus rapidement que la fréquence d'images : à peu près 10 ms sur un processeur de 200 MHz. Dans une image, le plus petit nombre de pixels qu'un code barres peut avoir pour la charge de données la plus petite tout en étant détectable est d'à peu près 45 pixels carré.
Il a fallu plus de deux ans de travail pour que tout ceci fonctionne sous des conditions variables. Cette technologie a été récemment cédée sous licence à des tiers et vous découvrirez des applications passionnantes vers la fin de l'année.
Gavin Jancke, responsable de l'ingénierie pour Microsoft Research, dirige les équipes Advanced Development Group et Web Experience. Il travaillait auparavant comme ingénieur support produit, ingénieur logiciel pour SQL Server et a fait partie du personnel de conseil technique principal de Bill Gates.


La vie secrète de Windows Travaillez plus dur, pas plus intelligemment
Raymond Chen

Pour les développeurs de logiciels, l'un des principaux avantages du programme Rapport d'erreurs Windows est qu'il leur permet d'obtenir des informations réelles sur les causes des défaillances de leurs programmes. Ces rapports d'erreur sont à la disposition de tout fournisseur de logiciels qui s'inscrit en ligne à winqual.microsoft.com. Bien sûr, vous pouvez exécuter toutes sortes de tests dans vos laboratoires, mais il existe toujours des différences entre les conditions de laboratoire et la réalité. Ainsi, certains bogues qui ne sont jamais détectés par vos tests peuvent rendre vos clients fous.
Il y a quelques années, un programmeur qui effectuait un travail pour le compte de l'équipe chargée de la fiabilité de son produit m'a raconté une histoire. L'équipe voulait résoudre les principales causes des incidents et pannes qui se produisaient dans un composant particulier. Après quelques négociations, les deux parties avaient convenu d'essayer de réduire le nombre de ces défaillances par un facteur de 2. L'objectif était de corriger les bogues responsables d'au moins 50 % des incidents et pannes dans le composant, tels qu'ils étaient mesurés par le programme Rapport d'erreurs Windows.
Nous savons tous que les pannes ne sont pas distribuées de manière uniforme. Certaines sont rares, d'autres courantes, et d'autres encore sont endémiques (relativement parlant). L'ingénierie est un jeu de compromis ; vous considérez vos ressources (temps, argent et ressources intellectuelles) et les injectez là où elles auront le plus grand effet. Puisque l'objectif, dans ce cas, était de réduire le nombre d'incidents et de pannes, il était raisonnable d'étudier les problèmes les plus fréquemment signalés par le programme Rapport d'erreurs Windows, d'en comprendre les causes et d'essayer ensuite de les résoudre.
Le Rapport d'erreurs Windows fournit des informations réelles sur les défaillances des programmes (cliquez sur l'image pour l'agrandir)
Lorsque le programmeur a examiné les données liées aux pannes, il s'est avéré que plus de 60 % des rapports étaient consacrés à cinq incidents et pannes particuliers. Si le programmeur arrivait à corriger les bogues qui causaient ces cinq défaillances, il réduirait le nombre d'incidents et de pannes par un facteur de 2,5, bien au-delà du facteur cible original qui était de 2.
L'analyse par Microsoft des données du Rapport d'erreurs Windows montre que le principe de Pareto est remarquablement approprié dans le cas des incidents et pannes de Windows : 80 % des défaillances sont causées par environ 20 % des bogues. La même étude a révélé un résultat encore plus étonnant : 50 % des erreurs sont causées par seulement 1 % des bogues. Les bogues ne sont pas tous égaux bien entendu, mais une telle inégalité dans leur distribution est surprenante.
Après avoir étudié ces cinq défaillances un peu plus en détail, le programmeur s'est rendu compte que toutes avaient la même cause. Les incidents et pannes n'étaient que des manifestations différentes d'un même bogue. Il a donc développé et testé un correctif et, en collaboration avec le personnel de l'assurance qualité, l'a inclus dans le jeu de correctifs suivant. Avec ce seul correctif, le taux de défaillance théorique du composant a immédiatement diminué d'un facteur de 2,5. Il a accompli sa mission d'un seul... code !
Ce qui m'a surpris dans cette histoire, c'est que la courbe de distribution d'erreurs pour le composant était encore plus prononcée que pour Windows. Plus de la moitié de tous les incidents et pannes étaient causés par un seul bogue. Une telle compréhension de votre code n'est pas possible sans les données recueillies par un programme tel que le Rapport d'erreurs Windows.
Vous penseriez que les membres de l'équipe chargée de la fiabilité des produits étaient aux anges lorsqu'ils ont appris que leur objectif avait été atteint aussi rapidement. En effet, l'objectif convenu avait été dépassé en seulement deux semaines, avec un seul correctif. Eh bien, non ! Ils étaient furieux !
« C'est inacceptable ! Ca devait prendre deux mois ! C'était trop facile ! » Apparemment, ils voulaient que le programmeur travaille plus dur, et pas plus intelligemment.
Le site Web de Raymond Chen, The Old New Thing, et son livre du même titre traitent de l’historique de Windows et de la programmation Win32. 20 % de ses vêtements sont responsables de 80 % de sa lessive !