Le rôle du quorum au sein d’un cluster est souvent mal compris et peut mener à la mise en place d’une configuration éronée, surtout avec Windows Server 2008 où un nouveau modèle est disponible.

Tout d’abord, la définition du quorum dans son sens commun (Définition d’un quorum) :

“ En droit, le quorum est le nombre minimum de membres d'un corps délibératif nécessaire à la validité d'une décision. C'est souvent la moitié des membres, mais beaucoup d'entités ont un prérequis plus bas ou plus haut.

Lorsque le quorum n'est pas atteint, le corps délibératif ne peut pas tenir de vote et ne peut pas changer le statu quo. Ainsi, les votants en faveur du statu quo peuvent bloquer une décision en ne se présentant pas au vote. Le vote sera alors automatiquement rejeté et le statu quo conservé.

Dans un corps législatif, le quorum est habituellement la majorité des membres de l'entité y compris les postes vacants. Bien des corps ne prennent pas en compte le quorum à moins qu'une question ait été soumise à l'ordre du jour (par exemple un amendement). “

Il faut donc retenir les notions de “votants” et de “majorité” pour bien comprendre le rôle du quorum au sein du cluster.

Qu’est-ce que le quorum et a quoi sert-il ?

Il est fréquent de voir appeler “quorum” le disque utilisé pour stocker la configuration du cluster. C’est en partie vrai.

Dans un cluster configuré avec un disque quorum, ce disque joue le rôle d’arbitre.

Dans un cluster sans dique quorum, le quorum au sein d’un cluster représente l’ensemble des votants permettant d’assurer la continuité de fonctionnement du service cluster et la cohérence ce celui-ci. Je développe plus tard cet aspect de continuité de fonctionnement.

Une nuance cependant, avec Windows Server 2008, un modèle de quorum inclut le disque quorum comme votant.

En ce qui concerne son utilité, le quorum a trois rôles très simples :

1. Fournir un moyen d’arbitrer l’appartenance au cluster
   
   
   Lors du démarrage d’un noeud, celui-ci utilise une copie de la configuration du cluster présent en local pour identifier les autres membres du cluster. Un mécanisme de sponsoring permet alors au noeud en cours de démarrage de se joindre ou non au cluster. Si ce serveur est sponsorisé par un noeud déjà démarré et si le cluster est fonctionnel, alors il récupère une copie récente de la configuration du cluster (on appelle cette action un JOIN).
   
   
2. Aider à maintenir la cohérence du cluster
   
   
   C’est le rôle le plus important du quorum. Dans un scenario de split-brain, le quorum est utilisé pour garantir que les ressources partagées ne soient montées que sur un seul noeud. Le quorum est utilisé comme un tie-breaker dans ce scénario. Voir plus bas ce qu’est un split-brain.
   
   
3. Fournir un moyen de stocker la configuration du cluster
   
   
   Au sein d’un cluster, chaque noeud doit disposer d’une vue consistante de la configuration du cluster. Cela est rendu possible par la mise à disposition par le quorum de la configuration du cluster stockée dans le quorum log.

Qu’est-ce que le quorum log ?

Le quorum log est une base de données contenant la configuration du cluster :

• Les serveurs faisant parti du cluster
• Les ressources installées et partagées
• L’état des ressources partagées

Le quorum log est stocké par défaut dans \MSCS\quolog.log.

Qu’est-ce qu’un split-brain ?

Mot à mot, l’expression “split-brain” peut se traduire par “cerveau-scindé”. Hum… pas encore tout à fait clair…

Imaginons que le cluster soit un corps humain et que les membres du cluster (les noeuds) soient les lobes du cerveau.

Imaginons que ces lobes ne communiquent plus. On peut s’attendre à ce que le corps ne réagisse plus vraiment correctement, les ordres venant distinctement des deux lobes qui ne se synchronisent plus, et menant donc à quelque catastrophe…

Dans le cas d’un cluster, un split-brain intervient lorsque les liens réseau entre deux ou plusieurs noeuds subissent une défaillance. Le cluster est alors scindé en une ou plusieurs partitions qui ne peuvent plus communiquer entre elles.

Dans ce cas de figure, la partition détenant le quorum (le noeud 1 dans cet exemple) est seule autorisée à continuer à fonctionner. La seconde partition (le noeud 2) devra s’arrêter.

Le but de ce fonctionnement ? Eviter que plusieurs noeuds ne pouvant plus se “concerter” effectuent des opérations sur les ressources partagées menant à une inconsistence du service en cluster.

