Immer häufiger wird der Wunsch an mich herangetragen, neben der normalen Silent Installation auch die Verteilung via Imaging-Verfahren in DSM zu implementieren. Gründe hierfür sind ein schnelleres Deployment und die Unterstützung von VDI Plattformen. Dabei soll zudem die Installation des Master-Images möglichst automatisiert und den Richtlinien entsprechend durchgeführt werden.

Mit DSM 7.2 sind nun alle wesentlichen Funktionen verfügbar, um das Deployment von Betriebssystemen mit Imaging-Verfahren wirklich vollständig umzusetzen. Dabei spielt es keine Rolle, ob das mitgelieferte DriveSnapshot, ImageX oder eine VDI Technologie (die ja aus Sicht der Softwareverteilung nichts weiter als ein Imaging Verfahren darstellt) genutzt wird.

Folgender Artikel beschreibt nun den konzeptionellen Ansatz, um das Deployment von Betriebssystemen und Software mittels Imaging Verfahren in DSM 7.2 zu integrieren. Zum Verständnis dieses Artikel sind noch folgende Informationen von Bedeutung:

Erläuterung zum Artikel

• Voraussetzung für die Implementierung der hier beschriebenen Lösung ist die vollständige Implementierung eines Silent Setup und entsprechender Pakete.
• Grundlegendes Wissen über die OSD Imaging Option und den Umgang mit OSD Image-Objekten ist Voraussetzung zum Verständnis dieses Artikels. Die Beschreibung der OSD Imaging Option kann im Blog von Aton Consult nachgelesen werden.
• Es wird im Rahmen dieses Artikel immer vom Image-Master und Image-Clone gesprochen. Der Begriff "Image-Master" stellt den Client dar, der initial erstellt wird und als Vorlage für die "Image-Clones" dient.  
• Im Folgenden wird das Verfahren mittels des (in DSM mitgelieferten) Tools DriveSnapshot beschrieben. Zur Nutzung ist eine DSM OSD Imaging Lizenz zwingend notwendig. 
• Der folgende Artikel geht nicht auf die Verteilung per Multicast ein.
• Alle hier genannten, in DSM implementierten, Werte (wie z.B. Schemaerweiterungen) können frei modifiziert werden. Die hier genannten Werte dienen ausschliesslich der Veranschaulichung.
• Der Artikel basiert auf DSM 7.2 HB1 (Februar 2013)

Strukturierung der Software

Soll die Softwareverteilung per Imaging aufgebaut werden, sind folgende Grundgedanken in Bezug auf die zur Verfügung zu stellende Software von Bedeutung:

1. Welche Software soll im Master-Image installiert werden und bei allen Image-Clones direkt nach der Verteilung des Images auf "grün" gehen?
   • Dies betrifft alle Standardpakete wie Office, Adobe Reader, etc. und deckt somit den größten Teil der Software ab.
2. Welche Software soll explizit nicht mit dem Image verteilt werden sondern nach dem Einspielen des Images auf einem Image-Clone?
   • Einige Softwarekomponenten erfordern eine Rekonfiguration nach dem ersten Start des Image-Clones. Oft ist die Rekonfiguration nicht "silent" oder nur sehr kompliziert umsetzbar. In diesem Fällen wird die Installation der betreffenden Komponente im Image-Master blockiert und erst im Image-Clone durchgeführt. Diese Softwarekomponenten sollten sehr sorgfältig ausgewählt werden, da jede Softwarekomponente, die im Image-Clone installiert wird auch die Installationszeit verlängert.
   • Häufig sind Virenscanner von diesem Szenario betroffen.
