KMS, ou Key Management System, est un service permettant de répondre aux demandes d’activation des systèmes Windows Vista et Windows Server 2008 sans spécifier de clé au niveau des machines “clientes” ni avoir besoin de contacter les services d’activation de Microsoft sur Internet.

Ce mécanisme permet de centraliser la gestion de l’activation de ces deux systèmes d’exploitation en exposant le moins possible ces clés (pas de diffusion dans un master, pas de clé transmise à des milliers de personnes, …).

Principe de fonctionnement de KMS

En bleu, la séquence d’activation du service KMS et en orange, la séquence d’activation d’un client KMS :

Installation :

1. Sur un hôte Windows Server 2003, après l’installation du service KMS, la clé KMS doit être spécifiée. Sur un hôte Windows Server 2008 ou Windows Vista, la fourniture de la clé KMS active le service KMS (il n’est pas nécessaire de l’installer car il est déjà présent).
   
   
2. Le service KMS contacte les services d’activation Microsoft sur internet (Microsoft Hosted Activation Services). Cette opération n’est réalisée qu’une seule fois. Aucun autre contact avec les services de Microsoft n’intervient par la suite sauf en cas d’ajout d’une autre clé KMS ou de renouvellement.
   
   
3. Par défaut, le service KMS tente de créer un enregistrement SRV dans DNS. Ceci permet aux clients de le trouver facilement.

Processus d’activation :

1. Après l’installation de la machine, le service Software Licensing tente de contacter l’hôte KMS. Tout d’abord, ce service vérifie dans la base de registre locale si un hôt KMS est spécifié. Si c’est le cas, nous passons à la seconde étape. Si ce n’est pas le cas, le service tente d’identifier l’hôte KMS en effectuant une requête DNS.
   
   
2. Le client forme sa demande d’activation en créant son Client Machine ID puis en signant sa requête (avec de l’encryption AES) et l’envoie à l’hôte KMS en TCP sur le port 1688 (le port utilisé par KMS peut être modifié).
   Cette requête est réémise toute les deux heures en cas d’échec (dans le cas d’une machine en période de grace) ou tous les sept jours (pour une machine déjà activée via KMS).
   
   
3. Après avoir reçu la requête d’activation, l’hôte KMS ajoute le CMID (Client Machine ID) à sa table.
   A noter que seuls les 50 derniers clients ayant demandés une activation sont présents dans cette table. Ceci permet à l’hôte KMS de s’assurer de son bon fonctionnement.
   
   
4. L’hôte KMS renvoie au client le décompte d’activations (le nombre de demande d’activation déjà effectuées).
   
   
5. A la réception de la réponse, le client évalue le décompte d’activations et la compare à la stratégie de license (voir plus bas cet aspect). Si le décompte a dépassé le nombre minimal de demandes d’activation, le client s’active et stocke le Product ID de l’hôte KMS, les fréquences d’activation et le Client Hardware ID.

Notion de décompte d’activation : pour qu’un hôte KMS commence à délivrer des activations aux clients qui les demandent, il est nécessaire qu’au moins 25 systèmes physiques Windows Vista ou 5 systèmes physiques Windows Server 2008 aient fait la demande. Les machines virtuelles ne sont pas comprises dans ce décompte.

Une fois atteint ce compteur, les machines qui réclament une activation pourront être activées.

Quelques exemples de décomptes :

Pour ce qui concerne le cycle d’activation des clients, le voici :

OOB = Out-of-Box

OOT = Out-of-Tolerance

Mode dégradé = remplace le mode RFM (Reduced Functionality Mode) sur les machines Windows Vista SP1 et Windows Server 2008. Si une machine atteint l’état de mode dégradé, l’utilisation du système reste toujours possible, seuls des notifications serint affichées pour rappeler l’état non activé de la machine.

Les systèmes concernés

Les systèmes d’exploitation pouvant être activés via KMS sont les suivants (achetés en mode License en Volume) :