Exemple : un cluster Exchange est hébergé dans un cluster 2 noeuds. Le noeud 1 détient le quorum, le noeud 2 détient les ressources Exchange (les bases de données).

• Si le noeud 2 vient à perdre la communication avec le noeud 1 alors le noeud 2 va tenter de prendre l’ownership sur le quorum. S’il n’y parvient pas, le service cluster sur le noeud 2 va s’arrêter de lui-même car il va se considérer en mauvaise santé et donc incapable d’assurer son rôle.
  Le noeud 1 tentera alors de récupérer les ressources détenues par le noeud 2 et les remettres en service.
• Si le noeud 2 parvient à prendre l’ownership du quorum, alors c’est que le noeud 1 subit une défaillance. C’est alors le noeud 1 qui, s’il n’est pas déjà arrêté ou hors d’état de fonctionner, qui va arrêter le service cluster.
• Enfin, si ni le noeud 1 ni le noeud 2 ne parviennent à prendre l’ownership du quorum, alors le cluster est arrêté sur les deux noeuds.

Ces opérations visent à laisser la ressource en cluster sur un seul noeud. On ne peut avoir deux instances du même service fonctionner sur un réseau.

Vous me direz : mais pourquoi un noeud s’arrête t’il de lui-même si c’est le réseau qui a un problème ? Et bien, le noeud n’en sait rien. Il agit de manière proactive en constatant qu’il ne détient pas le quorum.

Et après tout, un problème réseau peut être causé par une défaillance de la carte réseau, d’un changement de configuration IP, sous Windows Server 2003 le service RPC ne répond plus, …

Bien sûr la réalité est un peu plus compliquée, il y a d’autres mécanismes que je n’ai pas détaillé ici qui entrent en jeu et qui complexifient la donne. Mais le principe est là.

Par exemple le cas où le cluster met en oeuvre plus de 2 noeuds. Dans ce cas, la notion de majorité est encore plus forte. La partition détenant le plus de votants est maintenue.

Les modèles de quorum

Disk Only

Dans ce modèle, seul le disque partagé dit “quorum” dispose d’un vote. Je lui attribue plutôt un rôle d’arbitrage.

Le cluster continue de fonctionner si au moins un noeud accède au disque quorum.

Cette configuration n’est généralement pas recommandée sous Windows Server 2008 et si ce modèle est toujours disponible, c’est… pour les nostalgiques !

Disk and Node Majority

Ce modèle a été intorduit avec Windows Server 2008. Le cluster dispose de trois votants : les deux noeuds et le disque quorum.

Le cluster continue de fonctionner si au moins deux votants sont fonctionnels.

Node Majority

Ce modèle de quorum entre en jeu lorsque le cluster est composé d’au moins trois noeuds et sans stockage partagé.

Pour que le cluster continue de fonctionner, il est nécessaire d’avoir une majorité de votants fonctionnels.

Node and File Share Majority

Le dernier modèle de quorum est implémenté lorsque qu’il n’y a pas de stockage partagé.

Il s’appuie sur les votants (les noeuds du cluster) et un témoin (un partage sur un serveur qui n’est pas un noeud).

Le cluster continue de fonctionner si la majorité des votants ET le témoin sont fonctionnels.

Le cas particulier du quorum sans disque partagé

Dans les configurations Node Majority et Node and File Share Majority, la configuration du quorum est stockée sur chaque noeud du cluster sur le disque système.

La consistence du réplica (le quorum log) sur tous les noeuds est assurée par le témoin (le File Share Witness) ou pas le cluster lui-même qui détermine qu’une modification est considérée comme permanente dès lors que cette configuration est présente sur la moitié des noeuds.

Comment choisir le modèle de quorum adéquat

Deux éléments sont à prendre en compte pour choisir le modèle de quorum :

• La présence ou non de stockage partagé : SAN ou iSCSI / cluster local ou géographique
• Le nombre de noeuds défaillants tolérés avant arrêt total du cluster

1ère étape : choix en fonction du stockage et de la répartition des noeuds

	Disk Only	Disk and Node Majority	Node Majority	Node and File Share Majority
Avec stockage partagé	X	X
Sans stockage partagé			X	X
Cluster local	X	X	X	X
Cluster géographique			X	X

2nde étape : choix en fonction de la tolérance aux défaillances (sans stockage partagé ni File Share Witness)

