Windows-Aktivierungswasserzeichen wird weiterhin angezeigt

Artikel
07/30/2024

Gilt für: ✔️ Windows-VMs mit Windows Server 2022 Datacenter Azure Edition

In diesem Dokument wird erläutert, wie Sie das fortgesetzte Vorhandensein eines Windows-Aktivierungswasserzeichens auf virtuellen Microsoft Azure-Computern beheben.

Voraussetzungen

Azure-Befehlszeilenschnittstelle

Symptome

Wenn Sie einen virtuellen Azure-Computer (VM) verwenden, der Windows Server 2022 Datacenter Azure Edition ausführt, treten die folgenden Symptome auf:

Auf dem Desktop wird ein Wasserzeichen angezeigt, das die folgende Meldung enthält:

Windows aktivieren. Wechseln Sie zu den Einstellungen, um Windows zu aktivieren.

Dieses Wasserzeichen gibt an, dass der Windows-Aktivierungsstatus nicht original ist.
Wenn Sie die Einstellungs-App öffnen und die Systemaktivierung> auswählen, zeigt das Feld "Anwendungsstatus" einen Aktivierungsfehler an.
Wenn Sie ein Eingabeaufforderungsfenster mit erhöhten Rechten öffnen und das folgende Slmgr.vbs-Volumenaktivierungsskript ausführen, zeigt die Ausgabe an, dass Schlüsselverwaltungsdienst s (KMS)-Aktivierung erfolgreich ist, aber die ersten beiden Symptome bleiben:
```
cscript c:\windows\system32\slmgr.vbs /dlv
```
Wenn Sie den virtuellen Computer neu starten oder sich anmelden, wird ein Popupfenster mit der folgenden Meldung angezeigt:

Ihre Windows Server 2022 Datacenter Azure Edition VM wurde deaktiviert, da Sie nicht auf Azure oder einem unterstützten Azure Stack-Hypervisor ausgeführt werden oder dass Sie keine Azure-Vorteile für den unterstützten Azure Stack aktiviert haben. Um Azure-Vorteile zu aktivieren, wechseln Sie zu Ihren Clustereinstellungen in Windows Admin Center > Aktivieren von Azure-Vorteilen.

Ursache 1: Verbindungsproblem beim Azure Instance-Metadatendienst

Die Azure-VM kann keine Verbindung mit dem Azure Instance Metadata Service (IMDS) -Endpunkt herstellen, der für das Abrufen des Aktivierungstokens unerlässlich ist.

Ermitteln, ob das Gastbetriebssystem des virtuellen Computers erfolgreich mit IMDS kommunizieren kann

Führen Sie das folgende PowerShell-Skript abhängig von Ihrer PowerShell-Version aus, um zu überprüfen, ob die Metadaten von IMDS empfangen werden.

PowerShell 6 und höhere Versionen

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 und frühere Versionen

$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

Wenn Sie eine erfolgreiche Antwort erhalten, werden die Metadateninformationen der VM angezeigt, z. B. die folgende Ausgabe:

compute                                                                                                                                                                  
-------                                                                                                                                                                  
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...

Andernfalls bedeutet dies, dass die Verbindung mit dem IMDS-Drahtserver irgendwo blockiert wird und der Zugriff darauf zulässig sein muss. Die IP des IMDS-Servers lautet 169.254.169.254. Um das Verbindungsproblem zu beheben, wechseln Sie zu Lösung 1: Umgehen von Webproxys innerhalb der VM.

Zwischenzertifikate, die für den Aktivierungsprozess von entscheidender Bedeutung sind, sind abgelaufen.

Weitere Informationen finden Sie unter TLS für azure Instance Metadata Service-Attested Data TLS: Wichtige Änderungen sind hier.

Ermitteln, ob Zertifikate fehlen

Führen Sie das folgende PowerShell-Skript aus, um nach fehlenden Zertifikaten zu suchen:

# 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
}

Wenn zertifikate fehlen, wird eine ausgabe ähnlich wie die folgende angezeigt:

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

Um das Zertifikatproblem zu beheben, wechseln Sie zu Lösung 2: Stellen Sie sicher, dass Firewalls und Proxys so konfiguriert sind, dass Zertifikatdownloads zugelassen werden.

