In der Nachlese zum September-Patchday hatte ich den Verlust der Domänen-Vertrauensstellung nach KB5124008 noch als offenen Punkt geführt: reproduzierbar, aber ohne Erklärung und ohne offizielle Stellungnahme. Beides gibt es jetzt. Microsoft hat das Problem am 16. September 2026 als Known Issue ins Release-Health-Dashboard aufgenommen, die Ursache benannt und einen Workaround veröffentlicht. Die Kurzfassung vorab: Betroffen ist nur, wer die Funktion Machine Identity Isolation irgendwann einmal konfiguriert hat und dessen Domänencontroller nicht auf der Funktionsebene Windows Server 2025 laufen. Für alle anderen ist dieser Beitrag Hintergrundlektüre. Für die Betroffenen ist er eine Anleitung, die man vor dem nächsten Client-Neustart gelesen haben sollte.

Was passiert

Das Muster ist in allen Berichten dasselbe. Windows 11 24H2 oder 25H2, KB5124008 wird installiert, der Rechner startet neu, und ab dem nächsten Anmeldeversuch lehnt das System gültige Domänenkonten ab. Entweder erscheint die klassische Meldung, dass die Vertrauensstellung zwischen Arbeitsstation und Domäne fehlgeschlagen ist, oder Windows behauptet schlicht, Benutzername oder Kennwort seien falsch. Beides stimmt nicht: Das Kennwort ist korrekt, die Maschine hat nur ihren sicheren Kanal zum Domänencontroller verloren.

Zwei Details helfen bei der Abgrenzung von anderen Anmeldeproblemen. Erstens funktioniert die Anmeldung mit zwischengespeicherten Anmeldeinformationen weiterhin, solange der Rechner offline ist. Wer das Netzwerkkabel zieht, kommt also auf den Desktop. Zweitens zeigt das Ereignisprotokoll auf betroffenen Systemen gehäuft Kerberos-Fehler, gefolgt von Rückfällen auf NTLM und Netlogon-Fehlern.

Der Administrator Alex Turner, der das Problem im Microsoft-Q&A-Forum dokumentiert hat, konnte es sauber reproduzieren: Update deinstallieren und Vertrauensstellung reparieren, alles läuft; Update erneut installieren, Fehler kehrt zurück. Auf Reddit meldete ein Kollege 11 von rund 256 Windows-11-25H2-Geräten betroffen, ein anderer sprach von sämtlichen 25H2-Arbeitsplätzen in seinem Netz. Dass die Quote so unterschiedlich ausfällt, erklärt sich mit der Ursache.

Die Ursache: Machine Identity Isolation

Domänenmitglieder authentifizieren sich gegenüber dem Domänencontroller mit ihrem Computerkonto. Dessen Geheimnis liegt traditionell als LSA-Secret in der Registry, und genau das war Microsoft schon länger ein Dorn im Auge: Wer lokaler Administrator ist, kann es auslesen, und seit gMSA, dMSA und Kerberos Armoring auf Computerkonten aufbauen, ist ein ausgelesenes Maschinengeheimnis mehr wert als früher.

Mit Windows Server 2025 hat Microsoft deshalb Credential-Guard-geschützte Computerkonten eingeführt, gesteuert über die Einstellung Machine Identity Isolation (MII). Sie kennt drei Zustände:

Im Enforcement-Modus gibt es das Geheimnis also nur noch innerhalb der virtualisierungsbasierten Sicherheit. Jede Maschinenauthentifizierung läuft dann über Credential Guard, und die Domänencontroller müssen mit diesem Verfahren umgehen können. Das tun sie nach Microsofts Angabe nur ab der Domänenfunktionsebene Windows Server 2025.

Der Haken hat eine Vorgeschichte. Bereits im April 2025 hatte Microsoft die Funktion mit KB5055523 in Windows Server 2025 und Windows 11 24H2 vorübergehend abgeschaltet, weil sie mit der Kerberos-Kennwortrotation für Computerkonten kollidierte. Seither stand die Einstellung in vielen Umgebungen zwar noch in Gruppenrichtlinien, Intune-Baselines oder der Registry, tat aber nichts. Genau das hat KB5124008 geändert. Microsoft formuliert es so: Das Update aktiviere die Durchsetzung nicht selbst, sorge aber dafür, dass Windows vorhandene oder per Richtlinie ausgerollte MII-Einstellungen wieder berücksichtige.

