Einige interessierte Leser und Personen aus dem Projekt wo ich mich gerade verdinge haben mich gefragt, wie man es am besten angeht einen Hardware Zoo aus zig verschiedenen Client Servern, Desktops und Notebook Systemen beim Deployment mit den richtigen Treibern zu betanken.
Auch das 32/64bit Treiber Deployment läßt sich so sehr gut steuern.

Hier bietet uns der MDT2010 sehr effiziente Möglichkeiten. Ich bin zur Zeit in einem Projekt tätig indem ich ein Deployment Share übernommen habe, es aber einiges gibt was man daran verbessern kann.

In der Deployment Workbench betrachten wir dazu den Ordner “out-of-the-box Drivers“, hier werden alle Treiber die für ein Deployment benötigt werden abgelegt, so dass der MDT2010 eine zentrale Stelle hat aus der er sich mit Treibern bedienen kann.

Was viele falsch machen ist, dass sie einfach ALLE Treiber in diesen Ordner importieren (wie auf dem Bild zu sehen ist). Das gute Feature im MDT2010 ist aber das man einen Ordner für jedes Gerät anlegen kann und in diesen die Treiber importieren kann.

Den Ordner benennt man zweckmäßigerweise nach dem Gerät und es ist auch sinnvoll die release Nummer des Treiber Paketes anzugeben (ist bei Dell Geräten die “R” Nummer).

Wenn der Ordner angelegt ist, können wir mit dem Treiber Import anfangen, dazu einfach rechtsklick auf den Ordner und dann die Option “Import Drivers” wählen.
Wichtig ist das NICHT der Ordner out-of-the-box Drivers für den Import angeklickt wird, sonst landen die Treiber im Stammverzeichnis des Ordner “out-of-the-box Drivers” und genau das wollen wir ja nicht.

Jetzt wählen wir unser Dell Lattitude 5410 Treiberpaket aus, welches wir entpackt haben. Sollten wir das Treiberpacket als *.cab Datei bekommen können wir uns das entpacken komplett sparen, da der MDT 2010  das komplett für uns übernimmt .
Wichtig ist immer nur das man die Dateien die man importieren will in einem extra Ordner hat, weil sonst eventuell andere Treiber noch mit übernommen werden.

Der Import der Treiber läuft nach dem bekannten MDT 2010 Schema ab

der nächste Schritt kann etwas dauern….an dieser Stelle nicht ungeduldig werden!

Wenn alles importiert ist, sieht es so fertig im MDT 2010 aus

Jetzt gilt es nur noch das importierte Treiber Paket irgendwie auf die zu installierenden PC’s zu bekommen.

Dazu müssen wir die Task Sequences entsprechend anpassen, damit nicht wie per default alle Treiber im Ordner installiert werden sondern nur die, die wir für das spezielle Gerät benötigen.

Wenn wir das soweit alles durchgeführt haben steht einer Geräte spezifischen Installation nichts mehr im Wege

Wir haben ja im Deployment Share die Möglichkeit direkt bei der Installation die aktuellen security patches und hotfixes mit in unsere Installation einfließen zu lassen. Das ist in IT Umgebungen jeder Größe sehr sinvoll, in großen Umgebungen schonen wir beim rollout den WSUS Server; ich habe es schon sehr oft gesehen das Kunden und deren IT beim rollout vergessen haben dem WSUS Server mehr Ressourcen zuzuweisen um dem Anfrage Bombardement stand zu halten.
Für kleinere IT Landschaften eignet sich unser hotfix Deployment genauso, wird hier doch meist kein WSUS eingesetzt und alle PCs ziehen sich ihre Updates über das Internet.
So ist gewährleistet das ALLE PCs nach dem rollout den selben Patchstand haben.

Wir benötigen hier zu ein Tool das sich “WSUS offline” nennt, es ist als freeware hier erhältlich.

Nachdem runter laden brauchen wir das Tool einfach nur zu entpacken, was es auch sehr gut portable auf einem USB Stick macht und auf unserem Deployment Server auch nicht installiert werden muss.

Wenn wir die UpdateGenerator.exe starten sieht das ganze so aus wenn wir die updates für Windows 7×64 runterladen und in einem gesonderten Verzeichnis ablegen wollen

Wir haben dann noch die Möglichkeit alle hotfixes und patches für Microsoft Office bis zur Version 2007 in diversen Sprachen herunterzuladen

Wenn wir alles was wir benötigen angeklickt haben, klicken wir einfach auf “START” und das Helferlein beginnt alle updates in den von uns vorgegebenen Ordner zu kopieren, wenn er fertig ist sieht das dann im Ordner w61-x64glb so aus

Da mein Deployment MDT 2010 Server in einer QS Domäne ohne verbindung zum Internet hängt, kopiere ich mir alle hotfix Files auf meinen USB Stick.

Jetzt importieren wir die ganzen Patches in den MDT 2010…..wie immer im guten MDT2010 sehr easy zu handhaben

Import beendet und so sieht es dann im MDT2010 aus wenn alles geklappt hat

Sollte ein Patch schon vorhanden sein, wird er nicht erneut installiert.

Nur steht alles bereit um alle Microsoft Sicherheitsupdates und Hotfixes ohne WSUS mit dem MDT 2010 zu verteilen.

Ob wir ein thin, thick oder Hybrid Image erstellen wollen, das sollten wir vorher abklären. Als nächstes müssen wir im MDT2010 eine task sequence starten, wie das funktioniert haben wir ja bereits hier kennengelernt. In der neuen task sequence müssen wir nur  “sysprep und capture” auswählen, der Rest läuft wie schon im anderen Artikel beschrieben.