Nombre de noeuds (N)	Nombre de votants (V)	Tolérance aux défaillances : (V-1)/2
2	2	0
3	3	1
4	4	1
5	5	2
6	6	2
7	7	3
8	8	3

3ème étape : choix en fonction de la tolérance aux défaillances (avec stockage partagé ou File Share Witness)

Nombre de noeuds (N)	Nombre de votants (V)	Tolérance aux défaillances : (V-1)/2
2	3	1
3	4	1
4	5	2
5	6	2
6	7	3
7	8	3
8	9	4

Le piège a éviter

Prenons le cas d’un cluster Exchange sept noeuds configuré suivant le modèle Disk and Node Majority.

Sur ce cluster, quatre instances d’Exchange sont actives et trois noeuds sont passifs.

Si vous avez bien suivi, et si j’ai été clair, combien de votants peuvent subir une défaillance sans que cela n’impacte :

1. Les quatre instances actives ?
2. Le cluster dans son ensemble ?

La réponse à la première question est : les quatre instances Exchange restent fonctionnelles tant qu’un maximum de trois votants subissent une défaillance

La réponse à la seconde est : le cluster dans son ensemble reste fonctionnel tant qu’un maximum de trois votants subissent une défaillance

Jusque là tout va bien… mais en allant un peu plus loin, on peut dire que cette configuration amène un risque.

Pourquoi ? Il suffit qu’un votant supplémentaire subisse une défaillance pour que le cluster dans son ensemble ne fournisse plus le service qu’on attend de lui.

Et en l’occurence le risque vient du disque quorum. Si ce disque vient aussi à subir une défaillance alors la majorité n’est pas atteinte au sein du cluster. Le service cluster sera donc arrêté sur les noeuds fonctionnels afin d’éviter une inconsistance sinon de plus graves dommages au niveau du cluster et surtout de l'application en cluster.

Que faut-il tirer de cet exemple ?

Une recommandation très simple : toujours avoir un nombre impair de votants.

Conclusion

En définitive, la configuration du quorum dépend d’un certain nombre de facteurs dont le plus important est celui visant à déterminer le nombre de défaillances tolérées.

Dans la pratique, sur des clusters mettant en oeuvre plus de deux noeuds, une stratégie de secours doit être définie pour palier à la loi de Murphy. Cette stratégie s’inclut dans un plan de DRP (Disaster Recovery Plan) et la plupart du temps, implique la présence d’un cluster de secours ou tout au moins de procédures visant à remettre en service l’application en cluster le plus rapidement possible.

Ressources

Quelques ressources en anglais (les traductions restent parfois aléatoires) :

Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

Understanding Quorum Configurations in a Failover Cluster

Details of How Quorum Works in a Failover Cluster

Additional Information About Quorum Modes

Quorum resource

Troubleshooting Quorum Resource Problems

KB309186 - How the Cluster service reserves a disk and brings a disk online

Guillaume

Windows Core Support Escalation Engineer

Dans cette seconde édition, encore une fois des informations compilées au fil du mois dont certaines sont déjà un peu tièdes mais où d’autres sont à peine sorti du four sinon pas encore révélées…

Beaucoup de virtualisation (oh… encore ?) mais aussi une petite touche de Windows 7 et de debugging sans compter l'interview de Bernard Ourghanlian.

Bonne lecture !

NVidia et AMD met à disposition des drivers pour Windows 7

Lien : Drivers NVidia pour Windows 7

Lien : Drivers ATI Catalyst pour Windows 7

Les solutions d’hébergement de services de Microsoft

Concrétisation de l’offre “Software+Services”, Microsoft Online Services est là !

Les services proposés sont pour le moment Exchange Online, SharePoint Online, Office Live Meeting ou Office Communication Online. Un beau début !

Lien : Microsoft Online Services

Lien : pour les partenaires

Référence sur TCP/IP

Un peu de litérature sur les clés de registre concernant TCP/IP pour Windows Vista/Windows Server 2008

Lien : TCP/IP Registry Values for Microsoft Windows Vista and Windows Server 2008

Hypervisors benchmark

Dans un secteur où le benchmarking reste très délicat à mettre en oeuvre (A Big Step Backwards for Virtualization Benchmarking, Benchmarks: ESX vs Hyper-V vs XenServer), voici un comparatif montrant les performances des hypervisors de VMware (ESX), Citrix (XenServer) et Microsoft (Hyper-V), où l’on peut se figurer les différences de ces trois produits en fonction de la façon de les utiliser.