Anders gesagt: Eine Konfiguration, die seit anderthalb Jahren wirkungslos war, wurde über ein monatliches Sicherheitsupdate scharf geschaltet, ohne Hinweis in den Release Notes. Und wo die Domänencontroller die Funktionsebene 2025 nicht haben, was in der öffentlichen Verwaltung und im Mittelstand der Regelfall sein dürfte, läuft die Maschinenauthentifizierung gegen eine Wand. Das erklärt auch die unterschiedlichen Trefferquoten: Wer MII über eine gezielte Gruppenrichtlinie auf einige Geräte verteilt hatte, verliert genau diese; wer die Einstellung in einer breiten Sicherheits-Baseline hatte, verliert alle.

Ein Randaspekt aus dem Q&A-Thread: Microsoft nennt im Workaround nur den Wert 2. Mindestens ein Administrator berichtet jedoch, dass bei ihm der Wert 1 (Audit) stand und das Zurücksetzen auf 0 ebenfalls nötig war. Wer prüft, sollte also jeden Wert ungleich 0 als verdächtig behandeln.

Wer betroffen ist

Microsoft grenzt den Kreis klar ein. Betroffen sind ausschließlich Client-Systeme:

• Windows 11 24H2 und 25H2 mit KB5124008 (Build 26100.9445 bzw. 26200.9445)
• Windows 11 26H1 mit KB5124012

und auch dort nur unter zwei gleichzeitig erfüllten Bedingungen: MII ist auf dem Gerät konfiguriert, und die Domänencontroller laufen unterhalb der Funktionsebene Windows Server 2025.

Nicht betroffen sind Windows Server, die Domänencontroller selbst, die AD-Replikation, reine Entra-ID-Geräte, Arbeitsgruppenrechner und alle Clients, auf denen MII nie gesetzt wurde. Wer die Einstellung nicht kennt und nie eine Security-Baseline von Microsoft oder einem Drittanbieter ungeprüft übernommen hat, ist mit hoher Wahrscheinlichkeit außen vor.

Zuerst prüfen, bevor etwas kaputtgeht

Bevor Sie am Workaround arbeiten, lohnt sich ein Blick auf die Flotte, idealerweise bevor weitere Clients nach dem Update neu starten. Zwei Registry-Pfade sind relevant, einer für die effektive Einstellung, einer für die Richtlinienvorgabe:

powershell

$paths = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa',
         'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard'