• Windows Vista Professionnel (Business Edition)
• Windows Vista Enterprise (Enterprise Edition)
• Toutes les éditions de Windows Server 2008

Afin de simplifier la gestion des clés KMS, plusieurs types de clés KMS sont disponibles. Les clés sont regroupées en quatre groupes, représentés ci-dessous :

• Clés Client Volume License : permet d’activer uniquement des machines Windows Vista Enterprise et Professionnel
• Clés Groupe A : permet d’activer des machines Windows Server 2008 Web Edition et les produits du groupe Client Volume License
• Clés Groupe B : permet d’activer des machines Windows Server 2008 Enterprise et Standard Edition et les produits du groupe Client Volume License et du Groupe A
• Clés Groupe C : permet d’activer des machines Windows Server 2008 DataCenter Edition et les produits du groupe Client Volume License, du Groupe A et du Groupe B

KMS pas à pas

Les étapes pour mettre en œuvre un serveur KMS sont les suivantes :

Note : la plupart des commandes exécutées avec slmgr.vbs requièrent l’exécution depuis un prompt CMD en mode privilégié.

1. Installation du service KMS
   
   
   
   1. Si le service KMS doit être hébergé sur un serveur Windows Server 2003, télécharger le programme d’installation :
      
      
      Service Gestionnaire de clés 1.1 (x86) pour Windows Server 2003 SP1 et versions ultérieures
      Service Gestionnaire de clés 1.1 (x64) pour Windows Server 2003 SP1 et versions ultérieures
      
      
2. Activation du service KMS
   
   
   
   1. Exécuter la ligne de commande : cscript %WINDIR%\System32\slmgr.vbs –ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXX (où XXXXX-XXXXX-XXXXX-XXXXX-XXXX est la clé KMS)
      
      
      
      Pour que cette commande fonctionne sur un serveur Windows Server 2008, il faut utiliser une clé KMS appartenant au groupe de licences correspondant au serveur (voir plus bas les groupes de licences). L’utilisation d’une clé KMS pour Windows Vista avec slmgr.vbs retourne le code d’erreur 0xC004F015
      
      
      Sur un serveur Windows Server 2008 ou Windows Vista, cette commande active le service KMS
      
      
   2. Si le serveur hébergeant le service KMS a accès à internet, exécuter la ligne de commande : cscript %WINDIR%\System32\slmgr.vbs –ato
      
      
   3. Si le serveur KMS ne dispose pas d’un accès à internet, exécuter la ligne de commande : slui.exe 4 et suivre les instructions affichées à l’écran qui consistent à appeler le centre d’activation Microsoft et écouter la voix mélodieuse de l’automate.
      Cette étape prend quelques minutes le temps de donner l’identifiant d’installation et de rentrer ensuite l’identifiant de confirmation :
      
      
      
   4. Redémarrer le service Software Licensing Service

Une fois le serveur KMS opérationnel, les clients peuvent commencer à demander une activation. On peut donc attendre que le cycle par défaut s’en charge ou alors forcer ces demandes en exécutant la ligne de commande suivante sur les clients : cscript %WINDIR%\System32\slmgr.vbs –ato.

Il est possible de vérifier le statut du serveur KMS en exécutant sur l’hôte KMS la ligne de commande suivante : cscript %WINDIR%\System32\slmgr.vbs –dlv (ou –dli pour un résultat moins verbeux)

On voit ici que le serveur est activé (License Status : Licensed), que le service KMS est actif (Key Management Service is enabled on this machine) mais que le décompte d’activation est à 0 ce qui veut dire qu’aucune machine n’a encore demandé d’activation.

Vous comprendrez maintenant qu’il ne faut pas spécifier de clé KMS lors de l’installation (ou même après) des autres machines de l’environnement !

Du côté client, si l’on force une demande d’activation, on obtient ceci :

Retour du côté serveur où nous avons deux requêtes d’activation qui ont été reçues et un décompte d’activation à 1 (la même machine a effectué 2 requêtes), il nous en faut 5 émanant de machines Windows Server 2008 ou 25 émanant de machines Windows Vista :

