Windows 10 - In-Place-Upgrade

In meinem letzten Blogeintrag hatte ich bereits die Deploymentmöglichkeiten vorgestellt. In diesem werde ich das In-Place-Upgrade näher betrachten. Noch einmal kurz zur Erinnerung. Ein In-Place-Upgarde arbeitet vom Prinzip her wie das Wipe-and-Load, jedoch übernimmt Windows die ganze Arbeit.

Windows sammelt in diesem Zusammenhang selbst alle Daten, Einstellungen, Treiber und Anwendungen, installiert das Betriebssystem und spielt zuvor gesammelten Daten wieder auf das neue Betriebssystem ein. Auch Überprüfungen am System wie Kompatibilitätschecks werden automatisch durchgeführt.

In-Place-Upgrade

Als Image sollte das Standard Windows 10 Image verwenden werden, ohne Apps. Apps und Treiber werden von dem bestehenden Betriebssystem automatisch bezogen. Verwendet man beispielsweise auf dem alten Betriebssystem Office 2007 und hat in das neue Betriebssystem Office 2013 integriert, werden beide Anwendungen auf das neue Betriebssystem gelegt und es kommt zu Konflikten. Diese Problematik bezieht sich auf Apps. Treiber können ruhig auf dem Image vorhanden sein.

Es ist nicht ganz wie eine neue Installation. Manche unnötige Sachen werden einfach mit migriert weil sie für wichtig erachtet werden. Das ist eine der Gründe warum ein In-Place-Upgrade mehr Platz einnimmt. Ein weiterer wäre die integrierte Recovery-Funktion, dazu jedoch später mehr.

Es gibt mehrere Möglichkeiten ein In-Place Upgrade anzugehen, abhängig davon welche Tools uns zur Verfügung stehen. Windows 10 kann beispielsweise über das Software Center des System Center Configuration Managers verteilt werden. Das Verteilen und Verwalten von Windows 10 wird mit einem Service Pack Update ab SCCM 2012 unterstützt werden. System Center Configuration Manager 2007 unterstützt nicht mehr das Deployment für Windows 10, lediglich das Management.

In-Place-Upgarde über SCCM

Die Bereitstellung von Windows 10 kann über das Software Center des SCCM erfolgen, durch eine gewöhnliche Task Sequence. D.h. ich öffne meinen Configuration Manager, begebe mich in die Software Library, erstelle eine Task Sequence und stelle diese meinen Clients bereit.

Von dem Client finde ich nun im Software Center unter Available Software meine erstellte Task Sequence, die ich ausführen kann. Da es sich bei dieser Sequence um ein Betriebssystem handelt, wird mir vor Ausführung noch eine Warnmeldung ausgegeben, dass ich dabei bin ein neues Betriebssystem zu installieren. Nach Bestätigung dieser lädt der Client das Betriebssystem herunter und führt im Anschluss das Setup aus. Im Gegensatz zur manuellen Installation bekomme ich von den Prozessen, die im Hintergrund laufen nichts mit.

Falls der Betriebssysteminstallation nichts entgegensteht, sollte es noch einiger Zeit installiert worden sein.

Prinzipiell besteht beim In-Place Upgrade die Möglichkeit:

keine Daten, Anwendungen und Einstellungen zu migrieren
lediglich meine Dateien zu migrieren
alle Daten, Anwendungen und Einstellungen zu migrieren.

Der Vorteil bei SCCM liegt in der zentralisierten Bereitstellung, sowie der Überwachungsfunktion. Sollte eine Installation fehlschlagen, würde dies dem Configuration Manager direkt gemeldet werden. Man erhält Kontrolle über den gesamten Prozess.

In-Place-Upgrade über .MDT

Über das Microsoft Deployment Toolkit funktioniert der Vorgang ähnlich. Es wird wieder eine Task Sequence für Windows 10 Upgrade erstellt. Doch dieses Mal wird, wie in MDT üblich, das Betriebssystem auf einem Network Share abgelegt über welches der User das Upgrade später dann bezieht.

Doch was passiert während des Installationsprozesses?

Upgradephasen

Das In-Place-Upgrade besteht aus 4 Phasen. Der Down-Level Phase, der Windows Recovery Environment (WinRE) Phase, der ersten Boot- und der zweiten Bootphase. Und mit dem neuen In-Place Upgrade habe ich in jeder Upgradephase die Möglichkeit wieder auf mein altes Windows Betriebssystem zurückzukehren.

Schauen wir uns an was genau in den einzelnen Phasen passiert.

Down-Level-Phase

In der Down-Level-Phase werden Informationen über das bestehende System gesammelt und auf die Kompatibilität mit Windows 10 überprüft, um die Voraussetzung für die nächsten Phase zu erfüllen. D.h. ich möchte erst einmal wissen ob mein System überhaupt für Windows 10 geeignet ist und zusätzlich, ob meine Software, Einstellungen und Anwendungen in das neue Betriebssystem mit übernommen werden können.

Im ersten Schritt wird eine Hardware- und Softwareinventory durchgeführt. Sobald wir wissen welche Hard- und Software wir verwenden, wird ein Kompatibilitätscheck durchgeführt. Dafür werden die gesammelten Inventory-Informationen mit einer Compability Database abgeglichen. Diese ist lokal auf dem Installationsmedium verfügbar und wird stetig von Microsoft erweitert.

Sobald wir mit diesen Schritten fertig sind, haben wir eine komplette Übersicht über das System und können in den nächsten Schritt übergehen.

Beispiele für Systemchecks sind z.b:

CPUchecks – Um sicherzustellen, dass Windows 10 stabil läuft
RAMchecks – Sollte mind 1GB RAM für 32bit und 2GB RAM für 64-bit Version zur Verfügung stehen
Ausreichend Festplattenspeicher vorhanden? Wird nicht nur für das neue Betriebssystem benötigt, sondern auch um das Alte ablegen zu können und im Zweifelsfall wieder auf das alte Betriebssystem wechseln zu können.
Kritische Treiber: Kann z.B. der Netzwerktreiber aktualisiert werden? Wenn nicht soll gar nicht erst migriert werden, da solch ein Treiber als besonders wichtig eingestuft wird.
Treiberinventarisierung: Können alle Treiber auf Windows 10 aktualisiert werden?

Doch ab welchem Punkt haben wir die Möglichkeit in die nächste Phase überzugehen? Müssen dafür überhaupt alle Checks positiv sein oder habe ich trotzdem die Möglichkeit auf Windows 10 upzugraden?

Die Möglichkeiten zum weiteren Vorgehen wären zu migrieren, nicht zu migrieren, die Migration zu blocken oder den User die Entscheidung zu überlassen.

Entscheidungsweg

Gernerell wird erst einmal versucht alle Treiber zu migrieren. Lediglich inkompatible Treiber oder betriebssystemspezifische Treiber, die zum alten Betriebssystem gehören werden nicht mit migriert, sind aber im Falle eines Recoverys im alten System verfügbar. Das Upgrade wird erst dann geblockt, wenn kritische Treiber betroffen sind, also das System nicht ordnungsgemäß laufen würde.

Fehlerhafte Anwendungen stoppen den Upgradevorgang prinzipiell erstmal nicht. Anwendungen, die Schaden am System verursachen würden, werden einfach nicht mit migriert.

Windows Recovery Environment

WinRE ist der zweite Upgradeschritt. Die Windows Recorvery Environment kann als ein minimalistisches Betriebssystem gesehen werden. In dieser Phase werden beide Betriebssystem offline geschalten. Ich habe also nun Zeit, um mein altes Betriebssystem in Windows.old abzulegen und mir dadurch meinen Weg zurück zu meinem alten Betriebssystem zu sichern. Gleichzeitig kann ich mein neues Betriebssystem startbereit machen für die nächste Phase, die 1st boot Phase.

Dafür wird das neue Betriebssystem auf der Disk abgelegt, die Treiber in den Treiber Store gelegt und andere Offline Migrationsaufgaben durchgeführt.

1st boot

Wir haben in den vorangegangen Schritten alles soweit vorbereitet um dem Betriebssystem nun Leben einzuhauchen. Das Betriebssystem wird jetzt in die Maschine eingebunden, Treiber, die wir zuvor abgelegt haben werden installiert. Meine Anwendungen, die ich in den ersten Schritten inventarisiert und für migrationsfähig befunden habe, werden nun, genauso wie Apps und andere Sachen, migriert. All die vorangegangenen Schritte waren also notwendig um mir eine Karte oder einen Bauplan für die Migration zu erstellen.

2nd boot

In der zweiten Bootphase wird ein finaler Bootvorgang gestartet, um das Upgrade erfolgreich zu beenden. Der Benutzer wird in das neue Betriebssystem eingefügt und führen ihn zur Out-of-the-box-experience (OOBE).

Recovery und Roll-back

Von jeder der eben beschrieben Phasen aus wird ein Recovery und Roll-Back möglich sein, sobald etwas schief läuft oder der User sich spontan entscheidet doch nicht migrieren zu wollen, weil man z.b. das Design nicht mag oder bestimmte Programme nicht laufen. Das Ganze geschieht automatisch. Falls also irgendetwas schief läuft hat man im schlimmsten Fall ein bisschen Zeit verschwendet und ist wieder auf dem Stand des alten Betriebssystems. Aber es muss nicht ein Techniker dran der sich das Problem anschaut, weil kein Betriebssystem drauf ist und nicht mehr gebootet werden kann oder Ähnliches.

In manchen Fällen kommt es vor, dass das Windows 10 Upgrade fehlschlägt. Wie bereits erwähnt, kann in jeder der Upgradephasen auf das alte System migriert werden Dann sollte man das Roll-Back abwarten und eine Problembehandlung über die Eventlogs vornehmen. Vielleicht gab es auch einfach nur Verbindungsprobleme zu einem Share auf dem das Betriebssystem lag und nach erneutem Installationsversuch kann der Vorgang erfolgreich abgeschlossen werden. Solche Dinge können dem Eventlog entnommen werden.

Egal ob mit Win 7 , 8 oder 8.1. Zusätzlich soll die Recovery und Roll-Back-Funktion ca. 1 Monat verfügbar bleiben. So hat man genügend Zeit das Betriebssystem zu testen und sich dafür oder dagegen zu entscheiden. Je älter natürlich das Betriebssystem wird umso mehr Änderungen wurden vermutlich auf dem System ausgeführt und der Recoveryvorgang wird zunehmend komplexer. Deswegen möchte man sich hier auf eine bestimmte Dauer beschränken.

Zum Thema Windows 10 Deployment gibt es in der Microsoft Virtual Academy den Kurs Einführung in Windows 10 Deployment.

Das zweite Modul geht unter anderem auf das Thema In-Place Upgrade ein:

Das war es auch schon vom In-Place-Upgarde. Im nächsten Teil erkläre ich näheres zum Provisioning.

Dieser Blogeintrag ist der Teil der Windows 10 Deployment Serie:
Windows 10 - Deploymentmethoden
Windows 10 - In-Place-Upgrade
Windows 10 - Provisioning

UNSERE NÄCHSTEN SCHULUNGEN

DeploymentIris Gerlach23. Juli 2015Deployment, In-Place Upgrade, Revocery, Roll-back, Windows 10