Nadal wyświetlany jest znak wodny aktywacji systemu Windows
Dotyczy: ✔️ Maszyny wirtualne z systemem Windows Server 2022 Datacenter Azure Edition
W tym dokumencie omówiono sposób rozwiązywania problemów z ciągłą obecnością znaku wodnego aktywacji systemu Windows na maszynach wirtualnych platformy Microsoft Azure.
Wymagania wstępne
Symptomy
W przypadku korzystania z maszyny wirtualnej platformy Azure z systemem Windows Server 2022 Datacenter Azure Edition występują następujące objawy:
Na pulpicie zostanie wyświetlony znak wodny zawierający następujący komunikat:
Aktywuj system Windows. Przejdź do pozycji Ustawienia, aby aktywować system Windows.
Ten znak wodny wskazuje, że stan aktywacji systemu Windows nie jest prawdziwy.
Po otwarciu aplikacji Ustawienia i wybraniu pozycji Aktywacja systemowa>pole Stan aplikacji wskazuje niepowodzenie aktywacji.
Po otwarciu okna wiersza polecenia z podwyższonym poziomem uprawnień i uruchomieniu następującego skryptu aktywacji zbiorczej slmgr.vbs dane wyjściowe pokazują, że aktywacja usługa zarządzania kluczami s (KMS) zakończy się pomyślnie, ale dwa pierwsze objawy pozostają:
cscript c:\windows\system32\slmgr.vbs /dlv
Po ponownym uruchomieniu maszyny wirtualnej lub zalogowaniu się zostanie wyświetlone okno podręczne z następującym komunikatem:
Maszyna wirtualna z systemem Windows Server 2022 Datacenter Azure Edition została zdezaktywowana, ponieważ nie korzystasz z platformy Azure ani obsługiwanej funkcji hypervisor usługi Azure Stack lub że nie włączono korzyści platformy Azure w obsługiwanym usłudze Azure Stack. Aby włączyć korzyści z platformy Azure, przejdź do ustawień klastra w centrum administracyjnym > systemu Windows Włączanie korzyści platformy Azure.
Przyczyna 1. Problem z połączeniem z usługą Azure Instance Metadata Service
Maszyna wirtualna platformy Azure nie może nawiązać połączenia z punktem końcowym usługi Azure Instance Metadata Service (IMDS ), co jest niezbędne do uzyskania tokenu aktywacji.
Jak określić, czy system operacyjny gościa maszyny wirtualnej może pomyślnie komunikować się z usługami IMDS
Uruchom następujący skrypt programu PowerShell w zależności od używanej wersji programu PowerShell, aby sprawdzić, czy metadane są odbierane z usługi IMDS.
PowerShell 6 i nowsze wersje
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 i starsze wersje
$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
Jeśli otrzymasz pomyślną odpowiedź, zobaczysz informacje o metadanych z maszyny wirtualnej, takie jak następujące dane wyjściowe:
compute
-------
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...
Jeśli nie, oznacza to, że połączenie z serwerem przewodowym IMDS jest gdzieś zablokowane i dostęp do niego musi być dozwolony. Adres IP serwera IMDS to 169.254.169.254
. Aby rozwiązać problem z połączeniem, przejdź do rozwiązania 1: Obejście internetowych serwerów proxy na maszynie wirtualnej.
Przyczyna 2. Problem związany z certyfikatem
Certyfikaty pośrednie, które mają kluczowe znaczenie dla procesu aktywacji wygasły.
Aby uzyskać więcej informacji, zobacz Azure Instance Metadata Service-Attest data TLS: Krytyczne zmiany są tutaj.
Jak określić, czy brakuje certyfikatów
Uruchom następujący skrypt programu PowerShell, aby sprawdzić brak certyfikatów:
# 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
}
Jeśli brakuje certyfikatów, zobaczysz dane wyjściowe podobne do następujących:
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
Aby rozwiązać problem z certyfikatem, przejdź do rozwiązania 2: Upewnij się, że zapory i serwery proxy są skonfigurowane do zezwalania na pobieranie certyfikatów.
Rozwiązanie 1. Obejście internetowych serwerów proxy na maszynie wirtualnej
IMDS to interfejs API REST dostępny pod dobrze znanym, nieruchomym adresem IP (169.254.169.254
). Punkt końcowy USŁUGI IMDS jest dostępny z poziomu maszyny wirtualnej tylko pod następującym identyfikatorem URI: http://169.254.169.254/metadata/instance
. Komunikacja między maszyną wirtualną a usługą IMDS nigdy nie opuszcza hosta. Klienci HTTP pomijają internetowe serwery proxy na maszynie wirtualnej podczas wykonywania zapytań dotyczących usług IMDS. Upewnij się również, że klienci traktują 169.254.169.254
adres IP w taki sam sposób, jak traktują adres IP 168.63.129.16. Aby sprawdzić, czy istnieje to bezpośrednie połączenie sieciowe, wykonaj następujące kroki:
Uwaga 16.
168.63.129.16
to wirtualny publiczny adres IP należący do firmy Microsoft używany do komunikowania się z zasobami platformy Azure.
Aby wyświetlić lokalną tabelę routingu na maszynie wirtualnej, uruchom polecenie drukowania trasy:
route print
Aby zlokalizować wpis routingu dla docelowego usługi IMDS, przejdź do
Active Routes
sekcjiIPv4 Route Table
danych wyjściowych, a następnie znajdź wiersz zawierający169.254.169.254
adres IP w kolumnieNetwork Destination
.Miejsce docelowe sieci Maska sieci Brama Interfejs 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 Łącze lokalne 127.0.0.1 331 127.0.0.1 255.255.255.255 Łącze lokalne 127.0.0.1 331 127.255.255.255 255.255.255.255 Łącze lokalne 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 ... ... ... ... ... W przykładowych danych wyjściowych tabeli tras wpis docelowy IMDS znajduje się w ostatnim wierszu, a odpowiedni interfejs sieciowy jest wartością
Interface
w kolumnie w tym wierszu. (W tym przykładzie interfejs sieciowy to172.16.69.7
.)Aby wyświetlić konfigurację adresu IP maszyny wirtualnej, uruchom polecenie ipconfig :
ipconfig /all
W danych wyjściowych polecenia ipconfig znajdź konfigurację adresu IP, w której
IPv4 Address
pole odpowiada wartości interfejsu sieciowego wpisu 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 ...
W przykładowych danych wyjściowych ipconfig konfiguracja adresu IP zawierająca wartość interfejsu sieciowego wpisu IMDS to
Ethernet adapter Ethernet
.W konfiguracji adresu IP, która się znajduje, skopiuj adres MAC (Media Access Control) i podstawowy prywatny adres IP używany przez maszynę wirtualną. Adres MAC jest wyświetlany w
Physical Address
polu, a podstawowy prywatny adres IP jest wyświetlany wIPv4 Address
polu. W tym przykładzie adres MAC i podstawowy prywatny adres IP to00-0D-3A-E5-1C-C0
odpowiednio i172.16.69.7
.Sprawdź, czy adresy MAC i podstawowe prywatne adresy IP używane przez platformę Azure dla maszyny wirtualnej są zgodne z adresem MAC i podstawowym prywatnym adresem IP używanym przez system operacyjny gościa maszyny wirtualnej (adresy znalezione we wcześniejszym kroku). Aby określić, jakiego adresu MAC używa platforma Azure, należy użyć interfejsu wiersza polecenia platformy Azure. Aby określić, co platforma Azure używa jako podstawowego prywatnego adresu IP, należy sprawdzić konfigurację sieci w witrynie Azure Portal.
Znajdowanie adresu MAC (przy użyciu interfejsu wiersza polecenia platformy Azure w skryscie programu PowerShell)
Uruchom następujący skrypt programu PowerShell, który wywołuje polecenia interfejsu wiersza polecenia platformy Azure. Ten skrypt wywołuje polecenie az vm nic list w celu zbierania nazw interfejsów sieciowych na maszynie wirtualnej. Następnie wywołuje polecenie az vm nic show , aby wyświetlić nazwę każdego interfejsu sieciowego, niezależnie od tego, czy ten interfejs sieciowy jest podstawowym interfejsem sieciowym (
True
lubFalse
), oraz adresem MAC interfejsu sieciowego:Uwaga 16.
W poleceniach "nic" reprezentuje interfejs sieciowy, a nie kartę sieciową.
# 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
Znajdź podstawowy prywatny adres IP (przy użyciu witryny Azure Portal):
W witrynie Azure Portal wyszukaj i wybierz pozycję Maszyny wirtualne.
Na liście maszyn wirtualnych wybierz nazwę maszyny wirtualnej.
Na karcie Właściwości strony Przegląd maszyny wirtualnej znajdź nagłówek Sieć.
W polu Prywatny adres IP skopiuj wyświetlany adres IPv4.
Jeśli adresy MAC lub podstawowe prywatne adresy IP nie są identyczne między platformą Azure a systemem operacyjnym gościa maszyny wirtualnej, użyj różnych poleceń tras , aby zaktualizować tabelę routingu, aby podstawowy interfejs sieciowy i adres IP zostały ukierunkowane.
Rozwiązanie 2. Upewnij się, że zapory i serwery proxy są skonfigurowane do zezwalania na pobieranie certyfikatów
Sprawdź, czy 5036909 KB jest zainstalowana. Jeśli nie, zainstaluj go. Możesz go pobrać z wykazu usługi Microsoft Update.
Jeśli zainstalowano aktualizację, ale nadal występuje problem, sprawdź, czy zapory i serwery proxy systemu są skonfigurowane w celu umożliwienia pobierania certyfikatów. Aby uzyskać więcej informacji, zobacz Pobieranie certyfikatów i listy odwołania.
Alternatywnie można pobrać i zainstalować wszystkie certyfikaty bezpośrednio z łańcuchów głównych i podrzędnych urzędów certyfikacji.
Uwaga 16.
Pamiętaj, aby wybrać lokalizację magazynu jako Komputer lokalny w kreatorze instalacji.
Otwórz wiersz polecenia jako administrator, przejdź do folderu c:\windows\system32 i uruchom fclip.exe.
Uruchom ponownie maszynę wirtualną lub wyloguj się, a następnie zaloguj się ponownie. Zobaczysz, że znak wodny na stronie głównej nie jest już wyświetlany, a pole Stan aplikacji na ekranie Aktywacja ustawień>zgłasza powodzenie.
Więcej informacji
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.