IT-Wissen · IT-Wissen

Windows 11 Enterprise 23H2: So gelingt der kontrollierte Wechsel auf eine unterstützte Version

Kurz zusammengefasst: Windows 11 Enterprise 23H2 erhält noch bis zum 10. November 2026 Updates. Der anstehende Versionswechsel sollte deshalb als steuerbarer Servicing-Prozess vorbereitet werden. Im Mittelpunkt stehen ein verlässlicher Versionsbestand, eine begründete Zielentscheidung, dokumentierte Anwendungstests sowie passende Intune- oder Windows-Update-Richtlinien. So wird aus dem Supporttermin eine planbare Betriebsentscheidung mit klaren Freigabe- und Ausnahmeregeln.

Nutzen und Einordnung

Ein geplanter Versionswechsel schafft einen einheitlichen und weiterhin unterstützten Windows-Stand. Gleichzeitig wird sichtbar, welche Geräte, Anwendungen und Verwaltungsregeln vor einer Freigabe tatsächlich betrachtet werden müssen.

Für Windows 11 Enterprise 23H2 endet der Updatezeitraum laut Microsoft am 10. November 2026. Die Version ist damit noch nicht sofort abgekündigt, sollte aber in der laufenden Servicing-Planung berücksichtigt werden.

Microsoft führt Windows 11 in jährlichen Funktionsupdates weiter. Für die Planung zählen immer die konkrete Edition, Version und der eingesetzte Servicing- beziehungsweise Updatekanal. Die Enterprise-Frist darf daher nicht auf Windows 11 Pro übertragen werden.

Ziel ist ein unterstützter und dokumentierter Versionsstand.
Die Entscheidung wird an Geschäftsprozessen, Anwendungen und Wartungsfenstern ausgerichtet.
Eine Pilotierung liefert belastbarere Betriebserkenntnisse als ein rein technischer Kompatibilitätscheck.

1. Bestand und Supportstatus feststellen

Erfassen Sie alle betroffenen Windows-Geräte mit Edition, Version, Build, Architektur, Hardwaremerkmalen, Benutzergruppe und Standort. Ergänzen Sie die eingesetzte Verwaltungsplattform, etwa Microsoft Intune, Configuration Manager oder lokale Richtlinien.

Prüfen Sie den Supportstatus für genau diese Edition anhand der Microsoft-Lifecycle- und Release-Informationen. Windows 11 Enterprise 23H2, Windows 11 Pro 23H2 und Enterprise LTSC folgen unterschiedlichen Servicing-Modellen.

Kennzeichnen Sie Geräte mit abweichender Hardware, spezieller Software, eingeschränkter Erreichbarkeit oder einer besonderen Betriebsrolle. Für diese Gruppen sollte die Freigabeentscheidung getrennt dokumentiert werden.

Version und Build zentral auslesen und exportieren.
Edition und Updatekanal gegen die konkrete Lifecycle-Angabe prüfen.
Sondergeräte, gemeinsam genutzte Geräte und Offline-Geräte separat bewerten.

2. Zielversion und Servicing-Modell festlegen

Die Zielversion sollte nicht allein nach dem neuesten Namen ausgewählt werden. Maßgeblich sind Supportdauer, vorhandene Hardware, Verwaltungsfähigkeit, Anwendungskompatibilität und die Fähigkeit des Unternehmens, Funktionsupdates regelmäßig zu prüfen und auszurollen.

Microsoft beschreibt Windows 11 24H2 und 25H2 als reguläre Releases für die bestehende Enterprise-Bereitstellung. Windows 11 26H1 ist dagegen für ausgewählte neue Geräte vorgesehen, wird nicht als In-place-Funktionsupdate für vorhandene Geräte angeboten und ist nicht für eine breite Bereitstellung in bestehenden Umgebungen gedacht.

Legen Sie vor dem Rollout fest, welche Version künftig Standard ist, für welche Gerätegruppen sie gilt und welche Ergebnisse eine Freigabe oder einen Stopp auslösen. Übergangsversionen und Ausnahmen brauchen einen Eigentümer sowie einen nächsten Prüftermin.

