2026 Windows Server 2025 KMS nicht bereit: Müssen Sie den Host wechseln?

Der KMS-Host meldet, dass die Hardware-Sicherheitsanforderungen nicht erfüllt sind, obwohl die Aktivierung bisher funktioniert.

Dieser Beitrag ist für Sie relevant, wenn Sie einen Unternehmens-KMS-Host betreuen und die Meldung von einem Aktivierungsfehler unterscheiden müssen.
Er richtet sich ebenso an IT-Verantwortliche, die TPM- und Zertifizierungsbedingungen in eine geplante Servererneuerung aufnehmen.
Wenn Sie einen Windows-Server mieten oder beschaffen, erhalten Sie außerdem konkrete Fragen, mit denen Sie nicht veröffentlichte Hardwaremerkmale vorab klären.

Letzte Aktualisierung: 30.10.2026. Der Faktenabgleich stützt sich auf die Microsoft-Dokumentation zur hardwaregesicherten KMS-Aktivierung, die KMS-Planungshinweise und den Windows Server Catalog.

Der Hinweis zur KMS-Hardware-Sicherheitsbereitschaft ist keine Sperre

Microsoft hat die Anzeige zum KMS-Hardware-Sicherheitsstatus mit einem kumulativen Update für Windows Server 2025 im August 2026 ergänzt. Sie soll Administratoren dabei unterstützen, die Hardwareeignung einer KMS-Umgebung einzuschätzen. Sie ist für sich genommen weder ein Nachweis, dass die bestehende Aktivierung fehlgeschlagen ist, noch eine Aufforderung, den Host sofort auszutauschen. Maßgeblich ist die Unterscheidung zwischen dem aktuellen Aktivierungsbetrieb und möglichen Anforderungen künftiger Windows-Server-Versionen. Microsoft hält diese Bereiche in der Funktionsbeschreibung ausdrücklich auseinander.

Führt „nicht bereit“ zum Verlust der aktuellen Aktivierung? Nein: Die Meldung allein ändert die aktuelle Standard-KMS-Aktivierung nicht. Prüfen Sie dennoch den tatsächlichen Lizenzstatus des Hosts und dokumentieren Sie, wann und in welchem Zusammenhang die Anzeige auftritt. Ein informativer Hardwarehinweis und ein realer Aktivierungsfehler sind unterschiedliche Befunde; behandeln Sie sie nicht als denselben Vorfall.

Die technische Trennung ist wichtig, weil eine KMS-Umgebung aus mehreren Teilen besteht: dem KMS-Host, den aktivierten Clients, der installierten Windows-Server-Version und der passenden Lizenzkonfiguration. Ein Hinweis zur Hardwarebereitschaft beweist nicht, dass Clients ihren Aktivierungsstatus verloren haben. Umgekehrt sollte eine funktionierende Clientaktivierung nicht als Beleg dafür gelten, dass die Hardware bereits die Bedingungen für künftige Aktivierungsmodelle erfüllt. Die Microsoft-Planung für KMS hilft, die Rollen und Voraussetzungen der Aktivierungsumgebung getrennt zu betrachten.

Microsoft beschreibt hardwarebasiertes Vertrauen als Thema künftiger Windows-Server-Versionen. Aus dieser Formulierung lässt sich jedoch kein konkretes Einführungsdatum und keine bestimmte Version ableiten. Planen Sie deshalb nicht mit einem vermuteten Stichtag. Halten Sie fest, was Microsoft tatsächlich veröffentlicht hat, und überprüfen Sie die offiziellen Hinweise erneut, sobald Sie ohnehin eine Serveränderung vorbereiten.

TPM 2.0 und Catalog-Zertifizierung getrennt prüfen

Für den hardwaregesicherten KMS-Host nennt Microsoft aktiviertes TPM 2.0 und eine Serverhardware, die im Windows Server Catalog zertifiziert ist. Beide Bedingungen sind eigenständig zu prüfen. Ein TPM allein bestätigt nicht, dass das konkrete Serversystem die Catalog-Anforderung erfüllt. Umgekehrt ersetzt ein passender Catalog-Eintrag nicht die Prüfung, ob TPM-Unterstützung auf dem eingesetzten System vorhanden und aktiviert ist. Die Anforderungen stehen in Microsofts Beschreibung der hardwaregesicherten Aktivierung; verfügbare zertifizierte Systeme lassen sich im Windows Server Catalog nach Hersteller und Modell recherchieren.

