Fout 0xC004F074 "Er kan geen contact worden gemaakt met Key Management Service (KMS)”

Artikel
07/30/2024

Van toepassing op: ✔️ Windows-VM's

In dit artikel wordt beschreven hoe u de 0xC004F074 fout oplost die optreedt wanneer u een virtuele Windows-machine (VM) in Microsoft Azure probeert te activeren.

Voorwaarden

Powershell
Het script Software License Manager (slmgr.vbs)
Het hulpprogramma PsPing

Symptomen

Wanneer u een Virtuele Azure Windows-machine probeert te activeren, wordt het volgende foutbericht weergegeven in Windows Script Host:

Fout: 0xC004F074 De softwarelicentieservice heeft gemeld dat de computer niet kan worden geactiveerd. Er kan geen contact worden gemaakt met de service voor sleutelbeheer (KMS). Raadpleeg het gebeurtenislogboek van de toepassing voor meer informatie.

Oorzaak

De VM kan geen verbinding maken met de KMS-service voor activering. Als een Azure KMS wordt gebruikt voor activering (de standaardselectie), moet de activeringsaanvraag afkomstig zijn van een openbaar Azure-IP-adres. De mogelijke oorzaken van deze verbindingsfout zijn:

Geforceerde tunneling, waarbij al het verkeer buiten Azure wordt gerouteerd (meestal naar een on-premises omgeving) met behulp van Azure ExpressRoute of een virtueel netwerkapparaat
Verkeer dat wordt geblokkeerd door een virtueel netwerkapparaat of een standaard interne load balancer

Onderzoek

Volg de driedelige procedure in de volgende secties om de specifieke oorzaak van het probleem te achterhalen.

Deel 1: De juiste installatiesleutel voor de KMS-client configureren

Notitie

Dit onderdeel is niet vereist voor VM's waarop Windows 10 Enterprise meerdere sessies worden uitgevoerd (ook wel Bekend als Windows 10 Enterprise voor Virtual Desktops) in Azure Virtual Desktop).

Voer de volgende scriptopdracht voor Software License Manager uit om te bepalen of de VM de editie met meerdere sessies uitvoert:

slmgr.vbs /dlv

Als de uitvoer de Name: Windows(R), ServerRdsh edition tekenreeks bevat, wordt de editie met meerdere sessies uitgevoerd op de virtuele machine en kunt u de rest van dit deel overslaan.

Notitie

Als u een windows 10 Enterprise-VM met meerdere sessies implementeert en de productcode vervolgens bijwerkt naar een andere editie, kunt u de virtuele machine niet terugzetten naar Windows 10 Enterprise-multisessie. In plaats daarvan moet u de VIRTUELE machine opnieuw implementeren. Zie Kan ik een Windows-VM upgraden naar Een Windows Enterprise-multisessie voor meer informatie ?

Voor de VM die is gemaakt op basis van een aangepaste installatiekopieën, moet u de juiste installatiesleutel voor de KMS-client configureren voor de virtuele machine. Volg vervolgens deze stappen:

Voer in een opdrachtpromptvenster met verhoogde bevoegdheid de volgende scriptopdracht voor Software License Manager uit:
```
cscript c:\windows\system32\slmgr.vbs /dlv
```
Controleer de Description waarde in de uitvoer om te bepalen of de VIRTUELE machine is gemaakt op basis van detailhandelmedia (RETAIL kanaal) of volumelicentiemediaVOLUME_KMSCLIENT.
Als de vorige uitvoer van de opdracht het RETAIL kanaal aangeeft, voert u de volgende Software License Manager-scriptopdrachten uit. Met de eerste opdracht wordt de installatiesleutel van de KMS-client ingesteld voor de versie van Windows Server die wordt gebruikt en de tweede opdracht dwingt een andere activeringspoging af.
```
cscript c:\windows\system32\slmgr.vbs /ipk <kms-client-setup-key>
cscript c:\windows\system32\slmgr.vbs /ato
```
Als u bijvoorbeeld Windows Server 2016 Datacenter gebruikt, wordt de eerste opdracht als volgt weergegeven:
```
cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG
```

