Nachdem der Mainstream-Support für Windows Server 2003 bereits am 13. Juli 2010 abgelaufen ist, steht nun am 14. Juli 2015 das Ende der "Extended Support"-Phase bevor. Danach wird Microsoft weder Updates noch Hotfixes oder Security-Patches für die in die Jahre gekommene Serverplattform liefern. Dies betrifft sämtliche Editionen von Windows Server 2003, Windows Server 2003 R2 sowie den Microsoft Small Business Server (SBS) 2003 und ist unabhängig davon, ob das OS auf einem physischen Server oder in einer Virtual Machine (VM) läuft.
Den betroffenen Unternehmen und Organisationen beschert das Support-Ende das Risiko nicht mehr zu behebender Sicherheitslücken und damit eine beträchtliche Gefährdung ihres Compliance-Status. Deshalb führt für sie nun endgültig kein Weg mehr daran vorbei, sich vom vertrauten Windows Server 2003 zu verabschieden und die Aktualisierung der Serverlandschaft in Angriff zu nehmen, wie dies schon kürzlich auf der Client-Seite mit dem Support-Ende von Windows XP der Fall war.
Das Problem hat ein beachtliches Ausmaß: Laut Microsoft lief Windows Server 2003 im Sommer letzten Jahres noch auf 24 Millionen Maschinen, und selbst das US-amerikanische Computer Emergency Readiness Team (US-CERT) warnte vor dem Ablauf des Microsoft-Supports. Nach HP-internen Schätzungen sind nach wie vor noch über neun Millionen Maschinen mit der bewährten Serverplattform zu migrieren.
Heutzutage ist die IT gefordert, sich immer zeitnäher an den Anforderungen der Fachbereiche auszurichten - Stichwort "DevOps". Da mag sich manch ein Außenstehender wundern, dass so viele IT-Organisationen auf ein längst veraltetes Serverbetriebssystem setzen. Doch dies hat seine Gründe - auch jenseits der in IT-Abteilungen weit verbreiteten Ansicht, man solle ein einmal laufendes Serversystem besser nie mehr verändern ("Never touch a running system").
Ein Haupthindernis für das zügige Ausrangieren von Windows Server 2003 ist der beträchtliche Bestand an veralteten ("Legacy"-) Windows-Anwendungen, vor allem Applikationen, die noch für die 16-Bit-Prozessorarchitektur geschrieben wurden. Im Gegensatz zum aktuellen Windows Server 2012 mit 64-Bit-Architektur und dessen Vorläufer Windows Server 2008 (32- und 64-Bit) war Windows Server 2003 das letzte Microsoft-Betriebssystem, das neben 32-Bit- noch 16-Bit-Applikationen unterstützte. So sah sich manch ein Unternehmen, dessen geschäftskritische ERP-Anwendung auf der 16-Bit-Architektur basiert, praktisch gezwungen, bei Windows Server 2003 "stehenzubleiben" und diese Plattform bis zum Schluss auszureizen.
Es geht nicht nur um das Betriebssystem
Microsoft bietet auf seiner Website - neben einer Countdown-Uhr, die bis zum EoL (End of Life) von Windows Server 2003 herunterzählt - eine Fülle von Hilfestellungen, um Kunden zu unterstützen, von Windows Server 2003 auf Windows Server 2012 oder zur Cloud-Umgebung Azure zu wechseln. Doch das obige Beispiel zeigt: Beim "Lebensende" der alten Windows-Plattform geht es nur vordergründig um ein OS-Migrationsprojekt. Das Betriebssystem dient, wie der Name schon sagt, lediglich dem Betrieb von Applikationen - und viele Unternehmen schreckten vor allem davor zurück, das Problem einer überalterten Applikationslandschaft anzugehen.
So ist vielerorts ein regelrechter Innovationsstau entstanden. Dieser zwingt die betroffenen Unternehmen nun angesichts des EoL-Zeitdrucks zu schnellem Handeln, will man sich nicht Sicherheits- und Compliance-Risiken aussetzen. Großunternehmen wie auch der Mittelstand sehen sich unter Zugzwang, und je größer und heterogener die jeweiligen IT-Umgebungen, desto komplexer ist das inzwischen dringlich anstehende Projekt, die Anwendungslandschaft zu modernisieren.
Workarounds vs. Modernisierung
Den IT-Organisationen stehen angesichts dieser Situation mehrere Vorgehensweisen offen. Zunächst ist festzuhalten: Selbst nach dem Auslaufen des Extended Supports für Windows Server 2003 bietet Microsoft Unternehmenskunden mittels "Custom Support Agreements" die Möglichkeit, weiterhin Support für ihr Altbetriebssystem einzukaufen. Microsoft hat diese Option allerdings mit saftigen - und von Jahr zu Jahr steigenden - Preisen versehen, will man doch die Kunden für den aktuellen Windows Server 2012 und Azure begeistern. Von Interesse ist diese Option einer Support-Verlängerung damit praktisch nur für Unternehmen, die sich ein Zeitfenster erkaufen müssen, um die Neuentwicklung geschäftskritischer Legacy-Applikationen abzuschließen.
Mittels spezieller Tools von Drittherstellern besteht die Möglichkeit, 16-Bit-Applikationen auch auf Windows Server 2012 zum Laufen zu bringen. Eine Alternative besteht darin, problembehaftete Applikationen mittels Terminal-Services oder VDI (Virtual Desktop Infrastructure) zu kapseln und sie per Fernzugriff bereitzustellen. Auch solche Lösungen sind allerdings immer nur ein Workaround für problematische Legacy-Applikationen: Man muss sich hier bewusst sein, dass man sich auf ein Abstellgleis zubewegt und die notwendige Modernisierung lediglich mit teils beträchtlichem Aufwand verzögert. Solche Vorgehensweisen sind deshalb nur anzuraten, wenn ein konkreter Bedarf besteht, eine bestimmte Legacy-Anwendung noch für einen überschaubaren Zeitraum weiter zu betreiben; also beispielsweise wenn ein Service-Provider im Rahmen einer Back-to-Back-Vereinbarung mit einem Kunden verpflichtet ist, eine bestimmte Anwendung noch zwei Jahre zu unterstützen.
Von solchen Sonderfällen abgesehen sollten IT-Organisationen jedoch das Ende des Produktzyklus von Windows Server 2003 zum Anlass nehmen, den Fokus nicht allein auf der Server-OS zu richten, sondern vor allem die Aktualität und den Geschäftsnutzen ihrer Applikationslandschaft zu hinterfragen: Entsprechen die Anwendungen noch dem Stand der Technik? Bilden sie die Anforderungen der Fachabteilungen nach wie vor angemessen ab? Und bieten sie noch einen ausreichend hohen Return on Investment, selbst wenn nun eine Migration zu bewältigen ist?
Praxisbewährtes Vorgehensmodell
Auf der Basis der Erfahrungen mit zahlreichen Windows-Server-2003-Migrationen empfehlen HP und Microsoft zur Beantwortung dieser Fragen ein vierstufiges Best-Practice-Vorgehensmodell: "Discover, Assess, Target, Migrate" (also Inventarisierung, Bewertung, Zieldefinition, Migration). Im ersten Schritt sollte eine IT-Organisation stets mit einer umfassenden Inventarisierung seiner Anwendungsbestände beginnen - besteht doch häufig das Risiko, dass manch eine Altapplikation nicht im Asset-Managementsystem erfasst ist, sondern ihr Dasein lediglich einer Schatten-IT-Umgebung verdankt.
Im zweiten Schritt gilt es, den Applikationsbestand zu evaluieren und zu kategorisieren: Welche Anwendungen kann man problemlos auf eine aktuellere Basis hieven, welche nur mit Anpassungen, welche lassen sich gar nicht auf einen modernen Server migrieren?
Foto: HP
Neben der rein technischen Sichtweise gilt es hier aber vor allem, den Geschäftsbedarf hinter der jeweiligen Applikation zu ermitteln: Wer ist der Inhaber (Owner) der Applikation? Wie geschäftskritisch ist sie? In welchem Maß erfüllt die Anwendung noch die an sie gestellten Erwartungen? Die Kombination aus Technik- und Business-Betrachtungen kann hier sehr schnell ergeben, dass eine 1:1-Migration gar nicht wünschenswert ist: Hinterfragt man den Status quo, ergibt sich als Ziel statt einer Migration oft eine Konsolidierung, Aktualisierung oder Ablösung der Legacy-Applikation.
Nach dieser Evaluierung stellt sich in der dritten Phase die Frage der Zielarchitektur, um sich mit der Applikationslandschaft zu möglichst niedrigen Kosten zukunftssicher aufzustellen. Die Zielarchitektur kann der lokale Betrieb der Applikation(en) auf physischen oder virtualisierten Servern im eigenen Hause sein, aber auch die Nutzung in einer Hosted Private Cloud, die Ablösung einer Altanwendung durch eine Standardapplikation oder ein SaaS-Angebot (Software as a Service) - oder aber die Kombination verschiedener Cloud-Bausteine im Rahmen einer Hybrid Cloud. So könnte zum Beispiel eine lokal betriebene CAD-Anwendung (Computer-Aided Design) dank moderner Virtualisierungstechnik (VDI) auch in einer extern gehosteten Private Cloud laufen und den Nutzern künftig ortsunabhängig per Fernzugriff zur Verfügung stehen.
Hier gilt es also, den aktuellen und den geplanten Betriebsmodus der Anwendungen abzugleichen und gegebenenfalls eine Transformation der Applikationslandschaft einzuleiten. Zur Ermittlung der Ziele empfiehlt es sich, Workshops abzuhalten, die neben dem IT-Personal auch die Business-Verantwortlichen mit einbeziehen. Gemeinsam lassen sich dann die Ziele definieren, die gewünschten Benefits herausarbeiten und ein Phasenmodell für die Transformation ableiten.
Erfahrungsgemäß sind in einer größeren IT-Umgebung für solch ein Projekt mehrere Monate nötig - auch vor dem Hintergrund, dass das Support-Ende von Windows Server 2003 immer näher rückt. Deshalb empfiehlt sich für die Phase vier - die eigentliche Migration - eine Best-Practice-basierte Umsetzung, um die Migration und/oder Transformation der Anwendungslandschaft zügig und möglichst reibungsarm zu bewältigen.
Best-Practice-basierte Umsetzung
Die Durchführung einer Anwendungstransformation erfordert in der Regel die Einteilung eines Projekts in mehrere parallel ablaufende Projekt-Streams mit jeweils eigenem Stream-Management und einem übergreifenden Projektmanagement. Die Streams konzentrieren sich dabei auf individuelle Anwendungen mit jeweils unterschiedlicher Komplexität sowie Kritikalität für das Kerngeschäft.
Die in Phase zwei ermittelte Kritikalität einer Anwendung für den Geschäftsbetrieb gibt vor, wie hoch priorisiert die Migration oder Transformation zu erfolgen hat. Im einfacheren Fall handelt es sich um Standardapplikationen wie Microsoft Exchange. Die Standardapplikationen machen erfahrungsgemäß zirka 70 Prozent eines Transformationsprojekts aus. Für die Migration solcher Standardanwendungen bestehen bewährte Best Practices. Experten können die jeweilige Applikation damit parallel zu den übrigen Projekt-Streams auf bewährte Weise aktualisieren.
Die restlichen 30 Prozent der Anwendungen verursachen in der Praxis meist 80 Prozent der Migrationsarbeit. Denn für individuell entwickelte Anwendungen wie veraltete ERP- und CRM-Systeme sind zunächst Interviews mit den Fachbereichen und meist auch eine deutlich umfassendere Zieldefinition erforderlich als für das Gros der Standardanwendungen.
Von enormer Bedeutung für das Gelingen des Projekts ist das Stream-übergreifende Projektmanagement. Denn die Custom- und Legacy-Anwendungen sind meist tief mit Standardanwendungen verzahnt. Ein CRM-System zum Beispiel ist in aller Regel in die E-Mail- und Office-Umgebung integriert. Hier muss das Projektteam wissen, welche Add-ins im Betrieb sind und wie diese mit dem CRM-System interagieren. Die reine Office-Migration ist hier relativ einfach, aber die Interaktion zwischen Office- und CRM-Lösung mittels Add-ins will gründlich auf Verträglichkeit und Anpassungen hin getestet sein. Das Projektteam muss hier also sicherstellen, dass einem Bestandssystem nicht durch die Aktualisierung von Standardanwendungen plötzlich wichtige Bausteine wegbrechen - oder umgekehrt.
Ähnlich verhält es sich mit der Aktualisierung der verwendeten Datenbank: Legacy-Applikationen greifen in aller Regel auch auf antiquierte Datenbanksysteme zu. Je älter diese sind, desto schwieriger gestaltet sich die Migration. So ist bei Microsofts SQL Server der Wechsel von einer Version zur Folgeversion relativ leicht zu bewältigen, der Sprung von SQL Server 2000 zu SQL Server 2012R2 hingegen sehr komplex. Hier gilt es, die Wechselwirkungen zwischen den Projekt-Streams mit wachsamem Auge zu beobachten, um die Datenkonsistenz nicht zu gefährden.
Die Umstellung als Chance nutzen
"Der Support für Windows Server 2003 endet am 14.7.2015": Was nach Bedarf an einer reinen Betriebssystemaktualisierung klingt, erweist sich bei näherem Hinsehen häufig als viel umfassenderes Problem, nämlich das eines überalterten Applikationsbestands. IT-Organisationen sollten die von Microsoft vorgegebene Zäsur deshalb dazu nutzen, die auf den Legacy-Windows-Servern laufenden Anwendungen mit den Anforderungen des modernen Geschäftsbetriebs abzugleichen.
Um den Transformationsbedarf zu ermitteln, gilt es, neben der IT- vor allem die Business-Sicht zu berücksichtigen. Deshalb sollte die IT die Verantwortlichen aus den Fachbereichen und wenn möglich auch die Geschäftsleitung in die anstehenden Diskussionen einbeziehen. Denn dass es hier nicht nur um den Austausch des Serverbetriebssystems geht, will angemessen vermittelt sein.
IT-Leiter haben somit durch das Ende von Windows Server 2003 die Chance, sich über die reine Bereitstellung von IT-Services hinaus als strategischer Partner der Fachabteilungen zu erweisen, der hilft, die Geschäftsprozesse durch die Transformation kritischer Applikationen zukunftsfähig aufzustellen - sei es durch Aktualisierung, Virtualisierung, den Wechsel von einer Custom- auf eine Standardanwendung oder die Verlagerung der Workloads in eine Private, Hybrid oder Public Cloud.
Und ganz nebenbei sollten die IT-Leiter dieses Transformationsprojekt auch dazu nutzen, effiziente Release-Managementprozesse zu etablieren. Denn im Jahr 2020 droht bereits das Extended-Support-Ende von Windows Server 2008 - und Microsoft wird seine Betriebssysteme künftig sicher mit höherer Schlagzahl auf den Markt bringen als früher. Auch dafür gilt es, gerüstet zu sein. (mje)