Archive pour la Catégorie: ‘Mirage

10 articles trouvés dans cette archive
Oct/14300
Par Dans Mirage

import-export-layer MirageBien qu’Horizon Mirage puisse être considéré comme un outil de sauvegarde, il reste avant tout un outil de gestion du contenu des postes de travail. C’est pourquoi, il n’est pas forcément nécessaire de sauvegarder l’intégralité du serveur Mirage et de tous les CVD qu’il contient. En revanche, il est utile de pouvoir sauvegarder le travail réalisé dans Mirage sur la standardisation des masters (Base Layer) et des applications (App Layer).

Cependant, l’interface graphique ne fournit pas cette option. On peut tout de même le faire en ligne de commande. En voici la procédure: Lire la suite…

Déc/1330

BootUSB-MirageHorizon Mirage permet de manipuler agilement les OS et les restaurations à partir du client Mirage. Mais pour les machines nues, il faut d’abord fournir un OS avec le client pour pouvoir gérer la machine depuis le serveur Mirage. Cette opération se fait à partir d’une installation automatisée de Windows 7 sur clé USB bootable.

Pour générer cette clé USB bootable, utiliser les scripts fournit dans « BootUSB.zip« . Avant d’utiliser les scripts, il faut fournir:

  • une clé USB de minimum 4 Go (qui sera formatée)
  • le contenu du DVD Windows 7 Professional/Enterprise 32/64 bits
  • le fichier MSI du client Mirage x86 ou x64 (en fonction de la distribution Windows 7 utilisée), le copier dans « BootUSB/MirageClient/« 
  • les drivers Windows 7 pour la machine nue (à minima le driver réseau), les copier dans « /BootUSB/Drivers/« 
  • avoir le lecteur U: disponible

Lire la suite…

Juil/1323
Par Dans Mirage

Mirage-migration_logonUne migration « in-place » vers Windows 7 s’appuie le plus souvent sur l’USMT (User State Migration Tool) de Microsoft en version 4.0 qui fait partie du AIK pour Windows 7.

Horizon Mirage utilise justement l’USMT en mode offline avec migration des hardlinks. Si l’on souhaite modifier les paramètres qui sont migrés par défaut, il faut modifier les fichiers .xml de l’USMT. La bonne pratique pour Mirage est de ne pas modifier ceux existant mais plutôt d’ajouter des fichiers .xml personnalisés en fonction du besoin.

Pour faire cela dans Mirage, il faut suivre le mode opératoire suivant: Lire la suite…

Juil/13220

La phase de migration d’OS par Mirage s’appuie sur un mécanisme de Pivot entre les 2 OS accompagné de l’USMT. Par défaut, la partie de l’ancien OS qui n’a pas été réutilisé est conservé dans le répertoire « C:\Windows.old ». Ce répertoire à l’avantage de diminuer le temps et la quantité de données à faire transiter par le réseau si l’on doit faire un retour arrière en XP par exemple (Revert to Snapshot). Cependant, ce répertoire prend de la place sur la machine et devra être supprimé par la suite.

Si l’on souhaite automatiser la suppression de ce répertoire pendant la migration, il faut suivre le mode opératoire suivant:

  1. Sur la machine de référence Windows 7, éditer le fichier « C:\ProgramData\Wanova\Mirage Service\post_migration.bat« 
  2. Ajouter les lignes suivantes dans le fichier avant la ligne « exit 0 » :

REG ADD « HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Previous Installations » /v StateFlags0033 /t REG_DWORD /d 00000002

cleanmgr /sagerun:33

Ce qui permettra après migration de la machine, d’ajouter un nouveau profile de nettoyage disques pour enlever seulement le répertoire « windows.old » puis de lancer ce nettoyage.

Le reste du mode opératoire est celui classique pour créer une base layer de migration Windows 7, c’est à dire lancer l’outil de préparation pour la migration puis capturer la Base Layer.

Mirage-post_migration

 

Juil/1350
Par Dans Mirage

La dernière version d’Horizon Mirage 4.2 dispose d’une nouvelle interface Web: Mirage Web Management. Il arrive que la page « /HorizonSuite » ne soit pas disponible après l’installation du composant. On a alors un message d’erreur HTTP 403.14 Forbidden:

HorizonMirageWebMgmtHTTP403.14Error Lire la suite…

Juin/1313
Par Dans Mirage

L’utilisation de licences Microsoft OEM sur des postes pour lesquels on travail depuis un master unique (re-imaging) est soumit à des contraintes légales et techniques avec n’importe quel outil. Pour rappel, les régles légales de Microsoft pour l’OEM sont les suivantes et s’applique à tous les produits utilisé pour cette gestion d’image:

  • le média de type Volume Licensing utilisé dans le master doit être du même niveau que les licences OEM sur les postes (même produit & version, contenir les même produits, et être de la même langue)
  • vous devez disposer d’un moins une licence de type volume (VLK) du produit pour avoir le droit de déployer un master sur X postes
  • le média de type Volume Licensing doit être utiliser pour faire le master.

Outre ces considérations légales, dans Mirage si l’on essayer de gérer un poste en licences OEM, on a un message d’erreur. Mais techniquement, on peut passer ce problème en plaçant une exception dans la « Base Layer Rule » pour ne pas modifier la clé de registre contenant la licence OEM. Pour cela, suivre le mode opératoire suivant:

  • Dans la « Mirage Management Console »,  aller dans la partie « Image Composer > Layer Rules« 
  • Faire un click-droit sur la règle par défaut et choisir « Clone » ou cliquer sur le « + » pour créer une nouvelle règle
  • Aller dans l’onglet « Software Hive » et dans la partie « Registry Keys to exclude » cliquer sur « Add« 
  • Ajouter la clé « Microsoft\Windows NT\CurrentVersion\ProductID« 
  • Cliquer 2 fois sur « OK »
  • Sélectionner la nouvelle règle, et d’un click-droit sélectionner « Set As Default« .

