Résoudre les problèmes liés à l’activation basée sur Active Directory (ADBA) clients qui ne s’activent pas

Remarque

Cet article a été initialement publié en tant que blog TechNet le 26 mars 2018.

J’ai récemment aidé un client à déployer Windows Server 2016 dans son environnement. Nous avons profité de cette occasion pour migrer également leur méthodologie d’activation d’un serveur KMS vers l’activation basée sur Active Directory.

Comme procédure appropriée pour apporter toutes les modifications, nous avons démarré la migration dans l’environnement de test du client. Nous avons commencé le déploiement en suivant les instructions fournies dans Active Directory-Based Activation et Key Management Services. Les contrôleurs de domaine dans l’environnement de test s’exécutaient tous Windows Server 2012 R2. Nous n’avons donc pas eu besoin de préparer la forêt. Nous avons installé le rôle sur un contrôleur de domaine Windows Server 2012 R2 et choisi l’activation basée sur Active Directory comme méthode d’activation en volume. Nous avons installé la clé KMS et lui avons donné le nom « ACTIVATION KMS AD (** LAB) ». Nous avons suivi le billet de blog étape par étape.

Nous avons commencé par créer quatre machines virtuelles, deux Windows 2016 Server Standard et deux Windows 2016 Server Datacenter. A ce stade, tout était super. Nous avons créé un serveur physique exécutant Windows 2016 Server Standard, et la machine s’est activée correctement.

En vérité, la configuration et la configuration étaient super faciles, de sorte que la partie était simple et simple. Cependant, toutes les machines virtuelles que j’avais créées la semaine précédente ont montré qu’elles n’étaient pas activées. Je suis retourné à la machine physique et tout allait bien. Je suis allé voir le client pour discuter de ce qui s’était passé. La première question était « Qu’est-ce qui a changé pendant le week-end ? » Et comme d’habitude, la réponse était « rien ». Cette fois, rien n’avait vraiment changé, et nous avons dû comprendre ce qui se passait.

Je suis allé sur l’un des serveurs à problème, j’ai ouvert une invite de commandes et vérifié la sortie de la slmgr /ao-list commande. Le /ao-list commutateur affiche tous les objets d’activation dans Active Directory.

Les résultats montrent que nous avons deux objets d’activation : un pour Windows Server 2012 R2 et la nouvelle activation KMS AD (** LAB), qui est la licence Windows Server 2016. Cela confirme qu’Active Directory est correctement configuré pour activer les clients KMS Windows.

Sachant que la commande est destinée à l’activation slmgr de licence, j’ai continué avec différentes options. J’ai essayé le /dlv commutateur, qui affichera des informations détaillées sur la licence. Cela semblait bien, j’exécutais la version Standard de Windows Server 2016, il y a un ID d’activation, un ID d’installation, une URL de validation, même une clé de produit partielle.

Est-ce que quelqu’un voit ce que j’ai manqué à ce stade ? Nous y reviendrons après mes autres étapes de résolution des problèmes, mais il suffit de dire que la réponse se trouve dans cette capture d’écran.

Je pense maintenant que pour une raison quelconque, la clé est cassée, donc j’utilise le /upk commutateur, qui désinstalle la clé actuelle. Bien que cela ait été efficace pour supprimer la clé, ce n’est généralement pas la meilleure façon de le faire. Le serveur doit-il être redémarré avant d’obtenir une nouvelle clé, il risque de laisser le serveur dans un état incorrect ? J’ai constaté que l’utilisation du /ipk commutateur (ce que je ferai plus tard dans ma résolution des problèmes) remplace la clé existante et est une route plus sûre à prendre.

J’ai ré-exécuté le /dlv commutateur pour voir les informations de licence détaillées. Malheureusement, cela ne m’a pas donné d’informations utiles, juste une erreur de clé de produit introuvable. Parce qu’il n’y a pas de clé depuis que je viens de la désinstaller.

Je me suis dit que c’était un long coup, mais j’ai essayé le /ato commutateur, qui devrait activer Windows sur les serveurs KMS connus (ou Active Directory selon le cas). Là encore, juste une erreur de produit introuvable.

La pensée suivante a été que parfois l’arrêt et le démarrage d’un service fait l’affaire, donc j’ai essayé que ensuite. J’ai besoin d’arrêter et de démarrer le service SPPSvc (Microsoft Software Protection Platform Service). À partir d’une invite de commandes d’administration, j’utilise les commandes trusty net stop et net start . Je remarque d’abord que le service n’est pas en cours d’exécution, donc je pense que cela doit être tout.

