Betriebssystem-Umstellung leicht gemacht! So vermeiden Sie Fehler bei der Migration von XP auf Windows 7

Autor / Redakteur: Sebastian Weber / Dipl.-Ing. (FH) Andreas Donner

Der Startschuss für die Migration von Arbeitsplatzrechnern von XP auf 7 ist in vielen Unternehmen spätestens mit dem Service Pack 1 für Windows 7 gefallen. Doch ein Migrationsprojekt birgt neben vielen organisatorischen Herausforderungen auch einige technische Stolpersteine. Wir zeigen, welche!

Firmen zum Thema

Eine Migration von Windows XP auf Windows 7 birgt viele Stolperfallen
Eine Migration von Windows XP auf Windows 7 birgt viele Stolperfallen

Dieser Beitrag greift auf die Erfahrungen aus zahlreichen erfolgreich durchgeführten Migrationsprojekten zurück und zeigt einige der größten Fehler auf, die es auf dem Weg zu Windows 7 zu vermeiden gilt.

Die erste Entscheidung eines Unternehmens bei einem Migrationsprojekts ist vermutlich, auf welche Variante von Windows 7 überhaupt migriert werden soll. Für Unternehmen kommen von den sechs Editionen hier eigentlich nur die Professional- oder Enterprise-Variante in Frage, wobei letztere funktional mehr oder weniger der Ultimate-Edition entspricht. Bei der Auswahl der passenden Edition kommt es letztlich darauf an, ob die Zusatzfunktionen der größeren Version benötigt werden und somit den Mehrpreis rechtfertigen.

Bildergalerie

Variante: 32 oder 64 Bit?

Schon etwas schwieriger ist die Entscheidung zwischen der 32- und 64-Bit-Variante. Denn hier kommt es sehr darauf an, was die im Unternehmen eingesetzte Hardware sowie die Anwendungen unterstützen. Gibt es für wichtige Hardware keine 64-Bit-Treiber oder laufen bestimmte Anwendungen nicht unter Windows 7 64-Bit, ist dies beispielsweise ein guter Grund für die 32-Bit-Version.

Andererseits hat die 64-Bit-Version in bestimmten Bereichen auch enorme Vorteile. In einem Migrationsprojekt, das Aagon Consulting bei einem Zulieferer der Automobilindustrie begleitete, dauerte beispielsweise die Berechnung eines Autoteils in Autocad LT unter Windows XP rund zwei Tage. Auf identischer Hardware benötigte dieselbe Kalkulation unter Windows 7 und der 64-Bit-Version von Autocad LT lediglich 25 Sekunden.

Mit Ausnahme von Spezialanwendungen gilt heute die Faustformel: Wer mehr als vier GByte Arbeitsspeicher benötigt oder in den nächsten Jahren benötigen wird, sollte sich die 64-Bit-Version näher ansehen und seine Anwendungen darunter genau testen. Für alle anderen sollte die 32-Bit-Version ausreichen.

Alternativ ist auch ein paralleler Betrieb beider Versionen möglich und denkbar. Jedoch sollte man dabei nicht vergessen, dass dies den nachfolgenden Aministrationsaufwand deutlich erhöht. Denn dann muss die IT unter anderem zwei Betriebssysteme unterstützen, Applikationen für die Softwareverteilung doppelt paketieren und auch den Helpdesk für entsprechende Anfragen ausrüsten.

Parallel-Migration auf Office 2010

Manche Unternehmen nutzen die Migration auf Windows 7 gleich dazu, auch ihr Microsoft Office flächendeckend auf die aktuelle Version 2010 zu bringen. Hier fällt die Entscheidung zwischen 32- und 64-Bit heute noch leicht. Denn selbst Microsoft empfiehlt über entsprechende Warnmeldungen bei der Installation mehr oder weniger direkt, Office 2010 64-Bit nicht zu benutzen.

Ein Grund sind wohl massive Probleme bei der Kompatibilität von Makros. Doch selbst wer keine Makros einsetzt, sollte noch die Finger vom 64-bittigen Office 2010 lassen, wenn Outlook zum Einsatz kommt. Denn Stand heute gibt es große Inkompatibilitäten bei der Synchronisation zwischen Outlook 2010 64-Bit und Mobiltelefonen, und sogar Microsofts eigene CRM-Software verweigert zur Zeit noch die Zusammenarbeit mit dem neuen Personal Information Manager aus dem selben Haus.

User Account Control

Unternehmen haben an Windows XP unter anderem so lange festgehalten, weil die neuen Sicherheitsfunktionen von Windows Vista ihre Benutzer mit vielen und vor allem lästigen Rückfragen verunsichert hätten. "Schuld" daran war die so genannte User Account Control (UAC), die eigentlich Spyware und Trojanern statt Anwendern das Leben erschweren sollte.