Voici à quoi ressemble cette règle avec l’exception:

Mirage_OEM-exception-rules

Ce workaround est une solution utilisable plutôt dans une phase de test ou pour simple faire de la sauvegarde des postes. Car légalement, pour distribuer un master unique sur des postes il faudra utiliser une clé volume. Et dans le cas de migration d’OS, il faudra en plus de la clé volume disposer d’une SA en complément de la licence OEM pour chacun des postes.

Mai/138
Par Dans Mirage

J’avais brièvement évoqué le fonctionnement par couche de Mirage dans l’article présentant Horizon Suite. Mais le but de cet article est de présenter plus en détail et surtout de façon illustrée la gestion des couches dans Mirage en fonction des cas d’usages.

Comme introduction, je vous recommande fortement de lire ces 2 articles très détaillés sur HorizonFlux:

Mirage4-App_Layering
Mirage fournit des mécanismes pour synchroniser un poste physique Windows avec son image (appelé CVD) dans le Datacenter. En plus des mécanismes d’optimisation des flux réseau, Mirage a l’intelligence de voir le contenu du poste comme un découpage en 6 couches (sans pour autant modifier le poste). Ensuite, les mécanismes permet de venir fusionner/mettre à jour/réinitialiser/restaurer ces couches en minimisant l’impact pour l’utilisateur.

On retrouve 3 grands types de couches: la couche master (en vert), les couches applicatives (en bleu) et la personnalisation du poste (en orange). En plus de ces couches, on pourrait également ajouter une 7e couche qui est tout ce qui n’est pas protégé (par exclusion). On peut paramétrer le contenu de ces couches en configurant les points suivants:

  • Layer Rules pour les couches vertes (et bleues).
  • Pendant la phase « Capture App Layer » (basé sur les Layer Rules) des couches bleues.
  • User Area (dans l’Upload Policy) pour les couches orange
  • Unprotect Area (dans l’Upload Policy) pour tout ce qui n’est pas protégé

Lire la suite…

Avr/1350
Par Dans Mirage

Lors de l’upgrade du/des serveur(s) Mirage, il faut passer par une phase d’uninstall/réinstall des composants comme expliqué dans le KB2031711. Bien entendu, on ne perd pas la configuration et les données stockées.

Par contre, lors de la phase de réinstallation, vous pouvez avoir un message d’erreur SQL qui vous dit que vous avez un problème de droit sur la base: « Failed install user rights validations. Failed to connect to database. Check server name, instance name and server settings« .

Mirage_SQL-error_user-rightsLa solution est en fait très simple, il suffit juste de ne pas renseigner de nom d’instance (et bien sûre, ne pas cocher la case « Create new storage areas »):

Mirage_SQLserver-config

Mar/135

Horizon-logoAnnoncé mercredi 20/2/2013 et disponible depuis hier, VMware marque une étape importante concernant son offre pour les utilisateurs finaux (EUC): Horizon Suite qui se qualifie comme « the platform for workforce mobility« . Ainsi, Horizon Suite permet d’offrir une plateforme complète de mobilité professionnelle permettant aux utilisateurs finaux de rester connectés à leurs données, à leurs applications et à leurs postes de travail sur n’importe quel appareil, et sans compromettre la sécurité ou le contrôle des systèmes d’information.
On peut le voir comme VMware l’avait annoncé lors des précédents VMworld, le portfolio End-User se complète pour être capable de couvrir tous les cas d’usages et l’intégration entre les produits est de plus en plus forte.
Lire la suite…

Jan/13260

Mirage_IconMalheureusement, je n’ai pas eu le temps de vous présenter la technologie Mirage de VMware. Je ne vais pas l’introduire ici car d’autres blogs l’ont déjà fait: en anglais sur le site de Vladan (avec des exemples d’utilisation) et en francais sur VirtualGeek.ch.

L’action de synchroniser un poste avec son image dans le datacenter dans Mirage s’appelle la « centralisation ». Les mécanismes de Mirage permettent d’optimiser ce transfert par la déduplication source, mais bien entendu le premier poste est nettement moins optimiser que les postes suivants. Il est donc recommandé de faire la centralisation du premier poste sur le LAN.

De plus, pour ne pas impacter les utilisateurs, Mirage limite le transfert réseau en fonction de la bande passante (network throttling) et la consommation CPU sur le postes (pendant le calcul des hash et la vérification d’intégrité) en fonction de l’activité de l’utilisateur (user throttling). Il existe aussi un bridage disque mais il est fortement recommandé de ne pas y toucher.

Simon Long a écrit récemment un article sur ce débridage lié à l’activité utilisateur, mais il est aussi possible de le faire sur le bridage réseau.

Voici la procédure à réaliser sur le poste (coté client):

  • Exécuter Notepad en tant qu’administrateur (Run as Administrator)
  • Ouvrir le fichier « C:\Program Files\Wanova\Mirage Service\Wanova.Desktop.Service.exe.config« 
  • Mettre le paramètre « throttleEnabled » (user) à « false »: <add key= »throttleEnabled » value= »true »/>
  • Mettre le paramètre « netThrottlingEnabled » (network) à « false »: <add key= »netThrottlingEnabled » value= »true »/>
  • Enregistrer le fichier
  • Redémarrer le service « Wanova Mirage Desktop Service« 

Nb: Il est important de ne pas modifier sur paramètre sur un poste qui servira de « Reference CVD ».