Le bench est relativement simple et, à mon sens ne montrant pas un bénéfice évident, mais il a l’intérêt de présenter tout le contexte des tests exécutés.

Lien : Lab Experiment: Hypervisors

Hyper-V Security Guide

Disponible en beta sur Connect, ce document aborde les aspects de hardening, de délégation d’administration et de protection des machines virtuelles.

Lien : Hyper-V Security Guide (nécessite un LiveID)

Dynamic Data Center Toolkit

Bien qu’encore un peu pauvre en contenu ce site a (ou aura) le mérite d’adresser les problématiques de déploiement, d’administration, de maintenance et de haute disponibilté d’un data center.

A suivre donc…

Lien : Dynamic Data Center Toolkit

Disponibilité de la beta de SCVMM 2008 R2

Disponible sur Connect.

Lien : SCVMM 2008 R2 Beta

Un nouveau compétiteur dans le monde de la virtualisation ?

Cisco vient d’annoncer une nouvelle solution (ou gamme de produits) appelée Cisco Unified Computing System permettant de rationnaliser les aspects réseau, computing, stockage, gestion.

Lien : Cisco Unleashes the Power of Virtualization with Industry's First Unified Computing System

L’annonce de Microsoft : Microsoft Partners With Cisco on New Unified Computing System

Hyper-V Planning and Deployment Guide 1.2

Lien : Hyper-V Planning and Deployment Guide

Le futur du déploiement du poste de travail

Où Bernard Ourghanlian livre quelques projections (retenons bien ce terme, car à ce jour un certain nombre des sujets abordées en sont encore à l’état d’étude) sur la virtualisation d’applications et du poste de travail, Hyper-V v3, Windows 8, les évolutions des processeurs, bref un paquet de choses intéressantes !

Lien : Il faut complètement repenser le déploiement du poste de travail - 1ère Partie

Lien : Il faut complètement repenser le déploiement du poste de travail - 2ème Partie

Lien : Il faut complètement repenser le déploiement du poste de travail - 3ème Partie

Internet Explorer 8 RTM

Disponible uniquement pour Windows XP, Windows Server 2003, Windows Vista et Windows Server 2008.

Lien : Internet Explorer 8: Home page

Téléchargement : téléchargement

Antivirus pour Windows 7

Une liste d’antivirus sur le blog de Stanislas Quastana.

Lien : Antivirus pour Windows 7 - Mise a jour de la liste

Une extension du debugger pour identifier les problèmes potentiels d’une application en développement

Lien : !exploitable Crash Analyzer – MSEC Debugger Extensions

Lien : Présentation PowerPoint

Les webcasts des Microsoft TechDays 2009 disponibles

Lien : Webcasts TechDays 2009

Comprendre la virtualisation

Vaste thème… mais voici 500 pages traitant de tous les aspects de la virtualisation : Hyper-V, MEDV, App-V, SCVMM.

Ce document est téléchargeable après identification avec votre LiveID.

Lien : Understanding Microsoft Virtualization Solutions

Linux Mouse Integration Components pour SUSE disponibles

La prise en charge de la souris dans une machine virtuelle est donc effective sur les distributions SLES 10 SP2, x86 et x64.

Lien : Citrix Project Satori

Représentation graphique de l’utilisation des ressources sur un hôte Hyper-V

Outil intéressant pour ceux qui cherchent à avoir une représentation simple des performances de l’hyperviseur, de la partition parente et des machines virtuelles.

Lien : TMurgent Tools

Microsoft IT Show Case – Meilleures pratiques pour le déploiement des machines virtuelles sous Hyper-V

C’est bien connu, Microsoft est lui-même son premier et meilleur client. Bien en amont de leur mise à disposition pour les entreprises et pour le grand public, Microsoft IT met en oeuvre les technologies livrées par les groupes de développement.

C’est effectivement le cas pour la virtualisation et encore une fois cela a permis d’en retirer une expérience concrète qui est mise à disposition de tous.

Lien : Best Practices for Deploying Virtual Machines by Using Hyper-V Virtualization Technology

Lien : Technical White Paper

Lien : IT Pro Webcast

Lien : WMA

Intel sur le point de révéler un nouveau processeur

La virtualisation on en parle beaucoup autour du logiciel. Mais savez-vous que sans le hardware rien ne serait possible ?

Grâce aux prouesses des ingénieurs des deux fondeurs bien connus autour de ce que l’on appelle la virtualisation assistée par le matériel (ça sonne mieux comme ça : Hardware Assisted Virtualization).