Zielstand, Freigabekriterien und Eskalationsweg vor dem Rollout beschließen.
Funktionsupdates und monatliche Qualitätsupdates getrennt planen.
Übergangsversionen mit Eigentümer und Folgeentscheidung dokumentieren.

3. Anwendungen, Gerätefunktionen und Richtlinien prüfen

Prüfen Sie die Arbeitsabläufe, die für die jeweiligen Benutzergruppen tatsächlich erforderlich sind. Dazu können Anmeldung, Dateizugriff, Drucken, VPN, Microsoft-365-Anwendungen, Browser-Erweiterungen, Zertifikatsnutzung oder branchenspezifische Fachverfahren gehören.

Eine Testmatrix mit Gerätetyp, Benutzerrolle, Anwendung, Testfall, Ergebnis und Verantwortlichem macht die Freigabe nachvollziehbar. Herstellerfreigaben und bekannte Probleme von Drittsoftware werden dabei als eigene Nachweise dokumentiert; sie ergeben sich nicht automatisch aus der Windows-Kompatibilität.

Sicherheits- und Verwaltungsfunktionen sollten nur ins Prüfprogramm aufgenommen werden, wenn sie in der jeweiligen Umgebung relevant sind. Beispiele sind Verschlüsselung, Secure Boot, Windows Hello, Defender, Firewall, Zertifikate oder die Verbindung zur zentralen Verwaltung. Die konkrete Prüftiefe muss zur Geräteklasse und zum Betriebsrisiko passen.

Mit realistischen, kontrollierten Testdaten arbeiten.
Herstellerfreigaben und bekannte Probleme der eingesetzten Anwendungen dokumentieren.
Ergebnisse nachvollziehbar festhalten und nicht nur mündlich freigeben.

4. Pilot und gestaffelter Rollout

Für die Bereitstellung empfiehlt sich ein abgestuftes Vorgehen mit Pilotgruppe, erster breiterer Gruppe und anschließendem Gesamt-Rollout. Die Gruppen sollten technisch unterschiedliche Geräte und relevante Arbeitsbereiche abbilden.

Jede Welle benötigt ein festgelegtes Wartungsfenster, erreichbaren Support und überprüfbare Abbruchkriterien. Treten gleichartige kritische Fehler auf, wird die nächste Welle pausiert, bis Ursache und Gegenmaßnahme geklärt sind.

Mit Microsoft Intune können Feature-Update-Richtlinien auf eine bestimmte Windows-Version ausgerichtet und geeigneten Gerätegruppen zugewiesen werden. Die Richtlinie bleibt wirksam, bis sie geändert oder entfernt wird. Sie steuert die angebotene Zielversion, ersetzt aber nicht die fachliche Freigabe.

Safeguard Holds verhindern die Bereitstellung, wenn Microsoft ein bekanntes Kompatibilitätsproblem berücksichtigt. Ein Umgehen dieser Schutzmaßnahme sollte nur erfolgen, wenn die technische Ursache verstanden, die betroffene Gerätegruppe kontrolliert und die Entscheidung ausdrücklich dokumentiert ist.

Pilotgruppe und Abbruchkriterien vorher festlegen.
Rollout-Wellen mit Supportkapazität und Wartungsfenstern synchronisieren.
Intune-Zielversionen, Zuweisungen und konkurrierende Updateeinstellungen kontrollieren.
Schutzsperren nicht ohne dokumentierte technische Begründung umgehen.

5. Sicherung, Wiederherstellung und Kommunikation

Vor jeder Welle muss feststehen, wo Benutzer- und Betriebsdaten liegen und wie ein betroffenes Gerät wieder arbeitsfähig gemacht wird. Die Sicherung oder zentrale Ablage sollte für die betroffene Gerätekategorie geprüft sein.

Dokumentieren Sie den vorgesehenen Wiederherstellungsweg, die verantwortliche Entscheidung und die Daten, die erhalten bleiben müssen. Der konkrete Weg kann je nach Verwaltung, Gerätestandard und Organisationsprozess unterschiedlich sein; ein allgemeiner Hinweis auf eine Neuinstallation reicht für kritische Arbeitsplätze nicht aus.