Wenn die neue task sequnce steht, müssen wir sie in die customsettings.ini eintragen und danach unser deployment share aktualisieren. Danach switchen wir zu unserem bereits fertig vorkonfiguriertem Windows 7 Master PC und starten von diesem aus die task sequence.

ACHTUNG:

Wir booten NICHT das vom Deployment Share erstellte PE Image !!! Der sysprep and capture task wurde dazu entwickelt nur von Master Image PC gestartet zu werden. Das Deplyoment Share sollte auf alle Fälle DeploymentShare$ benannt werden, sonst kann es zu Problemen kommen !

Dazu müssen wir zunächst vom MIPC aus eine Verbindung zu unserem Deployment Share erstellen. Das machen wir ganz klassisch von der commandshell aus, mit diesem Befehl:
net use * MDTserverDeploymentShare$ /user:domainusername

Wenn wir eine Verbindung erfolgreich hergestellt haben, rufen wir die Datei LiteTouch.vbs unter Scripts auf.
Dann sollte der MDT2010 Wizard auf dem MIPC starten und wir wählen unsere sysprep task sequence aus

dann legen wir das Admin Passwort fest

dannach wählen wir diese Option aus  und checken abschließend noch alle Einstellungen

Jetzt sollte alles wie geplant laufen

ACHTUNG:

Sollte es an dieser Stelle Probleme geben, ist in der customsettings.ini ein Eintrag vorzunehmen:

SkipComputerBackup=YES
ComputerBackupLocation=NETWORK
BackupShare=Mxx88UQP194zDeploymentShare2008R2$Captures
BackupDir=%OSDComputerName%

Wenn das Image erstellt wurde, müssen wir es im MDT2010 bereit stellen. Hierzu brachen wir es nur mit Hilfe des Assistenten in MDT2010 importieren. Dazu klicken wir im Deployment Share auf “Operation Systems” und dann auf “Custom Image File“

Hier geben wir den Pfad im Deployment Share Capture an

Jetzt steht das gecapture Image im MDT2010 zum Deployment zur Verfügung

Ein neues Projekt, Urlaub und WM bedingt habe ich nur mal ein kleines Päuschen gemacht, mir geht es hier ja nicht darum pünktlich jede Woche einen neuen Artikel auf Teufel komm raus einen neuen Artikel zu veröffentlichen. Dafür gibt es genug Windows 7 Blogs die die news von www.heise.de einfach umschreiben. Hier geht es nur um Windows 7 und natürlich auch um Server 2008 Deployment.

Heute wurde von Microsoft das erste Update für den MDT2010 veröffentlicht. Ihr könnt es hier runterladen.
http://go.microsoft.com/fwlink/?LinkId=159061

Als wesentliche Verbesserungen nennt Microsoft neben vielen kleinen bugfixes die Integration von Office 2010 und das vereinfachte und stabilerer Integration von Treiber.
Wer genau wissen will was sich konkret geändert hat, der sollte sich das Dokument”What’s New in MDT 2010 Guide.docx” auf der Download Seite zu Gemüte führen.

Wenn ihr den MDT2010 updated ist es am besten den PC neu zu starten und dann erst das  update der Deployment Shares durchzuführen, sonst kann es vorkommen das beim update der Shares Fehlermeldungen auftauchen.

Nächste Woche kommt ein neuer Artikel…..versprochen

Das kann bei einer Server Migration und/oder Virtualisierung sehr nützlich sein. Wer z.B. einmal einen Datenbank Server live migriert hat, weil der alte zu wenig Kapazitäten hatte, weiß von was ich spreche. Der neue Server muss mit allen Patches und Einstellungen neu installiert werden, dann werden die Datenbanken auf dem alten Server exportiert und auf dem neuen Server wieder importiert. Wenn man das alles gemacht hat, dürfte nicht mehr allzuviel vom Arbeitstag übrig sein. Ein weiteres Problem dabei ist, dass man noch keinen Test vom neuen Server gemacht hat, dafür gehen dann nochmals ein paar Stunden drauf.

Szenario

Gehen wir mal davon aus, dass ein kleines Unternehmen (von der Wirtschaftskrise gebeutelt) nicht mehr viel Geld für IT ausgeben kann und seine Server dringend migrieren muss, weil die entweder zu alt sind oder zu platzen drohen.
Es soll aber trotzdem eine zukunftsweisende Lösung gefunden werden, damit die Firma nicht von vornherein eine doch so weit verbreitete “permanete Interrimslösungen” schafft, die man auch als Flickschusterei bezeichnen kann !!!

Da kommt uns aber die Virtualisierung sehr entgegen .

Unseren Firma hat aber zum Glück einen cleveren IT Kollegen, der hier im blog regelmäßig mitliest und gerade noch 3000 € aus dem IT-budget zusammenkratzen kann, um einen neuen Server zu kaufen. Es sind insgesamt 4 Server zu migrieren, die in aktuellen 3x2GB RAM (x86 singls core Maschinen ) und 1x4GB RAM(x64 Core2Duo Maschine mit x64 Server 2003) haben.
Wichtig:
Das Konvertieren funktioniert noch nicht mit Windows 7 und Windows Server 2008R2 in den 64bit Versionen.

Der neue Server ist mit 2 Intel Xeon E5520, 16 GB DDR3 RAM  und einem 3x 1TB SATA RAID 5 bestückt, das macht 1 core pro GB RAM….das reicht erstmal um eine zeitlang über die Runden zu kommen .

