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

Note

Cet article a été publié à l’origine en tant que billet de 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 depuis 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 de l’activation basée sur Active Directory et des Service de gestion de clés s. Les contrôleurs de domaine de l’environnement de test exécutaient tous Windows Server 2012 R2. Nous n’avons donc pas 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. À ce stade tout était super. Nous avons créé un serveur physique exécutant Windows 2016 Server Standard et l’ordinateur est activé correctement.

En vérité, l’installation et la configuration on été très faciles, et cette partie a été simple et directe. Toutefois, 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 revenu voir la machine physique et tout allait bien. J’ai revu le client pour discuter de ce qui s’était produit. La première question était « Qu’est-ce qui a changé au cours du week-end ? » Et comme d’habitude, la réponse était « rien ». Cette fois, rien n’avait vraiment été changé, et nous avons dû déterminer ce qui se passait.

Je suis allé à l’un des serveurs problématiques, 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 que l’annuaire Active Directory est correctement configuré pour activer les clients KMS Windows.

Sachant que la slmgr commande est destinée à l’activation de la licence, j’ai continué avec différentes options. J’ai essayé le commutateur, qui affichera des informations détaillées sur la /dlv licence. J’ai bien regardé, 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.

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

Ma pensée est que pour une raison quelconque, la clé est rompue, donc j’utilise le /upk commutateur, qui désinstalle la clé actuelle. Bien que cela ait été efficace pour supprimer la clé, il 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é qu’il peut laisser le serveur dans un état incorrect ? J’ai trouvé que l’utilisation du /ipk commutateur (que je fais plus tard dans ma résolution des problèmes) remplace la clé existante et est un itinéraire plus sûr à prendre.

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

J’ai compris 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 comme le cas peut être). Là encore, j’ai obtenu seulement une erreur de produit introuvable.

La pensée suivante était que parfois l’arrêt et le démarrage d’un service fait l’astuce, donc j’ai essayé cela suivant. Je dois arrêter et démarrer le service Plateforme de protection logicielle Microsoft (SPPSvc). À partir d’une invite de commandes d’administration, j’utilise les commandes et net start les net stop approbations. Je remarque d’abord que le service n’est pas en cours d’exécution.

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 un des serveurs problématiques. Je trouve une erreur liée à l’activation de la licence, l’ID d’événement 8198, qui a un code 0x8007007B.

Lors de la recherche de ce code, j’ai trouvé un article indiquant que le code d’erreur signifie que le nom de fichier, le nom du répertoire ou la syntaxe d’étiquette de volume est incorrect. En lisant les méthodes décrites dans l’article, il ne semblait pas que l’un d’entre eux corresponde à la situation. Lorsque j’ai exécuté la nslookup -type=all _vlmcs._tcp commande, j’ai trouvé le serveur KMS existant (toujours un grand nombre de machines Windows 7 et Server 2008 dans l’environnement, il était donc nécessaire de le conserver), mais également 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.

Je sais ainsi que le DNS est correct. Active Directory est correctement configuré en tant que source d’activation KMS. Le serveur physique a été activé correctement. Pourrait-il s’agir d’un problème concernant simplement les machines virtuelles ? À ce stade, mon client m’informe qu’une personne d’un autre département a décidé de créer plus d’une dizaine de machines virtuelles Windows Server 2016. Maintenant, je suppose que j’ai une douzaine de serveurs à traiter avec ce ne sera pas l’activation. Toutefois, ces serveurs ont été activés très bien.

Eh bien, je suis retourné à la slmgr commande pour savoir comment obtenir ces monstres activés. 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 de configuration du client KMS pour obtenir les clés appropriées pour la version Standard de Windows Server 2016. Certains serveurs sont datacenter, mais je dois d’abord résoudre ce problème.

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

À partir d’ici, j’ai capturé seulement les résultats de mes expériences pour l’édition Datacenter, mais ils étaient les mêmes. J’ai utilisé le /ato commutateur pour forcer l’activation. Nous obtenons le message génial que le produit a été activé avec succès.

À l’aide du /dlv commutateur, nous pouvons voir que nous avons maintenant été activés par Active Directory.

Alors, 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 soient activées correctement ? Pourquoi l’autre dizaine de machines ont-elles été activées sans problème ? Comme je l’ai dit précédemment, j’ai manqué quelque chose dans les premières étapes de l’examen du problème. J’ai été soigneusement confus, donc contacté à l’affiche du blog initial. L’affiche a vu le problème immédiatement et m’a aidé à comprendre ce que j’avais manqué tôt.

Lorsque j’ai exécuté le premier /dlv commutateur, dans la description était la clé. La description était « Système d’exploitation Windows®, Canal RETAIL ». J’ai examiné cela et j’ai pensé que le canal RETAIL signifiait qu’il avait été acheté et que c’é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 en effet d’une licence en volume.

Que signifie alors le canal RETAIL ? En fait, cela signifie que le média utilisé pour installer le système d’exploitation était une image ISO MSDN. Je suis revenu vers mon client et j’ai demandé si par hasard, une image ISO de Windows Server 2016 se trouvait quelque part sur le réseau. Il s’est avéré que oui, il existait bien une autre image ISO sur le réseau, et qu’elle avait été utilisée pour créer l’autre dizaine de machines. Ils ont comparé les deux images ISO et il est apparu que celle qui m’avait été donnée pour créer les serveurs virtuels était en fait une image ISO MSDN. Ils ont supprimé msdn ISO de leur réseau et nous avons maintenant tous les serveurs existants activés et ne nous inquiétons plus de l’échec de l’activation sur les builds futures.