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 :

Windows Server 2008	Windows Vista	Hôte KMS	Décompte d’activation sur l’hôte KMS	Disponibilité de l’activation KMS
4	1	1	5	Uniquement pour les systèmes Windows Server 2008
1	4	1	5	Uniquement pour les systèmes Windows Server 2008
1	1	1	2	Aucun système
4	22	1	26	Windows Vista et Windows Server 2008

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

Groupe de clés	Clé KMS	Hébergement du service KMS	Produits activables
Vista Client Volume License	KMS	Windows Vista KMS 1.x sur Windows Server 2003	Windows Vista Business Windows Vista Enterprise
Groupe A	KMS_A	Windows Server 2008 Web Edition KMS 1.1 sur Windows Server 2003	Windows Vista Volume License Windows Server 2008 Web Edition
Groupe B	KMS_B	Windows Server 2008 Web Edition Windows Server 2008 Standard Edition Windows Server 2008 Standard Edition sans Hyper-V Windows Server 2008 Enterprise Edition Windows Server 2008 Enterprise Edition sans Hyper-V KMS 1.1 sur Windows Server 2003	Windows Server 2008 Standard Edition Windows Server 2008 Enterprise Edition Produits du groupe A Windows Vista Volume License
Groupe C	KMS_C	Windows Server 2008 Web Edition Windows Server 2008 Standard Edition Windows Server 2008 Enterprise Edition Windows Server 2008 DataCenter Edition Windows Server 2008 DataCenter Edition sans Hyper-V Windows Server 2008 pour systèmes Itanium KMS 1.1 sur Windows Server 2003	Windows Server 2008 DataCenter Edition Windows Server 2008 pour systèmes Itanium Produits du groupe A Produits du groupe B Windows Vista Volume License

 

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

Installer une application sous Terminal Server n’est pas anodin. En effet, le serveur étant multi-utilisateurs, il faut que l’application soit capable d’être utilisée simultanément par plusieurs utilisateurs. Il faut donc clairement séparer les données et paramètres communs, de ce qui ne l’est pas. Si l’application n’a pas été écrite en tenant compte de cela, les risques de plantage sont garantis.

   1. Le principe

Pour éviter ces situations, et gérer malgré tout le plus grand nombre d’applications, les différentes versions de Terminal Server font appel à un module de compatibilité, TS Compatibility, qui doit être activé à chaque installation. Cette activation se fait lors du basculement du serveur en mode « Installation » et se termine lorsque le serveur bascule de nouveau en mode « Exécution ».

En mode « Installation », selon les applications qui sont exécutées, un travail de surveillance sera effectué automatiquement ou pas. Ce qui détermine cette surveillance est la présence du flag TSAWARE ou non, dans l’entête du fichier exécutable de l’application. Pour les applications « TSAWARE », le serveur fera confiance à l’application pour gérer correctement ses paramètres et données. Pour toutes les autres applications, une capture des modifications des clés de registre, ainsi que des fichiers INI dans C:\Windows sera effectué.

2. Gestion des fichiers INI

Une copie des fichiers INI modifiés sera effectué vers un répertoire « Windows » crée dans le profil de l’utilisateur. Une modification de la variable d’environnement %WINDIR% permettra de pointer vers ce répertoire. Ainsi, si l’application référence les fichiers INI en se basant sur la variable d’environnement %WINDIR%, elle ne s’apercevra pas de la substitution et fonctionnera normalement. Dans le cas contraire, elle ouvrira la voie à tous les conflits de paramètres entre utilisateurs.

3. Gestion des clés de régistres – Les Shadow Keys

Les modifications de clés de registre provenant de HKEY_CURRENT_USER ou de HKEY_USERS\.DEFAULT seront dupliquées vers HKEY_LOCAL_MACHINE\Software\[Wow6432Node\]Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Ces clés de sauvegarde sont appelées les Shadow Keys. Ainsi, lorsqu’un utilisateur se connectera, selon que les clés de l’utilisateur seront plus récentes ou non que les Shadow Keys correspondantes, ces dernières seront recopiées dans le profil utilisateur.