Bei einer physischen Maschine benötigen Sie eine genaue Identifikation des Systems, nicht nur eine CPU-Bezeichnung. Halten Sie Hersteller, Modell und relevante Hardwarekonfiguration fest. Suchen Sie anschließend im Catalog nach dem passenden Eintrag und prüfen Sie, ob dieser tatsächlich zu Ihrer eingesetzten Plattform passt. Leiten Sie die Zertifizierung nicht aus dem Prozessor, dem Servergehäuse oder einer allgemeinen Produktfamilie ab.

Für die TPM-Prüfung können Sie die grafische Oberfläche und PowerShell kombinieren. Öffnen Sie die TPM-Verwaltung mit tpm.msc und kontrollieren Sie, ob das TPM erkannt und bereit ist. Prüfen Sie zusätzlich die Firmware- beziehungsweise BIOS-Einstellungen des Servers: Ein vorhandenes TPM kann dort deaktiviert sein. Die genaue Menübezeichnung hängt vom System ab; dokumentieren Sie deshalb den angezeigten Zustand und die verwendete Konfiguration, statt nur „TPM vorhanden“ zu notieren.

Microsoft dokumentiert außerdem die PowerShell-Abfrage für unterstützte TPM-Funktionen. Führen Sie sie mit administrativen Rechten auf dem KMS-Host aus:

Get-TpmSupportedFeature -FeatureName KeyAttestation

Die Abfrage dient dazu, die Unterstützung der Funktion Key Attestation zu prüfen. Sie ersetzt weder die Prüfung des KMS-Aktivierungszustands noch den Abgleich des Servers mit dem Catalog. Beachten Sie die Microsoft-Cmdlet-Dokumentation zu Get-TpmSupportedFeature, wenn Sie den Befehl in eine administrative Prüfung übernehmen. Halten Sie den tatsächlichen Rückgabewert aus Ihrem System fest; übernehmen Sie keinen Beispielwert aus einer Anleitung als Messergebnis.

Aktivierungsstatus und Hardwarebereitschaft als getrennte Befunde erfassen

Um den aktuellen Lizenzstatus des Hosts zu kontrollieren, führen Sie eine Eingabeaufforderung mit administrativen Rechten aus und verwenden Sie:

slmgr.vbs /dlv

Der Befehl zeigt detaillierte Lizenzinformationen an. Interpretieren Sie die Lizenz- und Aktivierungsangaben anhand der Microsoft-Dokumentation zu den Optionen von Slmgr.vbs. Er ist kein Ersatz für die TPM-Prüfung und belegt für sich genommen keine Catalog-Zertifizierung. Wenn der KMS-Host tatsächlich Aktivierungsprobleme meldet, folgen Sie der Microsoft-Anleitung zur allgemeinen KMS-Fehlerbehebung, statt die Hardwarebereitschaftsmeldung als alleinige Fehlerursache zu behandeln.

Wo lässt sich der KMS-Hardwarestatus nachsehen? Verwenden Sie die in der Microsoft-Dokumentation beschriebene KMS-Hardware-Sicherheitsprüfung und legen Sie deren Ergebnis neben den Lizenzstatus aus slmgr.vbs /dlv. Die TPM-Verwaltung und Get-TpmSupportedFeature ergänzen diese Prüfung, beantworten aber nicht dieselbe Frage. So vermeiden Sie den häufigen Fehlschluss, ein bestätigter TPM-Zustand bedeute automatisch, dass der KMS-Host vollständig hardwarebereit sei.

Für die Dokumentation sollten Sie mindestens die installierte Windows-Server-Version, den Namen des Hosts, den Zeitpunkt der Prüfung und den genauen Text der Meldung festhalten. Erfassen Sie außerdem, ob es sich um eine physische Maschine oder eine virtuelle Maschine handelt, welche Hardwareidentifikation geprüft wurde und ob der passende Eintrag im Windows Server Catalog gefunden wurde. Bei einem realen Aktivierungsproblem notieren Sie zusätzlich die betroffene Clientgruppe und relevante Fehlerangaben. Bewahren Sie diese Informationen nach den internen Datenschutz- und Aufbewahrungsregeln Ihres Unternehmens auf.

Die Ergebnisse sollten vier getrennte Aussagen ermöglichen: Funktioniert die derzeitige Aktivierung? Ist TPM 2.0 verfügbar und aktiviert? Wird Key Attestation unterstützt? Ist die konkrete Serverhardware im Catalog passend zertifiziert? Wenn eine dieser Antworten fehlt, markieren Sie den Punkt als ungeklärt, statt aus den übrigen Ergebnissen eine Gesamtfreigabe abzuleiten.

