Startseite > Office & Kommunikation > Standardprozess statt Update-Projekt

Windows 10

Standardprozess statt Update-Projekt

3. Juli 2018, 13:49 Uhr | Autor: Horst Droege / Redaktion: Sabine Narloch

Fortsetzung des Artikels von Teil 1

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. 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.