Die im deutschen "Benutzerkontensteuerung" genannte UAC gibt es in etwas entschärfter Form weiterhin unter Windows 7. Deshalb sollten sich Administratoren vor ihrem Migrationsprojekt genau überlegen, wie sie die UAC auf den Rechnern ihrer Kollegen voreinstellen. Eine generelle Empfehlung kann man nur dahingehend aussprechen, die UAC nicht komplett auszuschalten. Alle weiteren Einstellungen sind eine sehr individuelle Balance zwischen Komfort und Sicherheit.

Daher ist es wichtig, diese Entscheidung vor der Migration mit ausgewählten Benutzern, den IT-Verantwortlichen und der Geschäftsleitung gemeinsam zu diskutieren. Denn keinem Unternehmen ist mit einem objektiv besseren Betriebssystem geholfen, wenn die Benutzer es ablehnen, weil die UAC zu aufdringlich ist.

Server- und Domänencontroller-Migration

Im Zusammenspiel mit dem Windows Server 2008 lassen sich unter Windows 7 mit Hilfe der Gruppenrichtlinien wesentlich mehr Einstellungen vornehmen, als dies noch unter der Kombination Windows Server 2003 und XP der Fall war. Dies bedeutet jedoch auch, dass man sinnvollerweise vor dem Migrationsprojekt "XP auf 7" zumindest seine Domänencontroller vom Windows Server 2003 auf den Server 2008 migriert haben sollte.

Erlaubt man dann per Group Policy Object (GPO) seinen Benutzern nur die Installation von ganz bestimmten Anwendungen, kann man gegebenenfalls die UAC etwas weiter öffnen und so weniger Rückfragen provozieren. Alternativ lässt sich die Installation von Applikationen grundsätzlich verbieten, wenn die Installation von Software auf den Arbeitsplätzen der Benutzer über ein Clientmanagement-System (CMS) erfolgt. Doch Vorsicht: Arbeitet der Agent des CMS nicht unter dem System-Account, sondern unter einem eigens dafür anzulegenden Benutzerkonto, ist nicht nur der administrative Aufwand deutlich größer. Auch die UAC kann dann bei Installationen wieder tätig werden.

weiter mit: Problempunkte lokale Daten und lokale Benutzereinstellungen

Problempunkt lokale Daten

Ein sehr wichtiger Punkt bei der Migration der Betriebssysteme von PC-Arbeitsplätzen ist der Umgang mit lokal gespeicherten Daten. Denn gibt es auf den Rechnern von den Anwendern selbst abgelegte Daten, müssen diese unter Umständen ebenfalls migriert werden, denn selbst wenn die Speicherung von Daten auf der C-Platte im Unternehmen untersagt ist, werden sich mit Sicherheit nicht alle Benutzer daran halten.

Den Verlust einer unerlaubten privaten MP3-Sammlung wird der betroffene Anwender dann wahrscheinlich noch zähneknirschend hinnehmen. Doch wenn Mitarbeiter aus der Geschäftsleitungsebene sich über die von ihnen selbst aufgestellte Richtlinie hinweggesetzt haben, kann es für den Administrator schnell ungemütlich werden, wenn dessen Daten nach der Migration plötzlich verschwunden sind.

Relativ einfach ist die Sicherung lokaler Daten, wenn im Zuge der Migration gleichzeitig die Hardware ausgewechselt wird. In diesem Fall bleiben die ausgemusterten PCs mit Inventarnummern versehen einfach ein paar Monate im Lager stehen, bevor sie fachgerecht entsorgt werden. Wird jedoch das Betriebssystem bestehender Rechner migriert, ist es etwas schwieriger.

Der Königsweg ist natürlich die Sicherung aller lokalen Daten vor der Migration ins Netz, was auch ein adäquater Fallback-Plan wäre. Doch bei 500 Rechnern mit lokal bis zu mehreren 100 Gigabyte an Daten, kann dies sowohl das lokale Netzwerk als auch die Speichersysteme für die Datensicherung an ihre Belastungsgrenzen bringen.

Wenn weder die eine noch die andere Variante möglich und die im Unternehmen vorhandene Hardware relativ homogen ist, gibt es noch einen Trick aus der Praxis: Da es sich sowieso empfiehlt, nicht das gesamte Unternehmen auf einmal, sondern besser Abteilung für Abteilung zu migrieren, stattet man die erste zu migrierende Abteilung mit neuer Hardware aus. Deren alten Rechner bleiben dann einige Zeit als Backup stehen, bevor sie auf Windows 7 umgestellt und der nächsten Abteilung übergeben werden. Deren alte Rechner werden dann wieder einige Zeit vorgehalten, bis die nächste Abteilung an der Reihe ist, und so weiter.

Lokale Benutzereinstellungen

Neben lokalen Daten möchten Benutzer natürlich auch ihre Einstellungen unter dem neuen Betriebssystem wiederfinden. Da die Migration von XP auf Windows 7 eine Neuinstallation des Betriebssystems voraussetzt und Windows 7 eine veränderte Verzeichnisstruktur aufweist, sollte hier am besten ein entsprechendes Werkzeug mit grafischer Benutzeroberfläche zu Hilfe genommen werden.