Et comme l’avancée technologique ne s’arrête jamais, dans cette partie aussi l’avenir est encore plus brillant qu’aujourd’hui.

Ainsi Intel est sur le point de révéler un nouveau modèle de processeur pour les plateformes serveurs qui amène un beau bouquet d’innovations qui permettront d’optimiser encore plus les plateformes virtualisées.

C’est pour très bientôt et peut-être en parlerons-nous lors de notre journée virtualisation du mardi qui vient…

Guillaume

Windows Core Support Escalation Engineer

Sur les serveurs hébergeant le rôle Hyper-V où une carte graphique contrôlée par un driver mettant en oeuvre les fonctionnalités d’accélération des performances graphiques est installée, il est fortement probable de subir certaines baisses de performance.

En effet, comme l’allocation de la mémoire est assumée par l’hyperviseur, cela génère de nombreuses interceptions qui ralentissent le fonctionnement général de la plateforme.

La solution : laisser le driver générique inclus avec Windows Server 2008 : VGA.SYS ou VGAPNP.SYS.

Avons nous besoin d’un affichage performant sur un serveur ? Pour ma part, je pense que non… Qui lit des vidéos ou joue à des jeux sur une plateforme serveur ?

KB961661 - Video performance may decrease when a Windows Server 2008-based computer has the Hyper-V role enabled and an accelerated display adapter installed

Guillaume

Windows Core Support Escalation Engineer

Le webcast de la session présentée par Hervé est disponible.

Débogage d’applications en production (Web, Service, NT et autres…)

Autre webcast, la session de Jérôme Mombelli, un ancien ingénieur support, et Christophe Dubos à propos de la technologie cluster et Hyper-V :

Haute disponibilité en environnement Windows Server : bonnes pratiques et principales évolutions au sein de R2

Et pour le plaisir, la session d’Arnaud Lheureux sur Direct Access :

Windows Server 2008 R2 DirectAccess : accès au réseau d'entreprise sécurisé et transparent

Guillaume

Windows Core Support Escalation Engineer

Il peut arriver que le redémarrage d’un serveur Windows Server 2003 ne fonctionne pas comme il le faudrait.

Divers symptômes peuvent apparaître dont celui de l’écran noir avec le logo Windows et la barre de progression qui tourne en boucle avec parfois un cursor qui clignote en haut à gauche de l’écran.

Après avoir essayé tous les modes de démarrage proposé par Windows (mode sans échec, avec ou sans réseau, mode VGA, …), le serveur ne parvient toujours pas à démarrer.

Quelques fiches techniques traitent de ce dysfontionnement :

• KB325375 - How to troubleshoot startup problems in Windows Server 2003
• KB244905 - How to Disable a Service or Device that Prevents Windows from Booting
• KB316434 - How to perform advanced clean-boot troubleshooting in Windows XP
• KB199175 - Situations in Which Windows May Not Start in Safe Mode

Processus de démarrage

Tout d’abord, il est intéressant de connaître le méchanisme de démarrage de Windows que l’on peut découper en cinq phases (il y en a quatre mais j’ai découpé la première en deux).

Je les ai décrites ci-après de manière très succinte mais suffisament pour identifier quel composant impliquer lors d’un problème de démarrage.

La première étape est purement matérielle et est connue sous l’appellation P.O.S.T. (Power On Self Test). Cette phase consiste à effectuer des vérification au niveau de la carte mère, du CPU, etc…

Cette étape est “software agnostic”.

A cette étape, le BIOS va tenter d’accéder au premier périphérique de démarrage comme spécifié dans les options du BIOS afin d’y trouver le premier secteur du disque afin de vérifier la présence du MBR (Master Boot Record). Le MBR étant identifié, il s’agit de lire le Boot Sector de la partition active.

A cet instant, le Boot Sector de la partition active va se charger et chercher NTLDR pour l’exécuter.

NTLDR se charge et bascule le mode d’exécution du processeur du mode réel en mode 32 bit puis il charge le mini driver NTFS contenu dans son code.

Le fichier BOOT.INI est lu afin de lister les options de démarrage qui seront affichée à l’écran (si plus d’une option sont présentes dans le BOOT.INI).

Le démarrage commence par le chargement de NTDETECT.COM qui va énumérer tout les périphériques supportés et les renvoyer à NTLDR.