foreach ($p in $paths) {
    $v = (Get-ItemProperty -Path $p -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
    '{0}: {1}' -f $p, $(if ($null -eq $v) { 'nicht gesetzt' } else { $v })
}

Alles, was nicht auf „nicht gesetzt“ oder 0 steht, ist ein Kandidat. Das Skript lässt sich per Invoke-Command, über die RMM-Lösung oder als Inventarabfrage im Patch-Management gegen alle Windows-11-Clients fahren.

Die zweite Frage ist die Domänenfunktionsebene:

powershell

(Get-ADDomain).DomainMode

Steht dort etwas anderes als Windows2025Domain, hat MII in Ihrer Umgebung nichts verloren, egal ob das Update schon installiert ist oder nicht.

Ob der sichere Kanal eines konkreten Rechners noch intakt ist, verrät Test-ComputerSecureChannel -Verbose oder klassisch nltest /sc_verify:<Domäne>.

Der Workaround

Microsofts Anweisung ist im Kern eine Regel: MII muss auf demselben Weg deaktiviert werden, auf dem es aktiviert wurde. Wer die Einstellung über Intune (Policy CSP DeviceGuard/MachineIdentityIsolation) verteilt hat, setzt sie dort auf deaktiviert. Wer sie per Gruppenrichtlinie gesetzt hat, findet sie unter Computerkonfiguration → Administrative Vorlagen → System → Device Guard → Virtualisierungsbasierte Sicherheit aktivieren, Unterpunkt Machine Identity Isolation Configuration, und stellt dort auf Deaktiviert um. Ein Praxishinweis aus dem Q&A-Thread: Bei mindestens einem Administrator hat die Gruppenrichtlinie den Wert auf den Clients nicht zuverlässig zurückgesetzt, er musste zusätzlich die Registry direkt anfassen.

Wurde MII direkt in der Registry gesetzt, oder greift die Richtlinie nicht, geht es so:

1. Registry sichern.
2. In beiden Pfaden den Wert MachineIdentityIsolation auf 0 setzen:

   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation
   HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

3. Neustart.
4. Sicheren Kanal reparieren, in einer administrativen PowerShell:

powershell

   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Abgefragt wird ein Konto, das die Maschine in der Domäne reparieren darf.

Achtung beim Abtippen aus Microsofts Support-Eintrag: Dort steht hinter dem Befehl ein überzähliges Hochkomma, das PowerShell mit einer Fehlermeldung quittiert. Günter Born hat darauf hingewiesen; die Zeile oben ist die korrekte Fassung.

Das Henne-Ei-Problem in der Praxis: Der Rechner nimmt keine Domänenanmeldung mehr an, aber Sie brauchen eine Anmeldung, um den Wert zu ändern. Der Weg, der sich im Q&A-Thread bewährt hat: Netzwerk trennen (Dock abziehen, WLAN aus), mit einem Domänenkonto über den Anmeldecache einloggen, Netzwerk wieder verbinden, dann per Fernwartung oder mit dem lokalen Administratorkonto aus LAPS den Registry-Wert setzen, reparieren, neu starten. Ohne LAPS oder ein anderes verwaltetes lokales Admin-Konto wird es an dieser Stelle unangenehm.

Warum das Deaktivieren selbst gefährlich sein kann

Hier liegt der Teil, der in vielen Kurzmeldungen fehlt. Microsofts eigene Dokumentation warnt: War MII im Enforcement-Modus aktiv und wird dann deaktiviert, kann das Gerät sich nicht mehr authentifizieren und muss aus der Domäne genommen und neu aufgenommen werden. Das gilt, weil im Enforcement-Modus das LSA-Secret gelöscht wurde; nach dem Abschalten ist schlicht kein Geheimnis mehr da, mit dem sich die Maschine ausweisen könnte.

Ein Administrator im Q&A-Thread hat das schmerzhaft bestätigt: Nach dem Umstellen von Audit bzw. Enforcement auf Deaktiviert verloren in seiner Umgebung flächendeckend Geräte die Vertrauensstellung, darunter auch solche, auf denen KB5124008 nie installiert war. Wer die Einstellung per Gruppenrichtlinie auf alle Clients gleichzeitig zurückdreht, riskiert also, das Problem zu verbreitern statt es zu lösen.

Die Konsequenz für die Reihenfolge:

• Nicht die Richtlinie blind auf „Deaktiviert“ stellen und auf den nächsten Neustart warten.
• Erst prüfen, welche Geräte MII tatsächlich effektiv hatten und ob sie den Enforcement-Modus schon durchlaufen haben (Wert 2 in HKLM\SYSTEM\...\Lsa).
• Für diese Geräte den Repair-Schritt fest einplanen, und für den Fall, dass Test-ComputerSecureChannel scheitert, Domänenaustritt und Neubeitritt mit lokalem Admin-Konto vorbereiten.
• Den Rollout von KB5124008 an Clients mit MII-Konfiguration anhalten, bis die Einstellung bereinigt ist.

Was Microsoft noch plant

Microsoft will die Durchsetzung von Machine Identity Isolation in einem kommenden Windows-Update vorübergehend wieder aussetzen, während an der Funktion weitergearbeitet wird. Einen Termin gibt es nicht; der Oktober-Patchday am 13. Oktober ist die naheliegende Vermutung. Wer den Workaround anwendet, sollte die Deaktivierung als Dauerzustand betrachten, bis Microsoft die Unterstützung für ältere Funktionsebenen dokumentiert. Die Einstellung im Oktober einfach wieder auf 2 zu setzen, wie es ein Kollege im Q&A-Thread vorhat, ist ohne Domänencontroller auf 2025-Niveau kein Plan, sondern eine Wiederholung.

Bleibt die Einordnung. Das ist bereits das zweite Mal, dass Microsoft dieselbe Funktion per Monatsupdate an- oder abschaltet, ohne dass es in den Release Notes stünde. Im April 2025 wurde sie still deaktiviert, im September 2026 still reaktiviert, und beide Male haben Administratoren die Folgen ausbaden dürfen. Eine Funktion, die Microsoft selbst nur für die Funktionsebene 2025 freigibt, hätte auf Clients gegen ältere Domänencontroller nie greifen dürfen. Dass die Prüfung fehlt, ist kein Bug im eigentlichen Sinne, sondern eine Designentscheidung, und die liegt in Redmond. Für die Zeit bis zum Fix gilt der Hinweis, der nach diesem Patchday ohnehin auf jedem Tisch liegen sollte: Erst die Flotte inventarisieren, dann patchen.

Quellen

• Microsoft Release Health: Domain-joined devices might lose their secure trust relationship with the domain (16.09.2026)
• Microsoft Learn: Credential Guard protected machine accounts
• Microsoft Q&A: KB5124008 (26200.9445) breaks machine secure channel / domain trust

Haben Sie in letzter Zeit Probleme mit Ihren Remotedesktop-Verbindungen unter Windows 11 festgestellt? Microsoft hat reagiert und mit dem Out-of-Band Update KB5077744 eine gezielte Lösung für die Versionen Windows 11 24H2 und 25H2 veröffentlicht. Dieses Update wird nicht automatisch über Windows Update verteilt, was ein manuelles Eingreifen erforderlich macht.

In diesem Artikel erfahren Sie, warum dieses Update so wichtig ist, welche Rolle die „Known Issue Rollback“ (KIR) Technologie spielt und wie Sie das Update sicher installieren. Wir analysieren die Hintergründe der Remotedesktop-Fehler und bieten Ihnen eine Schritt-für-Schritt-Anleitung zur Fehlerbehebung.

Warum wurde das Update KB5077744 veröffentlicht?

Normalerweise liefert Microsoft Updates am monatlichen Patchday aus. Wenn jedoch kritische Fehler auftreten, die den Arbeitsfluss massiv stören, wird ein sogenanntes Out-of-Band (OOB) Update bereitgestellt.

Das Hauptproblem bei den betroffenen Windows 11 Versionen war eine instabile Remotedesktop-Verbindung. Nutzer berichteten von plötzlichen Verbindungsabbrüchen, Performance-Einbrüchen oder der Unmöglichkeit, überhaupt eine Verbindung zu Remote-Hosts aufzubauen. Da viele Unternehmen auf RDP (Remote Desktop Protocol) angewiesen sind, war der Druck auf Microsoft groß.

Sekundäre Keywords und technische Analyse

Für ein besseres Verständnis der Thematik sind folgende Begriffe entscheidend:

1. Windows 11 24H2 Fix
2. Known Issue Rollback (KIR) Erklärung
3. RDP Verbindung abbruch beheben
4. Microsoft Update Katalog manueller Download
5. Windows 11 Out-of-Band Update Installation

Was ist Known Issue Rollback (KIR)?

Ein wesentlicher Teil der Fehlerbehebung bei Microsoft basiert heute auf der Known Issue Rollback (KIR) Technologie. Dies ist eine wichtige Cloud-basierte Funktion, die es Microsoft ermöglicht, problematische Code-Änderungen schnell rückgängig zu machen, ohne dass der Nutzer ein komplettes Update deinstallieren muss.

• Funktionsweise: Wenn ein fehlerhafter Patch ausgerollt wurde, sendet Microsoft eine Konfiguration an die Geräte. Diese weist das System an, den alten, funktionierenden Code-Pfad anstelle des neuen, fehlerhaften Pfades zu verwenden.
• Vorteil: Die Sicherheitspatches bleiben erhalten, während nur die funktionalen Fehler „zurückgerollt“ werden.
• Einschränkung: Für nicht verwaltete Geräte geschieht dies oft automatisch innerhalb von 24 Stunden, sofern eine Internetverbindung besteht. In Unternehmensumgebungen müssen Administratoren jedoch oft spezielle Gruppenrichtlinien anwenden.

Die Parallele: Performance-Probleme in Spielen (KB5001391 & Co.)

Die Notwendigkeit von schnellen Korrekturen ist nicht neu. Bereits in der Vergangenheit, etwa bei Windows 10 (Versionen 21H1, 20H2, 2004), gab es ähnliche Szenarien. Damals verursachten Updates massive Performance-Probleme in Spielen (Ruckeln, geringe FPS).

Microsoft nutzte auch hier KIR, um die Probleme serverseitig zu lösen. Die Erfahrungen aus diesen Vorfällen zeigen, dass die Kombination aus serverseitigen Fixes (KIR) und gezielten manuellen Updates (wie KB5077744) das Standard-Vorgehen für moderne Windows-Wartung darstellt. Während einfache Bugfixes oft im Hintergrund via KIR gelöst werden, erfordern tiefgreifende Protokoll-Änderungen im Remotedesktop-Bereich ein eigenständiges Update-Paket.

So installieren Sie KB5077744 manuell

Da dieses Update als „Out-of-Band“ klassifiziert ist, finden Sie es in der Regel nicht durch einfaches Klicken auf „Nach Updates suchen“ in den Einstellungen. Sie müssen den Microsoft Update Katalog nutzen.

Schritt-für-Schritt Anleitung:

1. Identifizieren Sie Ihre Version: Stellen Sie sicher, dass Sie Windows 11 24H2 oder 25H2 verwenden.
2. Update Katalog besuchen: Rufen Sie die offizielle Seite des Microsoft Update Katalogs auf.
3. Suche: Geben Sie in das Suchfeld KB5077744 ein.
4. Download: Wählen Sie die passende Version für Ihre Systemarchitektur (meist x64) und klicken Sie auf „Herunterladen“.
5. Installation: Öffnen Sie die heruntergeladene .msu-Datei und folgen Sie den Anweisungen auf dem Bildschirm.
6. Neustart: Ein Systemneustart ist zwingend erforderlich, um die Änderungen an den Netzwerkprotokollen wirksam zu machen.

Zusammenfassung und Fazit

Das Update KB5077744 ist eine essenzielle Korrektur für alle Nutzer von Windows 11 24H2 und 25H2, die auf Remotedesktop-Verbindungen angewiesen sind. Durch die gezielte Behebung der Verbindungsprobleme stellt Microsoft die gewohnte Produktivität wieder her.

Die wichtigsten Punkte im Überblick:

• KB5077744 behebt spezifische RDP-Fehler.
• Es handelt sich um ein manuelles Update aus dem Microsoft Update Katalog.
• Die KIR-Technologie unterstützt im Hintergrund die Stabilität des Betriebssystems.
• Ein zeitnahes Handeln verhindert Arbeitsausfälle im Home-Office oder in Server-Umgebungen.

Die Anforderungen an moderne IT-Infrastrukturen wachsen rasant. Ob KI-Workloads, riesige Datenbanken oder Virtualisierung – die Geschwindigkeit des Datendurchsatzes ist oft der Flaschenhals. Microsoft hat dieses Problem erkannt und mit Windows Server 2025 eine fundamentale Änderung eingeführt: den Wechsel auf Native NVMe.

Bisher basierte die NVMe-Anbindung in Windows auf dem veralteten SCSI-Modell (Small Computer System Interface), was moderne SSDs künstlich ausbremste. In diesem Artikel erfahren Sie, wie der neue, von Grund auf neu geschriebene Storage-Stack die NVMe-Leistung entfesselt, welche Vorteile das für Unternehmen bietet und wie Sie die „geheimen“ Optimierungen in Windows 11 (Version 25H2) freischalten.

1. Warum Native NVMe? Der Abschied vom SCSI-Erbe

Jahrzehntelang war SCSI der Goldstandard für die Kommunikation zwischen Betriebssystem und Massenspeicher. Doch SCSI wurde für rotierende Festplatten (HDDs) entwickelt. NVMe (Non-Volatile Memory Express) hingegen wurde speziell für Flash-Speicher konzipiert.

Das Problem der SCSI-Translation

Bisher musste Windows jeden NVMe-Befehl intern in einen SCSI-Befehl übersetzen (SCSI Translation Layer). Dieser Prozess erzeugte CPU-Overhead und Latenzen. Mit der Einführung von Native NVMe in Windows Server 2025 entfällt dieser Umweg komplett. Die Kommunikation erfolgt nun direkt und ohne Protokoll-Ballast.

2. Die technischen Highlights: Bis zu 70 % mehr Performance

Die Messwerte, die Microsoft in der Tech-Community veröffentlicht hat, sind beeindruckend. Durch die native Integration erzielt Windows Server 2025 signifikante Steigerungen in fast allen relevanten Metriken:

• Höhere IOPS: Tests zeigen eine Steigerung der Ein-/Ausgabevorgänge pro Sekunde (IOPS) um bis zu 70 %.
• Geringere Latenz: Da der Übersetzungsschritt entfällt, sinkt die Antwortzeit der SSDs spürbar.
• Effiziente CPU-Nutzung: Der neue Stack benötigt weniger Prozessorzyklen pro I/O-Operation, wodurch mehr Rechenleistung für die eigentlichen Anwendungen (z. B. SQL Server) übrig bleibt.
• Optimiertes Locking: Der neue Treiber reduziert interne Sperren (Locks), was die Skalierbarkeit auf Systemen mit vielen Kernen massiv verbessert.

3. Schritt-für-Schritt: So aktivieren Sie Native NVMe

Um in den Genuss der vollen Performance zu kommen, muss der neue Stack teilweise manuell adressiert oder verifiziert werden, insbesondere in der aktuellen Übergangsphase.

In Windows Server 2025 einrichten

In Windows Server 2025 ist der Native NVMe-Stack als neuer Standard implementiert. Um das volle Potenzial auszuschöpfen und die Konfiguration zu validieren, folgen Sie diesen Schritten:

1. Voraussetzung: Windows-Standardtreiber: Stellen Sie sicher, dass Sie über NVMe-fähige Geräte verfügen, die den Windows-eigenen NVMe-Treiber (StorNVMe.sys) verwenden. Beachten Sie, dass einige Anbieter (z. B. Samsung oder Intel) eigene Treiber bereitstellen. Wenn Sie nicht den mitgelieferten Windows-Treiber nutzen, werden Sie keine Performance-Unterschiede durch den neuen Stack feststellen.
2. Aktivierung via Registry/PowerShell: Sofern das Oktober-Update für Windows Server 2025 installiert ist, kann der benötigte Feature-Key direkt über die PowerShell (mit Administratorrechten) hinzugefügt werden:reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f
3. Verwendung des MSI-Installers: Alternativ stellt Microsoft einen MSI-Installer für Gruppenrichtlinien bereit. Diese MSI ist universell für Windows 11 (24H2, 25H2) sowie für Server 2025 einsetzbar und automatisiert die Aktivierung in Unternehmensumgebungen.
4. Validierung im Geräte-Manager: Sobald Native NVMe aktiviert ist, öffnen Sie den Geräte-Manager (devmgmt.msc). Stellen Sie sicher, dass alle angeschlossenen NVMe-Geräte im Abschnitt „Laufwerke“ korrekt angezeigt werden und der Controller unter „Speicherkontroller“ auf den neuen Treiber-Build verweist.
5. Einrichtung von NVMe over Fabrics (NVMe-oF): Falls Sie Remote-Storage nutzen, aktivieren Sie die Unterstützung im Server-Manager unter „Rollen und Features hinzufügen“ -> „Datei- und Speicherdienste“ -> „Dateidienste“ -> „NVMe-over-Fabrics-Unterstützung“.

In Windows 11 25H2 (Experten-Anleitung)

In Windows 11 ist der native Stack für Client-Systeme (GeClient) vorhanden. Um den Performance-Modus in Windows 11 25H2 freizuschalten, sind drei spezifische Registry-Einträge notwendig.

Achtung: Eingriffe in die Registry erfolgen auf eigene Gefahr. Erstellen Sie vorab einen Wiederherstellungspunkt.

• 735209102 (NativeNVMeStackForGeClient): Aktiviert den nativen Stack für Client-Editionen.
• 1853569164 (UxAccOptimization): Beschleunigt den Datendurchsatz.
• 156965516 (Standalone_Future): Aktiviert zukunftsorientierte Optimierungen.

Registry-Befehl:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
"735209102"=dword:00000001
"1853569164"=dword:00000001
"156965516"=dword:00000001

4. NVMe over Fabrics (NVMe-oF): Storage im Netzwerk

Ein weiteres zentrales Feature für Rechenzentren ist die verbesserte Unterstützung von NVMe over Fabrics. Dies erlaubt es, NVMe-Speicher über das Netzwerk so anzusprechen, als wäre er lokal im Server verbaut. Dies ist ein entscheidender Vorteil für hyperkonvergente Infrastrukturen (HCI).

5. Vergleich: Alter Stack vs. Neuer Native Stack

6. Best Practices für die Implementierung

1. Treiber-Check: Deinstallieren Sie herstellerspezifische NVMe-Treiber, um StorNVMe.sys zu nutzen.
2. UEFI-Modus: Ein Betrieb im Legacy-Modus verhindert die Nutzung moderner Storage-Features.
3. Benchmarks: Testen Sie vor und nach der Aktivierung mit CrystalDiskMark, um die IOPS-Steigerung zu validieren.

Fazit: Ein Pflicht-Upgrade für Storage-Enthusiasten

Microsoft macht mit dem Native NVMe Stack in Windows Server 2025 und den Anpassungen in Windows 11 25H2 einen gewaltigen Schritt nach vorn. Es ist die Beseitigung eines jahrzehntealten Erbes, das moderne Hardware künstlich limitiert hat.

Glossar

• StorNVMe.sys: Der standardmäßige NVMe-Treiber von Microsoft.
• Feature Management Overrides: Registrierungsschlüssel, die neue Windows-Funktionen steuern.
• NVMe-oF: NVMe-Befehle über Netzwerkprotokolle wie TCP oder RDMA.
• Externer Link: Microsoft Tech Community – Announcing Native NVMe

Die neuesten administrativen Vorlagen (.admx) für Windows 11 2025 Update (Version 25H2) und Windows Server 2025 stehen ab sofort zum Download bereit. Dieses Update ist für alle IT-Administratoren, die ihre Client- und Server-Umgebungen zentral über Gruppenrichtlinien (Group Policy) steuern, unerlässlich.

Mit jeder neuen Windows-Version führt Microsoft neue Konfigurationsmöglichkeiten ein. Um diese neuen Richtlinieneinstellungen in der Gruppenrichtlinien-Verwaltungskonsole (GPMC) oder im lokalen Gruppenrichtlinien-Editor (gpedit.msc) sehen und konfigurieren zu können, müssen die entsprechenden administrativen Vorlagen (.admx-Dateien) aktualisiert werden.

Warum das ADMX-Update für 25H2 und Server 2025 notwendig ist

Administrative Vorlagen (.admx-Dateien) sind die sprachneutralen Dateien, die die Struktur der Gruppenrichtlinieneinstellungen definieren. Die zugehörigen sprachspezifischen Dateien (.adml-Dateien) enthalten die Texte, die in der Konsole angezeigt werden.

Wenn Sie in Ihrem Central Store auf dem Domänencontroller (DC) noch ältere ADMX-Dateien verwenden, fehlen Ihnen sämtliche neuen GPO-Einstellungen, die mit Windows 11 25H2 und Windows Server 2025 eingeführt wurden.

Die wichtigsten Vorteile des Updates:

1. Zugriff auf neue Richtlinien: Ermöglicht die Steuerung neuer Funktionen und Verhaltensweisen in Windows 11 25H2.
2. Abwärtskompatibilität: Die neuen ADMX-Dateien sind in der Regel abwärtskompatibel und können zur Verwaltung älterer Windows-Versionen (z. B. Windows 10 oder frühere Windows 11-Versionen) verwendet werden, solange der Central Store auf einem modernen Domänencontroller liegt.
3. Zentrale Verwaltung: Stellt sicher, dass alle Gruppenrichtlinieneinstellungen von einem zentralen Ort aus verwaltet werden können.

Download der administrativen Vorlagen

Microsoft stellt die ADMX-Dateien als MSI-Installationspaket im Microsoft Download Center zur Verfügung. Es gibt separate Pakete für die Client- und Server-Betriebssysteme.

• Administrative Vorlagen (.admx) für Windows 11 2025 Update (25H2):
  • (Link zur offiziellen Microsoft Download-Seite)
• Administrative Vorlagen (.admx) für Windows Server 2025:
  • (Link zur offiziellen Microsoft Download-Seite)

Tipp für Profis: Zusätzlich zu den ADMX-Dateien veröffentlicht Microsoft auch eine Referenztabelle der Gruppenrichtlinieneinstellungen (als XLSX-Datei). Diese Tabelle listet alle verfügbaren Computer- und Benutzerkonfigurationen detailliert auf und ist eine wertvolle Hilfe beim Planen der neuen Richtlinien.

Anleitung: Central Store aktualisieren

Der Central Store ist der empfohlene Speicherort für ADMX-Dateien in einer Active Directory (AD)-Umgebung. Er befindet sich im SYSVOL-Verzeichnis des Domänencontrollers und gewährleistet, dass alle Administratoren immer dieselbe, aktuelle Version der Richtlinienvorlagen verwenden.

Folgen Sie diesen Schritten, um Ihren Central Store zu aktualisieren:

1. Vorbereitung und Sicherung:
   • Erstellen Sie auf einem Domänencontroller oder einer Verwaltungsstation einen temporären Ordner (z. B. C:\ADMX_Update).
   • Sichern Sie den bestehenden Central Store. Der Pfad ist in der Regel: \\*Domänenname*\SYSVOL\*Domänenname*\Policies\PolicyDefinitions. Kopieren Sie den Ordner PolicyDefinitions und dessen Inhalt an einen sicheren Ort.
2. Installation der neuen Dateien:
   • Führen Sie die heruntergeladene MSI-Datei von Microsoft aus.
   • Wählen Sie als Installationsort ein temporäres Verzeichnis (z. B. den Ordner C:\ADMX_Update aus Schritt 1). Das MSI-Paket entpackt die ADMX- und ADML-Dateien in dieses Verzeichnis.
3. Kopieren in den Central Store:
   • Navigieren Sie zum temporären Installationsordner und finden Sie den Ordner PolicyDefinitions.
   • Kopieren Sie alle .admx-Dateien aus dem Stammverzeichnis von PolicyDefinitions in den Central Store: \\*Domänenname*\SYSVOL\*Domänenname*\Policies\PolicyDefinitions. Überschreiben Sie dabei die vorhandenen Dateien.
   • Kopieren Sie anschließend den oder die gewünschten Sprachordner (z. B. de-DE für Deutsch) aus dem temporären PolicyDefinitions-Ordner in den Central Store-Ordner PolicyDefinitions. Überschreiben Sie auch hier die vorhandenen .adml-Dateien.
4. Überprüfung:
   • Öffnen Sie auf einer Verwaltungsstation die Gruppenrichtlinien-Verwaltungskonsole (GPMC).
   • Erstellen Sie ein neues Gruppenrichtlinienobjekt (GPO) oder bearbeiten Sie ein bestehendes.
   • Navigieren Sie zu den Richtlinieneinstellungen (z. B. Computerkonfiguration -> Administrative Vorlagen). Wenn die neuen Kategorien und Einstellungen für Windows 11 25H2 sichtbar sind, war das Update erfolgreich.

Wichtig: Stellen Sie sicher, dass die Replikation des SYSVOL-Verzeichnisses auf alle Domänencontroller erfolgreich abgeschlossen wurde, bevor Sie sich auf die neuen Richtlinien verlassen.