4. Les TimeStamp

Pour déterminer s’il faut mettre à jour les clés de registre du profil utilisateur, une comparaison entre 2 TimeStamp est réalisée. A chaque Shadow Keys créée, un 1^er TimeStamp contenant l’heure de cette modification est écrit dans HKEY_LOCAL_MACHINE\Software\[Wow6432Node\]Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times\LatestRegistryKey. Cette valeur pourra ainsi être comparée au 2^ème TimeSTamp, qui contient l’heure de la dernière synchronisation entre profil utilisateur et Shadow Keys. Ce TimeSTamp est stocké pour chaque utilisateur dans HKEY_CURRENT_USER\Software\[Wow6432Node\]\Microsoft\Windows NT\CurrentVersion\Terminal Server\LastUserIniSyncTime.

Une fois la recopie démarrée, il faut savoir qu’elle n’est pas réalisée « en aveugle ». En effet, seules les clés ayant été récemment modifiées dans la Shadow Keys seront recopiées. Pour faire le tri, une nouvelle comparaison de TimeStamp est réalisée, mais cette fois avec l’attribut caché affecté à chaque clé de registre. Cet attribut caché est appliqué uniquement sur les clés, et non sur les valeurs.  Ainsi donc, seules les clés contenant de réelles modification récentes seront recopiées, et dans ce cas, avec l’intégralité de leurs valeurs.

5. Cas des fermes de serveurs

Ce mécanisme pourrait être parfait, s’il n’y avait pas une petite complication : l’ajout d’un serveur TS/RDS dans une ferme de serveurs déjà existante. En effet, pour ce nouveau serveur, le TimeStamp des Shadow Keys étant forcément plus récent que celui des profils utilisateur, la synchronisation, et donc l’écrasement des clés du profil utilisateur se fera à chaque connexion d’un nouvel utilisateur de ce serveur. C’est la raison pour laquelle il est recommandé, lors de l’ajout d’un nouveau serveur qui contient des applications non TSAWARE native, de modifier la date système de celui-ci lors de l’installation des applications, afin qu’il ait une date d’installation équivalente aux autres serveurs. A la fin de l’installation, ce serveur pourra reprendre la date courante.

 

6. Conclusion

En conclusion, le fonctionnement des Shadow Keys a été imaginé à l’origine uniquement pour permettre à des applications mal écrites de fonctionner quand même sur un Terminal Server. Aujourd’hui, les éditeurs de logiciel sont à même d’écrire des applications certifiées TSAWARE, évitant ainsi les complications liées au Shadow Keys. Ce mécanisme devrait donc disparaitre avec le temps.

Enfin, afin que tout soit clair, voici une petite Foire Aux Questions :

Q: Ce mécanisme, est il toujours le même sous Remote Desktop Server 2012 ?

R: Oui. Ce mécanisme n’a pas changé depuis Windows Server 2003.

Q : Comment basculer en mode « Installation » puis en mode « Execution » ?

R : Pour basculer en mode « Installation », plusieurs méthodes sont possibles :

-          Saisir la commande       change user /install     dans une invite de commande avec élévation de privilège.

-          Depuis le panneau de configuration, faire  Ajout/suppression de programme / Installer un nouveau programme

-          Lancer l’installation d’un fichier MSI

-          Exécuter un programme depuis la clé RunOnce au démarrage du serveur.

De la même façon, pour rebasculer en mode « Exécution », plusieurs méthodes :

-          Saisir la commande      change user /execute     dans une invite de commande avec élévation de privilège

-          Cliquer sur la boite de dialogue de    « fin d’installation » du panneau de configuration

-          Terminer l’installation d’un fichier MSI.

-          Terminer l’installation du programme lancé depuis la clé RunOnce

Q : Pourquoi est-il particulièrement recommandé d’installer le rôle Terminal Service ou Remote Desktop Session Host en premier, avant d’installer toute autre application ?

R : Plusieurs bonnes raisons à cela.