Das erste Einsparpotenzial ergibt sich daraus, dass wir den Server ohne ein Betriebssystem ordern und wir darauf einfach nur einen baremetal Hypervisor installieren können. Wir entscheiden uns in diesem konkreten Fall für VMware ESXi Server den VMware kostenlos anbietet. Genauso gut könnten wir auch den Hyper-V Server 2008R2 einsetzen den Microsoft kostenlos zum download anbietet.
Jetzt müssen wir uns noch von der VMware homepage das magische Tool VMware vCenter Converter Standalone 4.0.1 besorgen und dann kann es auch schon los gehen .

Die Vorbereitung

Zuerst bereiten wir den neuen Server mit ESXi vor, dazu einfach die ISO auf eine CD brennen und das ganze dann installieren. Ist so simpel das es nicht mal screenshots machen wert ist…wer dennoch Hilfe braucht findet sie hier.

Das Konvertieren

Wir installieren den VMware Converter auf unserem Admin PC mit dieser Option

der Rest läuft ganz normal ab….

Einzig die Ports sind ggf. anzupassen

Wenn alles installiert ist, startet unser Converter und wir melden uns mit dem lokalen Account an.
Dann wird uns dieser Button weiterführen

In dem nächsten Fenster wird es dann interessant, hier legen wir unsere Parameter für den Dump fest.
Zuerst geben wir den DNS Namen oder die IP Adresse und  die Admin Anmeldedaten für die zu konvertierende Maschine ein

Im nächsten Schritt wird der VMware Converter per remote einen Agent auf der zu virtualisierenden physischen Maschine installieren, um den Dump überhaupt erst zu ermöglichen

Anschließend können wir den Typ der neuen virtuellen Maschine auswählen um sicher stellen zu können, dass die neue virtuelle Maschine auch mit der Version unseres eingesetzten Hypervisors kompatibel ist.
Wir sollten auf jedenfall drauf achten, dass die rot gekennzeichneten Einstellungen ausgewählt sind !
Weiter unten müssen wir noch ein Netzwerk Share auswählen zu dem unsere neue VM transferiert wird.
Sollte dieses Share ein Passwort benötigen, können wir das rechts neben dem Pfad zum Share unter “Connect as” eintragen.

Im nächsten Schritt haben wir mannigfaltige Einstellmöglichkeiten für die neue  VM, die einzig interessante Einstellung ist aber letztlich , weil diese Option nicht revidierbar ist.
Hier wird festgelegt welche Partitionen die neue VM enthalten soll. Der Vollständigkeit halber sei noch die Option Services erwähnt , in der man einige Dienste vor dem Dump stoppen kann.

In den anderen Optionen sind auch später noch in der virtuellen Maschine einstellbar.

Danach wird nochmal eine Zusammenfassung eingeblendet und dann wird die virtuelle Maschine erstellt.

Die Migration

Wenn der Vorgang beendet ist, haben wir auf dem Share eine neue virtuelle Maschine, die exakt der physischen Maschine entspricht. Die müssen wir jetzt nur noch mit VMware Workstation auf den ESXi Server verschieben und dort starten oder wir kopieren die neue virtuelle Maschine einfach auf einen normalen VMware Server 2.0.

Von dort starten wir die VM jetzt einfach (ACHTUNG bei fest vergebenen Servern IPs müssen diese logischerweise zuerst geändert werden) und überprüfen dann die Funktionen des migrierten Servers.

Fazit

Mit dem VMware Converter ist es sehr gut möglich den Einstieg in die Welt der virtuellen Server zu finden und auch ihn effizient zu beschreiten.

Es spielt keine Rolle ob wir ein Thin, Thick oder Hybrid Image verteilen wollen, wichtig ist nur das wir ein Image pro Unternehmen haben um den administrativen Aufwand so gering wie möglich zu halten.

In diesem konkreten Beispiel erstellen wir eine bootfähige Deployment DVD die bereits das fertige Image enthält.
Diese Einstellung funktionieren natürlich auch wenn man von einem Deployment Share aus bootet, nur dann bitte nicht vergessen die bootstrap.ini mit den Netzwerk Anmeldedaten zu bestücken

Die customsettings.ini für die Ultra Lite Touch Installation

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
_SMSTSOrgName=IPCtec Windows 7 Deployment
SkipAppsOnUpgrade=YES
SkipCapture=YES
SkipAdminPassword=YES
AdminPassword=kennwort
SkipProductKey=YES
SkipDeploymentType=YES
SkipDomainMembership=YES
SkipUserData=Yes
UserDataLocation=NONE
SkipTaskSequence=YES
TaskSequenceID=win7
Sk ipComputerName=NO
SkipPackageDisplay=YES
SkipLocaleSelection=YES
UILanguage=de-DE
UserLocale=de-DE
KeyboardLocale=0407:00000407
SkipTimeZone=YES
TimeZone=110
TimeZoneName=W. Europe Standard Time
SkipApplications=YES
Applications001={5e6d9ca1-9d29-490c-b3a9-efb642d949eb}
Applications002={783d6cb7-802e-4ed6-ac7d-6df9db7fc71d}
SkipBitLocker=YES
SkipSummary=YES

Die bootstrap.ini für die Ultra Lite Touch Installation

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES

Mit diesen Einstellungen braucht man lediglich die den Computernamen zu von Hand einzutragen, der Rest läuft automatisch wie von Geisterhand

Anmerkung:

Applications001={5e6d9ca1-9d29-490c-b3a9-efb642d949eb}
Applications002={783d6cb7-802e-4ed6-ac7d-6df9db7fc71d}

