Strategien zu Windows as a Service – Eine Prozessorientierte Sichtweise

A screenshot of a map

Oft werde ich nach der richtigen Strategie zum Thema “Windows as a Service” gefragt. Doch gibt es den einen, richtigen Weg? Die kurze Antwort ist nein. Es hängt wie so oft von den Umständen, den Anforderungen des Kunden und der weiteren Kunden spezifischen Umständen ab. In diesem Artikel möchte ich verschiedene Wege zum Thema Windows as a Service (WaaS) aufzeigen. Auch bekommen Sie Tipps was Sie bei der Suche nach Ihrem Weg beachten sollten.

Wichtig ist, Windows as a Service ist kein Projekt, es ist ein Prozess. Und die Kunst ist es den Prozess für Ihr Unternehmen so zu entwickeln das er performant funktioniert, aber alle Unwägbarkeiten abdeckt. Dazu gehören nicht nur die Frage wie viele Releases man überspringen möchte .

Zielgruppe für diesen Artikel

Normalerweise definiere ich keine Zielgruppen für einen Artikel, aber diesmal ein kleiner Hinweis. Die meisten Teile des Artikels sind für Mittelständische Firmen bis zu großen Konzernen relevant. Wenn Sie eine Ein-Personen-IT-Abteilung sind, wird der Artikel für Sie eher aus der Rubrik “Mit Kanonen auf Spatzen schießen” sein.

Wichtig ist auch, hier geht es mehr um Prozesse und um das Organisatorisch wie als um die Technik. Ich werden aber an den passenden Stellen zu weiterführenden, technischen Artikeln verlinken.

Wenn es Ihnen nur um das Thema “Vorbereitungen für ein In Place-Upgrade mit Windows 10” geht empfehle ich einen Blick in den Deutschen Dell EMC Blog. Da finden Sie zwei Artikel von mir zu diesem Thema:

Rahmenbedingungen, Anforderungen und Abhängigkeiten

Bevor es um die Wege geht, betrachten wir erstmal ein paar Dinge. Es gibt einige Dinge über die Sie nachdenken müssen, wenn Sie ihren Weg bei WaaS finden möchten. Der wichtigste Punkt ist das Thema Anforderungen, diese gilt es zu erfüllen.

Anforderungen an Windows as a Service

Hier gilt es sich Gedanken zu machen welche Anforderungen bei Ihrer Strategie unbedingt zu beachten sind. Dies können Regulatorische oder Gesetzliche Anforderungen sein. Oftmals kommen auch noch Anforderungen aus Zertifizierungen wie ISO oder IT-Grundschutz oder ähnliches zum tragen. Weitere Anforderungen können auch noch Betriebsvereinbarungen mit dem Betriebsrat sein (zum Beispiel Stichwort Telemetrie), oder Anforderungen an die IT aus dem eigenen Unternehmen.

Wichtig ist, eine Anforderung gilt es zu erfüllen oder Sie müssen sich eine Ausnahmeregelung genehmigen lassen. Hier einige Beispiele von Anforderungen die die Windows as a Service Strategie beeinflussen:

  • Validierung nach Medizinproduktegesetz (Wenn auch für Software vorgesehen)
  • IT Grundschutz
  • Regulatorische Vorgaben zum Update Management oder Software Integration
  • Betriebsvereinbarung zum Thema Telemetrie oder Analyse der Softwarenutzung
  • Ggf. Datenschutzgesetzte / GDPR / DSVGO
  • Interne Prozesse zum Thema Softwaremanagement, zum Teil durch Zertifizierungen vorgegeben

Praxisbeispiele