Lorsque le décompte d’activation atteind le seuil requis, la prochaine requête d’activation devrait donner ceci :

Et du côté serveur :

Où on voit deux machines ayant reçu une activation.

Options de configuration

• Pour désactiver la publication automatique du service KMS dans DNS, créer la clé de registre suivante sur l’hôte KMS avant son activation :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
Nom : DisableDnsPublishing
Type : REG_DWORD
Valeur : 1

• Pour créer manuellement l’enregistrement SRV pour le service KMS dans un DNS Microsoft :

Depuis la console DNS, sélectionner la zone DNS où l’enregistrement doit être créé puis “Click droit | Nouveaux enregistrements”

Sélectionner l’enregistrement de de type “Emplacement du service (SRV)” et cliquer sur “Créer  un enregistrement”

Spécifier les informations suivantes :

Service: _VLMCS
Protocole: _TCP
Port: 1688
Hôte offrant ce service: <FQDN_hôte_KMS>

• Pour spécifier le serveur KMS qui doit être utilisé sur les clients, exécuter la ligne de commande cscript %WINDIR%\System32\slmgr.vbs /skms <KMS_FQDN>:<port> (ou l’adresse IP ou le nom NetBIOS de l’hôte KMS).

• Pour réactiver la détection automatique de l’hôte KMS sur un client , exécuter la ligne de commande cscript %WINDIR%\System32\slmgr.vbs /ckms

• Pour modifier le port utilisé par défaut (1688) par le service KMS, créer la clé de registre suivante sur l’hôte KMS et sur les clients KMS :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
Nom : KeyManagementServicePort
Type : REG_SZ
Valeur : <port>

• Pour modifier l’intervalle de tentative de première activation par défaut (2 heures), modifier la clé de registre suivante :
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
  Nom : VLActivationInterval
  Type : REG_DWORD
  Valeur : nombre de minutes (2 heures = 120 minutes)

• Pour modifier l’intervalle de renouvellement de l’activation par défaut (7 jours), modifier la clé de registre suivante :
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
  Nom : VLRenewalInterval
  Type : REG_DWORD
  Valeur : nombre de minutes (7 jours = 10080 minutes)

D’autres options de configuration sont disponibles dans le guide Volume Activation 2.0.

Ce qu’il peut être utile de savoir

• Lorsque l’on installe une version de Windows Vista ou Windows Server 2008 depuis un média Volume License, le setup ne demande pas de clé d’activation. Ce comportement est expliqué par le fait qu’une clé temporaire est utilisée pendant l’installation. Cette clé est disponible dans le fichier .\Sources\pid.txt du média d’installation.
  
  Cette clé, appelée “KMS Client Setup Key”, dépend de l’édition et du système d’exploitation en cours d’installation :
  
  

  Système d’exploitation	Clé produit
  Windows Vista Business	YFKBB-PQJJV-G996G-VWGXY-2V3X8
  Windows Vista Business N	HMBQG-8H2RH-C77VX-27R82-VMQBT
  Windows Vista Enterprise	VKK3X-68KWM-X2YGT-QR4M6-4BWMV
  Windows Vista Enterprise N	VTC42-BM838-43QHV-84HX6-XJXKV
  Windows Server 2008 Datacenter	7M67G-PC374-GR742-YH8V4-TCBY3
  Windows Server 2008 Datacenter without Hyper-V	22XQ2-VRXRG-P8D42-K34TD-G3QQC
  Windows Server 2008 for Itanium-Based Systems	4DWFP-JF3DJ-B7DTH-78FJB-PDRHK
  Windows Server 2008 Enterprise	YQGMW-MPWTJ-34KDK-48M3W-X4Q6V
  Windows Server 2008 Enterprise without Hyper-V	39BXF-X8Q23-P2WWT-38T2F-G3FPG
  Windows Server 2008 Standard	TM24T-X9RMF-VWXK6-X8JC9-BFGM2
  Windows Server 2008 Standard without Hyper-V	W7VD6-7JFBR-RX26B-YKQ3Y-6FFFJ
  Windows Web Server 2008	WYR28-R7TFJ-3X2YQ-YCY4H-M249D