Hier müssen natürlich die GUIDs der Software eingetragen werden die man mit verteilen möchte ! Alternativ dazu kann man auch ein Software Package erstellen und dies in der Task Sequence verteilen lassen.

Diese Konfiguration funktioniert auch natürlich bei eine Installation von einem Deployment Share aus.

Wie sollte eine Migration genau generell ablaufen ?
Zunächst müssen wir uns ein Ziel definieren- was soll in welcher Zeit und auf welchen Status migriert werden. Wir unterscheiden hierbei 2 Migrationsformen:

a.) die Vollständige Migration des Unternehmens
Hierbei werden in einem vordefiniertem Zeitraum alle PC’s im Unternehmen in einem rollout migriert. Der Vorteil hierbei ist, dass es keine Problem im Mischbetrieb gibt und alle PC’s den selben Standard haben. Der Nachteil ist, der große logistische Aufwand und der Schulungsaufwand bei den Mitarbeitern, da jeder User am Tag X der Migration über ein Windows 7 Basiswissen verfügen muss.

b.) die sukzessive Migration
Bei dieser Migrationsform werden die ältesten PC’s durch neu Windows 7 PC’s ersetzt und es wird eine Migration in mehreren Schritten durchgeführt. Hierbei ist es sinnvoll z.B. nach und nach die Abteilungen umzustellen. Der Vorteil hierbei ist, dass man in kleineren Schritten vorgeht und die User gezielter Abteilungsweise auf das neue Betriebssystem schulen kann. Der Nachteil ist, der Mischbetrieb von mehreren Betriebssystemen (der z.B. im Support Probleme verursachen kann).

Die IST Zustand Analyse
Die genaue Analyse des “momentanen IT Zustandes” eines Unternehmens ist ein Grundpfeiler für eine erfolgreiche Windows 7 Migration. Nur so ist eine Umstellungsphase möglich.
Zur Analyse des IST Zustands gehört:

• Testen der Hardware Kompatibilität
  Die Hardware sollte die Mindestanforderungen von Windows 7 erfüllen, sprich mind. einen CPU mit > 1Ghz (am besten schon direkt mit mind. 2 Kernen), 1GB RAM (2GB bei x64 Systemen) und mindestens einer 60GB Festplatte ausgestattet sein. Sollte hier eine Voraussetzung nicht erfüllt sein, muss der PC getauscht werden (PC’s die hier durchfallen sind in der Regel längst abgeschrieben.) Hier ist der Windows 7 Upgrade Advisor wieder eine wertvolle Hilfe.

• Testen der Kompatibilität der Applikationen
  Eine weitere sehr wichtige Frage die im Vorfeld zu klären ist, ist ob alle im Unternehmen eingesetzten Programme mit Windows 7 kompatibel sind. Es kann durchaus sein, dass Programme ein kostenpflichtiges update benötigen damit sie mit Windows 7 zusammenspielen. Sowas kann sehr leicht sehr teuer werden! Wenn der CIO dies vergisst zu checken und von Anfang an mit einzubeziehen, kann er sehr massive Probleme mit dem Management bekommen.
  Wie man mit Hilfe dem Microsoft Application Compatibility Toolkit (ACT) 5.5 Programme testet stehe auch hier im blog. Es gibt viele Möglichkeiten Applikationen kompatibel mit Windows 7 zu machen, darauf wird aber in speziellen Artikeln eingegangen.

Auch hier läßt uns Microsoft glücklicherweise nicht im Regen stehen, genau für diese Fälle wurde der Windows Inventory Collector entwickelt. Was das ist und wie das funktioniert….auch dazu wird noch ein vollständiger Artikel geschrieben .
Wichtig ist auf alle Fälle, dass man einen vollständigen Gesamtüberblick über alle Systeme und Applikationen im Unternehmen hat um sich so perfekt auf die anstehenden Aufgaben vorbereiten zu können !

Einzelplatz – Upgrade oder Neuinstallation ?
Auch wenn man ein in-place-upgrade von Vista machen könnte, sollte man sich folgendes überlegen…..
Wenn ich mit meinem Hausstand umziehe, ziehe ich blind alles mit um oder nutze ich die Gelegenheit mich von Dingen zu trennen die ich sowieso nicht mehr benötige -> ich werfe den Kram weg, den ich nicht mehr brauche .
Auch bei einem in-place-upgrade wird viel Müll, den man nicht mehr benötigt, vom alten OS mit umgezogen -das nimmt uns nur Systemressourcen und birgt potenzielle Fehlerquellen mit sich.
Wie schon oben angesprochen muss man vorher klären ob das z.Z. verwendetet Windows sich so einfach upgraden läßt. Der Windows 7 Upgrade Advisor ist dabei eine wertvolle Informationsquelle und ein sehr guter Ratgeber !

Hier trotzdem mal eine kleine Übersicht was man in-place upgraden kann…….

• Windows Vista Ultimate 32 Bit -> Windows 7 Ultimate 32 Bit
• Windows Vista Ultimate 64 Bit -> Windows 7 Ultimate 64 Bit

• Windows Vista Business 32 Bit -> Windows 7 Professional 32 Bit
• Windows Vista Business 64 Bit -> Windows 7 Professional 64 Bit