Ein Tipp: Grundsätzlich sollten die Einträge im Startmenü sowie Verknüpfungen auf dem Desktop nicht migriert werden. Andernfalls wären diese Einträge auf dem Zielrechner doppelt vorhanden und die Hälfte würde nicht funktionieren. Zudem sollte die Migration der Benutzereinstellungen ausgiebig getestet werden – am besten mit mehreren Benutzern mit einer sehr komplexen Umgebungen und vielen lokalen Daten.

Die Wiederherstellung der Einstellungen kann im Testlauf dabei ohne weiteres in einer virtuellen Maschine erfolgen. Dort dürfen die auserwählten Tester dann prüfen, ob alles Wichtige mitgekommen ist.

Ähnliches gilt für die Migration von Roaming Profiles, da sich auch dort hinterlegte Pfade schwer verändern lassen. Einfacher ist es, das alte Profil zu sichern und es anschließend neu anzulegen. Dabei gilt es jedoch zu bedenken, dass in den Profilen auch viele große Dateien beispielsweise vom Desktop des Benutzers enthalten sein können. Ein Weg, diese Migrationslast zu verringern ist, die Benutzer zu Löschung aller unnötigen Daten auf ihren Desktops aufzufordern. Dabei sollten die Benutzer an die Administration zudem Vollzug melden, um zu verhindern, die Desktops von länger abwesenden Kollegen dabei zu übersehen.

Anwendungen testen

Einer der wichtigsten Punkte der Migrationsvorbereitung ist die Inventarisierung aller im Unternehmen vorhandener Anwendungen. Darauf folgt die Entscheidung, welche davon zukünftig noch benötigt werden und der Test, ob sie unter dem neuen Betriebssystem überhaupt korrekt arbeiten.

Diese Überlegungen bergen viel Arbeit, aber auch Chancen. So lässt sich beispielsweise die Flut an unterschiedlichen Adobe-Reader-Versionen im Unternehmen eindämmen, indem nach der Migration nur der aktuelle Reader installiert wird. Schaltet man dann dessen Update-Mechanismus aus und aktualisiert ihn zukünftig zentral über die Softwareverteilung des Clientmanagement-Systems, so hat zumindest hier Wildwuchs auch weiterhin keine Chance.

Wichtig ist bei den Tests zudem, dass nicht nur Administratoren, sondern auch ausgewählte Endanwender die Kompatibilität ihre Applikationen zu Windows 7 testen. Denn manche Anwendungen lassen sich zwar problemlos installieren, bestimmte Features verweigern jedoch bei genaueren Untersuchungen ihren Dienst. Müssen Anwendungen auf eine neuere Version aktualisiert werden, um Windows-7-kompatibel zu sein, kann dies weitere unvorhergesehene Kosten bedeuten.

Erfordert die neue Version einer kritischen Applikation dann noch Veränderungen im Backend, kann es schnell richtig teuer werden. Daher ist diese Testphase immens wichtig, um überhaupt die Kosten einer Migration abschätzen zu können. Ein guter Ansatzpunkt für den Test von Anwendungskompatibilität ist bspw. das kostenlose MS Application Compatibility Toolkit 5.5 (ACT). Besser ist jedoch der Live-Test mit realen Daten und echten Benutzern.

Projektablauf standardisieren

Theoretisch ist es möglich, eine Windows-7-Migration allein mit kostenlosen Bordmitteln von Microsoft durchzuführen. In der Praxis werden das jedoch nur die Unternehmen tun, die zu viele Administratoren mit zu wenig Arbeit beschäftigen.

Viel Zeit und Kosten spart bei der Migration ein Clientmanagement-System, da es den Aufwand für die Bestandsaufnahme von Hard- und Software sowie für die Neuinstallation von Betriebssystem und Anwendungen gering hält. Viele Systeme werden allein dadurch die eigenen Kosten mehr als amortisieren.

Voraussetzung hierfür ist natürlich, dass ein vorhandenes CMS selbst Windows-7-kompatibel ist. Ist es das nicht, könnte dies ein guter Zeitpunkt für einen Wechsel der Clientmanagement-Plattform sein. Im Idealfall hat der Hersteller des CMS selbst umfangreiche Erfahrung bei Migrationsprojekten gesammelt.

Den meisten Unternehmen ist es dringend anzuraten, sich professionelle Unterstützung bei der Planung und Durchführung von großen Migrationsprojekten ins Haus zu holen. Denn nur ein standardisierter und praxisbewährter Projektablaufplan ermöglicht es, ein großes Migrationsprojekt im vorgesehenen Umfang, Zeitrahmen und Budget durchzuführen.

Wer beispielsweise eine Aufwandsabschätzung ohne eine detaillierte Bestandsaufnahme vornimmt, wird in den allermeisten Fällen bitter enttäuscht. Um ihren Kunden bei solchen Projekten Kosten zu sparen, haben einige flexible Dienstleister in ihrem Projektplan so genannte Abbruchpunkte definiert, ab denen der Kunde das Projekt selbst zu Ende führen kann – wenn er es denn möchte.

Über den Autor

Sebastian Weber ist Produktmanager ACMP bei Aagon Consulting.

(ID:33357890)