Erreur 0xC004F074 « Aucun service de gestion de clés (KMS) n’a pu être contacté »

S’applique à : ✔️ Machine virtuelles Windows

Cet article explique comment résoudre l’erreur de 0xC004F074 qui se produit lorsque vous essayez d’activer une machine virtuelle Windows dans Microsoft Azure.

Conditions préalables

• PowerShell
• Script du Gestionnaire de licences logicielles (slmgr.vbs)
• Outil PsPing

Symptômes

Lorsque vous essayez d’activer une machine virtuelle Windows Azure, vous rencontrez le message d’erreur suivant dans l’hôte de script Windows :

Erreur : 0xC004F074 Le service de gestion des licences logicielles a signalé que l’ordinateur n’a pas pu être activé. Aucun Gestionnaire de clés (KMS) n’a pu être contacté. Pour plus d’informations, consultez le journal des événements des applications.

Cause

La machine virtuelle ne peut pas se connecter au service KMS pour l’activation. Si azure KMS est utilisé pour l’activation (sélection par défaut), la demande d’activation doit provenir d’une adresse IP publique Azure. Les causes possibles de cette défaillance de connectivité sont les suivantes :

• Tunneling forcé, dans lequel tout le trafic est acheminé en dehors d’Azure (généralement vers un environnement local) à l’aide d’Azure ExpressRoute ou d’une appliance virtuelle réseau

• Trafic bloqué par une appliance virtuelle réseau ou un équilibreur de charge interne standard

Examen

Pour déterminer la cause spécifique du problème, suivez la procédure en trois parties dans les sections suivantes.

Partie 1 : Configurer la clé de configuration du client KMS appropriée

slmgr.vbs /dlv

Pour la machine virtuelle créée à partir d’une image personnalisée, vous devez configurer la clé de configuration du client KMS appropriée pour la machine virtuelle. Effectuez les étapes suivantes :

1. Dans une fenêtre d’invite de commandes avec élévation de privilèges, exécutez la commande de script du Gestionnaire de licences logicielles suivante :

   cscript c:\windows\system32\slmgr.vbs /dlv
   

2. Vérifiez la Description valeur dans la sortie pour déterminer si la machine virtuelle a été créée à partir du support de licence de vente au détail (RETAIL canal) ou de volume (VOLUME_KMSCLIENT).

3. Si la sortie de la commande précédente indique le RETAIL canal, exécutez les commandes de script du Gestionnaire de licences logicielles suivantes. La première commande définit la clé de configuration du client KMS pour la version de Windows Server utilisée, et la deuxième commande force une autre tentative d’activation.

   cscript c:\windows\system32\slmgr.vbs /ipk <kms-client-setup-key>
   cscript c:\windows\system32\slmgr.vbs /ato
   

   Par exemple, si vous utilisez Windows Server 2016 Datacenter, la première commande s’affiche comme suit :

   cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG
   

Partie 2 : Vérifier si la machine virtuelle se trouve derrière un équilibreur de charge interne de référence SKU Standard

Suivez ces étapes pour vérifier si la machine virtuelle se trouve derrière un équilibreur de charge interne de référence SKU Standard qui bloque le trafic Internet sortant par défaut :

1. Dans le portail Azure, recherchez et sélectionnez Machines virtuelles.

2. Dans la liste des machines virtuelles, sélectionnez le nom de votre machine virtuelle.

3. Dans le volet de menu de votre machine virtuelle, recherchez le titre Réseau , puis sélectionnez Équilibrage de charge. Si vous voyez un message indiquant Qu’aucune ressource d’équilibrage de charge n’est affichée, la machine virtuelle ne se trouve derrière aucun équilibreur de charge. Dans ce cas, vous pouvez passer à la partie 3 : vérifiez la connectivité entre la machine virtuelle et le service Azure KMS.

4. Si vous voyez une ressource d’équilibreur de charge, sélectionnez le nom de l’équilibreur de charge pour accéder à la page Vue d’ensemble de l’équilibreur de charge.

5. Dans le volet de menu de l’équilibreur de charge, sélectionnez Propriétés.

6. Dans la page Propriétés , recherchez les valeurs de la référence SKU et du type d’équilibrage de charge, puis consultez le tableau suivant pour obtenir des conclusions.

   Valeurs de référence SKU et de type d’équilibrage de charge	Conclusion
   La valeur de la référence SKU est Standard et la valeur type d’équilibrage de charge est privée.	La machine virtuelle se trouve derrière un équilibreur de charge interne de référence SKU Standard qui bloque le trafic Internet sortant par défaut. Pour activer la connectivité sortante, consultez la solution 2 : (Pour l’équilibreur de charge interne standard) Utilisez une passerelle NAT ou un équilibreur de charge public standard.
   La valeur de la référence SKU n’est pas Standard et la valeur type d’équilibrage de charge est Publique.	La machine virtuelle ne se trouve pas derrière un équilibreur de charge interne de référence SKU Standard et le trafic Internet sortant n’est pas bloqué par défaut. Passez à la partie 3 : vérifiez la connectivité entre la machine virtuelle et le service Azure KMS.

Partie 3 : Vérifier la connectivité entre la machine virtuelle et le service Azure KMS

1. Assurez-vous que la machine virtuelle est configurée pour utiliser le bon serveur Azure KMS. Pour ce faire, exécutez la commande de script du Gestionnaire de licences logicielles suivante :

   Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"
   

   Cette commande doit retourner le texte suivant :

   Le nom de machine de KMS a été configuré sur azkms.core.windows.net:1688 avec succès.