-          Si votre application est TSAWARE, mais ne peut pas détecter qu’elle s’installe sur un serveur TS/RDS, elle n’initialisera pas les bons paramètres, et risque même de ne pas installer les bon modules. Par exemple, les différentes versions de Microsoft Office, quand elles s’installent, n’installent pas les mêmes composants selon qu’elles sont sur un serveur TS/RDS ou sur toute autre type de machine.

-          Si votre application n’est pas TSAWARE, le mécanisme des Shadow Keys ne pourra pas s’appliquer, et les risques de conflits lors de l’utilisation seront importants.

Q : Si j’ai installé plusieurs applications, et que je doive ajouter le rôle Terminal Service ou Remote Desktop Session Host sur mon serveur, que dois-je faire ?

R : Le plus simple est de commencer par désinstaller toutes les applications, redémarrer la machine, installer le rôle, redémarrer autant de fois que nécessaire, puis, installer de nouveau les applications, en basculant préalablement le serveur en mode « Installation ».

Q : Comment savoir si mon application contient le flag TSAWARE dans son entête ?

R : Il n’y a pas d’outil intégré au système permettant de vérifier cela. Toutefois, l’utilitaire dumpbin.exe, fournit avec les différentes versions de Visual Studio, le permet. Il suffit de l’exécuter avec le paramètre /headers pour afficher une liste des attributs de l’entête PE du fichier exécutable.  L’attribut à chercher est : « Terminal Server Aware ».

Q : Pourquoi quand je modifie manuellement les clés de HKEY_CURRENT_USER, en mode installation, ces clés ne sont pas recopiées dans la zone Shadow Keys ?

R : Cela est très certainement dû au fait que l’outil que vous utilisez pour modifier ces clés manuellement, regedit.exe ou reg.exe, est par défaut flaggué comme étant TSAWARE. Les modifications ne sont donc pas surveillées par le serveur TS/RDS.

Q : Je voudrais utiliser le mécanisme des Shadow Keys pour modifier les profils des utilisateurs de mon serveur TS/RDS, mais les différents TimeStamp me compliquent la vie. Y aurait-il une façon simple de procéder ?

R : Oui, ne pas utiliser ce mécanisme, mais lui préférer une mise à jour par GPO.

 

Philippe

Windows Core Support Escalation Engineer

Cela fait quelques temps que nous peinons à poster des bulletins sur notre blog.

Je profite donc de l'occasion pour vous annoncer que les webcasts des TechDays 2010 sont disponibles.

 

En particulier la notre (nous ne sommes pas peu fiers Lionel et moi tout autant que Jérôme, notre acolyte d'un jour) qui concerne les meilleures pratiques autour du clustering :

 

 

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

A travers cet article, je vais tenter d’expliquer comment mettre en place le SSO (Single Sign On) pour l’utilisation de RemoteApp publiées sous RDS 2008 R2.

 

Pour les besoins de l’explication, je vais partir du principe que l’infrastructure en place est la suivante :

 

-          1 domaine : core.lab

-          1 ferme de 2 serveurs RDSH 

o   RDSH1.core.lab

o   RDSH2.core.lab

Le nom de la ferme est  RDFARM.core.lab

-          1 RD Connection Broker : RDCB.core.lab

-          1 RD Web Access : RDWA.core.lab

-          1 RD Gateway : RDGW : RDGW.core.lab

 

La mise en place du SSO peut se décomposer en plusieurs phases :

1)      Choix des certificats

2)      Génération des certificats

3)      Installation des certificats sur les différentes machines

4)      Paramétrage des RD Session Hosts

5)      Paramétrage du RD Connection Broker

6)      Paramétrage du RD Web Access

7)      Paramétrage du RD Gateway

8)      Créations des GPOs

 

 

1.     Choix des certificats

 

Un ou plusieurs certificats devront être générés.

Il y a besoin de certificat pour les éléments suivants :

-          Chaque serveur RD Session Host

-          Le serveur RD Connection Broker

-          Le serveur RD Web Access

-          Le serveur RD Gateway.

 

Les serveurs RD Session Hosts et le serveur RD Connection Broker devront partager le même certificat.

Les serveurs RD Web Access et RD Gateway peuvent chacun avoir un certificat différent.