• Il est tout à fait possible de changer le type d’activation d’une machine. On peut passer d’une activation KMS à une activation MAK ou inversement.
  
  Un exemple est représenté par le cas d’un administrateur ayant utilisé une clé KMS sur plusieurs serveurs Windows Server 2008, pensant que cette clé correspondait à la clé habituellement utilisée lors de l’installation de machines sous Windows XP ou Windows Server 2003. En faisant cela, chaque serveur Windows Server 2008 s’est vu activer le service KMS et potentiellement le nombre maximum d’activation de la clé KMS a pu être atteind et donc compromettre la clé KMS.
  
  Dans ce cas, l’administrateur peut exécuter la ligne de commande %WINDIR%\System32\slmgr.vbs –ipk TM24T-X9RMF-VWXK6-X8JC9-BFGM2 (en rapport avec le tableau précédent) pour repasser tous les serveurs (sauf l’hôte KMS) en période de grâce initiale.
  En exécutant ensuite la ligne de commande %WINDIR%\System32\slmgr.vbs –ato, les serveurs contacteront l’hôte KMS pour s’activer.

• Pour la création de masters, il existe une fonctionnalité permettant de réarmer l’activation pour éviter qu’un master créé en janvier soit hors de la période de tolérance lors de son déploiement en décembre.
  Pour réarmer l’activation, il suffit d’exécuter sysprep.exe /generalize puis de capturer l’image du système.
  On peut réarmer toutes les versions de Windows Vista et de Windows Server 2008 3 fois à l’exception des versions Entreprise de Windows Vista et Windows Server 2008 pour lesquelles il est possible de réarmer jusqu’à 5 fois.
  
  
• Pour afficher la description d’un code d’erreur, exécuter la ligne de commande Slui.exe 0x2a ErrorCode

Ressources

Volume Activation 2.0 Technical Guidance (en Anglais)

Guides techniques de Volume Activation 2.0 (en Français)

Product Activation for Windows Vista and Windows Server 2008 (en Anglais)

Windows Server 2008 KMS Setup Demonstration (en Anglais)

Using Server Isolation to Protect the Key Management Service (KMS) (en Anglais)

Microsoft's Software Protection Platform: Planning Activation in Isolated Environments for Windows Vista (en Anglais)

Volume Activation 2.0 for Windows Vista and Windows Server 2008 (TechNet, en Anglais)

Volume Activation 2.0 pour Windows Vista et Windows Server 2008 (TechNet, en Français)

Guide de l’activation en volume (TechNet, en Français)

Informations sur l'activation du volume pour Windows Vista

Comment résoudre les codes d'erreur de l’activation en volume sur Windows Vista

Guillaume

Windows Core Support Escalation Engineer

C’est la première fois que je rencontre ce cas de figure et c’est presque un coup de chance qui m’a permis d’identifier la solution à ce problème.

Le contexte est le suivant : sur un cluster Windows Server 2008 deux noeuds, lorsque l’on passe la ressource IP Address offline ou que l’on forçe un failover du groupe contenant cette ressource il n’est plus possible de contacter le noeud qui détenait cette ressource à travers le réseau. Encore moins d’ouvrir une session en Remote Desktop.

Comportement qui laisse sceptique au début et qui relève de la magie lorsqu’on nous le montre…

En une images, la configuration simple pour reproduire ce comportement :

Trois réseaux (le problème apparaît avec deux voir un seul réseau) :

• Réseau publique : communication intra-cluster et connectivité clients
• Réseau pour le heartbeat : communication intra-cluster seule autorisée
• Réseau iSCSI : aucune communication cluster autorisée

Une ressource IP Address disposant de l’adresse IP 192.168.40.33