• Windows Vista 32 Bit (NICHT die Starter Edition) -> Windows 7 Ultimate 32 Bit
• Windows Vista 64 Bit (NICHT die Starter Edition) -> Windows 7 Ultimate 64 Bit
• Windows Vista Home Basic 32 Bit -> Windows 7 Home Premium 32 Bit
• Windows Vista Home Basic 64 Bit -> Windows 7 Home Premium 64 Bit
• Windows Vista Home Premium 32 Bit -> Windows 7 Home Premium 32 Bit
• Windows Vista Home Premium 64 Bit -> Windows 7 Home Premium 64 Bit

und was nicht…..

• Windows XP -> Windows 7 (32 Bit oder 64 Bit)
• Windows Vista Starter -> Windows 7 (alle editions)
• 32 Bit Edition von Windows Vista -> 64 Bit Edition von Windows 7
• 64 Bit Edition von Windows Vista -> 32 Bit Edition von Windows 7
• Windows Vista Ultimate -> Windows 7 Professional (64 oder 32 Bit)
• Windows Vista Home Basic -> Windows 7 Professional (64 oder 32 Bit)
• Windows Vista Home Premium -> Windows 7 Professional (64 oder 32 Bit)
• Windows Vista Business -> Windows 7 Home Premium (64 oder 32 Bit)
• Windows Vista Ultimate -> Windows 7 Home Premium (64 oder 32 Bit)

Wird neuen Hardware angeschafft ?
Wenn neue Hardware angeschafft werden soll, ist es sinvoll direkt  auf 64bit zusetzten, wir leben mittlerweile in Zeiten wo jeder 299€ teure Consumer PC  100% 64bit tauglich ist und 64bit Treiber weit verbreitet sind.

Wie Benutzerdaten sichern ?
Wie hier im blog schon mehrfach geschrieben, sollten die User Daten extern gesichert werden (z.B. USB HDD), man kann das mit tools wie Acronis True Image umsetzen -dabei wird ein komplettes Image Backup der Festplatte gesichert. Der Vorteil hierbei ist, dass wenn der User Daten vergessen hat zu sichern, man auf dem neuen System ganz einfach durch das angelegte Image browsern kann um die Dateien  wieder auf das neue System zu sichern. Der einfacherer Weg ist jedoch, das Windows Easy Tranfer tool benutzt, wie dieses tool genau funktioniert ist hier erklärt.
Im Geschäftsumfeld wird man eher auf das User State Migration Tool zurückgreifen. Ein spezieller Artikel ist hierzu bereits in Vorbereitung.

Treiberupgrade ?
Das Problem  zu Vista Zeiten war, dass es für 64bit OS kaum Treiber gab und die Hersteller nur langsam mit der Entwicklung der 64bit releases ihrer Treiber voran kamen.

Dann stellt sich noch eine Frage, die besonders beim Deployment im Geschäftsumfällt eine grosse Rolle spielt:
Welche Treiber sind sinnvoll und absolut notwendig und welche kann man beruhigt weglassen ?
Treiber sind oft nicht mehr nur pure “Verbinder” zwischen Hardware und Betriebssystem, es ist leider bei den Herstellern üblich geworden Treiber zu entwickeln die komplette Programme sind. Besonders im Notebook Bereich kann man hier mit Grauen feststellen das dort zum Teil 200MB große “System Management” Treiber benötigt werden um den Rest der Treiber überhaupt installieren zu können .
Wenn man z.B. ein Masterimage anfertigen und es ganz “sauber” aufsetzten will, installiert man Windows setzt den ersten Wiederherstellungspunkt als master und installiert einen Treiber, dann testet man ob man ihn braucht und was für Auswirkungen dieser Treiber hat.
Wenn alles ok ist -> neuer Wiederherstellungspunkt, wenn nicht Wiederherstellungspunkt wieder lösen und mit dem nächsten Treiber weitermachen.
So werden Masterimages im Enterprise Umfeld gemacht, ist sehr viel Arbeit aber so hat man dauerhaft ein hochperformantes System, welches auch weniger störanfällig ist und somit auch weniger Wartung benötigt.

Das Master Image – Thin, Thick oder Hybrid ?!?
Wenn wir alles soweit überprüft haben wird es Zeit sich um die From des Images Gedanken zu machen.
Das Windows Deployment bietet 3 verschiedene Image Typen an:

Thin Image

Das “dünne” Masterimage enthält nur die absolut notwendigsten und grundlegendsten Komponenten die für ALLE PC Typen im Unternehmen absolut notwendig sind (z.B. active Perl, Software Deployment Clients, Java). Diese Komponenten, deren Versionstände durch das Change Management bestätigt werden, erhalten eher seltener ein Update.
Vorteil:
-Deployment übers LAN verursacht weniger Traffic
-bessere Skalierbarkeit
-verringerter Administrativen Aufwand durch leichter Imagepflege
Nachteil:
-benötigte Programme müssen nachinstalliert werden (Softwareverteilungstool, Gruppenrichtlinien)

Thick Image
Das “fette” Masterimage enthält alle Komponenten die der fertige Client erhalten soll, z.B. Office, Acrobat Reader, Bildbetrachter, diverse Software die das Unternehmen einsetzt.
Vorteil:
-alle Komponeten werden auf einmal installiert
-kein Softwareverteilungstool oder Gruppenrichtlinien zur Installation zusätzlicher Software nötig
Nachteil:
-bei jedem Update oder Change muss das ganze Image angepasst werden
-hoher Platzbedarf verursacht viel Traffic währen der Installation
-kann u.U. nicht mehr auf einer bootfähigen DVD untergebracht werden
-Lizenzproblematiken, weil alle PC’s jede Software erhalten

