Entscheidung für Windows 10: The Day After
Autor/Redakteur: Horst Droege, Chief Product Architect bei Matrix42/gg
Viele Unternehmen zögern noch, von Windows 7 oder 8/8.1 auf das aktuelle Windows 10 umzusteigen. Denn Microsoft hat sein Release-Konzept geändert und bringt nun halbjährlich Updates heraus. So befürchten IT-Leiter, künftig von Update-Projekten überrollt zu werden. Doch angesichts des angekündigten Support-Endes für Windows 7 im Jahr 2020 ist ein Umstieg unvermeidlich. Dieser Beitrag erläutert, wie eine IT-Organisation verfahren sollte, sobald die Würfel zugunsten von Windows 10 gefallen sind – und warum man für den „Tag danach“ auf Prozesse statt auf die LTSB-Version (Long-Term Servicing Branch) setzen sollte.
Anfang des Jahres war zu lesen, dass der Anteil von Windows 10 unter den Windows-Anwendern in Deutschland bereits die 50-Prozent-Marke überschritten hatte: Sein Marktanteil lag Ende 2017 laut StatCounter bei 51,3 Prozent. Diese hohe Marktdurchdringung speist sich aber vorrangig aus dem Consumer-Segment: In zahlreichen Unternehmen ist man noch zurückhaltend und zögert den Umstieg auf die aktuelle Windows-Version nach wie vor hinaus.
Moderne Release-Zyklen
Denn zusammen mit Windows 10 hatte man in Redmond auch die Release-Politik modernisiert: In Anlehnung an agile Softwareentwicklung kündigte das Softwarehaus eine kontinuierliche Aktualisierung nach dem „Rolling Releases“-Prinzip an: „Windows-as-a-Service“ ist das Ziel. Jeweils im Frühjahr und im Herbst („semiannual channel“, also „halbjährlicher Kanal“ genannt) gibt es seither Updates für die Windows-10-Varianten Home, Pro, Enterprise sowie – für den Bildungssektor – Education. Diese können nicht nur Bugfixes, sondern auch neue Funktionen enthalten. So sollen die Anwender laufend von funktionalen Neuerungen und Sicherheitsupdates profitieren.
Im Release-Track Current Branch (CB), gedacht für Privatanwender wie auch Unternehmen, lädt Windows dabei Updates automatisch herunter und installiert sie. Mit der Variante „Windows Update for Business“ können Administratoren Security Patches zu Testzwecken um bis zu 30 Tage aufschieben, Feature Upgrades um maximal 365 Tage. Lediglich der Release-Zweig „Long-Term Servicing Branch“ (LTSB) behält das vertraute Zwei- bis Drei-Jahres-Intervall zwischen Betriebssystem-Iterationen bei.
Der halbjährliche Erneuerungsrhythmus soll, geht es nach Microsoft, in den Unternehmen für Planbarkeit sorgen. Dennoch blieben bislang viele IT-Organisationen misstrauisch, hat man doch den Aufwand des unternehmensweiten Umstiegs auf Windows 7 oder Windows 8/8.1 noch gut in Erinnerung. Die Befürchtung: Aufgrund der stark verkürzten OS-Update-Zyklen könnte man künftig permanent mit der Aktualisierung der Client-Systeme zu kämpfen haben.
LTSB meist keine Option
Manch ein IT-Leiter liebäugelt deshalb mit der Idee, einfach alle Clients auf Windows 10 LTSB zu migrieren – dann, so die Hoffnung, könnten die Update-Projekte so ablaufen wie gehabt. Von dieser Vorgehensweise ist jedoch abzuraten: Der Ansatz führt in die Sackgasse!
Denn Microsoft hat LTSB lediglich für solche Endpunkte vorgesehen, deren Software-Image dauerhaft praktisch unverändert bleibt, also zum Beispiel Kassensysteme oder Steuerungsrechner an Produktionsstraßen. Als Release-Option für Office-Rechner hingegen ist LTSB nicht gedacht – und das macht sich früher oder später bemerkbar.
So verfügt die LTSB-Variante zum Beispiel nicht über den modernen, schlanken Edge Browser, den Microsoft zusammen mit Windows 10 vorgestellt hatte. Dies könnte man als Detail abtun – es ist aber ein Indiz dafür, dass der LTSB-Kanal jederzeit von Neuerungen der Windows-Client-Welt abgeschnitten werden kann. Dadurch ist zum Beispiel nicht garantiert, dass auch die nächste LTSB-Version noch mit Microsoft Office 365 zusammenarbeitet.
Prozess statt Projekt
Wenn also das Verharren auf Vertrautem mittels LTSB kein gangbarer Weg ist, wie sollte sich eine IT-Abteilung dann auf „The Day After“ vorbereiten? Wichtig ist es hier vor allem, den Modernisierungsschritt in Microsofts Release-Politik auf Organisationsseite nachzuvollziehen: Die IT-Abteilung muss sich vom Projekt OS-Migration verabschieden und es durch einen „Prozess OS-Migration“ ersetzen. Sie muss ein standardisiertes Verfahren etablieren, um die halbjährliche Aktualisierung des Client-Betriebssystems zu stemmen – wenn es sein muss, mittels mehrerer Rollout-Wellen schnell und doch unternehmensweit. Das individuelle Projekt muss zu einem Satz Standardaufgaben werden, die das Client-Management-Team „nach Schema F“ abarbeiten kann.
Auf organisatorischer Ebene bietet sich für das Change- und Release-Management eine Orientierung an den Standardprozessen des Service Management Frameworks ITIL an, alternativ der Rückgriff auf das Microsoft Operations Framework (MOF). Auch für Cobit-erfahrene IT-Organisationen (Cobit: Control Objects for IT and Related Technology) sollte der Übergang zu einem Standard-OS-Migrationsprozess ein Leichtes sein. Ergänzend ist auf technischer Ebene Softwareunterstützung gefragt, um die geplanten Prozesse möglichst hochgradig automatisiert umsetzen zu können.