NTLDR va alors charger NTOSKRNL.EXE et HAL.DLL en mémoire puis charger la ruche SYSTEM de la base de registre en mémoire afin de construire la branche HKLM\System\CurrentControlSet.

NTLDR lit la clé HKLM\System\Select\Current afin de déterminer quel version de CurrentControlSet il doit utiliser.

NTLDR copie alors la branche CurrentControlSet sélectionnée dans  HKLM\System\CurrentControlSet.

NTLDR énumère la branche HKLM\System\CurrentControlSet\Services pour identifier les drivers qui ont un statut de démarrage à 0x0 afin de les charger en mémoire.

NTLDR exécute alors NTOSKRNL.EXE et lui passe la liste des périphériques identifiés par NTDETECT.COM et le contrôle du processus de démarrage.

Le kernel affiche le logo Windows et la barre de progression.

Le kernel créé la branche HKLM\Hardware avec les données qui lui ont été transmises par NTLDR.

Le kernel créé la branche HKLM\System\Clone à partir du contenu du CurrentControlSet sélectionné au démarrage.

Le kernel initialise les drivers ayant un statut de démarrage à 0xà identifiés par NTLDR.

Le kernel énumère la branche HKLM\System\CurrentControlSet\Services pour identifier les drivers qui ont un statut de démarrage à 0x1 afin de les charger en mémoire et les initialiser.

Le kernel exécute SMSS.EXE (Session Manager Subsystem).

SMSS.EXE démarre les autres subsystems et les services, vérifie si un ChkDsk doit être exécuté, initialise la base de registre, détermine et configure la configuration de pagination, et enfin charge CSRSS.EXE (Client/Server Run-time SubSystem ).

CSRSS.EXE initie Winlogon.

SMSS.EXE démarre les drivers ayant un statut de démarrage à 0x2.

WINLOGON.EXE exécute LSASS.EXE (Local Security Authority Subsystem) qui permet d’interroger la base SAM et/ou Active Directory.

WINLOGON.EXE affiche la fenêtre d’authentification (Ctrl+Alt+Del)

SERVICES.EXE (précédemment chargé par SMSS.EXE) identifie les services ayant un statut de démarrage à 0x2 n’étant pas encore chargé.

SERVICES.EXE va tenter de démarrer les drivers ayant un statut de démarrage à 0x3.

Pour le reste du processus de logon concernant l’authentification, ce n’est plus du ressort de l’équipe Core et je ne m’aventurerais pas sur ce terrain mais nous avons l’essentiel.

Plus de détails sur les deux premières phases sont disponibles ici :

• How Windows starts up part 1 of 4
• How Windows starts up part 2

Revenons à notre problème de démarrage. Nous pouvons sans trop nous avancer dire qu’il est situé dans l’étape assumée par le kernel.

Donc potentiellement, il peut y avoir plusieurs causes à ce problème et je vais tenter d’en aborder certaines :

• Partition système corrompue (impossibilité de charge les ruches de la base de registre car fichier inaccessible, …)
• Corruption de la base de registre
• Driver filtre défectueux ou ne fonctionnant pas correctment
• Disque physique défectueux
• …

De quoi a t’on besoin pour traiter ce problème ?

Les outils indispensables pour traiter ce type de problème :

• WinPE 2.1
• Un CD-ROM original Windows Server 2003 (de la même version que le serveur installé, i.e. SP1, SP2)
• Les drivers de la carte de stockage
  • De la même architecture et pour la bonne version de l’image WinPE
  • De la même architecture et pour la bonne version de la version installée de Windows
• Un logiciel permettant de graver les fichiers ISO (DVDBURN et CDBURN sont les seuls outils supportés par Microsoft pour graver des fichiers ISO bootables)
• Un lecteur de disquettes (USB ou intégré au serveur) et une disquette (comme quoi, vous avez eu raison de ne pas tout jeter à la benne !)

Il est tout a fait possible de se passer de WinPE mais il s’avère souvent qu’il est plus pratique de l’utiliser que la Recovery Console.

Création d’une image WinPE 2.1