Hybrid Image
Das Hybrid Image ist die Image Form die wir am häufigsten antreffen. Es wird bewußt schmal gehalten, d.h. hier wird nur die Software installiert, die auf allen Clients im Unternehmen zu finden ist, z.B. auch größere Komponenten wie Office, Packer Tools und Acrobat Reader. Es werden aber  nicht Fachbereich spezifische Tool wie beispielsweise MS Project oder das Lohnbuchhaltungstool mit ins Image gepackt.
Vorteil:
-Deployment übers LAN verursacht weniger Traffic
-bessere Skalierbarkeit durch weniger installierte Komponenten
-Einsparung bei den Lizenzkosten
-verringerter administrativer Aufwand durch leichtere Imagepflege
Nachteil:
-benötigte Programme müssen nachinstalliert werden (Softwareverteilungstool, Gruppenrichtlinien)

Das Hybrid Image ist die beste Form die wir besonders im small business Bereich favorisieren sollten, sie bietet uns größere Flexibilität und dadurch weniger administrativen Aufwand. Im Enterprise Bereich verfügt man meist über eine seperate Software Deployment Lösung, sodass wir in diesem Fall auf ein Thin Image zurückgreifen, in dem einfach nur dafür gesorgt wird, dass der Client eine Verbindung zum Deployment Server erhält durch den er dann betankt wird.
Im very small business Bereich (<30 Clients) macht das Thick Image am meisten Sinn, den dort ist es häufig so, dass ein Client alle Programme enthalten muss.

Wie man korrekt ein Masterimage erstellt, das behandeln wir in einem extra Artikel, hier soll es nur mal um einen groben Überblick gehen !

Fazit:
Wie man sieht, gibt es bei einer Migration jede Menge Dinge denen man nicht direkt Beachtung schenkt. Es gilt hierbei sich erst einen genauen Überblick über die Anforderungen von Windows 7 zu verschaffen, die im Unternehmen eingesetzte Software auf Kompatibilität mit Windows 7 zu testen und abzuwägen welche Image Form man für das Deployment wählt.

Zu was sind diese Dateien notwendig ?
Die customsettings.ini ist quasi die „Master Deployment Datei“, hier werden alle relevanten Parameter gesetzt, welche das Deployment steuern.

Die bootstrap.ini wird verwendet, wenn der zu installierende Computer keine Verbindung zum entsprechenden Deployment Share herstellen kann. Dieses Problem tritt nur im Szenario „Neuer Computer“ und „Computer ersetzen“ auf. Man muss in die bootstrap.ini folglich die Verbindungsdaten zum Deployment Share eintragen.

Wo findet man die CustomSettings.ini und d bootstrap.ini ?
Die beiden Dateien sind auf 2 Wegen erreichbar:

Einmal über das Dateisystem unter C:DeploymentShareControl, dies ist einfach zu editieren mit dem Notepad oder dem Wordpad

…oder der einfacherer Weg ist, direkt aus unserer Deployment Bench.. in dem man auf dem DeploymentShare einen Rechtsklick macht und dann die Eigenschaften (Properties) auswählt.

..dort dann auf den Reiter „Rules“ klickt. Schon ist man in der CustomSettings.ini.

Will man die Boostrap.ini editieren muss man unten rechts auf den entsprechenden button klicken.

Parameter der CustomSettings.ini

!!! ACHTUNG SEHR WICHTIG !!!
!!! YES/NO MÜSSEN groß geschrieben werden !!!!

[Settings]
Priority=Default

Properties=MyCustomProperty
Gibt den Bereich an wo individuelle Einstellungen vorgegeben werden können.
Richtig Interessant wird dieser Bereich aber erst, wenn man den Microsoft System Center Configuration Manager (SCCM) oder die Windows Bereitstellungsdienste (WDS) nutzt.

Für unsere Zwecke reichen aber diese Grundeinstellungen:

[Default]
OSInstall=YES/NO
Soll ein Betriebssystem installiert werden ?
Denke schon das es sinnvoll ist hier IMMER „YES/NO“ einzutragen

SkipWizard=YES/NO
Dieses Parameter legt fest ob der ganze Deployment Assistent übersprungen werden soll.

_SMSTSOrgName=IPCtec Windows 7 Deployment
Hier kann man den Namen des Unternehmens eintragen, sieht cooler aus während der Blaken sich von links nach rechts schiebt

SkipLocaleSelection=YES/NO
UILanguage=de-DE
UserLocale=de-DE
KeyboardLocale=0409:00000409
Legt die Ländereinstellung fest….wir müssen für deutsch de-DE statt en-US eintragen. Hier können auch hexadezimal Werte stehen (en-US = 0409:00000409) und es kann aber auch der Wert de-DE eingetragen werden.
Eine Übersicht der Ländercodes findet man hier

SkipUserData=YES/NO
Überspringt die Angabe wo USMT die Benutzerdaten gesichert hat, um diese direkt in die Installation zu integrieren

ScanStateArgs=/v:5 /o /c
LoadStateArgs=/v:5 /c /lac /lae
Hier kann man die genauen settings für das einspielen der USMT Daten definieren.

UserDataLocation=NONE oder
UserDataLocation=serverXusmtshare$
Wenn man mit USMT User Daten auf ein Share sichern will, kann man hier den Pfad eintragen (UNC Pfad !!!!). Die Variable NONE zeigt an, dass die Benutzer Konfiguration nicht integriert werden soll. Keine Angaben hier lassen die Installation abbrechen !!