3. Welche Software soll sowohl auf den Image-Master als auch auf dem Image-Clone installiert werden?
   • Speziell Steuerungspakete müssen häufig auf dem Image-Master als auch dem Image-Clone installiert/ausgeführt werden.
   • Dies kann ein Paket sein, welches den Computer im AD in den richtigen OU Zweig verschiebt (oder in die richtige Gruppe aufnimmt), damit die Installation und der Betrieb einer nachgelagerte Softwareinstallation überhaupt erst korrekt möglich ist.
   • Auch ein, speziell für die Erstinstallation zur Verfügung gestelltes Patch Management Execution Package, (welches den Client schon während der OS Installation mit allen notwendigen Patchen versorgt, bevor der Computer für den Anwender freigegeben wird) ist sowohl im Image-Master als auch im Image-Clone von Nutzen.

Aufbau der Grundstruktur

Zur Ablaufsteuerung werden die folgenden Komponenten implementiert:

Schemaerweiterung

Es ist eine Schemaerweiterung notwendig, die die einzelnen Schritte des Imaging Prozesses abbildet. Diese Schemaerweiterung wird als Clientseitige Optionlist "Imaging" angelegt und enthält 4 Werte:

• Wert: 00
  • Text: No Imaging
  • Default
• Wert: 01
  • Text: Install Image-Master
• Wert: 02
  • Text: Capture Image-Master
• Wert: 03
  • Text: Relase Image-Clone to production

Die Option "The state info can also be changed in the property grid" wird aktiviert (siehe hier). Als Default Value wird "00 (No Imaging)" gewählt.

Dynamische Gruppen

Auf Basis dieser Schemaerweiterung wird nun eine Dynamische Gruppenstruktur auf höchster Ebene der ODS implementiert:

• Name: Imaging
  • • Filter: Imaging != 00
    • Beschreibung: Dieses Gruppe kapselt alle weiteren Imaging Gruppen
    • Name: 01 Install Image-Master
      • Filter: Imaging == 01 || Imaging == 02
      • Ist eine Untegruppe von "Imaging" und enthält alle Zuweisungen die für die Erstellung eines Computers notwendig sind, von dem das Image-Master gezogen wird.
    • Und je eine weitere Gruppe für "02 Capture Image-Master" und "03 Release Image-Clone"

Vorbereiten des Image-Master Computers

Ein Image-Master wird grundsätzlich erstellt, indem ein Computer auf ganz normalen Weg via DSM installiert wird. Es wird ein klassiches Silent Setup erstellt und die Software gemäß dem bestehenden Konzept auf die Clients zugewiesen. Die Nutzung des normalen DSM Installationsverfahren (gegenüber einer manuellen Installation) stellt sicher, dass der Betrieb der Umgebung auf ganz normalen Weg weiter geführt werden kann. Zum Beispiel werden Softwareupdates die in Form einer Revision in die Pakete implementiert werden, auch auf Image-Clones angewendet (wenn diese in den normalen Alltagsbetrieb übergegangen sind).

Um nun das Image von einem Image-Master Computer abzuziehen, wird die oben genannte Schemaerweiterung "Imaging" für den betreffenden Computer auf "01 (Install Image-Master)" gestellt. Der Computer ist nun Mitglied der entsprechenden dynamischen Gruppe.

Ausschluss von Software auf dem Image-Master

Um die Installation einzelner Softwarepakete auf dem Image-Master zu vermeiden (siehe Strukturierung der Software), wird nun auf die Gruppe "01 (Install Image-Master)" alle Software die nicht im Image enthalten sein soll, mit einer "Deny-Policy" zugewiesen. Wird in der Umgebung ein Finishing Paket (also ein allerletztes "Aufräumpaket", welches einen finalen Reboot u.ä. durchführt) verwendet, bietet es sich an, dieses ebenfalls nicht auf dem Image-Master laufen zu lassen sondern erst auf den Image-Clone's (siehe hier). 

Vorbereiten des Image-Master

Zusätzlich zu den Deny-Policies wird auf die Gruppe das folgend beschriebene Paket "Prepare client as Image-Master" zugewiesen.

!---------------------------------------------------------------------------------
!Author : NWC-Services
!Date: 2013-01-16
!---------------------------------------------------------------------------------