Lösung 1: Umgehen von Webproxys innerhalb der VM

IMDS ist eine REST-API, die unter einer bekannten, nicht routingfähigen IP-Adresse (169.254.169.254) verfügbar ist. Der IMDS-Endpunkt kann nur über den virtuellen Computer über den folgenden URI zugegriffen werden: http://169.254.169.254/metadata/instance Die Kommunikation zwischen dem virtuellen Computer und IMDS verlässt niemals den Host. Lassen Sie Ihre HTTP-Clients Webproxys innerhalb der VM umgehen, während sie IMDS abfragen. Stellen Sie außerdem sicher, dass die Clients die 169.254.169.254 IP-Adresse auf die gleiche Weise behandeln wie die IP-Adresse 168.63.129.16. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob diese direkte Netzwerkverbindung vorhanden ist:

Notiz

168.63.129.16 ist eine virtuelle öffentliche IP-Adresse von Microsoft, die für die Kommunikation mit Azure-Ressourcen verwendet wird.

Führen Sie den Befehl "Routendruck" aus, um die lokale Routingtabelle auf Ihrem virtuellen Computer anzuzeigen:
```
route print
```

Um den Routingeintrag für das IMDS-Ziel zu finden, wechseln Sie zum Active Routes Abschnitt der IPv4 Route Table Ausgabe, und suchen Sie dann die Zeile, die die 169.254.169.254 IP-Adresse in der Network Destination Spalte enthält.

Netzwerkziel	Netmask	Gateway	Schnittstelle	Metrik
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
...	...	...	...	...

In der Ausgabe der Beispielroutentabelle befindet sich der IMDS-Zieleintrag in der letzten Zeile, und die entsprechende Netzwerkschnittstelle ist der Wert in der Spalte in dieser Interface Zeile. (In diesem Beispiel ist 172.16.69.7die Netzwerkschnittstelle .)

Um die IP-Konfiguration Ihrer VM anzuzeigen, führen Sie den Befehl "ipconfig " aus:
```
ipconfig /all
```