2. Assurez-vous que le pare-feu de la machine virtuelle ne bloque pas le trafic réseau sortant vers le point de terminaison KMS sur le port 1688. Pour ce faire, appliquez l’une des options suivantes :

   • Vérifiez la connectivité en exécutant l’applet de commande Test-NetConnection dans PowerShell :

     Test-NetConnection azkms.core.windows.net -port 1688
     

     Si la tentative de connexion est autorisée, l’applet de commande affiche « TcpTestSucceededed : True » dans le texte de sortie.

   • Vérifiez la connectivité en exécutant l’outil PsPing :

     .\psping.exe azkms.core.windows.net:1688
     

     Dans la sortie de commande, la deuxième à la dernière ligne doit ressembler au texte suivant :

     Sent = 4, Received = 4, Lost = 0 (0% loss)

     Si Lost elle est supérieure à 0 (zéro), la machine virtuelle n’a pas de connectivité au serveur KMS. Dans ce cas, si la machine virtuelle se trouve dans un réseau virtuel et a un serveur DNS personnalisé spécifié, vous devez vous assurer que le serveur DNS peut résoudre le nom de azkms.core.windows.net domaine. Si ce n’est pas le cas, remplacez le serveur DNS par celui qui peut être résolu azkms.core.windows.net.

     Note

     Si vous supprimez tous les serveurs DNS d’un réseau virtuel, les machines virtuelles utilisent le service DNS interne d’Azure. Ce service peut résoudre kms.core.windows.net.

3. Utilisez un test de tronçon suivant Azure Network Watcher pour vérifier que le type de tronçon suivant est Internet de la machine virtuelle affectée vers des destinations particulières. Pour appliquer le test de tronçon suivant, procédez comme suit :

   1. Dans le portail Azure, recherchez et sélectionnez Machines virtuelles.

   2. Dans la liste des machines virtuelles, sélectionnez le nom de votre machine virtuelle.

   3. Dans le volet de menu de votre machine virtuelle, recherchez le titre d’aide , puis sélectionnez Résolution des problèmes de connexion.

   4. Dans la page Résolution des problèmes de connexion de votre machine virtuelle, spécifiez les valeurs de champ suivantes.

      Champ	Valeur
      Type de destination	Spécifier manuellement
      URI, nom de domaine complet ou adresse IP	20.118.99.224, 40.83.235.53 (pour azkms.core.windows.net), ou l’adresse IP du point de terminaison KMS approprié qui s’applique à votre région
      Port de destination	1688
      Port source	1688
      Tests de diagnostic	Tronçon suivant

   5. Sélectionnez le bouton Exécuter les tests de diagnostic.

   6. Une fois les tests de diagnostic terminés, passez en revue la zone Résultats qui apparaît sous le bouton. Le test Tronçon suivant (à partir de la source) doit avoir une valeur d’état de réussite, et la valeur Détails doit inclure le type de tronçon suivant : Internet dans le texte. Si le type de tronçon suivant est Internet, répétez le test de tronçon suivant pour chacune des adresses IP restantes. Toutefois, si le type de tronçon suivant est affiché comme VirtualAppliance, VirtualNetworkGateway ou autre chose qu’Internet, l’un des scénarios suivants se produit probablement :

      • Un itinéraire par défaut existe qui route le trafic en dehors d’Azure avant que le trafic ne soit envoyé au point de terminaison Azure KMS.

      • Le trafic est bloqué quelque part le long du chemin d’accès.

      Pour ces scénarios, consultez la solution 1 : (Pour le tunneling forcé) Utilisez l’itinéraire personnalisé Azure pour acheminer le trafic d’activation vers le serveur Azure KMS.

4. Une fois qu’une connexion a azkms.core.windows.net réussi, exécutez la commande suivante à cette invite Windows PowerShell avec élévation de privilèges. Cette commande tente d’activer la machine virtuelle Windows plusieurs fois :

   1..12 | ForEach-Object {
       Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato";
       Start-Sleep 5
   }
   

   Si la tentative d’activation réussit, la commande affiche un message semblable au texte suivant :

   Activation de Windows(R), Server Datacenter edition (<kms-client-product-key>) ... Le produit a été activé avec succès.

Solution 1 : (pour le tunneling forcé) Utiliser l’itinéraire personnalisé Azure pour acheminer le trafic d’activation vers le serveur Azure KMS

Si la cause est un scénario de tunneling forcé dans lequel le trafic est acheminé en dehors d’Azure, collaborez avec votre administrateur réseau pour déterminer le bon cours d’action. Une solution possible est décrite dans la section Solution de l’activation de Windows échoue dans le scénario de tunneling forcé. Appliquez cette solution si elle est cohérente avec les stratégies de votre organisation.

Solution 2 : (pour l’équilibreur de charge interne standard) Utiliser une passerelle NAT ou un équilibreur de charge public standard

Si un équilibreur de charge interne standard bloque le trafic, il existe deux approches différentes pour résoudre le problème, comme décrit dans Utiliser la traduction d’adresses réseau source (SNAT) pour les connexions sortantes :

• Associez une passerelle NAT (Network Address Translation) au sous-réseau.

• Passez à un équilibreur de charge public standard et définissez des règles de trafic sortant.

Nous vous recommandons d’utiliser une configuration NAT d’Azure Réseau virtuel pour la connectivité sortante dans les déploiements de production. Pour plus d’informations sur Azure NAT Gateway, consultez Qu’est-ce que Azure NAT Gateway ?

Toutefois, s’il est nécessaire de bloquer tout le trafic Internet, veillez à refuser l’accès Internet sortant à l’aide d’une règle de groupe de sécurité réseau (NSG) sur le sous-réseau de la machine virtuelle que vous devez activer. Notez que le trafic d’activation du système d’exploitation vers les adresses IP KMS sur le port 1688 reste activé en raison de règles internes de la plateforme.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.