Les addresses IP des noeuds étant :

• LAB-WS08-SQL0 : 192.168.40.103
• LAB-WS08-SQL1 : 192.168.40.104

Après les quelques vérifications d’usage autour de la configuration des adaptateurs réseau de chaque noeud, nous avons vérifié la présence de paramétrages de routage spécifique, propre aux serveurs. Et il s’est avéré qu’une route statique avait été rajoutée sur chacun des noeuds.

Et c’est là que l’on pointe un sujet méconnu : l’adaptateur virtuel nommé Microsoft Failover Cluster Virtual Adapter.

La question est donc qu’est-ce que cet adaptateur et à quoi sert-il ?

En peu de mots, le code du cluster sous Windows Server 2008 a été en grande partie réécrite et la couche réseau en a bénéficié. Ce qui se traduit par l’apparition de cet adapateur qui a pour tâche de construire et de maintenir une structure de routage sur chacun des noeuds afin d’améliorer la connectivité réseau en cas de défaillance de l’un des adaptateur réseau.

C’est cette nouveauté qui permet de placer des noeuds d’un même cluster sur des sous-réseaux différents séparés par des routeurs, ce qui n’était pas possible avec Windows 2000 Server et Windows Server 2003.

Mais revenons à notre problème.

Sur ces deux serveurs, une route statique a été configurée, comme on peut le voir sur les captures d’écran ci-dessous :

LAB-WS08-SQL0	LAB-WS08-SQL1

On voit ici que cette route s’applique à tous les adaptateurs.

En rouge la route statique.

En bleu, l’adresse IP du noeud.

En vert l’adresse IP de la ressource IP Address du cluster.

Notez ce qui est entouré de jaune.

Lorsque l’on bascule la ressource IP Address ou que l’on passe offline cette ressource, la route statique du noeud disparait de la table de routage (du moins elle ne fait plus partie des routes actives) :

Ce qui rend impossible la connectivité vers et depuis le réseau 192.168.42.0 (le sous-réseau qui fait l’objet du routage statique).

Comment résoudre ce problème et utiliser tout de même un routage statique ? C’est simple, mettre en oeuvre le routage statique de manière recommandée, à savoir suivre la procédure suivante :

1. Supprimer la route statique :
   
   ROUTE DELETE 192.168.42.0
   
2. Identifier l’adaptateur réseau qui doit bénéficier de ce routage statique :
   
   NETSH INT IPV4 SHOW INT
   
   
   
3. Appliquer la route statique à cet adaptateur uniquement en exécutant la commande suivante :
   
   ROUTE –P ADD 192.168.42.0 MASK 255.255.255.0 0.0.0.0 IF 15
   
   où 15 correspond à l’adaptateur et 0.0.0.0 représente la route par défaut (en l’occurence la passerelle pour communiquer avec le réseau 192.168.42.0 sera l’adresse IP de l’adaptateur réseau du noeud)

On obtient ceci :

Table de routage avec la ressource IP Address online	Table de routage avec la ressource IP Address offline

On voit ici que la route statique reste active même lorsque la ressource IP Address est offline.

Meilleures pratiques

• Ne jamais modifier le paramétrage de l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
  
• Ne jamais désactiver l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
  
• Créer des routes statiques avec la méthode décrite ci-dessus

Ressources

Rendons à César ce qui appartient à César, le bulletin qui m’a permis de résoudre cet incident : Active Route gets removed on Windows Server 2008 offline Cluster IP Address – Blog Microsoft Enterprise Networking Team

What is a Microsoft Failover Cluster Virtual Adapter anyway? – Blog de l’équipe Core aux US

Multi-Site Failover Cluster Communications Connectivity – Blog de l’équipe Core aux US

Guillaume

Windows Core Support Escalation Engineer

Je suis presque sûr que tout ceux qui ont eu a générer un master sysprep ont rencontré un Stop 0x7B (Inaccessible Boot Device)
Bien que plusieurs articles KB tournent autour de cette erreur, aucun d'entre eux n'explique vraiment pourquoi elle apparait...

