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 :
Processus d’activation :
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
5
2
22
26
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) :
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 :
Groupe de clés
Clé KMS
Hébergement du service KMS
Produits activables
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é.
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
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL Nom : DisableDnsPublishing Type : REG_DWORD Valeur : 1
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>
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>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL Nom : KeyManagementServicePort Type : REG_SZ Valeur : <port>
D’autres options de configuration sont disponibles dans le guide Volume Activation 2.0.
Ce qu’il peut être utile de savoir
Système d’exploitation
Clé produit
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
Voici un exemple de troubleshooting d’un problème de 100% cpu en mode kernel en utilisant le « Microsoft Windows Performance Toolkit » + un kernel dump.
Scenario
Une application réalisant des accès aux données (ODBC) part en 100% cpu après quelques milliers d’accès au SGBD. i.e. tout marche correctement pendant quelques minutes puis nous partons en 100% cpu en mode kernel ce qui a pour résultat d’avoir un système inutilisable.
Outils
Nous allons utiliser le « Microsoft Windows Performance Toolkit » que l’on peut télécharger ici http://msdn.microsoft.com/en-us/library/cc305187.aspx , ainsi qu’un kernel dump au moment où le problème est visible. Pour analyser le kernel dump nous allons utiliser windbg.exe qui est distribué avec les « Debugging Tools for Windows » téléchargeable ici http://www.microsoft.com/whdc/devtools/debugging/default.mspx .
Collecte des données
Xperf: nous avons démarré une trace xperf alors que l’application marchait bien puis, nous avons laissé celle-ci continuer alors que le problème était visible. Les commandes étant les suivantes :
xperf –on Base+Diag (pour démarrer le tracing)
xperf –d c:\cpu.etl (pour arrêter le tracing)
Kernel Dump: http://msdn.microsoft.com/en-us/library/cc266492.aspx
Troubleshooting
La première étape va consister à constater le problème de 100% cpu à partir du dump. Pour cela j’ouvre le dump dans windbg (menu File+ Open Crash Dump…). Puis, je cherche mon processus (apisend.exe) responsable du 100% cpu en utilisant la commande «!process»:
Nous obtenons donc l’adresse de notre processus cible. Nous pouvons utiliser la commande !process avec cette nouvelle information afin d’obtenir des informations détaillées :
Nous constatons donc que le thread 81fc8290 a passé 7 minutes et 33 secondes en mode kernel. Sachant que l’application venait d’être lancée quelques minutes avant la génération du dump, cela semble effectivement important.
Maintenant, concentrons-nous sur la trace xperf. Je lance donc xperfview.exe, ouvre le fichier cpu.etl et me concentre sur la vue « CPU Sampling by Thread » :
Nous constatons bien que l’utilisation cpu est correcte pendant un moment puis passe en 100% cpu. Si je sélectionne une plage pendant cette période de 100% et fais un clique droit + « Summary Table ». J’obtiens les informations suivantes :
Il est maintenant clair que 99.06% du temps cpu est utilisé par apisend.exe. Nous pouvons récupérer plus d’informations en cliquant sur la croix devant notre nom de processus :
Nous obtenons ainsi la distribution du temps cpu par composant. Cette vue nous indique que 98.37% du temps cpu s’est effectué dans win32k.sys. Nous sommes donc bien en mode kernel et notre problème a un rapport avec le GDI.
Nous pouvons continuer la même démarche et descendre dans le détail des fonctions utilisées par win32k.sys en cliquant sur la croix dans la colonne « Function ». Nous obtenons ainsi :
Le/les appels à la fonction à l’adresse 0xbf876531 consomme(nt) 79.97% de notre temps cpu. Nous pouvons maintenant utiliser cette adresse à partir du kernel dump pour trouver notre coupable (ou victime).
Le débogueur nous indique que nous sommes dans du code ayant un rapport avec les Timers Windows. Les Timers sont bien gérés par la partie GDI (win32k.sys).
La situation est donc la suivante : cette application utilise des timers pour effectuer certaines tâches et, après quelques minutes, l’utilisation de ces Timers entraine un 100% cpu.
Pour aller plus loin, il nous faut donc comprendre ce que fait cette application et obtenir les morceaux de code concernant la manipulation des Timers.
Conclusion
Après analyse du code, nous avons apporté 2 modifications :
1- Le code était implémenté de telle manière qu’en cas d’erreur d’accès aux données, le Timer crée (pour effectuer une annulation de la requête de manière asynchrone) n’était jamais détruit. Nous avons donc ajouté un KillTimer() en cas d’erreur.
2- Lors de l’appel du handler de Timer, celui-ci n’était détruit que juste avant de quitter ce handler. Nous avons modifié cette implémentation afin de détruire le handler le plus tôt possible pour éviter des problèmes de réentrance si jamais le code (ODBC) devait prendre plus de temps que la durée du Timer lui-même.
Une fois ces 2 modifications apportées, l’application et le serveur se sont mis à fonctionner parfaitement bien.
Epilogue
Xperf est vraiment un outil extrêmement puissant. Il me parait indispensable de savoir l’utiliser. Xperf EST l’outil standard de tracing pour Windows Vista, Windows 2008 et les prochaines versions d’OS. Xperf peut être utilisé (pour la partie Kernel) sous Windows 2003 et Windows XP mais ne s’installera pas sur ces plateformes. Il faudra donc l’installer sur un Vista ou un 2008 puis copier l’intégralité du répertoire sur 2003 ou XP.
Merci de m’avoir lu jusqu’ici :-)
Hervé Chapalain
Windows Core Escalation Engineer
Le terme de “support” peut parfois être réducteur et faire penser à de la hotline mais dans le cas des grands fournisseurs de logiciels ou de matériel, le support est une entité à part entière qui tient sa place dans la stratégie. Chez Microsoft, le support représente un outil reconnu dans la relation avec ses clients car il permet de mieux aider les entreprises à assurer le suivi des produits déployés en production.
De toutes les manières, ne dites jamais à un ingénieur support Microsoft qu’il fait de la hotline :-)
Le périmètre
Afin d’avoir une idée de notre rôle de support dans le cadre de la plateforme Windows, il faut tout d’abord mettre en avant les produits et technologies qui font partis de notre domaine de compétences. Tous ne sont pas listés, il y a environ 80 briques, mais cela peut donner une idée de la complexité de la tâche !
Tout d’abord, la série Windows :
Les applications :
Enfin, les grandes technologies :
Quel est notre rôle ?
Concrètement, notre rôle consiste à assister nos clients quand ils font face dans leur environnement à des dysfonctionnements ou comportements inattendus liés aux produits et technologies Microsoft.
C’est ce que nous appelons le service de support réactif :
Nous avons également un autre rôle vis à vis de nos clients que nous identifions comme des services de support proactifs. Ce type de services fournit aux clients une assurance de supportabilité avant le déploiement d’un produit ou d’une solution Microsoft ou permet de délivrer des formations ou des présentations techniques.
Services proactifs :
Comment nous intervenons auprès de nos clients ?
Pour pouvoir faire appel à nous il faut disposer d’un contrat de Support Premier, étant donné que nous n’intervenons que dans des problématiques impliquant des produits professionnels auprès des sociétés ayant souscrit ce type de contrat. L’équipe de support Française Windows Core est engagée avec des clients présents en Europe du Sud, Afrique du Nord et au Proche Orient et nous sommes le point de contact pour tous les clients parlant Français en Europe.
Le principe est simple, pour être mis en contact avec l’un d’entre nous :
Bien évidement, nous avons des processus permettant de gérer le flux des dossiers afin d’assurer le meilleur service possible. Le premier mécanisme qui entre en œuvre est le respect des SLAs définies en fonction de la criticité de chaque incident.
Les cinq niveaux de criticité sont les suivants :
Nos principales tâches
Pour la partie la plus sympathique, la plupart de nos journées sont occupées par l’analyse des journaux d’évènements, des fichiers log divers et variés, des traces collectés sur les systèmes impliqués dans les dysfonctionnements qui nous sont remontés.
Plus délicat, les traces perfmon représentent également une part non négligeable ainsi que l’analyse de dumps, soit générés lors de crashes systèmes ou manuellement initiés.
De manière moins fréquente, la revue d’éléments de configuration et de documents d’architecture fait aussi partie de nos responsabilités.
Pour terminer, l’équipe Windows Core, qui est représentée par 17 ingénieurs aujourd’hui (je ne compte pas Elena et Laurentiu qui viennent de nous rejoindre et sont en formation), traite en permanence une moyenne de 200 incidents qui vont du plus simple (ce qui devient rare) au plus complexe et du moins critique au plus impactant.
A savoir que nous ne sommes pas en permanence 17 à gérer les incidents étant donné que nous nous déplaçons également pour délivrer des formations ou ateliers techniques et que nous sommes aussi impliqués dans des projets, que les Tech Leads ont des tâches administratives, etc. Le nombre d’incidents par ingénieur atteint régulièrement la quinzaine.
Voici donc brièvement décrit la mécanique mise en action au sein du support pour toujours améliorer l’expérience des clients autour de nos produits.
En espérant avoir levé un coin du voile… à très bientôt pour des bulletins plus techniques !
L’équipe de Support Windows Core
Problématique
En complément de cet article Technet Comment créer un Windows PE 2.x Multiboot 32 et 64 bit, je souhaiterais vous proposer un autre post permettant par exemple, un multiboot entre votre OS de production et WinPe
Objectif
En plus d'être un outil de déploiement, WinPe est aussi un outil de "récupération".
En proposant une solution de démarrage parallèle, vous pouvez par la suite essayer de recopier des fichiers manquant ou défectueux, lancer un Chkdsk, modifier la base de registre, ou, dans le pire des cas, redescendre directement un master.
Prérequis
Les prérequis sont les même que dans l'article technet Comment créer un Windows PE 2.x Multiboot 32 et 64 bit
Procédure
Imaginons le scénario suivant:
Attention : la manipulation ci-après va mettre à jour/modifier la séquence de démarrage de votre serveur vers une séquence Windows Vista/Server 2008/Seven
La séquence passe donc de :
Attention-2: (Le retour)
Note : c'est un peu lourd mais ça a son importance pour la suite. Vous pouvez consulter les informations sur ces secteurs en utilisant un outil comme DskProbe
Après ces petites remarques, voici donc les commandes qui peuvent être réutilisées dans un batch:
Le résultat devrait être le suivant:
Vincar (pour les intimes) Windows Core Support Engineer
Bienvenue sur le blog de l’équipe Française de Support Windows Core ! Nous ouvrons les portes de ce blog aujourd’hui !
Parmi la multitude de blogs disponibles sur la toile, nous visons par le biais de celui-ci porter au jour les aspects de notre métier qui est souvent considéré comme ingrat mais qui, pour Microsoft, représente un atout conséquent dans la relation avec les professionnels de l’informatique et, parfois de manière plus large, avec les utilisateurs de nos produits.
Toute l’équipe Française Windows Core participe à cette initiative et chacun a pour objectif de faire partager son quotidien en mettant à disposition son vécu et ses compétences au travers de bulletins traitant de retour d’expérience, de résolution de dysfonctionnements ou de meilleures pratiques.
Nous espérons, à travers ce blog, vous faire découvrir de l’intérieur ce que représente le support chez Microsoft, travail qui consiste à assister au mieux nos clients, tout en essayant de vous faire découvrir plus profondément les technologies et produits que nous supportons (sans, bien entendu, aucune prétention de notre part !).
N’hésitez pas à vous abonner au fil RSS et à nous partager vos commentaires, nous serons heureux de vous répondre !
Sans être la cours des miracles, notre équipe est composée d’une certaine diversité qui mêle l’expérience à la curiosité et la patience à la ténacité. Des plus anciens ayant une longue expérience à la fois chez Microsoft mais aussi du milieu IT à ceux ayant rejoint plus récemment l’équipe, nous partageons tous la soif de savoir, le besoin de comprendre et l’envie de répondre au mieux aux sollicitations des clients qui nous contactent.
La force de notre équipe réside donc dans sa diversité et sa cohésion. Personne n’est jamais laissé seul face à une problématique, il y a toujours au moins une personne prête à aider, quelque soit le contexte.
Nous avons d’ailleurs un crédo :
Nous voici donc :
Pour dire deux mots sur les jobs cités :
Dernière chose, pourquoi Windows Core ?
C’est notre côté nombriliste qui s’exprime, Core se traduisant par noyau, nous aimons nous sentir le centre de l’univers :-)
Avant que nous viennent cette fabuleuse idée d’ouvrir un blog, nous avons déjà contribué à la mise à disposition de certains retours d’expérience sur le portail TechNet ainsi que dans la newsletter IT Pro du même nom.
A travers ce média, nous avons pour objectif de synthétiser les aspects techniques d’un dysfonctionnement particulier afin de donner des éléments aux professionels de l’informatique permettant d’éviter des problèmes récurrents.
Voici la liste des articles déjà publiés :
Conversion de machines physiques à virtuelles vers Virtual Server 2005 R2 et Sp1
Backup des machines virtuelles dans Virtual Server 2005 R2 SP1
Rétablir la communication entre machines virtuelles sous Virtual Server 2005 R2 Sp1 en Host Clustering
Comment créer un Windows PE 2.x Multiboot 32 et 64 bit
Installation automatisée de Windows Vista ou de Windows Server 2008
Le lien vers le portail de la newsletter : IT Pros : choisissez votre info Microsoft avec la Newsletter TechNet !