Um das ganze Mal etwas anschaulicher zu machen hier ein paar gezielte Beispiele auf der Praxis, und mögliche Folgen:

  • In den Prozessen zur Qualitätssicherung im Unternehmen ist beschrieben das jeder neue Software Version auf Funktion geprüft werden muss. Dieser Prozess ist Bestandteil der Iso Zertifizierung in dem Unternehmen.
    • Je nach Definition des Prozesses muss jedes Update entsprechend dem Prozess getestet werden.
    • Automatische Lösungen sind je nach Vorgaben aus dem Prozess schwieriger abzubilden.
    • Dies Betrifft nicht nur Feature Upgrades, sondern kann auch normale Updates und Sicherheitsupdates betreffen.
  • In der IT Betriebsvereinbarung mit dem Betriebsrat ist vereinbart das keine Telemetriedaten erhoben werden dürfen, auch ist die Erfassung der Nutzung von Software untersagt.
    • Keine Nutzung von Moderner Analyse für Feature Upgrades wie Windows Analytics möglich. Die Softwareabhängigkeiten müssen selbstständig betrachtet werden.
    • Einfluss auf die Auswahl der Windows Edition: Telemetrie 0 (Nur Sicherheitsrelevantes) ist nur mit der Windows 10 Enterprise Edition möglich. Komplettes Abschalten der Telemetrie ist nicht Vorgesehen und wird nicht Unterstützt von Microsoft.
    • Es fehlt der Überblick welche Anwendungen, die nicht von der IT verwaltet / installiert wurden auf den Systemen sind. Dies kann zu Kompatibilitätsproblemen beim nächsten Feature Upgrade führen.
  • Gemäß dem internen IT Konzept, basierend auf dem IT-Grundschutz müssen Sicherheitsupdates innerhalb von 5 Werktagen installiert werden.
    • Dies kann zum Beispiel Probleme mit dem eben erwähnten QS-Beispiel Probleme geben, wenn der Prozess nicht passend ist.
    • Die hat Auswirkungen auf die Verteilung und ggf. das Monitoring der Updateinstallation.

Sie sehen, manche der Anforderungen können es in sich haben. Nun habe ich Bewusst ein paar extremere Beispiele aus der Praxis gewählt. Wichtig ist: wenn Sie in der IT-Abteilung mit dem Auseinandersortieren der Anforderungen und dem Gestalten des Prozesses Schwierigkeiten haben, suchen sie sich ruhig externe Experten zur Hilfe. Mein Tipp, fragen sie nach deren Erfahrungen und wie viele Prozesse, die schon für WaaS gestaltet haben. Auch nicht jeder IT-Consultant hat WaaS komplett verstanden und kennt die verschiedenen Möglichkeiten.

Rahmenbedingungen

Zu den Rahmenbedingungen zählen zum Beispiel auch die Umstände die Berücksichtigte werden müssen. Da WaaS nicht nur die Updates, sondern auch die Upgrades betrachten muss gibt es hier einige Dinge, die Extreme Einflüsse haben können. Hier wieder ein paar Beispiele mit der Erklärung warum das relevant sein könnte:

  • Anzahl der Mitarbeiter für den Windows Client / die notwendigen Prozesse
    • Je nachdem wie komplex der Prozess ist, macht es ein unterschied ob eine Person oder fünf Personen für diese Tätigkeiten bereitstehen.
    • Besonders gilt das, wenn manuelle Tests durchgeführt werden müssen
  • Anzahl der Applikationen, die auf Kompatibilität geprüft werden müssen und wie diese geprüft werden müssen.
    • Sind es 10 Anwendungen oder 3577 Anwendungen? Das macht bei der Überprüfung ob die Software für das nächste Release Ready ist einen nicht unerheblichen Unterschied. Gerade wenn keine Moderne Analyse, wie Windows Analytics, verwendet werden kann.
    • Wie sieht die Prüfung aus? Starten, drucken, schließen ohne Fehlermeldung? Oder eher detailliert?
    • Wer Prüft bzw. erteilt die Freigabe für eine neue Version? Die IT oder vielleicht Anwendungsverantwortliche aus der Abteilung?
  • Gibt es eine Test Umgebung?
    • Gibt es vielleicht eine eigene Testumgebung, in der erst alles geprüft werden muss? Dies ist sicherer, aber sorgt auch für komplizierte Prozesse.
    • Muss eine neue Software nach dem Test vielleicht als Change gemäß ITIL in die Produktion überführt werden?
    • Wird bei den Tests auch die verschiedenen Hardwareplattformen berücksichtigt

Auch hier merkt man schnell, wie wichtig einige der Punkte sind. Es wird auch schnell klar, ein Prozess der vorsieht, das 2 Personen 2500 Anwendungen manuell testen bevor diese freigegeben werden, ist sehr schwierig bis unmöglich.

Abhängigkeiten

Das letzte der drei großen Felder dieser vorbereitenden Denksportaufgabe ist das Thema Abhängigkeiten. Und damit ist nicht gemeint Anwendung B benötigt eine Java Version, die noch auf Steintafeln geliefert wurde. Es geht um Abhängigkeiten für den Prozess. Ein wichtiger Faktor, um den es bei Abhängigkeiten geht, ist das Thema Zeit und Wartezeiten. Wichtig ist es hier, dass Sie die Schnittstellen kennen und entsprechend nutzen und adressieren.