Comment que ça se fait que ça marche pas?

Pour répondre à cette question, revenons en arrière, bien avant que cet écran bleu n'apparaisse...

 ...Plus tôt : le même jour!

Nous sommes en face d'une machine de référence contenant le Master que vous souhaitez "syspreper".
Cette machine contient donc:

• une installation complète de Windows avec quelques personnalisations
• quelques applications
• un répertoire contenant les drivers des differents modèles de machines compatibles avec cette machine de référence
• un répertoire Sysprep à la racine de c:\

Satisfait de l'état actuel de la machine de référence et ayant vérifié que cette machine n'entrait pas dans les scénarios non-supportés 828287 | Unsupported Sysprep scenarios, l'OS doit étre préparé à être déployé et donc redémarré sur un matériel différent. C'est là que Sysprep intervient :

• Sysprep.exe : System Preparation Tool
• Setupcl.exe : Permet de regenérer les identifiants uniques de la machine
• Sysprep.inf : Fichier de réponse de Sysprep.exe

Note: Ces outils sont disponibles dans le deploy.cab. Il faut toujours utiliser le deploy.cab du dernier service pack sorti entre Xp et 2003 ; à l'heure d'aujourd'hui (à 5 minutes près), ce sont les outils du service pack 3 de Windows Xp qu'il faut utiliser
Windows XP Service Pack 3 Deployment Tools

...Vers Midi : Lancement de Sysprep, capture et descente du master

La commande Sysprep -mini -reseal a été lancée et la machine redémarre sur un WinPe 2.0 et Imagex (par exemple) est en train de capturer la partition contenant le Sysprep de Windows.

Mode de testing #1 :

la machine de référence est redémarrée sous WinPe, le disque formaté et l'imagex l'image wim du Master appliquée sur C:\ avec Imagex
Au redémarrage sur le disque local, la séquence de boot se passe normalement et Windows ecexute le mini-setup en utilisant les réponses dans le fichier Sysprep.inf

Mode de Testing #2 :

Pour s'assurer que le master est bien opérationnel, celui-ci est descendu sur la machine compatible la plus récente...
...et là c'est le drame du reboot en boucle (et le moment d'aller prendre un café) malgré le test des differents choix proposés par le mode sans echec.

...Plus tard : Pourquoi tu fais ça?

1.  Un peu plus loin dans le processus de démarrage
  

C'est lors de la bascule en mode driver que les bactéries attaquent, si Windows ne trouve pas de pilote compatible il affiche un Stop 0x7B.
Windows passe en mode driver afin d'améliorer les performances (I/O)

2.  Confirmer les soupçons

Si vous êtes bloqué dans une boucle de démarrage, vous n'avez pas le temps de voir le message d'erreur qui apparait.
En éditant le Wim avant la descente ou bien en redémarrant avec WinPe après avoir rencontré l'erreur, on peut forcé la machine à ne pas redémarrer suite à un écran bleu.

• Démarrer sous WinPe
• Lancer regedit :
  • Se placer sur HKLM
  • Cliquer sur Fichier\Charger la ruche
  • Aller sous %SystemRoot%\System32\Config
  • Sélectionner le fichier SYSTEM
  • Valider et donner n’importe quel nom (par exemple : TempSys)
    • Aller sous HKLM\TempSys\ControlSet001\Control\CrashControl
    • Passer la valeur de la variable AutoReboot de 1 à 0 
      
  • Se placer à la racine de TempSys, cliquer sur Fichier\Décharger la ruche
    
• Au prochain redémarrage, la machine devrait rester figée sur l'écran bleu
  
  

3.  Résoudre le problème (éviter serait plus juste) :

Pour éviter de tomber dans cette situation, il faut repartir du master avant de lancer Sysprep.exe;

• Créer un fichier Sysprep.inf ne contenant que la section [SysprepMassStorage]
• Lancer la commande : c:\Sysprep\Sysprep.exe –bmsd
  • Celui-ci peuple le fichier réponse avec les drivers MassStorage connus de Windows
    
     
    