Drei Wege für den KMS-Host im Vergleich

Die passende Maßnahme richtet sich nicht allein nach der Meldung. Entscheidend sind die nachgewiesene Hardwareeignung, die geschäftliche Abhängigkeit von KMS, das Risiko einer Änderung und der ohnehin geplante Erneuerungszeitpunkt. Die folgende Gegenüberstellung enthält deshalb keine pauschalen Kosten- oder Ausfallversprechen.

Muss ein nicht bereiter KMS-Host sofort ersetzt werden? Nicht allein wegen dieser Meldung. Wenn die derzeitige Aktivierung funktioniert, die Hardwareprüfung aber noch offen ist, ist zunächst eine dokumentierte Bestandsaufnahme die sachgerechte Reaktion. Ist die Plattform bereits für einen Austausch vorgesehen, können Sie die TPM- und Catalog-Bedingungen in die Beschaffung aufnehmen, ohne daraus einen unbelegten Soforttermin abzuleiten.

Wählen Sie die Maßnahme anhand folgender Bedingungen:

• Wenn die aktuelle Aktivierung funktioniert und der Hardwarehinweis der einzige Befund ist, dann betreiben Sie den Host vorerst weiter, dokumentieren den Status und setzen einen Termin zur erneuten Prüfung.
• Wenn TPM 2.0 vorhanden, aber deaktiviert ist, dann prüfen Sie mit dem zuständigen Hardwareverantwortlichen, ob eine kontrollierte Aktivierung möglich ist. Nehmen Sie Firmware-Änderungen nicht ungeprüft im laufenden Betrieb vor.
• Wenn TPM-Unterstützung oder Key Attestation auf der vorhandenen Plattform nicht nachweisbar ist, dann klären Sie zunächst Herstellerangaben und Virtualisierungseinstellungen. Fehlt weiterhin ein belastbarer Nachweis, vergleichen Sie eine geeignete Ersatzplattform mit Ihrem regulären Erneuerungsplan.
• Wenn der Server im Catalog nicht passend identifiziert werden kann, dann fragen Sie beim Hardwareanbieter nach einer überprüfbaren Modell- und Zertifizierungsangabe. Eine ähnliche Modellbezeichnung genügt nicht.
• Wenn ein echter Aktivierungsfehler vorliegt, dann behandeln Sie ihn als separates KMS-Störungsthema und folgen der Microsoft-Fehlerbehebung; tauschen Sie nicht allein aufgrund der Bereitschaftsanzeige den Host aus.

Prüfergebnisse in den nächsten Änderungsplan übernehmen

Eine kompakte Bestandsaufnahme verhindert, dass die Meldung später erneut ohne Kontext bewertet wird. Gehen Sie in dieser Reihenfolge vor:

1. Alle KMS-Hosts erfassen. Erstellen Sie eine Liste der physischen und virtuellen Hosts, ihrer Windows-Server-Version und ihrer betrieblichen Funktion. Trennen Sie produktive Systeme von Testsystemen.
2. Aktuellen Zustand sichern. Führen Sie slmgr.vbs /dlv aus, speichern Sie die relevanten Angaben und erfassen Sie den genauen Wortlaut sowie den Zeitpunkt der Hardwaremeldung. Notieren Sie, ob Clients tatsächlich einen Aktivierungsfehler melden.
3. Hardwarebedingungen abgleichen. Prüfen Sie TPM 2.0 in der TPM-Verwaltung und in der Firmware, ermitteln Sie mit dem dokumentierten PowerShell-Befehl die Unterstützung von Key Attestation und gleichen Sie das konkrete physische Modell mit dem Windows Server Catalog ab.
4. Virtuelle Systeme gesondert behandeln. Prüfen Sie virtuelles TPM, Key Attestation und die konkret zugewiesene VM-Konfiguration. Verwenden Sie keine Befunde eines physischen Hosts als Ersatz für diesen Nachweis.
5. Geplante Änderungen zuerst testen. Wenn Sie Firmware-Einstellungen, die VM-Konfiguration oder den KMS-Host ändern wollen, prüfen Sie den Ablauf in einer geeigneten Testumgebung. Legen Sie vor der Produktivänderung fest, wie Sie den vorherigen Zustand wiederherstellen.
6. Verantwortung und Wiedervorlage festlegen. Benennen Sie die zuständige Person und ein Datum für die erneute Prüfung. Aktualisieren Sie den Plan, wenn Microsoft neue Anforderungen für künftige Windows-Server-Versionen veröffentlicht.

