Le filigrane d’activation Windows continue d’être affiché
S’applique à : ✔️ machines virtuelles Windows exécutant Windows Server 2022 Datacenter Azure Edition
Ce document explique comment résoudre la présence continue d’un filigrane d’activation Windows sur les machines virtuelles Microsoft Azure.
Prerequisites
Symptômes
Lorsque vous utilisez une machine virtuelle Azure qui exécute Windows Server 2022 Datacenter Azure Edition, vous rencontrez les symptômes suivants :
Vous voyez un filigrane sur le bureau qui contient le message suivant :
Activez Windows. Allez dans les Paramètres pour activer Windows.
Ce filigrane indique que l’état d’activation de Windows n’est pas authentique.
Lorsque vous ouvrez l’application Paramètres et sélectionnez Activation du système>, le champ État de l’application indique un échec d’activation.
Lorsque vous ouvrez une fenêtre d’invite de commandes avec élévation de privilèges et exécutez le script d’activation de volume slmgr.vbs suivant, la sortie indique que l’activation Service de gestion de clés s (KMS) réussit, mais les deux premiers symptômes restent :
cscript c:\windows\system32\slmgr.vbs /dlvLorsque vous redémarrez ou connectez-vous à la machine virtuelle, une fenêtre contextuelle avec le message suivant s’affiche :
Votre machine virtuelle Windows Server 2022 Datacenter Azure Edition a été désactivée, car vous n’êtes pas en cours d’exécution sur Azure ou sur un hyperviseur Azure Stack pris en charge, ou que vous n’avez pas activé les avantages Azure sur Azure Stack pris en charge. Pour activer les avantages Azure, accédez à vos paramètres de cluster dans Windows Admin Center > Activer les avantages Azure.
Cause 1 : Problème de connexion au service de métadonnées d’instance Azure
La machine virtuelle Azure ne peut pas établir de connexion avec le point de terminaison IMDS (Azure Instance Metadata Service), ce qui est essentiel pour obtenir le jeton d’activation.
Comment déterminer si le système d’exploitation invité de la machine virtuelle peut communiquer avec IMDS
Exécutez le script PowerShell suivant en fonction de votre version de PowerShell pour vérifier si les métadonnées sont reçues de IMDS.
PowerShell 6 et versions ultérieures
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2020-09-01 | Format-List * | Out-File "IMDSResponse1.txt"PowerShell 5 et versions antérieures
$Proxy=New-object System.Net.WebProxy $WebSession=new-object Microsoft.PowerShell.Commands.WebRequestSession $WebSession.Proxy=$Proxy Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -WebSession $WebSession
Si vous obtenez une réponse réussie, vous verrez les informations de métadonnées de la machine virtuelle, telles que la sortie suivante :
compute
-------
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...
Si ce n’est pas le cas, cela signifie que la connexion au serveur de câble IMDS est bloquée quelque part et que l’accès à celui-ci doit être autorisé. L’adresse IP du serveur IMDS est 169.254.169.254. Pour résoudre le problème de connexion, accédez à la solution 1 : Contourner les proxys web au sein de la machine virtuelle.
Cause 2 : Problème lié au certificat
Les certificats intermédiaires qui sont essentiels pour le processus d’activation ont expiré.
Pour plus d’informations, consultez TLS des données attestées du service de métadonnées d’instance Azure : les modifications critiques sont ici.
Guide pratique pour déterminer si des certificats sont manquants
Exécutez le script PowerShell suivant pour rechercher les certificats manquants :
# Get the signature
# Powershell 5.1 does not include -NoProxy
$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01
#$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01
# Decode the signature
$signature = [System.Convert]::FromBase64String($attestedDoc.signature)
# Get certificate chain
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]($signature)
$chain = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Chain
if (-not $chain.Build($cert)) {
# Print the Subject of the issuer
Write-Host $cert.Subject
Write-Host $cert.Thumbprint
Write-Host "------------------------"
Write-Host $cert.Issuer
Write-Host "------------------------"
Write-Host "Certificate not found: '$($cert.Issuer)'" -ForegroundColor Red
Write-Host "Please refer to the following link to download missing certificates:" -ForegroundColor Yellow
Write-Host "https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?tabs=certificate-authority-chains" -ForegroundColor Yellow
} else {
# Print the Subject of each certificate in the chain
foreach($element in $chain.ChainElements) {
Write-Host $element.Certificate.Subject
Write-Host $element.Certificate.Thumbprint
Write-Host "------------------------"
}
# Get the content of the signed document
Add-Type -AssemblyName System.Security
$signedCms = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms
$signedCms.Decode($signature);
$content = [System.Text.Encoding]::UTF8.GetString($signedCms.ContentInfo.Content)
Write-Host "Attested data: " $content
$json = $content | ConvertFrom-Json
}
Si des certificats sont manquants, vous verrez une sortie similaire à la suivante :
CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
3ACCC393D3220E40F09A69AC3251F6F391172C32
------------------------
CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US
------------------------
Certificate not found: 'CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US'
Please refer to the following link to download missing certificates:
https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?tabs=certificate-authority-chains
Pour résoudre le problème de certificat, accédez à la solution 2 : vérifiez que les pare-feu et les proxys sont configurés pour autoriser les téléchargements de certificats.
Solution 1 : Contourner les proxys web au sein de la machine virtuelle
IMDS est une API REST disponible à une adresse IP non routable connue (169.254.169.254). Le point de terminaison IMDS est accessible à partir de la machine virtuelle uniquement à l’URI suivant : http://169.254.169.254/metadata/instance La communication entre la machine virtuelle et IMDS ne quitte jamais l’hôte. Les clients HTTP contournent les proxys web au sein de la machine virtuelle pendant qu’ils interrogent IMDS. Vérifiez également que les clients traitent l’adresse 169.254.169.254 IP de la même manière qu’ils traitent l’adresse IP 168.63.129.16. Pour vérifier que cette connexion réseau directe existe, procédez comme suit :
Note
168.63.129.16 est une adresse IP publique virtuelle appartenant à Microsoft utilisée pour communiquer avec les ressources Azure.
Pour afficher la table de routage locale sur votre machine virtuelle, exécutez la commande d’impression de routage :
route printPour localiser l’entrée de routage de la cible IMDS, accédez à la
Active Routessection de laIPv4 Route Tablesortie, puis recherchez la ligne qui contient l’adresse169.254.169.254IP dans laNetwork Destinationcolonne.Destination réseau Masque réseau Passerelle Interface Métrique 0.0.0.0 0.0.0.0 172.16.69.1 172.16.69.7 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 168.63.129.16 255.255.255.255 172.16.69.1 172.16.69.7 11 169.254.169.254 255.255.255.255 172.16.69.1 172.16.69.7 11 ... ... ... ... ... Dans l’exemple de sortie de table de routage, l’entrée cible IMDS se trouve dans la dernière ligne et l’interface réseau correspondante est la valeur de la
Interfacecolonne dans cette ligne. (Dans cet exemple, l’interface réseau est172.16.69.7.)Pour afficher la configuration IP de votre machine virtuelle, exécutez la commande ipconfig :
ipconfig /allDans la sortie de la commande ipconfig, recherchez la configuration IP dans laquelle le
IPv4 Addresschamp correspond à la valeur de l’interface réseau de l’entrée IMDS (172.16.69.7) :... Ethernet adapter Ethernet: Connection-specific DNS Suffix . : xic3mnxjiefupcwr1mcs1rjiqa.cx.internal.cloudapp.net Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter Physical Address. . . . . . . . . : 00-0D-3A-E5-1C-C0 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::3166:ce5a:2bd5:a6d1%3(Preferred) IPv4 Address. . . . . . . . . . . : 172.16.69.7(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 ...Dans l’exemple de sortie ipconfig, la configuration IP qui contient la valeur de l’interface réseau de l’entrée IMDS est
Ethernet adapter Ethernet.Dans la configuration IP que vous avez située, copiez l’adresse MAC (Media Access Control) et l’adresse IP privée principale utilisée par la machine virtuelle. L’adresse MAC est affichée dans le
Physical Addresschamp, et l’adresse IP privée principale est affichée dans leIPv4 Addresschamp. Dans cet exemple, l’adresse MAC et l’adresse IP privée principale sont00-0D-3A-E5-1C-C0et172.16.69.7, respectivement.Vérifiez si les adresses IP MAC et ip privées primaires qu’Azure utilise pour la machine virtuelle correspondent à l’adresse MAC et à l’adresse IP privée principale que le système d’exploitation invité de la machine virtuelle utilise réellement (les adresses que vous avez trouvées à l’étape précédente). Pour déterminer l’utilisation d’Azure comme adresse MAC, vous utilisez Azure CLI. Pour déterminer ce qu’Azure utilise comme adresse IP privée principale, vous examinez la configuration du réseau dans le Portail Azure.
Rechercher l’adresse MAC (à l’aide d’Azure CLI dans un script PowerShell)
Exécutez le script PowerShell suivant qui appelle des commandes Azure CLI. Ce script appelle la commande az vm nic list pour collecter les noms des interfaces réseau sur votre machine virtuelle. Ensuite, il appelle la commande az vm nic show pour afficher le nom de chaque interface réseau, que cette interface réseau soit l’interface réseau principale (
TrueouFalse) et l’adresse MAC de l’interface réseau :Note
Dans les commandes, « carte réseau » représente l’interface réseau, et non une carte d’interface réseau.
# Placeholder variable definitions $ResourceGroup = "<resource-group-name>" $VmName = "<virtual-machine-name>" # Code $NicNames = az vm nic list --resource-group $ResourceGroup --vm-name $VmName | ConvertFrom-Json | Foreach-Object { $_.id.Split('/')[-1] } foreach($NicName in $NicNames) { az vm nic show --resource-group $ResourceGroup --vm-name $VmName --nic $NicName | ConvertFrom-Json | Format-Table -Property name, primary, macAddress }name primary macAddress ---- ------- ---------- wintest767 True 00-0D-3A-E5-1C-C0Recherchez l’adresse IP privée principale (à l’aide du Portail Azure) :
Dans le portail Azure, recherchez et sélectionnez Machines virtuelles.
Dans la liste des machines virtuelles, sélectionnez le nom de votre machine virtuelle.
Sous l’onglet Propriétés de la page Vue d’ensemble de votre machine virtuelle, recherchez le titre Réseau.
Dans le champ Adresse IP privée, copiez l’adresse IPv4 affichée.
Si les adresses MAC ou les adresses IP privées principales ne sont pas identiques entre Azure et le système d’exploitation invité de la machine virtuelle, utilisez différentes commandes de routage pour mettre à jour la table de routage afin que l’interface réseau principale et l’adresse IP soient ciblées.
Solution 2 : Vérifier que les pare-feu et les proxys sont configurés pour autoriser les téléchargements de certificats
Vérifiez si la base de connaissances 5036909 est installée. Si ce n’est pas le cas, installez-le. Vous pouvez l’obtenir à partir du catalogue Microsoft Update.
Si vous avez installé la mise à jour mais que vous rencontrez toujours le problème, vérifiez que les pare-feu et proxys de votre système sont configurés pour autoriser le téléchargement des certificats. Pour plus d’informations, consultez les listes de téléchargements et de révocation de certificats.
Vous pouvez également télécharger et installer tous les certificats directement à partir des chaînes d’autorité de certification racine et secondaire.
Note
Veillez à sélectionner l’emplacement du magasin en tant qu’ordinateur local dans l’Assistant Installation.
Ouvrez l’invite de commandes en tant qu’administrateur, accédez à c :\windows\system32 et exécutez fclip.exe.
Redémarrez la machine virtuelle ou déconnectez-vous, puis reconnectez-vous. Vous verrez que le filigrane de la page d’accueil n’est plus affiché et que le champ État de l’application dans l’écran Activation des paramètres>signale la réussite.
Plus d’informations
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.