1. Télécharger et extraire les drivers de la carte de stockage (dans C:\Temp\Drv par exemple)
2. Télécharger le WAIK (téléchargement)
3. Lancer Windows PE Tools Command Prompt depuis Start | Programs | Microsoft Windows AIK
4. Tapez les commandes suivantes :
   1. COPYPE x86 C:\Temp\WinPE_x86 –> création d’une structure de répertoires permettant de personnaliser une image WinPE
   2. IMAGEX /MOUNTRW C:\Temp\WinPE_x86\ISO\Sources\boot.wim 1 C:\Temp\WinPE_x86\Mount –> on monte l’image WinPE pour pouvoir la personnaliser
   3. PEIMG /INF:C:\Temp\Drv\driver.inf C:\Temp\WinPE_x86\Mount\Windows (où driver.inf représente le fichier .INF présent dans le package du driver) –> injection du driver de stockage
   4. IMAGEX /UNMOUNT C:\Temp\WinPE_x86\mount /COMMIT –> démontage de l’image WinPE avec prise en compte des modifications
   5. OSCDIMG –n –m –betfsboot.com C:\Temp\WinPE_x86\ISO C:\Temp\WinPE_x86\WinPE_x86.ISO –> création d’un fichier ISO bootable
   6. CDBURN D: C:\Temp\WinPE_x86\WinPE_x86.ISO –> gravure du fichier ISO

Méthode 1 – Vérification de la consistence du volume système

1. Démarrer sur le CD gravé précédement
2. A l’invite de commande, exécuter la commande suivante : CHKDSK C: /F /R

Un volume sain présentera le résultat suivant :

Dans le cas contraire, il sera présenté un certain nombre d’erreurs et le statut de Check Disk devrait indiquer ce qui a été corrigé ou non.

En fonction du nombre et de l’importance des erreurs, un redémarrage pourra être effectué afin de vérifier si le problème de démarrage survient toujours.

Si oui, passer à la méthode suivante.

Méthode 2 – Utilisation d’une copie antérieure de la base de registre

Après le premier logon suivant l’installation de Windows, une copie des ruches de la base de registre est effectuée dans le dossier C:\Windows\Repair.

Additionnellement, a chaque fois qu’une sauvegarde impliquant un System State complet est initiée, cette copie est effectuée.

L’idée ici est de démarrer Windows sur une version antérieure de la base de registre qui serait jugée fonctionnelle.

1. Démarrer sur le CD gravé précédement
2. A l’invite de commande :
1. Aller dans C:\Windows\System32\Config
2. Renommer les fichier SOFTWARE et SYSTEM en SOFTWARE.BCK et SYSTEM.BCK (ex: REN SOFTWARE SOFTWARE.BCK)
3. Copier les fichiers SOFTWARE et SYSTEM présents dans C:\Windows\Repair dans C:\Windows\System32\Config (ex: COPY C:\Windows\Repair\SOFTWARE C:\Windows\System32\Config)
3. Redémarrer le serveur

Si cela ne résoud pas le problème, effectuer le manipulation dans l’autre sens :

1. Démarrer sur le CD gravé précédement
2. A l’invite de commande :
1. Aller dans C:\Windows\System32\Config
2. Supprimer les fichier SOFTWARE et SYSTEM
3. Renommer les fichier SOFTWARE.BCK et SYSTEM.BCK en SOFTWARE et SYSTEM (ex: REN SOFTWARE.BCK SOFTWARE)

Passer à la méthode suivante.

Méthode 3 – Désactivation de drivers filtre – méthode simple

Dans les modes de démarrage sans échec, un nombre limité de driver sont chargés en mémoire mais il se peut qu’une application ait modifié la liste initiale de ces drivers pour pouvoir être chargé dans tous les cas.

Un driver de stockage pourrait éventuellement avoir besoin d’être chargé même en mode sans échec.

Cette méthode consiste à désactiver les drivers filtres internant très tôt dans le processus de démarrage afin de vérifier s’ils interviennent dans le dysfonctionnement.

Elle a pour avantage de respecter les meilleures pratiques mais se révèle fastidieuse vu le nombre de drivers et services qui sont listés.

Il faut donc évaluer la complexité de cette méthode avec la méthode suivante (n’oublions pas que même en mode sans échec, le serveur ne démarre pas) qui permet d’identifier plus rapidement un driver posant potentiellement problème.

1. Démarrer sur le CD originel de Windows Server 2003
2. Si un driver de stockage est requis, insérer la disquette contenant les fichiers du driver de stockage pour Windows Server 2003 et appuyer sur F6 lorsque le setup le demande (attention : cette étape passe très vite)
3. A l’affichage du premier écran, appuyer sur R
   
4. Dans l’écran suivant, sélectionner l’installation à réparer et taper le mot de passe Administrateur local (attention clavier anglais sur installations Windows Server 2003 en anglais) :
    