Die Bestandsaufnahme sollte nicht nur aus einem einzelnen Bildschirmfoto bestehen. Ein brauchbarer Änderungsnachweis verbindet Systemidentifikation, Lizenzstatus, TPM-Befund, Catalog-Ergebnis und die Entscheidung über den weiteren Betrieb. Damit können Einkauf, Systembetrieb und Sicherheitsverantwortliche dieselbe Grundlage verwenden, ohne eine informative Meldung als akute Störung umzudeuten.

Servermiete und Beschaffung anhand belegbarer Hardwaredaten bewerten

Wenn Sie eine neue Windows-Server-Plattform beschaffen, fragen Sie nicht nur nach dem installierbaren Betriebssystem. Klären Sie ausdrücklich, ob das konkrete Serversystem TPM 2.0 besitzt, ob diese Funktion verfügbar und aktivierbar ist, ob Key Attestation für Ihre vorgesehene Betriebsform unterstützt wird und ob sich die verwendete Hardware im Windows Server Catalog passend nachweisen lässt. Bei einer virtuellen Maschine benötigen Sie Angaben zur tatsächlichen VM-Funktion, nicht bloß eine allgemeine Aussage zur darunterliegenden Serverhardware.

Lassen Sie sich die relevanten Modell- und Funktionsangaben schriftlich bestätigen. Prüfen Sie anschließend, ob der Nachweis genau die angebotene Konfiguration abdeckt. Wenn ein Anbieter nur den Prozessor nennt, ist damit weder die TPM-Ausstattung noch die Zertifizierung des gesamten Servers belegt. Auch die Bezeichnung „dedizierter Server“ ist kein Nachweis für eine bestimmte Sicherheitsfunktion.

Bei OSFP Cloud nennen die vorliegenden Produktangaben Windows Server 2019, Windows Server 2022 und Windows Server 2025 sowie englische, traditionell chinesische und vereinfacht chinesische Sprachversionen. Die aktuellen Windows-Optionen finden Sie auf der deutschen Produktübersicht. Die vorliegenden Angaben bestätigen jedoch weder TPM 2.0 noch Key Attestation oder eine Zertifizierung der angebotenen Hardware im Windows Server Catalog. Leiten Sie diese Eigenschaften daher nicht aus der Betriebssystemauswahl oder dem Servertyp ab. Prüfen Sie die Leistungs- und Servicegrenzen und lassen Sie nicht aufgeführte Hardwaremerkmale vor einer Bestellung ausdrücklich bestätigen.

Wenn Sie eine Änderung im regulären Erneuerungszyklus erwägen, stimmen Sie die Beschaffung außerdem mit Ihrem internen Umstellungsplan ab. Eine Planung der Mietlaufzeit kann die organisatorische Betrachtung ergänzen, ersetzt aber keine technische Eignungsprüfung. Für ein Unternehmen mit laufender KMS-Abhängigkeit ist eine nachvollziehbar bestätigte TPM- und Catalog-Eignung wichtiger als eine allgemeine Produktbeschreibung. Falls diese Angaben nicht veröffentlicht sind, holen Sie die Bestätigung vor der Beschaffung ein und dokumentieren Sie, welche Konfiguration tatsächlich zugesagt wurde.

Ein gemieteter dedizierter Server kann für dauerhaft benötigte Windows-Workloads sinnvoll sein, wenn Sie die Hardwarebedingungen vorab verifizieren und die Umstellung selbst planen. Eine gemeinsam genutzte virtuelle Maschine kann dagegen eine passende Wahl bleiben, wenn die Last gering ist und der Anbieter die benötigten TPM-Funktionen nachweislich für die konkrete Instanz bereitstellt. In beiden Fällen gilt: Ein Betriebsmodell, ein CPU-Name oder eine Betriebssystemoption ersetzt nicht die Prüfung von TPM, Key Attestation und Catalog-Eintrag.

Ihre nächste Entscheidung: Wenn die aktuelle KMS-Aktivierung funktioniert, ändern Sie den Host nicht allein wegen des Hinweises. Sichern Sie den Zustand, prüfen Sie die Hardwarebedingungen und nehmen Sie eine notwendige Anpassung in den regulären Änderungsplan auf. Wenn Sie dafür eine neue, dauerhaft betriebene Plattform erwägen, vergleichen Sie die dokumentierten Eigenschaften Ihrer bisherigen Lösung mit einem dedizierten Server von OSFP Cloud; bei nicht ausgewiesenen TPM- oder Zertifizierungsangaben lassen Sie die konkrete Eignung vor der Bestellung bestätigen.