Suchen Sie in der Ipconfig-Befehlsausgabe die IP-Konfiguration, in der das IPv4 Address Feld mit dem Netzwerkschnittstellenwert des IMDS-Eintrags übereinstimmt (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
...

In der Ipconfig-Beispielausgabe lautet Ethernet adapter Ethernetdie IP-Konfiguration, die den Netzwerkschnittstellenwert des IMDS-Eintrags enthält.

Kopieren Sie in der von Ihnen gespeicherten IP-Konfiguration die Mac-Adresse (Media Access Control) und die primäre private IP-Adresse, die die VM verwendet. Die MAC-Adresse wird im Physical Address Feld angezeigt, und die primäre private IP-Adresse wird im IPv4 Address Feld angezeigt. In diesem Beispiel sind 00-0D-3A-E5-1C-C0 die MAC-Adresse und die primäre private IP-Adresse bzw 172.16.69.7. die primäre private IP-Adresse.
Überprüfen Sie, ob die mac- und primären privaten IP-Adressen, die Azure für den virtuellen Computer verwendet, mit der MAC-Adresse und der primären privaten IP-Adresse übereinstimmen, die das Gastbetriebssystem der VM tatsächlich verwendet (die Adressen, die Sie im vorherigen Schritt gefunden haben). Um zu ermitteln, welche Azure als MAC-Adresse verwendet, verwenden Sie Azure CLI. Um zu ermitteln, welche Azure als primäre private IP-Adresse verwendet, untersuchen Sie die Netzwerkkonfiguration im Azure-Portal.
- Suchen der MAC-Adresse (mithilfe der Azure CLI in einem PowerShell-Skript)
  
  Führen Sie das folgende PowerShell-Skript aus, das Azure CLI-Befehle aufruft. Dieses Skript ruft den Befehl "az vm nic list " auf, um die Namen der Netzwerkschnittstellen auf Ihrer VM zu erfassen. Anschließend wird der Befehl az vm nic aufgerufen , um den Namen der einzelnen Netzwerkschnittstellen anzuzeigen, unabhängig davon, ob es sich bei dieser Netzwerkschnittstelle um die primäre Netzwerkschnittstelle (True oder False) und die MAC-Adresse der Netzwerkschnittstelle handelt:
  
  Notiz
  
  In den Befehlen stellt "nic" die Netzwerkschnittstelle dar, keine Netzwerkschnittstellenkarte.
```
# 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-C0
```
- Suchen Sie die primäre private IP-Adresse (mithilfe des Azure-Portal):
  1. Suchen Sie im Azure Portal nach Virtuelle Computer und wählen Sie diese aus.
  2. Wählen Sie in der Liste der virtuellen Computer den Namen Ihrer VM aus.
  3. Suchen Sie auf der Registerkarte "Eigenschaften " der Seite "Vm Overview " die Überschrift "Netzwerk ".
  4. Kopieren Sie im Feld " Private IP-Adresse " die angezeigte IPv4-Adresse.
Wenn die MAC-Adressen oder die primären privaten IP-Adressen nicht zwischen Azure und dem VM-Gastbetriebssystem identisch sind, verwenden Sie verschiedene Routenbefehle , um die Routingtabelle so zu aktualisieren, dass die primäre Netzwerkschnittstelle und DIE IP-Adresse gezielt sind.

Lösung 2: Sicherstellen, dass Firewalls und Proxys so konfiguriert sind, dass Zertifikatdownloads zugelassen werden

Überprüfen Sie, ob KB-5036909 installiert ist. Wenn dies nicht der Fall ist, installieren Sie diese Version. Sie können es aus dem Microsoft Update-Katalog abrufen.
Wenn Sie das Update installiert haben, das Problem jedoch weiterhin auftritt, stellen Sie sicher, dass die Firewalls und Proxys Ihres Systems so konfiguriert sind, dass der Download von Zertifikaten zugelassen wird. Weitere Informationen finden Sie unter Zertifikatdownloads und Sperrlisten.

Alternativ können Sie alle Zertifikate direkt aus den Stamm- und untergeordneten Zertifizierungsstellenketten herunterladen und installieren.

Notiz

Stellen Sie sicher, dass Sie den Speicherort als lokaler Computer im Installations-Assistenten auswählen.
Öffnen Sie die Eingabeaufforderung als Administrator, navigieren Sie zu "c:\windows\system32", und führen Sie fclip.exe aus.
Starten Sie den virtuellen Computer neu, oder melden Sie sich ab, und melden Sie sich dann erneut an. Sie werden sehen, dass das Wasserzeichen auf der Startseite nicht mehr angezeigt wird, und das Feld "Anwendungsstatus" im Bildschirm "Einstellungen>" meldet den Erfolg.

Weitere Informationen

Behandlung von Problemen bei der Aktivierung virtueller Windows-Computer

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über

Windows-Aktivierungswasserzeichen wird weiterhin angezeigt

Voraussetzungen

Symptome

Ursache 1: Verbindungsproblem beim Azure Instance-Metadatendienst

Ermitteln, ob das Gastbetriebssystem des virtuellen Computers erfolgreich mit IMDS kommunizieren kann

Ermitteln, ob Zertifikate fehlen

Lösung 1: Umgehen von Webproxys innerhalb der VM

Lösung 2: Sicherstellen, dass Firewalls und Proxys so konfiguriert sind, dass Zertifikatdownloads zugelassen werden

Weitere Informationen

Kontaktieren Sie uns für Hilfe

Feedback

Zusätzliche Ressourcen

Freigeben über

Windows-Aktivierungswasserzeichen wird weiterhin angezeigt

Voraussetzungen

Symptome

Ursache 1: Verbindungsproblem beim Azure Instance-Metadatendienst

Ermitteln, ob das Gastbetriebssystem des virtuellen Computers erfolgreich mit IMDS kommunizieren kann

Ursache 2: Zertifikatbezogenes Problem

Ermitteln, ob Zertifikate fehlen

Lösung 1: Umgehen von Webproxys innerhalb der VM

Lösung 2: Sicherstellen, dass Firewalls und Proxys so konfiguriert sind, dass Zertifikatdownloads zugelassen werden

Weitere Informationen

Kontaktieren Sie uns für Hilfe

Feedback

Zusätzliche Ressourcen