!clean up system from former unattend installations
DeleteFileList
%windir%\Panther\autounattend.xml
%windir%\Panther\unattend.xml
%windir%\Panther\Unattend\autounattend.xml
%windir%\Panther\Unattend\unattend.xml
%windir%\system32\Sysprep\unattend.xml
C:\autounattend.xml
C:\unattend.xml
EndProc/F/x64/TS
!
!# set imaging status
ModifyObjectProperty(f_CurrentComputer,'CustomGenCompClientProps','Imaging','02')
CommitChangesForImaging
!
!# Create Image object
RunAsEx('%NiBinDir%\niprep.exe','/prepare /name=%computername% /imageonly','','','5','_return',raUseSisAccount+WaitForExecution+Failed)/TS
!Deletes the discovery client
RunAsEx('%NiBinDir%\niprep.exe','/dd','','','5','_return',raUseSisAccount+WaitForExecution+Failed)/TS
!Deletes the image ID
RunAsEx('%NiBinDir%\niprep.exe','/d','','','5','_return',raUseSisAccount+WaitForExecution+Failed)/TS
!Remove client identification
RunAsEx('%NiBinDir%\niprep.exe','/r','','','5','_return',raUseSisAccount+WaitForExecution+Failed)/TS
!Erase all packages from the repository cache
RunAsEx('%NiBinDir%\niprep.exe','/e','','','5','_return',raUseSisAccount+WaitForExecution+Failed)/TS
!
!# delete old sysprep files
If CheckPlatform(cpWinSevenx64) or CheckPlatform(cpWinSrv2008x64)
 MakeDir('%WINDIR%\System32\Sysprep')/x64/TS
 If Exist('%WINDIR%\System32\Sysprep\unattend.xml')/x64
  Delete('%WINDIR%\System32\Sysprep\unattend.xml')/F/x64/TS
!
!# Create answer file for sysprep
 HIER DIE UNATTEND.XML WIE GEWÜNSCHT EINFÜGEN

EndProc/x64/TS
! # RunAsEx wird in Version 7.2 trotz deaktivierter 64 Bit Redirection immer in den 32 Bit Zweig umgeleitet, daher unbedingt ExecuteEx verwenden.
ExecuteEx('%WINDIR%\System32\Sysprep\Sysprep.exe /generalize /oobe /reboot /unattend:"%WINDIR%\System32\Sysprep\unattend.xml"','_return','20')/?/x64/TS
!
EndInstallerSession

In diesem Paket wird ein Image Objekt in der Image Library angelegt, der DSM Client generalisiert und der Repository Cache gelöscht. Es wird auf die Erstellung der DSM Imaging Gruppe verzichtet. Ziel der Implementierung ist eine möglichst nahtlose Integration in bestehende Konzepte. Im Anschluss wird Windows generalisiert und ein Reboot durch sysprep durchgeführt. 

Dieses Paket sollte als allerletztes Paket laufen, daher ist es wichtig, die Installationsreihenfolge des Paketes möglich hoch zu setzen. Nach Ausführung dieses Paketes ist der Client durch den ausgeführten Sysprep nicht mehr benutzbar und muss neu installiert werden. Soll noch ein Windows XP oder Windows Server 2003 System vorbereitet werden, müssen die sysprep Dateien von der Windows CD in das Paket integriert werden und der sysprep Aufruf entsprechend angepasst werden. Wichtig zu beachten ist, dass alle Aktionen die Massendaten des Paketes betreffen (also auch die Kopie von sysprep Dateien auf die lokale Festplatte), immer vor der Ausführung von "niprep.exe /e" (Löschen des Repository Cache) durchgeführt werden müssen. 