5. Aller dans C:\Windows\System32 et taper la commande : LISTSVC
   
6. Une fois identifié les drivers à désactiver, taper la commande suivante pour chacun d’eux (ex: driver du clavier) : DISABLE Kbdclass
   
7. Redémarrer le serveur

Si le serveur démarre, faire en sorte de réinstaller une version stable du ou des drivers qui ont été désactivés.

Sinon, suivre la procédure suivante.

Méthode 3 bis – Désactivation de drivers filtre du mode Safe Mode (Mode sans échec) – méthode avancée

Cette méthode a l’avantage de permettre l’identification d’un driver qui poserait problème dans une liste très réduite puis de le désactiver pour un démarrage normal.

Cependant, elle recquiert une certaine prudence car l’on manipule la base de registre. Donc, comme diraient certains : Use with caution ! En tout cas, avec l’aide d’un ingénieur support, vous ne vous poserez pas de questions.

1. Démarrer sur le CD gravé précédement
2. A l’invite de commande exécuter REGEDIT
3. Charge la ruche SYSTEM du serveur dans Regedit:
1. Sélectionner HKEY_LOCALE_MACHINE
2. Menu File | Load Hive…
3. Sélectionner le fichier C:\Windows\System32\Config\SYSTEM
   
4. Cliquer sur Open
5. Donner un nom temporaire a cette branche (ex: SSRV_SYSTEM)
   
4. Aller dans HKLM\SRV_SYSTEM\Select et identifier la valeur de Current (cette valeur permet d’identifier dans quel ControlSet travailler)
5. Aller dans HKLM\SRV_SYSTEM\ControlSetX\Control\SafeBoot\Minimal (ou X est la valeur identifiée précédement)
    
6. Exporter toute la branche sélectionnée (sur le disque C:)
7. Identifier les drivers qui pourraient être impliqués dans le problème de démarrage et supprimer la clé correspondante (ex: PCMCIA Adapter) :
   
8. Sélectionner HKLM\System\SRV_SYSTEM
9. Menu File | Unload Hive…
10. Redémarrer le serveur en mode sans échec

Note : identifier les drivers Anti-Virus, gestionnaires de quota, filter drivers OEM, drivers de carte de stockage OEM, …

Si le serveur démarre, désactiver le ou les drivers de manière permanente depuis Device Manager :

Après le démarrage, faire en sorte de réinstaller une version stable du ou des drivers qui ont été désactivés.

Si le serveur ne démarre toujours pas… il ne reste que peu de solutions… très peu.

Suivre donc la méthode suivante.

Méthode 4 – Réparation de l’installation

1. Démarrer sur le CD originel de Windows Server 2003
2. Si un driver de stockage est requis, insérer la disquette contenant les fichiers du driver de stockage pour Windows Server 2003 et appuyer sur F6 lorsque le setup le demande (attention : cette étape passe très vite)
3. A l’affichage du premier écran, appuyer sur ENTER
   
4. Appuyer sur F8 pour accepter l’accord de licence
5. A l’affichage de l’écran suivant, appuyer sur R :
   
6. Le setup va alors entamer la réinstallation de Windows en préservant les paramètres existants

Méthode 5 – Reinstallation et/ou restauration du système

Parfois il vaut mieux gagner du temps et rendre le service disponible plus rapidement en passant par une réinstallation de Windows suivi (dans le meilleur des cas) par une restauration éventuelle du système mais surtout des données.

Tout dépend de la complexité de la configuration du serveur et de sa criticité.

Guillaume

Windows Core Support Escalation Engineer

Suite au bulletin précédement posté sur notre blog et comme annoncé, la fiche technique décrivant le statut officiel du support des fonctionnalité de teaming est disponible.

L’article ne présente pas de nouveauté par rapport à tout ce qui a déjà été dit : les fonctionnalités de teaming sont supportées par le constructeur…

KB968703 - Microsoft Support Policy for NIC Teaming with Hyper-V

En tout cas, c’est dit…

Guillaume

Windows Core Support Escalation Engineer

Il se peut que vous subissiez un problème de connexion à vos machines virtuelles via VMConnect.

Dans ce cas, vous trouverez le bulletin officiel concernant ce comportement sur le blog officiel de la division Windows Server : Hyper-V certificate expiration and resolution.

Et l’article technique correspondant : KB967902 - You cannot connect to a virtual machine when the Windows Server 2008 Hyper-V VMMS certificate has expired

Guillaume

Windows Core Support Escalation Engineer