• Ensuite ajouter les drivers MassStorage non-connus de votre parc manuellement
  • Ajouter des lignes sous la forme : HardwareID = c:\Drivers\Mass\Sata1\Driver.inf
  • Il faut donc identifier sur vos différentes machines si le périphérique MassStorage est connus ou non
    • Si oui  : rien à faire (c'est pas souvent)
    • Si non : récupérer le driver dans un répertoire (1 fichier *.inf, 1 fichier *.sys, 1 fichier *.cat et des 1 fichier *.dll)

Note : le fichier Ref.chm du deploy.cab est une aide assez complète pour le Setup
La section [SysprepMassStorage] y est aussi détaillée

• La réponse BuildMassStorageSection=yes proposée dans l'article ci-arpès fonctionne aussi mais ne correspond qu'au Sysprep -bmsd :
  • 303786 | Missing [SysprepMassStorage] Section Causes STOP 0x7B Error Message on Windows XP Sysprep Images

4.  Vérifier avant de déployer :

Petite procédure pour vérifier la présence d’un contrôleur de stockage dans une image wim afin de s'assurer que le Master en rencontrera pas de Stop 0x7B :

• Monter le wim via : imagex /mountrw CheminDuWim Index RépertoireNTFSVide
• Lancer regedit :
  • Se placer sur HKLM
  • Cliquer sur Fichier\Charger la ruche
  • Aller sous %SystemRoot%\System32\Config
  • Sélectionner le fichier SYSTEM
  • Valider et donner n’importe quel nom (par exemple : TempSys)
    • Aller sous HKLM\TempSys\ControlSet001\Control\CriticalDeviceDatabase
    • Vérifier l’existence du HardwareID (HWID = PCI#Ven… ou SCSI#… )
    • Vérifier également l’existence du Service associé sous HKLM\TempSys\ControlSet001\Service
  • Une fois les contrôles effectués, se placer à la racine de TempSys, cliquer sur Fichier\Décharger la ruche
    
• Puis démonter le wim : imagex /unmount RépertoireNTFSVide (+ /commit si vous voulez enregister les modifications)

...Après "plus tard" : Journée super productive!!!

Mon master fonctionne sur tous les MassStorage de mon parc : ATA, Sata, SCSI...
Au revoir le stop 0x7B!

...Pour finir : d'autres petites infos

Plug&Play vs MassStorage:

• Les pilotes MassStorage ne sont pas Plug&Play, ils doivent être chargés très tot c'est pourquoi ils ne doivent pas apparaitre dans le OemPnpDriversPath du fichier de réponse.
• Cette réponse correspond à la variable HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion!DevicePath
  La detection plug&play est lancée bien plus tard.

Petit Rappel concernant La machine de référence :

• Elle doit être la plus simple possible
• Ne pas intégrer de périphérique "exotiques"
• Il faut installer un minimum de drivers afin d’éviter les entrées dupliquées dans la base de registre et périphérique fantôme
• Une machine virtuelle (sans additions) convient comme machine de référence

Ajouter des Contrôleur à un Sysprep existant:

• Ajouter manuellement les entrées de registre dans CriticalDeviceDatabase et Services pour un nouveau contrôleur n'est pas supporté
• MDT sait faire ce genre d'action
  Setting variables through a Task Sequence
  
  

Malgré la longeur de l'article j'espère que celui-ci reste clair et compréhensible...

Tête de Vincar
Windows Core Support Engineer

Un nouveau correctif est disponible pour Hyper-V.

Celui-ci permet de corriger certains comportements en erreur mais surtout permet de sauvegarder les machines virtuelles à chaud depuis System Center DPM 2007 SP1.

KB959962 - An update is available for Windows Server 2008-based computers to address issues with backing up and restoring Hyper-V virtual machines

Guillaume

Windows Core Support Escalation Engineer

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