Deel 2: Controleren of de virtuele machine zich achter een interne load balancer van de Standard-SKU bevindt

Volg deze stappen om te controleren of de VIRTUELE machine zich achter een interne Standard SKU-load balancer bevindt die standaard uitgaand internetverkeer blokkeert:

Ga naar Azure Portal, en zoek en selecteer Virtuele machines.
Selecteer in de lijst met virtuele machines de naam van uw virtuele machine.
Zoek in het menuvenster voor uw VIRTUELE machine de kop Netwerken en selecteer Vervolgens Taakverdeling. Als u een bericht ziet waarin staat dat er geen taakverdelingsbronnen worden weergegeven, bevindt de VM zich niet achter een load balancer. In dit geval kunt u doorgaan naar deel 3: De verbinding tussen de VIRTUELE machine en de Azure KMS-service controleren.
Als u een load balancer-resource ziet, selecteert u de naam van de load balancer om naar de overzichtspagina van de load balancer te gaan.
Selecteer Eigenschappen in het menuvenster van de load balancer.

Zoek op de pagina Eigenschappen de waarden voor het SKU - en taakverdelingstype en bekijk vervolgens de volgende tabel voor conclusies.

Waarden van het SKU - en taakverdelingstype	Conclusie
De SKU-waarde is Standaard en de waarde taakverdelingstype is Privé.	De VIRTUELE machine bevindt zich achter een interne standard-SKU-load balancer die standaard uitgaand internetverkeer blokkeert. Zie Oplossing 2: (voor standaard interne load balancer) Een NAT-gateway of een standaard openbare load balancer gebruiken om uitgaande connectiviteit in te schakelen.
De SKU-waarde is niet Standaard en de waarde taakverdelingstype is openbaar.	De VIRTUELE machine bevindt zich niet achter een interne load balancer van de Standard-SKU en uitgaand internetverkeer wordt standaard niet geblokkeerd. Ga door naar deel 3: Controleer de connectiviteit tussen de VM en de Azure KMS-service.

Deel 3: De connectiviteit tussen de VM en de Azure KMS-service controleren

Zorg ervoor dat de VM is geconfigureerd om de juiste Azure KMS-server te gebruiken. Voer hiervoor de volgende scriptopdracht voor Software License Manager uit:
```
Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"
```
Met deze opdracht moet de volgende tekst worden geretourneerd:

Computernaam voor Key Management Service is ingesteld op azkms.core.windows.net:1688.
Zorg ervoor dat de firewall in de VIRTUELE machine uitgaand netwerkverkeer niet blokkeert naar het KMS-eindpunt op poort 1688. U doet dit door een van de volgende opties toe te passen:
- Controleer de connectiviteit door de cmdlet Test-NetConnection uit te voeren in PowerShell:
```
Test-NetConnection azkms.core.windows.net -port 1688
```
  Als de verbindingspoging is toegestaan, wordt in de uitvoertekst 'TcpTestSucceededed: True' weergegeven.
- Controleer de connectiviteit door het PsPing-hulpprogramma uit te voeren:
```
.\psping.exe azkms.core.windows.net:1688
```
  In de uitvoer van de opdracht moet de tweede tot laatste regel lijken op de volgende tekst:
  
  Sent = 4, Received = 4, Lost = 0 (0% loss)
  
  Als Lost deze groter is dan 0 (nul), heeft de VIRTUELE machine geen verbinding met de KMS-server. Als de virtuele machine zich in een virtueel netwerk bevindt en een aangepaste DNS-server heeft opgegeven, moet u ervoor zorgen dat de DNS-server de azkms.core.windows.net domeinnaam kan omzetten. Als dit niet mogelijk is, wijzigt u de DNS-server in een server die kan worden omgezet azkms.core.windows.net.
  
  Notitie
  
  Als u alle DNS-servers uit een virtueel netwerk verwijdert, gebruiken VM's de interne DNS-service van Azure. Deze service kan worden omgezet kms.core.windows.net.

