La filigrana di attivazione di Windows continua a essere visualizzata
Si applica a: ✔️ Macchine virtuali Windows che eseguono Windows Server 2022 Datacenter Azure Edition
Questo documento illustra come risolvere la presenza continua di una filigrana di attivazione di Windows nelle macchine virtuali di Microsoft Azure.
Prerequisiti
Sintomi
Quando si usa una macchina virtuale di Azure che esegue Windows Server 2022 Datacenter Azure Edition, si verificano i sintomi seguenti:
Sul desktop viene visualizzata una filigrana contenente il messaggio seguente:
Attivare Windows. Passare a Impostazioni per attivare Windows.
Questa filigrana indica che lo stato di attivazione di Windows non è originale.
Quando si apre l'app Impostazioni e si seleziona Attivazione sistema>, il campo Stato applicazione indica un errore di attivazione.
Quando si apre una finestra del prompt dei comandi con privilegi elevati ed si esegue lo script di attivazione dei contratti multilicenza slmgr.vbs seguente, l'output mostra che l'attivazione dei Servizio di gestione delle chiavi (KMS) ha esito positivo, ma i primi due sintomi rimangono:
cscript c:\windows\system32\slmgr.vbs /dlvQuando si riavvia o si accede alla macchina virtuale, viene visualizzata una finestra popup con il messaggio seguente:
La macchina virtuale Di Azure Edition di Windows Server 2022 Datacenter è stata disattivata perché non è in esecuzione in Azure o in un hypervisor di Azure Stack supportato o che non sono stati abilitati i vantaggi di Azure in Azure Stack supportati. Per abilitare i vantaggi di Azure, passare alle impostazioni del cluster in Windows Admin Center > Abilitare i vantaggi di Azure.
Causa 1: Problema di connessione al servizio metadati dell'istanza di Azure
La macchina virtuale di Azure non riesce a stabilire una connessione con l'endpoint IMDS (Azure Instance Metadata Service), essenziale per ottenere il token di attivazione.
Come determinare se il sistema operativo guest della macchina virtuale può comunicare correttamente con IMDS
Eseguire lo script di PowerShell seguente a seconda della versione di PowerShell per verificare se i metadati vengono ricevuti da IMDS.
PowerShell 6 e versioni successive
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 e versioni precedenti
$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
Se si ottiene una risposta con esito positivo, verranno visualizzate le informazioni sui metadati della macchina virtuale, ad esempio l'output seguente:
compute
-------
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...
In caso contrario, significa che la connessione al server di trasmissione IMDS è bloccata da qualche parte e l'accesso a esso deve essere consentito. L'indirizzo IP del server IMDS è 169.254.169.254. Per risolvere il problema di connessione, passare alla soluzione 1: Ignorare i proxy Web all'interno della macchina virtuale.
Causa 2: Problema correlato al certificato
I certificati intermedi cruciali per il processo di attivazione sono scaduti.
Per altre informazioni, vedere Tls dei dati con attestazione del servizio metadati dell'istanza di Azure TLS: Modifiche critiche.
Come determinare se mancano certificati
Eseguire lo script di PowerShell seguente per verificare la presenza di certificati mancanti:
# 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
}
Se mancano certificati, verrà visualizzato un output simile al seguente:
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
Per risolvere il problema del certificato, passare alla soluzione 2: Assicurarsi che i firewall e i proxy siano configurati per consentire i download dei certificati.
Soluzione 1: Ignorare i proxy Web all'interno della macchina virtuale
IMDS è un'API REST disponibile in un indirizzo IP noto e non instradabile (169.254.169.254). L'endpoint IMDS è accessibile dall'interno della macchina virtuale solo all'URI seguente: http://169.254.169.254/metadata/instance. La comunicazione tra la macchina virtuale e IMDS non lascia mai l'host. Chiedere ai client HTTP di ignorare i proxy Web all'interno della macchina virtuale mentre eseguono query su IMDS. Assicurarsi inoltre che i client considerino l'indirizzo 169.254.169.254 IP nello stesso modo in cui trattano l'indirizzo IP 168.63.129.16. Per verificare che la connessione di rete diretta esista, seguire questa procedura:
Note
168.63.129.16 è un indirizzo IP pubblico virtuale di proprietà di Microsoft usato per comunicare con le risorse di Azure.
Per visualizzare la tabella di routing locale nella macchina virtuale, eseguire il comando di stampa della route:
route printPer individuare la voce di routing per la destinazione IMDS, passare alla
Active Routessezione dell'outputIPv4 Route Tablee quindi trovare la riga contenente l'indirizzo169.254.169.254IP nellaNetwork Destinationcolonna.Destinazione di rete Netmask Gateway Interfaccia Metric 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 ... ... ... ... ... Nell'output della tabella di route di esempio, la voce di destinazione IMDS si trova nell'ultima riga e l'interfaccia di rete corrispondente è il valore nella colonna all'interno di
Interfacetale riga. In questo esempio l'interfaccia di rete è172.16.69.7.)Per visualizzare la configurazione IP della macchina virtuale, eseguire il comando ipconfig :
ipconfig /allNell'output del comando ipconfig trovare la configurazione IP in cui il
IPv4 Addresscampo corrisponde al valore dell'interfaccia di rete della voce 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 ...Nell'output ipconfig di esempio, la configurazione IP che contiene il valore dell'interfaccia di rete della voce IMDS è
Ethernet adapter Ethernet.Nella configurazione IP che si trova copiare l'indirizzo MAC (Media Controllo di accesso) e l'indirizzo IP privato primario usato dalla macchina virtuale. L'indirizzo MAC viene visualizzato nel
Physical Addresscampo e l'indirizzo IP privato primario viene visualizzato nelIPv4 Addresscampo . In questo esempio, l'indirizzo MAC e l'indirizzo IP privato primario sono00-0D-3A-E5-1C-C0rispettivamente e172.16.69.7.Controllare se gli indirizzi IP privati mac e primari usati da Azure per la macchina virtuale corrispondono all'indirizzo MAC e all'indirizzo IP privato primario usato dal sistema operativo guest della macchina virtuale (gli indirizzi trovati nel passaggio precedente). Per determinare l'uso di Azure come indirizzo MAC, usare l'interfaccia della riga di comando di Azure. Per determinare l'uso di Azure come indirizzo IP privato primario, esaminare la configurazione di rete nel portale di Azure.
Trovare l'indirizzo MAC (usando l'interfaccia della riga di comando di Azure in uno script di PowerShell)
Eseguire lo script di PowerShell seguente che richiama i comandi dell'interfaccia della riga di comando di Azure. Questo script richiama il comando az vm nic list per raccogliere i nomi delle interfacce di rete nella macchina virtuale. Richiama quindi il comando az vm nic show per visualizzare il nome di ogni interfaccia di rete, indipendentemente dal fatto che tale interfaccia di rete sia l'interfaccia di rete primaria (
TrueoFalse) e l'indirizzo MAC dell'interfaccia di rete:Note
Nei comandi "nic" rappresenta l'interfaccia di rete, non una scheda di interfaccia di rete.
# 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-C0Trovare l'indirizzo IP privato primario (usando il portale di Azure):
In portale di Azure, cercare e selezionare Macchine virtuali.
Nell'elenco delle macchine virtuali selezionare il nome della macchina virtuale.
Nella scheda Proprietà della pagina Panoramica della macchina virtuale individuare l'intestazione Rete.
Nel campo Indirizzo IP privato copiare l'indirizzo IPv4 visualizzato.
Se gli indirizzi MAC o gli indirizzi IP privati primari non sono identici tra Azure e il sistema operativo guest della macchina virtuale, usare vari comandi di route per aggiornare la tabella di routing in modo che l'interfaccia di rete primaria e l'indirizzo IP siano destinati.
Soluzione 2: Assicurarsi che i firewall e i proxy siano configurati per consentire i download dei certificati
Controllare se è installato 5036909 KB. In caso contrario, installarlo. È possibile ottenerlo dal Catalogo di Microsoft Update.
Se l'aggiornamento è stato installato ma si verifica comunque il problema, verificare che i firewall e i proxy del sistema siano configurati per consentire il download dei certificati. Per altre informazioni, vedere Download di certificati ed elenchi di revoche.
In alternativa, è possibile scaricare e installare tutti i certificati direttamente dalle catene di autorità di certificazione radice e subordinata.
Note
Assicurarsi di selezionare il percorso dell'archivio come Computer locale nell'installazione guidata.
Aprire prompt dei comandi come amministratore, passare a c:\windows\system32 ed eseguire fclip.exe.
Riavviare la macchina virtuale o disconnettersi e quindi eseguire di nuovo l'accesso. Si noterà che la filigrana nella home page non è più visualizzata e il campo Stato applicazione nella schermata Attivazione impostazioni>segnala l'esito positivo.
Ulteriori informazioni
Contattaci per ricevere assistenza
In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.