Toutefois, après avoir démarré le service et tenté d’activer à nouveau Windows, j’obtiens toujours l’erreur du produit introuvable.

J’ai ensuite examiné le journal des événements d’application sur l’un des serveurs de problèmes. J’ai trouvé une erreur liée à l’activation de la licence, ID d’événement 8198, qui a un code de 0x8007007B.

En recherchant ce code, j’ai trouvé un article qui indique que le code d’erreur signifie que le nom de fichier, le nom du répertoire ou la syntaxe d’étiquette de volume est incorrecte. En lisant les méthodes décrites dans l’article, il ne semblait pas que l’une d’elles corresponde à la situation. Quand j’ai exécuté la nslookup -type=all _vlmcs._tcp commande, j’ai trouvé le serveur KMS existant (encore beaucoup de machines Windows 7 et Server 2008 dans l’environnement, il était donc nécessaire de le conserver), mais aussi les cinq contrôleurs de domaine. Cela a indiqué qu’il ne s’agissait pas d’un problème DNS et que les problèmes étaient ailleurs.

Donc je sais que LE DNS va bien. Active Directory est correctement configuré en tant que source d’activation KMS. Le serveur physique a été activé correctement. Est-ce qu’il s’agit d’un problème uniquement avec les machines virtuelles ? Comme une note secondaire intéressante à ce stade, mon client m’informe que quelqu’un dans un autre département a décidé de créer plus d’une douzaine de machines Windows Server 2016 virtuelles ainsi. Donc maintenant, je suppose que j’ai une autre douzaine de serveurs à gérer qui ne sera pas en cours d’activation. Toutefois, ces serveurs ont été activés correctement.

Eh bien, je suis retourné au slmgr commandement pour trouver comment activer ces monstres. Cette fois, je vais utiliser le /ipk commutateur, ce qui me permettra d’installer une clé de produit. Je suis allé à l’Annexe A : Clés d’installation du client KMS pour obtenir les clés appropriées pour la version Standard de Windows Server 2016. Certains serveurs sont des centres de données, mais je dois d’abord corriger celui-ci.

J’ai utilisé le /ipk commutateur pour installer une clé de produit, en choisissant la Windows Server 2016 clé Standard.

À partir de là, je n’ai capturé que les résultats de mes expériences de centre de données, mais ils étaient les mêmes. J’ai utilisé le /ato commutateur pour forcer l’activation. Nous recevons le message impressionnant que le produit a été activé avec succès.

En utilisant à nouveau le /dlv commutateur, nous pouvons voir que nous avons maintenant été activés par Active Directory.

Qu’est-ce qui s’est mal passé ? Pourquoi ai-je dû supprimer la clé installée et ajouter ces clés génériques pour que ces machines s’activent correctement ? Pourquoi les autres dizaines de machines se sont-elles activées sans problème ? Comme je l’ai dit plus tôt, j’ai raté quelque chose de clé dans les premières étapes de l’analyse de la question. J’étais complètement confus, donc contacté à l’affiche du blog initial. L’affiche a vu le problème tout de suite et m’a aidé à comprendre ce que j’avais manqué tôt.

Lorsque j’ai exécuté le premier /dlv commutateur, dans la description se trouvait la clé. La description était Système d’exploitation Windows®, CANAL DE VENTE AU DÉTAIL. J’avais examiné cela et je pensais que RETAIL Channel signifiait qu’il avait été acheté et était une clé valide.

Lorsque nous examinons la sortie du /dlv commutateur à partir d’un serveur correctement activé, notez que la description indique maintenant le canal VOLUME_KMSCLIENT. Cela nous permet de savoir qu’il s’agit bien d’une licence en volume.

Alors, que signifie ce canal RETAIL ? Eh bien, cela signifie que le média qui a été utilisé pour installer le système d’exploitation était un ISO MSDN. Je suis retourné voir mon client et lui ai demandé si, par hasard, il y avait une deuxième Windows Server 2016 ISO flottant autour du réseau. Il s’avère que oui, il y avait un autre ISO sur le réseau, et il avait été utilisé pour créer les autres douzaines de machines. Ils ont comparé les deux isos et assez sûr que celui qui m’a été donné pour créer les serveurs virtuels était, en fait, un ISO MSDN. Ils ont supprimé ce fichier ISO MSDN de leur réseau et nous avons maintenant tous les serveurs existants activés et plus de soucis concernant l’échec de l’activation sur les builds futures.