Nach der Durchführung von sysprep wird durch Sysprep ein Reboot forciert. Durch den Befehl ModifyObjectProperty(f_CurrentComputer,'CustomGenCompClientProps','Imaging','02') ist sichergestellt, dass der Computer nun zusätzlich Mitglied der Gruppe "02 (Capture Image-Master)" ist. Durch die ODER Verknüpfung des Filter in der Gruppe "01 (Install Image-Master)" ist sichergestellt, dass der Computer keine Policies verliert und DSM nicht versucht Deinstallation durchzuführen oder rote Policy Instanzen erzeugt. 

Erstellen der Image Datei

Zuweisen des Capture Paketes

Um den Inhalt der Festplatte eines Computers in eine Image Datei zu schreiben, kann bei Nutzung des mitgelieferten Tools "drivesnapshot" das Paket FRS Paket "DriveSnapshot Capture (with WinPE)" unverändert verwendet werden. Soll ein anderes Tool (z.B. ImageX) verwendet werden, kann dieses Paket als Vorlage dienen. Diese Paket verwendet die Infrastruktur Variablen "Disk Image*" die in der Sektion "OSD Proxy Settings" abgelegt sind. Hier ist also zuvor der Netzwerkshare, dass Kennwort und das Passwort für die Ablage der Image Datei zu definieren. 

Soll eine Integration in eine VDI Umgebung stattfinden, wird ein Paket erstellt, welches an dieser Stelle den Snapshot in der Virtualiserungsumgebung via Powershell initiiert.

Das Paket wird auf die Gruppe "02 (Capture Image-Master)" zugewiesen und das BootEnvironment in den ODS Variablen passend auf Basis der Gruppe eingestellt. Im Falle von Drivesnapshot ist zu beachten, dass ein 32 Bit Bootenvironment verwendet wird. 

Installation des Image-Masters und Sichern der Image Datei

Nun kann ein beliebiger Computer im Unternehmen verwendet werden, um eine Image Datei zu erstellen. Der Computer wird wie jeder andere Computer in der DSM Umgebung angelegt und alle Eigenschaften und ODS Variablen werden wie gewünscht eingestellt. Die clientseitige Eigenschaft "Imaging" wird dabei auf "01 (Install Image-Master)" gestellt.

Der Computer sollte nun durch folgende Schritte laufen:

• Installation Betriebssystem
• Installation aller notwendigen Software
• Installation aller freigegebenen und zugewiesenen Patches
• Generalisieren der DSM Komponenten und Erstellung eines Image Objekt in der "Image Library"
• Durchführen eines Sysprep und Neustart 
• Starten von Windows PE und erstellen einer Image Datei

Nach dem Schreiben der Image Datei in das zentrale Image Verzeichnis wird nun ein neues OS-Set auf für das Betriebssystem Deployment via image Datei erstellt. Es können dabei alle FRS Vorgaben verwendet werden. Als Setup Source File wird die gerade erstellte Image Datei verwendet. DSM erstellt aus den Angaben nun ein OS-Set mit einem OS Configuration Package. 

Installieren eines Client auf Basis der Image Datei

Erstellen des OS-Sets

Das zuvor erstellte OS-Set wird nun um ein neues PreOS Action Package erweitert. Dieses PreOS Action Package enthält den folgenden Befehl: 

(echo CurrentComputer.CustomGenCompClientProps.Imaging=03)>_result.txt (Beschreibung siehe hier)

Dieser Befehl sorgt dafür, dass die Imaging Eigenschaft auf 03 gesetzt wird und der Computer, der das Image erhalten soll, in die dritte Imaging Gruppe aufgenommen wird (Dies kann natürlich auch manuell geschehen, ist aber der hohen Anzahl von Objekten schwer handhabbar). Dieser Befehl kann alternativ auch in das OSConfiguration Package integriert werden, allerdings müsste dies bei der Nutzung mehrerer OSConfig Pakete auch mehrfach durchgeführt werden, daher die Auslagerung in eine eigenes PreOS Action Package. Nun kann gemäß dem Standard der Konzept der vorliegenden DSM Umgebung das OS-Set zugewiesen werden (i.d.R. eine zusätzliche statische oder dynamische für das Betriebssystem).