En conclusion, il nous faut au maximum 3 certificats différents.

 

Le certificat des serveurs RD Session Host et du RD Connection Broker devra comporter les indications suivantes :

CN=RDFARM.core.lab

 

Le certificat du serveur RD Web Access devra comporter les indications suivantes :

CN=RDWA.core.lab

 

Le certificat du serveur RD Gateway devra comporter les indications suivantes :

CN=RDGW.core.lab

 

Il est possible de n’utiliser qu’un seul certificat pour tous ces serveurs.

Il faudrait alors soit utiliser un wildcard de type  *.core.lab dans le Subject Name, soit référencer les différents noms utiles, dans les champs SAN (Subject Alternative Name) du certificat.

Il est à noter toutefois que seuls les clients RDC 6.1 et au-delà peuvent faire usage de ces possibilités.

 

Pour l’utilisation de Subject Alternative Name dans notre exemple, il faudrait renseigner :

 

Subject Name :

CN=RDFARM.core.lab

 

Subject Alternative Name :

DNS= RDFARM.core.lab

DNS= RDWA.core.lab

DNS= RDGW.core.lab

 

On retrouve le nom RDFARM.core.lab, aussi bien dans le Subject Name que dans le Subject Alternative Name.

Cette répétition est volontaire.

 

Pour la suite de cet article, je vais considérer que nous allons utiliser 3 certificats différents.

 

2.     Génération des certificats

 

Pour générer nos certificats, il existe 2 possibilités :

-          Utiliser une autorité de certification au sein du domaine Active Directory

-          Acheter vos certificats auprès de société telles que VeriSign ™, Thawte ™, et autres…

 

Si l’ensemble des postes clients accédant à l’infrastructure visée sont sous contrôle de votre service informatique, vous pouvez vous contenter d’utiliser votre propre autorité de certification.

En effet, si ces postes sont dans la même forêt que l’autorité de certification, il y aura une approbation automatique de celle-ci.

Dans le cas contraire, ils devront être paramétrés pour approuver cette autorité de certification, et devront avoir un accès à la CRL (Certificate Revocation List) de celle-ci.

 

Pour créer vos propres certificats, je vous invite à consulter cet article.

  

3.     Installation des certificats sur les différentes machines

 

Une fois les certificats créés, il faut les installer sur les différents serveurs concernés.

Dans notre exemple, il s’agit des serveurs et certificats suivants :

 

Serveur	Certificat
RDSH1.core.lab	RDFARM.core.lab
RDSH2.core.lab	RDFARM.core.lab
RDCB.core.lab	RDFARM.core.lab
RDWA.core.lab	RDWA.core.lab
RDGW.core.lab	RDGW.core.lab

 

Cela se fait de la manière suivante :

Depuis l’un des serveurs en question, lancer une MMC en élévation de privilège, faire« Add or Remove Snap-ins ».

Choisir le snap-in « certificate »

 

 

Sélectionner« Computer Account », puis « Local Computer »

 

 

Depuis le magasin « Personal », faire « All Tasks » puis« Import… »

 

 

Sélectionner le fichier en .pfx préalablement créé, saisir le mot de passe communiqué lors de l’export de la clé privée,

 

 

Sélectionner l’emplacement du  certificat dans le magasin « Personal » et faire l’import.

A la fin de l’opération, vous devez voir le certificat dans la console.

 

 

Cette opération est à refaire pour chacun des serveurs précédemment cités, avec leur certificat respectif.

  

4.     Paramétrage des RD Session Hosts

 

Sur les serveurs RD Session Hosts, il y a 2 choses à configurer :

-          Le protocole RDP

-          Les RemoteApp

 

Pour le protocole RDP, cela se passe au niveau de la MMC : « Remote Desktop Session Host Configuration ».

 

Ouvrir les propriétés de la connexion RDP-TCP, et dans l’onglet général, cliquer sur le bouton « Select » afin de sélectionner le certificat.

 

 

Mettre le certificat choisi en surbrillance, et cliquer sur « OK »

 

 

Le certificat sélectionné sera alors affiché.

 

 