Wieder ein paar Beispiele aus der Realität:

  • Software mit geänderten Funktionsumfang (z.B. neues Office365 Release oder neues Windows 10 Release) müssen vom Betriebsrat genehmigt werden.
    • Aus der Erfahrung versuchen Sie eine SLA zu vereinbaren. Ich hatte das einmal das ein Betriebsrat 9 Monate für eine Windows 10 Freigabe gebraucht hat. Überlegenen Sie sich, was das bei 18 bis 30 Monate Support-Lifecycle bedeutet. Tipp: Auf Infrastrukturhelden.de gibt es verschiedene Life-Cycle Diagramme zum kostenlosen Download.
  • Sicherheitsupdates müssen mit dem IT-Sicherheitsbeauftragten abgestimmt werden
    • Auch hier ist das Thema SLA und Vertreterregelung wichtig, oder muss 3 Wochen gewartet werden bis die Sicherheitsbeauftragte Person aus dem Urlaub kommt?
  • Abhängigkeiten zu weiten Abteilungen, zum Beispiel neue Gruppenrichtlinien Vorlagen können nur vom Active Directory Team implementiert werden.

Wichtig ist hier, suchen Sie Ihre Schnittstellen und Abhängigkeiten. Achten Sie auch auf SLAs für die Schnittstellen, gerade wenn eine SLA von Ihnen erwartet wird. Wie wollen Sie eine SLA von 30 Tagen zur Upgrade Bereitschaft einhalten, wenn sich zum Beispiel der Betriebsrat 90 Tage für die Prüfung Zeit lässt.

Fazit

Wichtig ist, dokumentieren Sie Anforderungen, Abhängigkeiten, Schnittstellen und Rahmenbedingungen genau. Hinterfragen Sie auch ruhig die eine oder andere Anforderung. Da sich der Prozess für Windows durch den Hersteller geändert hat, ist es legitim den bisherigen Status Quo zu hinterfragen. Eventuell ergibt sich hier auch der eine oder andere Sinnvolle Change an den bisherigen Prozessen.

Wichtig ist auch, sammeln Sie diese Punkte in einem Team. Eventuell ist es auch sinnvoll weitere Stellen schon bei der Prozessfindung mit einzubinden, zum Beispiel den Betriebsrat oder den IT-Sicherheitsbeauftragten.

Häufige Fehler oder Suboptimale Entscheidungen aus der Realität der Prozessgestaltung

Hier noch ein paar Beispiele aus der Realität die ich für Suboptimal oder Schwierig halte. Diese müssen nicht unbedingt falsch sein, es hängt von den Anforderungen ab. Hier mal ein paar Beispiele 0aus der Realität die ich für Suboptimal oder Schwierig halte. Diese müssen nicht unbedingt falsch sein, es hängt von den Anforderungen ab. Hier mal meine persönlichen zwei Highlights:

Acrobat PDF und seine Tücken

Bei diesem Kunden war die IT Verantwortlich für die Funktion der Software. Es gab keine Testvorgaben der Fachabteilungen bezüglich der jeweiligen Software. Da die IT keine Vorgaben hat, sah das Testszenario für den Acrobat Reader wie folgt aus:

  1. Starten
  2. Beliebiges PDF öffnen
  3. PDF ausdrucken
  4. Programm schließen

Wenn dies ohne Fehler funktionierte und der Ausdruck mit dem PDF übereinstimmte galt der Test als erfolgreich.