Gebruik een volgende hoptest van Azure Network Watcher om te controleren of het volgende hoptype internet is van de betreffende VM naar bepaalde bestemmingen. Voer de volgende stappen uit om de volgende hoptest toe te passen:

Ga naar Azure Portal, en zoek en selecteer Virtuele machines.
Selecteer in de lijst met virtuele machines de naam van uw virtuele machine.
Zoek in het menuvenster van uw VIRTUELE machine de Help-kop en selecteer vervolgens Verbindingsproblemen oplossen.

Geef op de pagina Verbindingsproblemen van uw VIRTUELE machine de volgende veldwaarden op.

Veld	Waarde
Doeltype	Handmatig opgeven
URI, FQDN of IP-adres	20.118.99.224, 40.83.235.53 (voor `azkms.core.windows.net`) of het IP-adres van het juiste KMS-eindpunt dat van toepassing is op uw regio
Doelpoort	1688
Bronpoort	1688
Diagnostische tests	Volgende hop

Selecteer de knop Diagnostische tests uitvoeren.
Nadat de diagnostische tests zijn voltooid, bekijkt u het vak Resultaten dat onder de knop wordt weergegeven. De test Volgende hop (van bron) moet de statuswaarde Geslaagd hebben en de waarde Details moet het volgende hoptype bevatten : Internet in de tekst. Als het volgende hoptype internet is, herhaalt u de volgende hoptest voor elk van de resterende IP-adressen. Als het volgende hoptype echter wordt weergegeven als VirtualAppliance, VirtualNetworkGateway of iets anders dan internet, gebeurt er waarschijnlijk een van de volgende scenario's:
- Er bestaat een standaardroute die het verkeer buiten Azure routeert voordat het verkeer naar het Azure KMS-eindpunt wordt verzonden.
- Verkeer wordt ergens langs het pad geblokkeerd.
Zie oplossing 1 voor deze scenario's : (voor geforceerde tunneling) Gebruik de aangepaste Azure-route om activeringsverkeer naar de Azure KMS-server te routeren.

Nadat u hebt gecontroleerd of er verbinding is azkms.core.windows.net gemaakt, voert u de volgende opdracht uit op de Windows PowerShell-prompt met verhoogde bevoegdheid. Met deze opdracht wordt geprobeerd de Windows-VM meerdere keren te activeren:
```
1..12 | ForEach-Object {
    Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato";
    Start-Sleep 5
}
```
Als de activeringspoging is geslaagd, wordt met de opdracht een bericht weergegeven dat lijkt op de volgende tekst:

Windows(R), Server Datacenter Edition (<kms-client-product-key>) activeren... Product geactiveerd.

Oplossing 1: (Voor geforceerde tunneling) Gebruik de aangepaste Azure-route om activeringsverkeer naar de Azure KMS-server te routeren

Als de oorzaak een scenario voor geforceerde tunneling is waarin verkeer buiten Azure wordt gerouteerd, neemt u contact op met de netwerkbeheerder om de juiste actie te bepalen. Een mogelijke oplossing wordt beschreven in de sectie Oplossing van windows-activering mislukt in het scenario voor geforceerde tunneling. Pas deze oplossing toe als deze consistent is met het beleid van uw organisatie.

Oplossing 2: (voor standaard interne load balancer) Gebruik een NAT-gateway of een standaard openbare load balancer

Als een standaard interne load balancer verkeer blokkeert, zijn er twee verschillende benaderingen om het probleem op te lossen, zoals beschreven in SNAT (Source Network Address Translation) gebruiken voor uitgaande verbindingen:

U wordt aangeraden een NAT-configuratie van Azure Virtual Network te gebruiken voor uitgaande connectiviteit in productie-implementaties. Zie Wat is Azure NAT Gateway?

Als er echter een vereiste is om al het internetverkeer te blokkeren, moet u ervoor zorgen dat u uitgaande internettoegang weigert met behulp van een netwerkbeveiligingsgroepregel (NSG) op het subnet van de VIRTUELE machine die u moet activeren. U ziet dat activeringsverkeer van het besturingssysteem naar de KMS-IP's op poort 1688 blijft ingeschakeld vanwege interne platformregels.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.

Delen via