Zuweisen der zusätzlichen Software

Auf die Gruppe "03 (Release Image-Clone)" wird nun alle Software zugewiesen, die ausschliesslich auf dem Image Clone laufen soll und deren Installation auf der Gruppe "01 (Install Master-Image)" via Deny-Policy verhindert wurde.

Um Software auf dem Image-Clone wiederholt laufen zu lassen, muss ein kleiner Trick angewendet werden. Mit der Einführung von DSM 7.2 hat die neue Paketeigenschaft "Allow multiple exexcution" Einzug gehalten. Diese Eigenschaft sorgt theoretisch dafür, dass ein Paket nun ebenfalls auf der Gruppe "03 (Release Image-Clone)" zugewiesen werden kann und wiederholt auf dem Client ausgeführt wird. Leider sorgt aber das Image Objekt in der Image Library (welches über alle Pakete im Master-Image eine Registrierung pflegt) dafür, dass die betroffende Policy sofort auf grün gesetzt wird, ohne dass das Paket ein zweites mal ausgeführt wird. Um dieses Verhalten zu umgehen, wird in die betreffenden Pakete ein Installationsparameter als Boolean Wert aufgenommen. Der Installationsparameter trägt den Namen "IsImageAssignment". Im Anschluss werden die Pakete zweimal zugewiesen. Das erste mal, mit der Einstellung "IsImageAssignment=false", auf die die OU/Gruppe/Computer wo das Paket im normalen (silent) Installationsaublauf installiert werden soll (Von hier bezieht der Image-Master Computer seine Policy Instanz). Das zweite mal wird die Zuweisung auf die Gruppe "03 (Release Image-Clone)" mit der Option "IsImageAssignment=true" durchgeführt. Durch die unterschiedlich gesetzten Installationsparameter wird DSM gezwungen, das Paket mehrfach zu installieren.

Start der Installation eines Image-Clones

Sind alle Zuweisungen durchgeführt, wird ein beliebiger Client in DSM angelegt und gemäß des Standardrichtlinien der vorliegenden DSM Umgebung in Gruppen aufgenommen, sowie dessen Eigenschaften und ODS Variablen konfiguriert. Im besten Fall erhält der Image-Clone Computer die identischen Zuweisungen, wie zuvor der Image-Master Computer. Einziger Unterschied ist, dass dem neuen Client nun das zuvor neu erstellte Imaging OS-Set zugewiesen wird, anstatt eine normale Silent Installation. 

Wird der Computer hochgefahren, durchläuft er nun die folgenden Schritte: 

• Starten von WinPE
• Zurücksichern des Images
• Anwenden der Einstellungen in der unattend.xml (aus dem Standard FRS OSConfig Paket)
• Hochfahren des Clients
• Setzen aller Policy Instanzen auf "grün" die im assoziierten Image Objekt registriert sind
• Installation aller Pakete deren Installation auf der dynamischen Gruppe "01 (Install Master-Image)" verboten war und nun auf der Gruppe "03 (Release Image-Clone)" zugewiesen sind
• Installation aller Pakete die doppelt zugewiesen sind (IsImageAssignment=true)

Fazit

Mit Hilfe der hier beschriebenen Lösung kann sowohl die vollautomatische Erzeugung eines Images, als auch die Verteilung des Images auf beliebig viele Clients, in nahezu jede beliebige Umgebung implementiert werden. Die Installationszeit pro Computer verkürzt sich dabei von durchschnittlich 3 Stunden (Schätzwert für einen Win7 SP1 Client mit Standard Office Software und MS Patchen) auf ca. 20 Minuten.

Der Aufwand für die Implementierung und das Testen dieser Lösung sollte sich je nach Umgebung auf 1-5 Tage beziffern. Die Erstellung eines Images erfordert aktive Tätigkeiten von ca 20 Minuten. Dazu kommen Wartezeiten für die Distribution eines neuen Images im Unternehmen.