Was die IT nicht wusste, eine Unternehmenskritische Fachanwendung in einer Abteilung basierte auf einem Interaktiven PDF-Dokument, das mit einer älteren Version von Adobe Acrobat erstellt wurde. Die Fachanwendung wurde überwiegend zum Monatsende eingesetzt. Das klingt an sich nicht schlimm, interaktiv bedeutete in diesem Fall aber:

  • Das Formular verändert sich auf Basis der Eingaben zur Laufzeit
  • Die Druckansicht entspricht nicht der Bildschirmansicht (Gewollt, da das Formular nicht alle Informationen enthalten muss.
  • Der Inhalt des Formulars kann als Mail in einem definierten Format verschickt werden

Bei diesen speziellen Anforderungen ist dann mal etwas schiefgegangen. Einige der Funktionen funktionierten auf einmal nicht mehr. Die Suboptimalen Umstände in diesem Fall?

  • Die Testprotokolle waren nicht abgestimmt.
  • Die IT war ohne Wissen der Anforderungen für die Funktion verantwortlich
  • Am Anfang des Monats hat eine Testgruppe die neue Version erhalten, nach 5 Tagen ohne Probleme wurde diese auf alle Systeme verteilt => Leider hat in den 5 Tagen keiner der Testgruppe die Anwendung mit dem Spezial PDF benutzt.

Dies ist eines meiner Lieblingsbeispiele warum man für alle Anwendungen, selbst einen Browser oder Adobe ein abgestimmtes Testprotokoll haben sollte. Oder noch besser, die Verantwortung für Fachanwendungen an den Fachbereich delegieren. Dieser soll testen und Freigeben. Da sitzt meistens auch die Kompetenz für die Anwendung.

Probleme mit Treibern

Ein Kunde hat eine extra Testumgebung. In dieser wurden neue Windows Releases und Updates getestet. In dieser Testumgebung wurden alle definierten Tests auf Virtuellen Maschinen und einer Hardwareklasse getestet. Leider hatte ein anderes Hardwaremodel, das ca. 30% der Systeme in der Umgebung ausmachten, ein Problem mit dem Treiber. Dies führte zu Bluescreen in unregelmäßigen Abständen. Bonus Problem: Dies war das bevorzugte Hardwaremodell der VIPs.

Was war gut in diesem Fall?

  • Eigene Testumgebung und Pre-Produktion
  • Changemanagement nach ITIL
  • Definierte Testprotokolle

Was war suboptimal?

  • Zu wenige Hardwareplattformen
  • Kein sauberes Management von Treibern. Mein Tipp: Behandeln Sie Treiber wie normale Software, inkl. Release Management.

Lösungsansätze für einen Prozess

Im Grunde ist ein Windows as a Service Prozess genauso wie früher die Prozesse für Windows Updates und die Implementierung von einer neuen Windows Version samt der Migration dahin. Ich empfehle beide Themen in einzelnen Prozessen abzubilden: Normale Updates und Feature Upgrades, also neue Releases. Da meine Erfahrungen aus der Praxis die sind, dass die meisten Kunden die Update-Themen im Griff haben, möchte ich mich hier auf das Thema Feature Upgrade konzentrieren.

Ein klassischer Prozess dafür sah in der Vergangenheit zum Beispiel so aus:

Die eigentlichen Überschriften können auch für den neuen Prozess genutzt werden. Der Unterschied ist, dass der Prozess nach Vollendung direkt wieder startet, bzw. mit dem nächsten Windows Release. Das wäre aber ein sehr klassischer Ansatz. Dieser Ansatz wäre auch eher der Statische, und wird gerne von Firmen genutzt, die den alten Weg erstmal gehen wollen. Wie könnte so ein Prozess für WaaS aber auch aussehen? Hier mal eine alternative Version:

Dieser Prozess sieht schon etwas komplexer aus, ist er auch. Aber es ist nur ein Beispiel und je nach Umgebung ist auch dieser noch oberflächlich. Es könnte zum Beispiel noch Windows Analytics Upgrade Readiness als Auswahlkriterium für den Rollout integriert werden. Das bedeutet, nur Systeme, die nach Upgrade-Readiness bereit sind, werden umgestellt. Auch könnten noch weitere Prozessschritte wie Anwendungstests durch Anwendungsverantwortliche integriert werden.

Dieser Prozessentwurf berücksichtigt aber auch die neuen Ansätze wie Insider-Preview for Business, um die Implementierungsgeschwindigkeit zu verringern. Auch wird hier das von Microsoft empfohlene Ringmodell genutzt. Und bevor Fragen kommen, eine Detaillierte Prozessbeschreibung zum Kopieren veröffentliche ich hier bewusst nicht. Dieser Prozess ist ein Beispiel, keine Kopiervorlage.

Autor: Fabian Niesen

Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs. Hier schreibt er privat und unabhängig von seinem Arbeitgeber. Unter anderem ist er Zertifiziert als MCSA Windows Server 2008 / 2012, MCSA Office 365, MCSA Windows 10, MCSE Messaging, MCT und Novell Certified Linux Administrator. Seit 2016 ist er auch MCT Regional Lead für Deutschland. Seine Hobby’s sind Social Media, Bloggen, Mittelaltermärkte, Historische Lieder und der Hausbau. Zu finden ist er auch auf folgenden Plattformen: -

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Ich akzeptiere