SkipCapture=YES/NO
Überspringt den Capture Prozess zum Erstellen eines Referenzabbildes.
Sollte man den Befehl gebrauchen, muss man die folgenden Parameter mit eingeben, sonst macht der MDT2010 trouble während der Installation.

ComputerBackupLocation=ServerXBackup$
Gibt den UNC Pfad zum Share an, wo der Capture liegt.

BackupFile=MeinImage.wim
Gibt den Dateinamen vom Image an.

SkipAdminPassword=YES/NO
Die Eingabe eines lokalen Adminpassworts wird ausgelassen.

AdminPassword=deinPasswort
Hier kann man ein Admin Passwort eintragen, dieses wird dann in die Konfiguration übernommen.

SkipProductKey=YES/NO
Überspringt die Key Abfrage, KMS Server Abfragen können hier ein- und ausgeschaltet werden.

SkipPackageDisplay=YES/NO
Hier können wir optionale Sprachpacket einfach unserer Installation hinzufügen. Dazu müssen wir zuerst die GUID (global unify ID), von dem via MDT2010 installierten Sprachpaket, rausfinden. Hierfür müssen wir in der Datei C:DeploymentShareControlpackages.xml diesen Eintrag suchen <packages guid=”{a555b311-88f-41150-8ba7-df0811a8b999}” und alles aus der geschweiften Klammer kopieren.
Der fertige Befehl sieht dann so aus:

LanguagePacks001={ a555b311-888f-4110-8ba7-df0811a8b999}
Sollen weitere Sprachpakete installiert werden, müssen wir die Nummerierung einfach weiter fortführen
LanguagePacks002={XXXXXX}
LanguagePacks003={XXXXXX} usw.

SkipAppsOnUpgrade=YES/NO
Überspringt die Anzeige, in der man eine oder mehrere Anwendungen zur Installation auswählen kann. Will man Applikation direkt mit installieren benötigt man diesen Parameter.

SkipApplications=YES/NO
Hier können wir angeben welche Softwarepakte mit installiert werden sollen.
Wenn wir ein fertiges Image nutzen, können wir hier den Installationsschritt einsparen, in dem wir unsere paketierte Software Installation wählen. Die Vorgehensweise ist ähnlich wie bei den Sprachpaketen. Auch hier müssen wir zuerst die GUID rausfinden. Dazu müssen wir die Datei C eploymentShareControlApplications.xml öffnen. Diese listetet alles genauso wie bei den Sprachpaketen auf:
Applications001={a26c6358-8db9-4615-90ff-d4511dc2feff}

Applications002={7e9d10a0-42ef-4a0a-9ee2-90eb2f4e4b98}

SkipDeploymentType=YES/NO
Schaltet die Art des Windows Deployments aus.

SkipDestinationDisk=YES/NO
Diesen Schlüssel, um Windows7 auf einer anderen Partition oder Festplatte zu installieren braucht man nur sehr, sehr selten. Er ist per default auf YES.
DestinationDisk=HHD1
DestinationPartition=D:
Hier könne wir eine Zielpartition für die Installation festlegen.
ACHTUNG: Dieser Aufruf kann nur gestartet werden, wenn der DeploymentType NewComputer oder RefreshComputer ist.

DeploymentType=NEWCOMPUTER
Mit dieser Einstellung wird die Festplatte komplett gelöscht und deshalb speichert man keine User Daten. Es sind folgende Einstellungen möglich:
New Computer, Refresh Computer, Upgrade Computer, Replace Computer

SkipDomainMembership=YES/NO
Überspringt das Eintragen einer Domain in die neu Konfiguration.

JoinDomain=IPCTEC
Hier wird die Domain festgelegt, der der Rechner nach seiner Installation automatisch beitritt. Wichtig hierbei ist, dass man mit folgenden Befehlen sicherstellt, dass man auch als Domain Admin eine Autentifizierung gegen die Domain vornimmt:

DomainAdmin=IchAdmin
Benutzer Name des DomainAdmin wird hier eingetrage.
DomainAdminPassword=kennwort
Passwort des DomainAdmin wird hier eingetragen.

SkipTaskSequence=YES/NO
Überspringt die Assistentenseite bei der man die Tasksequence auswählen kann. Wenn man diesen Part überspringen will.

TaskSequence=IPCtec Deploy Windows 7
Mit diesem Schalter kann man eine Task Sequence standardmäßig vorgeben

SkipComputerName= YES/NO
So können wir die Eingabe des PC Namens überspringen.
ComputerName=TEST-COMPUTER
Legt den neuen PC Namen fest. Wir können an dieser Stelle auch einen Webservice aufrufen oder eine Userexit Funktion verzweigen, die uns automatisch einen PC Namen generiert. Der Computername kann auch über die Variabel %ComputerName% zugewiesen werden. Wir haben auch die Möglichkeit die Seriennummer eintragen zu lassen, dies funktioniert über die Variable %SerialNumber%.

SkipTimeZone=YES/NO
Überspringt das Einstellen der Zeitzonen.

TimeZone=110
Legt die Zeitzone nummerisch fest.

TimeZoneName=GMT
Hier kann man die verwendete Zeitzone festlegen.
Eine Übersicht aller Zeitzonen findet man hier.

SkipBitLocker=YES/NO
Hier könnte man die Bitlocker Laufwerksverschlüsselung ein- und ausschalten.
Wenn man es einschaltet benötigt man folgende Schlüssel:

BDEDriveLetter=X: (der Laufwerksbuchstabe von zu verschlüsselnden Laufwerk)
BDEDriveSize=5000 (die Laufwerksgröße in MB)
BDEInstall=YES/NO
BDEInstallSuppress=YES/NO
BDERecoveryKey=AD
BDEInstall=TPMKey
TPMOwnerPassword
OSDBitLockerStartupKeyDrive
OSDBitLockerWaitForEncryption
BDEKeyLocation=C:

SkipSummary=YES/NO
Die überspringt die Zusammenfassung am Ende des Assistenten.

CaptureGroups=YES/NO
Speichern die derzeitigen Gruppenmitglieder auf dem PC, so dass sie (nachdem die Maschine fertig aufgebaut ist), von dort gelesen werden können.

SkipLocaleSelection=YES/NO
Überspringt die Gebietsschemaauswahl.

SLShare=COMPUTERlogs$
Ändert den Speicherort der Log Dateien. Es ist sinnvoll hier mal rein zuschauen, sobald sich Probleme bei der Installation ergeben. Wenn man WDS oder SCCM benutzt, kann man diese Option ignorieren.

Home_page=http://www.ipctec.de
Legt im Internet Explorer eine Startseite fest (kann man auch natürlich später via GPO machen).

SkipBuild=YES/NO
Überspringt im Deployment Assistenten die Betriebssystemauswahl.

BuildID=Test1
Wählt das auf dem neuen PC zu installierende Betriebsystem.

WSUSServer=http://wsus1
Gibt dem Pfad zum WSUS Server an der Windows Servioce Packs und Updates bereitstellt. Es können auch mehrere Server angegeben werden.

SkipFinalSummary=YES/NO
Zeigt nach der kompletten Installation eine Zusammenfassung der Ereignisse an.

Bootstrap.ini Einstellungen

Die Bootstrap.ini Befehle sind fast genau dieselben die wir schon von der CustomSettings.ini her kennen. Hier geht es ja auch eigentlich in der LTI nur darum eine Verbindung zum Deployment Share aufzubauen.
Weiter Features werden erst bei der Bereitstellung via Windows Deployment Service oder Microsoft System Center Configuration Manager (SCCM) interessant.

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES/NO
DeployRoot=MYSERVERDeploy$
UserDomain=DOMAIN
UserID=admin

SkipBDDWelcome=YES/NO
Der splash screen am Anfang kann aus und ein geschaltet werden. Da hier eine keyboard Layout Auswahl getroffen wird, sollten wir die Werte entsprechend ändern

DeployRoot=MYSERVERDeploy$
Der UNC Pfad den man braucht um sich zum Deployment Share zu verbinden.
Dies braucht man nicht zu setzen, wenn man z.B. eine Deployment DVD baut.

UserDomain=DOMAIN
Die Domäne die man braucht um sich zum Deployment Share zu verbinden.

UserID=admin
Der Benutzername den man braucht um sich zum Deployment Share zu verbinden.

UserPassword=XXXX
Das Passwort das man braucht um sich zum Deployment Share zu verbinden.

Wie man eine Ultra Lite Touch Installation von einem neuen PC hinbekommt, welche man komplett von einer DVD starten und komplett installieren kann, betrachten wir in einem gesonderten Artikel !

Die 32 bit Version benötigt mind. 1 GB (aber 2GB sind ABSOLUT zu empfehlen um ein flüssiges Arbeiten zu gewährleisten.) Die 64 bit Version benötigt mind. 2 GB (aber mind. 3GB sind ABSOLUT zu empfehlen um ein flüssiges Arbeiten zu gewährleisten).

Es muss auch gewährleistet sein, dass ALLE Geräte auf die ein 64bit System installiert werden soll über eine 64bit CPU verfügen (CPUs ab AMD64 oder Intel Core2Duo). Bei älterer Hardware wie z.B. Scanner, FAXkarten, Spezialdruckern (z.B. in Druckstrassen) und älteren externen SCSI Komponenten ist es sehr oft so, dass deren Treiber nicht unter 64bit lauffähig sind. Sollten die 32bit Treiber trotzdem von dem 64bit System auf den ersten Blick akzeptiert werden (was fast nie vorkommt), kann es im Betrieb zu unerklärlichen Fehlern kommen z.B. falsches adressieren der Speicheradressen. Diese Fehler zu finden ist SEHR diffizil, da sie nicht immer auftreten und schwer nachvollziehbar sind. Ferner werden nicht digitale, vom Hersteller signierte Treiber, nicht installiert. Auch bei Anwendungssoftware kann es zu massiven 32/64bit Inkompatibilitäten kommen, auch diese können z.T. mit shims und/oder dem 32bit Modus von Windows 7 behoben werden, aber ein 64bit System überwiegend im 32bit Modus zu betreiben ist eine Rechnung die keinen Sinn macht.
Ältere 16bit Programme können unter 64bit generell nicht mehr verwendet werden. Im Client Bereich gibt es bis dato nur sehr wenige 64bit Anwendungen die über eine komplett neue 64bit Architektur verfügen (z.B. Adobe Photoshop, Illustrator, 3D Applikationen wie Softimage3D, Lightwave usw ). Diese Software ist meist im Grafikbereich angesiedelt, ein normaler Office 2007 User profitiert nur minimal von der (auch nicht 100%igen) 64bit Architektur.

Fazit:

Es ist mit immensen Kosten verbunden im Clientbereich alle Systeme auf Hardware umzustellen, welche 64bit fähig ist. Im Serverbereich hingegen ist es schon fast unabdingbar geworden 64bit System zu verwenden, bieten sie schon alleine den Vorteil das sie >4GB RAM verwalten können und hardwaregestützte Datenausführungsverhinderung verwenden.