Benutzer sollten vorab über Zeitpunkt, erwarteten Neustart, mögliche Unterbrechungen und den Ansprechpartner informiert werden. Der Helpdesk benötigt die zu erwartenden Änderungen und den Eskalationsweg vor Beginn der ersten Welle.

Sicherung und Wiederherstellung praktisch prüfen.
Wiederherstellungsweg je Gerätekategorie dokumentieren.
Benutzerinformation und Helpdesk-Unterlagen vor dem Pilot vorbereiten.

6. Nach dem Wechsel kontrollieren

Nach jeder Welle werden Version, Build, Richtlinienanwendung und Verwaltungsverbindung kontrolliert. Weitere Prüfungen wie Aktivierung, Verschlüsselungsstatus oder Schutzstatus gehören dazu, wenn sie für die jeweilige Umgebung als Freigabekriterium festgelegt wurden.

Technische und fachliche Abnahme werden getrennt dokumentiert. Rückmeldungen und Helpdesk-Tickets sollten nach Benutzergruppe und Gerätetyp ausgewertet werden.

Geräte, die wegen einer Anwendung oder eines technischen Problems zunächst auf 23H2 bleiben, benötigen einen dokumentierten Übergangsstatus, eine verantwortliche Stelle und eine Folgeentscheidung vor dem Supportende.

Nach Abschluss wird der Vorgang als wiederkehrender Servicing-Prozess etabliert. Die verwendeten Inventar-, Test- und Freigabedokumente bilden die Grundlage für spätere Windows-Versionen.

Technische und fachliche Abnahme getrennt dokumentieren.
Ausnahmen mit Eigentümer, Begründung und Folgeaktion versehen.
Versionsinventar und Testfälle als Betriebsdokumentation pflegen.

Beispiel aus der Praxis

Beispiel: Ein mittelständischer Betrieb mit rund 80 Windows-Arbeitsplätzen stellt fest, dass ein Teil der Geräte Windows 11 Enterprise 23H2 nutzt. Die IT exportiert zunächst Edition, Version, Build, Verwaltungsstatus und Gerätegruppe. Anschließend legt sie 25H2 als zu prüfenden Zielstand fest und ordnet die Geräte nach Standardarbeitsplatz, Außendienst, Verwaltung und Fertigung. Für jede Gruppe werden die erforderlichen Arbeitsabläufe getestet. Zehn technisch unterschiedliche Geräte bilden den Pilot. Die Intune-Richtlinie wird nur den vorgesehenen Pilotgeräten zugewiesen; die Ergebnisse und Abbruchkriterien werden vor der nächsten Welle geprüft. Zwei Sondergeräte bleiben vorerst zurück. Ihre Ausnahme wird mit Begründung, Verantwortlichem und Folgeprüfung dokumentiert.

Chancen für Unternehmen

Ein einheitlicher Zielstand vereinfacht Inventarisierung, Richtlinienpflege und Support.
Der Rollout macht veraltete Anwendungen, Treiber und Sonderkonfigurationen sichtbar.
Gestaffelte Wellen schaffen klare Entscheidungspunkte und begrenzen die Auswirkung einzelner Fehler.
Ein dokumentierter Servicing-Prozess erleichtert spätere Windows- und Sicherheitsupdates.

Grenzen und Prüfpunkte

Die geeignete Zielversion hängt von Edition, Updatekanal, Hardware, Verwaltung und den eingesetzten Anwendungen ab.
Ein Versionswechsel behebt keine grundsätzlich unsicheren Fachanwendungen, fehlenden Sicherungen oder unklaren Berechtigungen.
Nicht jedes Problem ist durch ein In-place-Upgrade lösbar; einzelne Geräte benötigen eine Neuinstallation oder einen Austausch.
Herstellerfreigaben und Supportaussagen für Drittsoftware müssen separat geprüft werden.
Ohne aktuelles Inventar sowie geprüfte Sicherungs- und Wiederherstellungsdaten bleibt die Planung unvollständig.