dimanche 28 novembre 2010

Hyper-V 2008 R2 : Guide de survie en appartement.

HyperRobot-2

Si vous avez comme moi installé un serveur Hyper-v chez vous, vous vous êtes probablement rendu compte que l’utilisation de cet engin obéit à certaines règles qui lorsqu'‘elle ne sont pas suivit peuvent au mieux perturber votre expérience utilisateur, et au pire cracher/réinstaller la bête ! Voici donc mon retour d’expérience sur les principaux écueils rencontrés, et comment les contourner : le “Do/Don’t” de l’hyperviseur d’appartement..

Il va sens dire que  tout ceci est du domaine du connu si vous êtes un professionnel de l’informatique. Cependant comme nous ne le sommes pas tous, ces quelques rappels éviteront au plus novices d’entre nous de s’arracher les cheveux.

1 – La bonne façon d’éteindre Hyper-v

N’étant pas en entreprise, vous éteigniez certainement votre Hyperviseur après avoir joué avec. Sachez que l’intégrité de votre hyperviseur ou de vos VM peuvent être compromis si vous ne prenez pas le plus grand soin à éteindre l’ensemble. Voici donc comment procéder : connectez vous sur chacune des VM est cliquez sur le bouton “Arrêtez” du menu démarrer. Une fois toutes les VM éteintes, connectez vous à l’hyperviseur est arrêtez le avec l’option 14 du menu principal.

2 – Protégez vos machines Virtuelle

Pour vous facilité l’administration, la sauvegarde , la migration et tout le reste ; Installer vos VM sur une autre partition que celle ou vous avez installé Hyper-V, ou mieux encore : sur un autre disque. Ainsi, si vous perdez le host (Hyper-v), vous n’aurez pas perdu vos VM.

Petit plus : si vous formatez la partition qui va recevoir les VM avec des clusters de 64 Ko, vous allez améliorer les performances générale de d’Hyper-V.

Sur vos VM la sécurité est également de mise, et quelques bonnes pratiques peuvent vous éviter de gros problèmes :

  • Activer RDP : Si vos VM ne remontent plus dans votre console d’ administration, vous pourrez toujours y accéder en utilisant RDP. De plus le protocole est plus rapide que celui de la console d’administration. Un tutoriel ici !
  • Installer un Antivirus : surtout si vos VM ont une patte vers internet. Qu’elle soit serveur ou Workstation. Microsoft propose un anti-virus gratuit qui fonctionne très bien sur serveur.
  • Installer et Configurer Server Backup : afin de réaliser une sauvegarde planifiée et régulière de  vos machines virtuel sur un partage réseau. Autre solution ; vous pouvez également exporter vos VM à intervalle régulier. Le but étant de restaurer vos VM en cas de défaillance de l’une d’elle… Pour l’anecdote j’ai du réinstaller une VM WSUS pour avoir juste perdu un GUID (fichier de moins de 1 ko) qui empêchait un service de démarrer.

3 – Protégez l’hyperviseur

La question de l’antivirus…

Comme vous l’avez constaté Hyper-v, c’est quand même du bon vieux serveur Microsoft en version allégée. Et donc, comme pour tout produit de la même marque, le premier reflexe qui vient à l’esprit, c’est la sécurité… Malheureusement, c’est une question qui ne trouve pas de réponse  acceptable dans le monde du gratuit… (Edit : Vous pouvez utiliser security Essential via ce tutoriel !) Evidement, dit comme cela, ça peu jeter un froid, mais comme le dit Ben Armstrong, si la machine n’est pas connectée à internet, c’est une chose qui se fait…

Activer la sauvegarde.

Aussi important que la sauvegarde de vos VM, la sauvegarde du host qui ce fait elle aussi via Server Backup. L’activation s’effectue de la façon suivante. D’autres infos également ici. Sans oublier bien sur, la question crucial : comment restaurer

4 – Problème courant

Connexion  impossible au service RPC !

peut arriver de façon inopinée, ou après un arrêt un peu rude… la console d’admin affiche le message suivant :

NO-RPC 

En premier lieu, désactivez votre par-feux, c’est un moyen simple d’y voir plus claire durant la période ou vous dépannez, et cela permet également de vérifier que le problème ne viens pas de là !

Re-enregistrez les identifiants de connexions de votre hyperviseur sur votre machine d’administration :

cmdkey /add:Mon_Hyper-v /user:Mon_hyper-v\CompteAdminHyper-V /pass:MotDepasseCompteAdmin

J’ai personnellement toujours récupéré ma console en utilisant cette commande !

Voila, avec ces quelques compléments vous devriez être capable de faire tourner Hyper-V sans trop de problèmes. La solution est, je doit le dire, extrêmement  robuste, est a déjà survécu plusieurs fois à la curiosité destructrice de mon fils de 3 ans…

samedi 20 novembre 2010

MDT 2010 : Fix error 87 - DISM /set-targetfile Failed

imagesCADQCT2Q

Il y'a deux semaine en préparant une installation de Windows dans MDT 2010, je tombe sur un bug particulièrement énervant : Lorsque je tente de mettre à jour mon DeploymentShare, l'opération échoue en me présentant le message suivant :

MDT-fail

Google et le reste du monde étant au abonnées absent, j'entreprends de troubleshooter moi même le problème, voici donc la solution, qui je l’espère pourra peut être éviter à d’autres les quelques jours de galère que je viens de vivre   :

- Si vous rencontrez cette erreur, vérifier bien dans la même fenêtre quel fichier WIM est utilisé par MDT pour créer le fichier de boot :

Windows PE WIM D:\-ADDS-\DeploymentShare\Operating Systems\Windows 7 x64\Sources\boot.wim will be used.

Si comme dans cet exemple MDT utilise le fichier boot.Wim de votre OS à déployer, le problème viens probablement là !
Un petit tour dans le log de DISM nous confirmera la cause du problème :
ouvrez le fichier : C:\Windows\Logs\DISM\dism.log et cherchez y la chaine "retrieved installroot"

Si les lignes de log se présentent comme suit :

DISM   PE Provider: CPEImg::GetInstallRoot: Successfully retrieved installroot X:\$windows.~bt\

C'est que le fichier Boot.wim et trop riche pour être utilisé en l'état par MDT. En effet, l'inspection de ce fichier révèle qu'il ne contient pas une, mais deux images en sont sein, ce qui ne semble pas être du gout de MDT.
 mdt-winpeCMD

Le remède à ce problème est donc simple : il faut proposer à MDT d'aller chercher sont fichier de Boot Windows PE ailleurs ! Et notamment d'utiliser à la places, les images WIM installées automatiquement avec le WAIK.

Comme il n'y a pas de méthode explicite pour dire à MDT ou il doit chercher, je vais simplement renommer le fichier boot.wim (il se trouve quelque par dans <Votre DeploymentShare>\Operating Systeme\sources) en boot.wim.old ce qui suffira pour qu’MDT cherche dans les répertoires du WAIK.

Si vous avez importés d'autres OS dans votre DeploymentShare, il sera peut être nécessaire de renommer les fichier boot.wim au sein de ces installations.

Pour Finir, je relance la mise à jour afin de vérifier que tout fonctionne :
Avant cela il faut fermer et rouvrir MDT afin qu'il libère les fichiers montés.

Roulement de tambour…, on vérifie au passage que MDT prend bien sont fichier dans le WAIK comme suit :

Windows PE WIM C:\Program Files\Windows AIK\Tools\PETools\amd64\winpe.wim will be used.

MDT-good

et voili, tournicoti !! Erreur Fixée !

Mots clés Technorati : ,,,