Faire OK, pour appliquer les modifications.

 

Concernant les RemoteApp, ouvrir la MMC « RemoteApp Manager ».

Choisir le lien « Change » à coté de « Digital Signature Settings »

 

 

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton « Change».

 

 

Choisir le certificat, et valider par « Ok »

 

 

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

 

 

Faire la même opération avec l’autre serveur RD Session Host de la ferme.

 

 

5.     Paramétrage du RD Connection Broker

 

Sur le serveur RD Connection Broker, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le RD Connection Broker lui-même.

 

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

 

Pour le RD connection Broker, lancer la MMC « Remote Desktop Connection Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

 

 

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton «Select ».

Choisir le certificat, et valider par « Ok »

 

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

 

  

6.     Paramétrage du RD Web Access

 

Sur le serveur RD Web Access, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le protocole HTTPS.

 

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

 

Pour le protocole HTTPS, lancer la MMC « Internet Information Services (IIS) Manager ».

Se positionner sur le « Default Web Site », puis sélectionner l’option de « Binding… ».

 

 Sélectionner ensuite le protocole HTTPS, puis le bouton « Edit… »

 

 Il ne reste plus qu’à sélectionner le certificat à employer, et à valider.

 

 Un redémarrage du site Web est à prévoir.

  

7.     Paramétrage du RD Gateway

 

Sur le serveur RD Gateway, il y a 2 choses à configurer :

-          Le protocole RDP

-          Le certificat utilisé par le protocole HTTPS.

 

Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ».

 

Pour le protocole HTTPS, cette fois ci, on va passer par le « RD Connection Manager »

Lancer la MMC « RD Gateway Manager ».

Puis, sélectionner l’option pour mettre à jour le certificat.

 

 

Choisir ensuite l’import de certificat.

 

 Sélectionner ensuite le bon certificat, puis cliquer sur le bouton « Import », puis valider par « OK ».

 

8.     Créations des GPOs

 

Les GPOs à créer sont à mettre en place pour tous les postes clients qui souhaiteront exécuter des RemoteApp en faisant du SSO.

 

Dans notre exemple, j’ai créé une OU « Desktop » dans laquelle j’ai déplacé tous les postes utilisateurs.

Ensuite, depuis la MMC « Group Policy Management », il faut sélectionner l’OU en question, puis sélectionner « Create a GPO in this domain, and Link it here ».

 

 

Dans notre exemple, je l’ai nommée SSO for RDS.

 

 

Faire ensuite Edit

 

 

La MMC« Group Policy Management Editor » s’ouvre alors.

 Aller dans« Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation »

Modifier le paramètre « Allow Delegating Default Credentials »

Selectionner« Enabled », puis cliquer sur le bouton « Show… »

 

 

Saisir ensuite le SPN pour les serveurs concernés.

Dans notre exemple , il faut saisir le nom de notre ferme.

Valider ensuite deux fois par « OK ».

 

 

Aller ensuite dans « Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Connection Client »

Le paramètre à modifier est « Specify SHA1 thumbprints of certificates representing trusted .rdp publishers »

 

 

Le « thumbprint »ou « empreinte » est à récupérer sur le certificat de la ferme.

Pour cela, depuis la console certificat, choisir le certificat RDFARM.core.lab, puis dans l’onglet « Details », récupérer les données du champ« Thumbprint »

 

 

Ces données sont à recopier, de préférence sans les espaces, pour éviter les« copier/coller » malheureux.

En effet, selon ce qui est sélectionné, des caractères non affichables peuvent être inclus dans le presse-papier, et ainsi corrompre les données.

 

 Une fois ceci fait et validé, la configuration du SSO est terminée.

 

Pour que la GPO soit prise en compte, ne pas oublier de fermer la MMC « Group Policy Management Editor ».

 

9.     Utilisation du site web RD Web Access

 

Une dernière chose est nécessaire pour que le SSO fonctionne correctement : il faut impérativement cocher la case “J’utilise un ordinateur privé” depuis le site RD Web Access.

 

 

 

Philippe

Windows Core Support Escalation Engineer