[Deployment von MSP-Updates über WSUS: Teil 1 (Konfiguration) | How the ESCde does IT]
http://infrablog.escde.net/2011/03/18/deployment-von-msp-updates-uber-wsus-teil-1-konfiguration/

[Deployment von MSP-Updates über WSUS: Teil 2 (Paketerstellung für Adobe Reader X) | How the ESCde does IT]
http://infrablog.escde.net/2011/03/31/deployment-von-msp-updates-uber-wsus-teil-2-paketerstellung-fur-adobe-reader-x/

Beim zweiten Artikel empfiehlt es sich, auch einen Blick auf den ersten Kommentar zu werfen, der einen zusätzlichen Trick mit Hilfe eines SQL-Kommandos hinzufügt.

Verwandte Beiträge:

1. SP1-Problem bei Windows 7 und 2008 R2: WSUS-Installation optimiert
   Ein Eintrag im WSUS-Teamblog weist darauf hin, dass das Service...
2. Get WSUS Content .NET: Updates flexibel
   Updates sind wichtig – oder wie installiert man möglichst bequem...
3. Microsoft-Updates ohne WSUS verteilen – Teil 1
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...

Ich weiß nicht ob ich der einzige Admin auf dieser Welt bin, der in einem mittelständischen Unternehmen (wie Nils immer sagt 50 – 50.000 Mitarbeiter *g) arbeitet und keine Clientmanagementlösung (ConfigMgr o.ä.) im Einsatz hat.

Was bedeutet das für uns und unserer in ganz Deutschland verteilten Kassensysteme?

Patches in der Testumgebung testen – und dann ausrollen. Aber wirklich auf alle Systeme gleichzeitig?

Viel geschickter wäre es doch, diese gestaffelt auszurollen und dann auch noch immer erst mal nur eine Kasse pro Filiale. Und erst wenn das läuft noch Kasse 2, 3 usw.

Natürlich kann man den "theoretischen" Installationszeitpunkt per GPO einstellen und natürlich kann man auch über WSUS-Gruppen dafür sorgen, dass nicht für alle Gruppen alle Updates genehmigt werden.

In einem interessanten Gespräch bei der ice:2011 in Lingen mit Andreas S. hat mir dieser von einem selbst erstellten Script erzählt, welches die Windows-Update-API antriggert, wodurch sich Updates scriptgesteuert herunterladen und installieren lassen. Nachdem er mir das Script freundlicherweise zur Verfügung gestellt hat, habe ich mir dies zusammen mit unserem Programmierer mal angesehen und sind nach ein wenig "BING it" auch im Netz beim MSDN fündig geworden.

Dieses Script triggert die WUA-API, lädt alle benötigten Updates vom WSUS Server auf den Client und installiert diese. Hierbei werden auch Updates, welche zusammen installiert werden sollten oder solche, die aufeinander aufbauen in Gruppen zusammengefasst. Außerdem erkennt das Script ob ein Reboot benötigt wird und führt diesen auf Nachfrage auch aus.

Wir haben das Originalskript so verändert, dass es, wenn es Updates gefunden hat, unsere Antiviren Lösung stoppt (Zeile 22-25 – das beschleunigt das Update auf unseren Kassensystemen um Faktor 10) und den Reboot automatisch ohne Nachfrage durchführt bzw. das AV-Programm wieder startet (Zeile 98-100), sollte kein Reboot benötigt werden.

Das Script wird wie folgend lokal ausgeführt:

cscript WUA_SearchDownloadInstall.vbs

oder Remote per PsExec

"PsExec.exe \\RECHNERNAME -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs"

Um mehrere Rechner von einer Remotemaschine anzutriggern, könnte man die @File-Option von PsExec nutzen – leider werden diese dann nacheinander ausgeführt, was deutlich zu zeitaufwändig ist.

Eine Quick-and-Dirty-Lösung ist es, für eine überschaubare Anzahl an Clients diese in ein Batch einzubauen:

start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME1 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs"
start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME2 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs"

Hier wird jetzt für jeden Rechner ein CMD-Fenster geöffnet.

Wenn man sich das Resultat noch ansehen will kann man den Befehl um ein & pause ergänzen:

start c:\windows\system32\cmd /c "PsExec.exe \\RECHNERNAME2 -u DOMAIN\USER -p PASSWORD -e cscript \\SERVER\SHARE\WUA_SearchDownloadInstall.vbs & pause"

Download modifiziertes Script WUA_SearchDownloadInstall_tap.vbs

Getestet unter Windows XP 32bit SP3, Windows 7 32bit SP1, Windows Server 2008 32/64bit inkl. R2

Happy Patching

www.ewig-drohendes-versagen.de

Verwandte Beiträge:

1. Get WSUS Content .NET: Updates flexibel
   Updates sind wichtig – oder wie installiert man möglichst bequem...
2. Microsoft-Updates ohne WSUS verteilen – Teil 1
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
3. SP1-Problem bei Windows 7 und 2008 R2: WSUS-Installation optimiert
   Ein Eintrag im WSUS-Teamblog weist darauf hin, dass das Service...

Durch diese Maßnahme hofft Microsoft Installationsfehler zu vermeiden, die es bislang oft bei der WSUS-basierten Installation des SP1 gegeben hatte. Daher scheint es jetzt sicherer zu sein, das SP1 im WSUS zur Installation freizugeben. Wie bei jedem Service Pack ist aber auch hier weiterhin Aufmerksamkeit nötig, denn ein SP ist nun mal kein normaler Patch – schon aufgrund seiner Größe und des temporären Speicherplatzes, den er braucht.

[Windows 7 / Windows Server 2008 R2 Service Pack 1 updates available on WSUS have been revised - WSUS Product Team Blog]
http://blogs.technet.com/b/wsus/archive/2011/04/12/windows-7-windows-server-2008-r2-service-pack-1-updates-available-on-wsus-have-been-revised.aspx

Verwandte Beiträge:

1. Service Pack 1 per WSUS macht Probleme
   Zahlreiche Meldungen – und leider auch Erfahrungen im eigenen Unternehmen...
2. Windows 7/Server 2008 R2 Service Pack 1: Troubleshooting
   Leider gibt es mit dem Service Pack 1 für Windows...
3. Hinweise zu SP1 für Windows Server 2008 R2 und Hyper-V
   Das Service Pack 1 für WIndows Server 2008 R2 steht...

Dieser Artikel erschien zuerst auf Bents Blog.

Wer öfter Systeme aufsetzen muss (egal ob Server oder Client), weiß, welche Dinge dafür benötigt werden. Das neu einzurichtende Gerät wird ausgepackt, oftmals im Servicebereich der IT-Abteilung aufgebaut und verkabelt. Danach beginnt erfahrungsgemäß die Suche nach dem passenden Datenträger. Geht man von den aktuellen Betriebssystemen für Server (Windows Server 2008 und R2) und Clients (Windows Vista und Windows 7)  in den jeweiligen Sprachen (Deutsch, Englisch, …), Versionen (Standard, Enterprise, …) und Architekturen (x86 oder x64) aus, so kommt da schnell eine beträchtliche Anzahl zusammen. Doch es geht auch viel eleganter – mit Hilfe der Windows-Bereitstellungsdienste im eigenen Netzwerk.

Voraussetzung: Die Windows-Bereitstellungsdienste (WDS) arbeiten nach dem Client-Server-Prinzip. Der Client fragt den Server und erhält darauf eine Antwort. Das bedeutet allerdings auch, dass der Client eine bestimmte Sprache spricht, in diesem Fall PXE (Preboot Execution Environment), in Kombination mit DHCP (Dynamic Host Configuration Protocol) . Diese Funktion muss in der Netzwerkkarte des Clients integriert sein – bei heutigen Modellen ist dies fast immer der Fall. Ferner benötigt man einen Server mit aktuellem Betriebssystem – in meinem folgenden Beispiel einen Windows Server 2008 R2. Diese muss Mitglied einer Domäne (Active Directory) sein, DHCP und DNS muss ebenso verfügbar und funktional sein. Auf dem System selbst wird (abhängig von der Anzahl der Betriebssysteme) entsprechend Festplattenplatz benötigt, doch dazu später mehr. Mit Hilfe des Server-Managers kann man in wenigen Minuten die Rolle "Windows-Bereitstellungsdienste" installieren:

Konfiguration: Nach der Installation muss der Server noch konfiguriert werden, um auf PXE-Anfragen (Preboot Execution Environment) reagieren zu können:

Möchte man aus Sicherheitsgründen nicht allen Computern im Netzwerk (die via DHCP eine IP-Adresse empfangen haben) per PXE antworten, kann man diese Funktion auf bekannte Computer eingeschränkt werden. Diese Computer müssen dann erst in der Domäne vorab bereitgestellt werden:

Über die MMC Active Directory-Benutzer und -Computer muss das Computer-Objekt manuell erstellt werden und als "Verwalteter Computer" mit einer eigenen GUID versehen werden. Der WDS-Server behandelt dann dieses Objekt alsbekannten Clientcomputer.

Bei der oben ausgewählten Richtlinie antwortet der WDS-Server allen Clients – auch hier kann aber die Sicherheit erhöht werden. So kann bei unbekannten Computern eine Administratorgenehmigung erforderlich gemacht werden, erst wenn dieser den Client akzeptiert, kann der Computer das PXE-Abbild laden.

Soll der installierte Client automatisch einer Domäne hinzugefügt werden, kann über verschiedene Filter der zukünftige Name definiert werden. In meinem Beispiel verwende ich die MAC-Adresse der Netzwerkkarte, da diese eineindeutig ist. Die IP-Adresse des Clients findet man sehr schnell in den Adressleases des DHCP-Servers, welcher als eindeutige ID ebenfalls die MAC-Adresse auflistet. Zum Speicherort des Computerkontos muss ich keine weiteren Worte verlieren, die Optionen sind selbsterklärend.

Achtung: Aufgrund eines Fehlers in einer DLL-Datei des WDS Servers muss vor der Nutzung des %MAC Filters einPatch von Microsoft eingespielt werden, da sonst für die MAC-Adresse des Clients ein NULL-Wert generiert wird, der zu doppelten Namenseinträgen führen würde.

Im Register "Start" kann das Verhalten des Clients nach dem PXE-Start definiert werden. Wenn der Client via DHCP eine IP-Adresse erhalten hat, beginnt der PXE-Start. Wird in diesem Fall nicht innerhalb von 3 Sekunden die Taste F12gedrückt, bootet der Client nach der Reihenfolge seiner BIOS-Einstellungen. Diese Option macht aus meiner Sicht am meisten Sinn, da sonst immer das PXE-Abbild geladen werden würde.

Wer die Funktion benötigt, kann für die jeweilige Architektur die unbeaufsichtigte Installation aktivieren. Dafür wird das Windows Automated Installation Kit (WAIK) benötigt, mit dem die Unattend.xml Datei(en) erzeugt werden können. Den automatischen Beitritt des Computers zu einer Domäne habe ich deaktiviert, da ich diese diverse Kundensysteme nicht erst in unsere eigene Service-Domäne (Installationsumgebung) heben möchte.

Abhängig davon, ob der Server auch ein DHCP-Server ist, darf dieser den Port 67 nicht abhören. In meinem Fall habe ich einen eigenen DHCP-Server im Netz der Service-Domäne – soll der WDS Server auf dem DHCP Server funktionieren, müssen beide Haken gesetzt werden.

Alle weiteren Optionen spare ich mir hier – sie sind sowohl selbsterklärend als auch mehr oder weniger in speziellen Umgebungen nötig, wie beispielsweise die Multicast-Übertragungen zum gleichzeitigen "Betanken" mehrerer gleichartiger Clients.

Vorbereiten des Servers: Zunächst muss der gewillte Administrator die Installations- und Startabbilder dem WDS-Server hinzufügen.

Das Startabbild findet man auf dem Installationsmedium im Ordner \Sources, die Datei selber heißt Boot.wim. Für jede Architektur (x86 und x64) wird jeweils ein eigenes Startabbild benötigt. Für die Installationsabbilder empfiehlt es sich, vor dem Hinzufügen selbiger, Gruppen zu definieren. Danach kann das jeweilige Abbild (wiederum aus dem Ordner\Sources, Dateiname Install.wim) hinzugefügt werden. Das folgende Bild zeigt alle unterschiedlichen Versionen vonWindows 7 und Windows Server 2008 R2 (also Kernel 6.1.x):

Wie zu erkennen, lässt diese Liste einen relativ großen Bedarf an Speicherplatz vermuten – doch weit gefehlt. Der WDS-Server führt bei der Erstellung der Installationsabbilder eine Deduplizierung der Dateien durch, dass heißt: Identische Dateien innerhalb mehrerer Abbilder werden nur einmal gespeichert und dann nur noch intern mittels Zeiger verlinkt. Sehr clever und nützlich, da die obige Liste so gerade einmal 11 GByte Speicherplatz verbraucht.

Damit ist der WDS-Server prinzipiell einsatzbereit. Wer allerdings öfter ähnliche oder gleiche Systeme installieren möchte, kann für diese Systeme notwendige Treiber (Display, Netzwerkkarte, SCSI-Controller etc.) im WDS-Server hinterlegen und via Filter automatisch installieren lassen. Das macht beispielsweise für VMware Clients großen Sinn (die sich genau wie physische Server via WDS installieren lassen), da die Treiber für diese Systeme bei jeder Installation identisch sind. Dazu fügt man die gewünschten Treiber im WDS-Server hinzu:

Die einzelnen Treiberpakete können nun noch in Gruppen eingeordnet werden. Ob ein Treiber auf dem zu installierenden Client aktiviert wird, entscheiden Filter. Diese vergleichen die hinterlegten Werte mit denen des BIOS des Clients – im folgenden Beispiel werden nur die Treiber der Gruppe "VMware Treiber" installiert, wenn der Client vom Hersteller "VMware, Inc." stammt:

WDS im Einsatz: Wie verhält sich nun eine Installation durch einen WDS-Server auf einem jungfräulichen System? Wie schon erwähnt macht der Einsatz eines WDS-Servers nicht nur für physische sondern ebenso für virtuelle Clients im Netzwerk durchaus Sinn. Das folgende Beispiel zeigt aber einen physischen Server von Hewlett-Packard, die Screenshots wurden mit Hilfe der HP Integrated Remote Console gemacht:

Beim Starten des Servers kann man sehr oft via Tastendruck den Bootvorgang vom Netzwerk aktivieren (bei HP immer Taste F12). Danach wird das PXE-BIOS der Netzwerkkarte geladen, die (hier im Beispiel) via DHCP eine IP-Adresse vom DHCP-Server 10.0.0.1/24 empfängt:

Im Bild ist die GUID des Servers rot markiert, die man benötigen würde, wenn nur bekannte Clients vom WDS-Server bedient werden sollen und das Computer-Objekt vorher im Active Directory erstellt werden muss (siehe oben). Im Bild wurde der PXE-Boot abgebrochen, da ich nicht innerhalb 3 Sekunden F12 gedrückt hatte – die Netzwerkkarte startet aber wenige Sekunden später den Vorgang erneut.

Nach dem PXE-Boot präsentiert der WDS-Server (im Beispiel 10.0.0.2/24 ) eine Auswahl der erstellten Startabbilder. Der Client lädt anschließend die hinterlegte Boot.wim der auch eventuell benötigte Treiber (Netzwerkkarte) vom WDS-Server lädt:

Nachdem das Startabbild erfolgreich vom Client geladen wurde wird die Installation des Betriebssystems gestartet, alle folgenden Schritte sind auch von Installationen von DVD bekannt:

Fazit: Die Windows-Bereitstellungsdienste (WDS) bieten die Möglichkeit, im internen Netzwerk, Clients die PXE-fähig sind, schnell und unkompliziert mit einem neuen Betriebssystem zu versehen. Die Suche nach einem passenden Datenträger entfällt, wer die Automatisierung völlig ausreizen mag, kann automatische Antwortdateien für die Installationen definieren, Clients automatisch zur Domäne hinzufügen und mit aktuellen Treibern versehen – ein Rollout à la carte.

Verwandte Beiträge:

1. Verwaltung von Benutzerprofilen leicht gemacht mit Helges Profil-Toolkit
   Am vergangenen Wochenende stellte ich mein Benutzerprofil-Toolkit auf der E2E...
2. Installation von NT4-Druckertreibern auf Windows Server 2003
   Für die meisten Drucker gibt es auf der Windows Server...
3. SP1-Problem bei Windows 7 und 2008 R2: WSUS-Installation optimiert
   Ein Eintrag im WSUS-Teamblog weist darauf hin, dass das Service...

Es spielt keine Rolle, ob wir ein Thin, Thick oder Hybrid Image verteilen wollen, wichtig ist nur dass 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 (hier die ID eurer Task Sequence eintragen)
SkipComputerName=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

Noch eine kleine Anmerkung:

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

Hier müssen natürlich die GUIDs der Software eingetragen werde,n 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 bei einer Installation aus einem  einem Deployment Share über das Netzwerk und nicht nur von DVD.

Noch mehr Tips und Tricks zum Thema Windows 7 Deployment unter http://www.eyeonwin.de, dem MDT 2010 und Windows 7 Deployment Blog

Verwandte Beiträge:

1. SP1-Problem bei Windows 7 und 2008 R2: WSUS-Installation optimiert
   Ein Eintrag im WSUS-Teamblog weist darauf hin, dass das Service...
2. Installation von NT4-Druckertreibern auf Windows Server 2003
   Für die meisten Drucker gibt es auf der Windows Server...
3. Windows 7 Deployment: bootstrap.ini und CustomSettings.ini
   In diesem Artikel veröffentliche ich die Einstellungen der CustomSettings.ini und...

Hier geht es erst einmal darum, dass wir eine Übersicht bekommen, welche Einstellungen in diesen speziellen Dateien eine Rolle spielen und was man wie automatisieren kann. Ich habe mir diese Einstellungen mühevoll im Netz zusammen gesucht, leider bietet Microsoft zu diesem Thema nicht sehr viel an. TechNet und auch die MDT2010 Anleitung gibt nicht allzu viel über die ganzen Sub-Parameter preis, deshalb werden hier die wichtigsten Befehle mit 1-2 Sätzen erklärt.

Wozu 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 die bootstrap.ini?

Die beiden Dateien sind auf zwei Wegen erreichbar:

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

…oder der einfacherer Weg ist, direkt aus unserer Deployment Bench, indem 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, dass es sinnvoll ist, hier immer „YES/NO“ einzutragen .

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

SkipBDDWelcome=YES/NO
Der Splashscreen am Anfang kann aus- und eingeschaltet werden. Da hier eine Keyboard-Layout-Auswahl getroffen wird, sollten wir die Werte entsprechend ändern.

SkipLocaleSelection=YES/NO
UILanguage=en-USUserLocale=en-US
KeyboardLocale=0409:00000409
Legt die Ländereinstellung fest. Wir müssen für deutsch de-DE statt en-US eintragen. Hier können auch Hexadezimalwerte stehen (en-US = 0409:00000409), es kann aber auch der Wert de-DE eingetragen werden.

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=\\serverX\usmtshare$
Wenn man mit USMT Userdaten auf ein Share sichern will, kann man hier den Pfad eintragen (UNC-Pfad!). Der Wert NONE zeigt an, dass die Benutzerkonfiguration 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 Ärger während der Installation.

ComputerBackupLocation=\\ServerX\Backup$\
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 (Globally Unique ID), von dem via MDT2010 installierten Sprachpaket, rausfinden. Hierfür müssen wir in der Datei C:\DeploymentShare\Control\packages.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 mitinstallierenm benötigt man diesen Parameter.

SkipApplications=YES/NO
Hier können wir angeben, welche Softwarepakte mitinstalliert werden sollen.
Wenn wir ein fertiges Image nutzen, können wir hier den Installationsschritt einsparen, indem 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:\DeploymentShare\Control\Applications.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 neue 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 (bzw. als ausreichend berechtigter Benutzer) eine Autentifizierung gegen die Domain vornimmt:

DomainAdmin=IchAdmin
Benutzername des Domain-Admin wird hier eingetragen.
DomainAdminPassword=kennwort
Passwort des Domain-Admin wird hier eingetragen.

SkipTaskSequence=YES/NO
Überspringt die Assistentenseite, bei der man die Tasksequence auswählen kann.

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 Variable %ComputerName% zugewiesen werden. Wir haben auch die Möglichkei,t die Seriennummer eintragen zu lassen, dies funktioniert über die Variable %SerialNumber%.

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

TimeZoneName=GMT
Hier kann man die verwendete Zeitzone festlegen.

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 des zu verschlüsselnden Laufwerks)
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
Speichert 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=\\COMPUTER\logs$
Ä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.

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.

Weitere 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=\\MYSERVER\Deploy$
UserDomain=DOMAIN
UserID=admin

SkipBDDWelcome=YES/NO
Den lästigen Willkommen-alles-ist-besser Bildschirm verschwinden lassen.

DeployRoot=\\MYSERVER\Deploy$
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!

Noch mehr Tips und Tricks zum Thema Windows 7 Deployment unter http://www.eyeonwin.de

Verwandte Beiträge:

1. Die Ultra Lite Touch Installation
   Wie im letzten Artikel erwähnt, können wir uns mit dem...
2. Eigene Patches über WSUS ausrollen
   Die Windows Server Update Services (WSUS) verteilen in vielen Unternehmen...
3. Gezieltes installieren von Windows Updates via WSUS
   Jeden Monat fängt das Grauen von neuem an – MS...

Zuerst  hier den AppDeploy Repackager 1.02 runterladen (Anmeldung auf der Webseite ist nötig, der Rest ist aber kostenlos) und auf dem PC lokal installiert. Zweifelsohne ist es bei solch einem Tool,  welches *.msi Dateien anhand von Veränderungen des Systems generiert, besser, es in einer virtuellen Maschine laufen zu lassen. Dazu installiert man sich eine leere virtuelle Maschine, macht einen Snapshot, dann installiert man den AppDeploy Repackager 1.02 und macht wieder einen Snapshot. So kann man bequem beliebig *.msi Pakete erstellen und kann vor jeder Neuerstellung einfach den Snapshot wieder zurück sichern.

Da ich meinen PC gerade neu aufgesetzt habe und noch kein VMware installiert habe, wird VMware Workstation 7.0 unser Testobjekt!

Die Installation

… nichts Heißes …

Jetzt starten wir das Programm

… und wählen dann "Create an MSI setup based on system changes" und wählen dann die *.exe Datei aus, welche wir in eine *.msi Datei umwandeln wollen, in unserem Fall ist das VMware (das muss ich ja sowieso installieren;-) ).

Im nächsten Schritt zeigt uns der AppDeploy Repackager 1.02 eine Liste von Registry-Einträgen und Verzeichnissen, von denen ein Snapshot erstellt wird, um ein Abbild erstellen zu können.

… im nächsten Schritt beginnt der Scan zur Abbild-Erstellung …

… danach beginnt der eigentliche Paketierungs-Prozess, wir wählen die erste Option, da wir ja auch die Software installieren wollen.

Nach ca. 30 Sekunden startet die Installation von VMware, und dann installieren wir VMware Workstation 7 einfach wie gehabt.

Wenn VMware Workstation 7 fertig ist, muss ein Reboot erfolgen,und wenn der PC neu gestartet ist, ruft man wieder den AppDeploy Repackager 1.02 auf.

Dieser erkennt von sich aus, dass ein Vorgang nicht beendet wurde und wir klicken auf "Continue".

Das Programm "erinnert" sich nochmal an seinen letzten State …

… und dann fängt der AppDeploy Repackager 1.02 an, den Orginal-Snapshot mit dem Installations-Snapshot zu vergleichen, um daraus später die  *.msi-Datei paketieren zu können.

Anschießend haben wir die Möglichkeit, bestimmte Dateien noch der *.msi-Datei hinzuzufügen oder wegzulassen. Wir brauchen an dieser Stelle keine Änderungen vorzunehmen.

Logischerweise kann man dann auch für die Registry die Einstellung anpassen (müssen wir aber zum Glück nicht!).

Im nächsten Schritt können wir allen benötigten *.exe-Dateien der Anwendung Verknüpfungen und Icons zuweisen. Weiterhin können wir den Namen und den Zielpfad für das zu erstellende *.msi-Paket ändern.

Danach wird das *.msi-Paket vom AppDeploy Repackager erstellt

FERTIG

Explorer-Ansicht:

Fazit

Der AppDeploy Repackager 1.02 ist ein mächtiges Werkzeug mit dem man sehr  leicht *.msi-Dateien zum Software Deployment erstellen kann.

Noch mehr Tips und Tricks zum Thema Windows 7 Deployment unter http://www.eyeonwin.de

Verwandte Beiträge:

1. Warum ein Software-Patch kein Flicken ist
   Gerade erhalte ich vom Microsoft-Presseservice eine Mitteilung, die ich inhaltlich...
2. Microsoft iSCSI Software Target jetzt für Produktion supported – kostenlos!
   Gestern kam ganz nebenbei eine kleine Sensation in die IT:...
3. VMware Workstation: Inkompatible Festplatte
   Es gibt immer wieder Dinge, die einen unnötig lange aufhalten....

Ich beschäftige mich schon seit mehreren Jahren mit dem Thema Windows Updates. Mich störte bisher immer, dass man zwar Updates bequem online installieren konnte, aber sofern der Rechner neu aufgesetzt wird, ist man den Gefahren aus dem Internet ausgesetzt. Das Problem dabei: Den Schutz dagegen bekommt man nur aus dem Internet. Aus diesem Grunde wurde Get WSUS Content .NET entwickelt.

Es existiert eine Vielzahl von Programmen, die sich um das Thema Updateinstallation kümmern. Die meisten Programme werden von Hand Monat für Monat vom Autor aktualisiert und bereitgestellt. Dabei wird bei den Programmen z.B. manuell eine Information hinzugefügt, ob ein Update ein Securityupdate ist oder nicht. Die meisten Programme berücksichtigen weiterhin nur die Updates, die in der Datei „wsusscn2.cab“ enthalten sind oder vom Microsoft Security Baseline Analyzer gefunden werden. Das Problem dabei ist, dass nicht alle Updates zur Verfügung stehen; die optionalen Updates, die Windows Update anbietet, fehlen in der „wsusscn2.cab“.

Get WSUS Content .NET ist anders. Es nutzt den Windows Update Agent. Dies ist die Methode, mit der Updates über Windows Update gesucht und installiert werden. Der Windows Update Agent berücksichtigt nicht nur einen Teil der Updates, sondern alle, die auch über Windows Update angeboten werden (außer Treiber). D.h., es werden auch Updates für Office, Visual Studio, SQL-Server und mehr gefunden.

Die Software findet sich hier in der jeweils aktuellen Fassung: http://download.winboard.org/details.php?file=1608

Get WSUS Content .NET bietet die Möglichkeit, die Updates automatisch zu installieren. Im Gegensatz zu anderen Programmen hat der Anwender die volle Kontrolle, was installiert wird. Es werden alle Updates ermittelt, aber das heißt nicht, dass diese auch automatisch installiert werden. So kann Get WSUS Content .NET z.B. unter Windows XP das SP3 nicht berücksichtigen, in dem es gar nicht in die Auswahl für Windows XP aufgenommen wird. D.h., dass problemlos alle Updates vor dem SP3 ausgewählt und installiert werden können. So kann mit beliebigen Updates verfahren werden und es wird nur das installiert, was der Anwender wünscht. Weiterhin können auch Updates von anderen Herstellern eingebunden werden. Voraussetzung ist, dass diese mit Kommandozeilenschaltern umgehen können.

Weiterhin kann eine Übersicht über die verfügbaren und installierten Updates angezeigt werden. Sofern Microsoft Excel installiert ist, kann der Bericht dort angezeigt werden:

Abb. 1: Der Rechner wird untersucht

Die Berichtsfunktion ist ausgehend vom Hauptdialog unter „Nach Updates suchen“ zu finden und dort unter „Übersicht anzeigen“ (nur Windows Update Agent).

Abb. 2: Das Ergebnis

Get WSUS Content .NET kann darüber hinaus auf einem USB-Stick eingerichtet werden und ist somit auf jedem Rechner einsatzbereit.

Die Verfahren

Get WSUS Content .NET ist zum einen für Administratoren eines WSUS-Servers gedacht (http://www.grurili.de/HowTo/WSUS3_Server.htm) und für Endanwender. Sie arbeiten mit dem Windows Update Agent. Get WSUS Content .NET arbeitet auch im Modus des Windows Update Agent mit einem WSUS problemlos zusammen.

Windows Update Agent

Updates herunterladen

Ausgehend vom Hauptdialog wählen wir „Nach Updates suchen“ und dann „Alle Updates“. Get WSUS Content .NET nimmt seine Arbeit auf und zeigt im Anschluss die Dateien im Auswahldialog links an. Mit einem Klick auf „>>“ werden alle Updates rechts aufgeführt, bei einem Klick auf „>“ nur das markierte. Auf die gleiche Weise kann mit „<“ oder „<<“ die Auswahl aufgehoben werden. Nach einem Klick auf „Weiter“ werden die Updates heruntergeladen.

Abb. 3: Gefundene und ausgewählte Updates

Updates erfassen

Nach dem Download müssen die Updates noch erfasst werden. Get WSUS Content .NET bietet die Möglichkeit, mehrere Updates auf einem Medium zu vereinen. So können z.B. deutsche Windows XP Updates zusammen neben englischen Windows Vista Updates und französischen Windows Server 2000 Updates existieren. Es werden nur die Updates aufgrund des ermittelten Systems und der Sprache bei der Installation verwendet.

Zunächst müssen die Parameter angegeben werden, mit denen das Update installiert wird. In den überwiegenden Fällen ist dies bei Windows Updates „/passive /quiet /norestart“. Bei Windows Vista, Windows 7 und Windows Server 2008 ist dies einfacher. Dort wird der Parameter automatisch von Get WSUS Content .NET eingetragen.

Weiterhin müssen das Produkt und die Art des Updates angegeben werden. Das Produkt wird anhand des aktuellen Systems automatisch ermittelt und ausgewählt. Die Art des Updates ist mit „update“ voreingestellt. Das bedeutet, dass dies ein „einfaches“ Update ist, welches eingespielt wird. Hierunter fallen meist die Updates, die jeden Monat erscheinen. Unter „Vorbereitung“ fallen z.B. Produkte wie im Beispiel der Internet Explorer. Unter „Service Pack“ fallen Service Packs für das Betriebssystem. Der Grund für die drei Phasen ist schnell erklärt: Z.B. kann ein Update für den Internet Explorer 7 (Phase „Update“) nur installiert werden, wenn der Internet Explorer 7 vorhanden ist (Phase „Vorbereitung“). Der Internet Explorer 7 kann aber nur installiert werden, wenn das Service Pack 2 für Windows XP vorhanden ist (Phase „Service Pack“).

Abb. 4: Erfassung der Updates, hier der Internet Explorer 8

Ein Klick auf „Speichern“ sichert die Einstellungen, der Eintrag wird aus der Liste entfernt und man kann mit dem nächsten Update fortfahren.

Ein Klick auf „Hilfe“ zeigt die verfügbaren Parameter der Updates an.

Updates installieren

Im Hauptdialog wählen wir „Persönliches Updatearchiv verwalten“ und dann „Updates zur Installation auswählen“. Es erscheint folgender Dialog, aus dem die zu installierenden Updates ausgewählt werden:

Abb. 5: Auswahl der Updates, die installiert werden sollen

Das Ergebnis kann z.B. so aussehen:

Abb. 6: Anzeige und Auswahl der Updates

Mittels „>“ wird z.B. der Internet Explorer 8 auf die rechte Seite übertragen. Nur die dort erscheinen Updates werden installiert. Je nach Einstellung wird ein .iso-Image erstellt oder es wird ein Icon auf dem Desktop erstellt.

Nach dem die Installation gestartet wurde, zeigt der folgende Dialog einige Informationen zur Installation an:

Abb. 7: Information über die zu installierenden Updates

Nach einem Klick auf „Weiter“ kann auf Wunsch ein automatischer Neustart eingerichtet werden. Im Anschluss startet die eigentliche Installation und der Rechner wird gemäß der angezeigten Anzahl neu gestartet.

Abb. 8: Die Installation läuft

Das Ende des Vorgangs wird im Anschluss entsprechend angezeigt.

Abb. 9: Die Installation ist beendet

WSUS – Windows Server Update Services

Das Kopieren von Dateien erfolgt auf einfache Weise. Ausgehend vom Hauptdialog wählen wir „Updates extrahieren“ und dann z.B. „KB-Nummern abfragen“. In dem dort erscheinenden Dialogfeld geben wir z.B. „926140,923810“ ein (ohne Anführungszeichen) und klicken auf „Weiter“. Get WSUS Content .NET beginnt die Datenbankabfrage.

Abb. 10: Updatesicht des WSUS

Abb. 11: Eingabe der Updates aus Abbildung 10

Das Ergebnis der Abfrage wird auf der linken Seite aufgeführt. Ggf. werden hier mehrere gleiche Dateien aufgeführt. Dies liegt an der WSUS-API, die die Informationen zurückgibt.

Abb. 12: Auflistung und Auswahl der Updates

Mittels „>“ und „>>“ werden die Dateien rechts aufgeführt und nach einem Klick auf „Weiter“ kopiert. Die Auswahl wird mit „<“ bzw. „<<“ aufgehoben.

Nach dem Download müssen die Updates noch erfasst werden. Get WSUS Content .NET bietet die Möglichkeit, mehrere Updates auf einem Medium zu vereinen. So können z.B. deutsche Windows XP Updates zusammen neben englischen Windows Vista Updates und französischen Windows Server 2000 Updates existieren. Es werden nur die Updates aufgrund des ermittelten Systems und der Sprache bei der Installation verwendet.

Zunächst müssen die Parameter angegeben werden, mit denen das Update installiert wird. In den überwiegenden Fällen ist dies bei Windows Updates „/passive /quiet /norestart“. Bei Windows Vista, Windows 7 und Windows Server 2008 ist dies einfacher. Dort wird der Parameter automatisch von Get WSUS Content .NET eingetragen.

Weiterhin müssen das Produkt und die Art des Updates angegeben werden. Die Art des Updates ist mit „update“ voreingestellt. Das bedeutet, dass dies ein „einfaches“ Update ist, welches eingespielt wird. Hierunter fallen meist die Updates, die jeden Monat erscheinen. Unter „Vorbereitung“ fallen z.B. Produkte wie im Beispiel der Internet Explorer. Unter „Service Pack“ fallen Service Packs für das Betriebssystem. Der Grund für die drei Phasen ist schnell erklärt: Z.B. kann ein Update für den Internet Explorer 7 (Phase „Update“) nur installiert werden, wenn der Internet Explorer 7 vorhanden ist (Phase „Vorbereitung“). Der Internet Explorer 7 kann aber nur installiert werden, wenn das Service Pack 2 für Windows XP vorhanden ist (Phase „Service Pack“).

Abb. 13: Erfassung der Updates

Nachdem die Updates erfasst wurden, können weitere Dateien vom WSUS-Server kopiert und erfasst werden.

Updates installieren

Wir wählen im Hauptdialog „Updates extrahieren“ und dann „Updates zur Installation auswählen“. Es erscheint erneut der Dialog zur Erfassung. Sollte ein Update vergessen worden sein, so kann es hier noch erfasst werden. Mit einem Klick auf „Weiter“ gelangen wir zur Auswahl der Kategorien.

Abb. 14: Auswahl der Kategorie

Abb. 15: Auswahl der zu installierenden Updates

Mit „>“ werden die Dateien rechts aufgeführt und nach einem Klick auf „Weiter“ kopiert. Auf Wunsch entsteht ein .iso-Image oder die Updates werden von der Festplatte installiert. Dieses funktioniert naturgemäß nur, wenn die Updates zum System passen, auf dem der WSUS-Server installiert ist.

Nachdem die Installation gestartet wurde, werden zunächst ein paar Informationen angezeigt.

Abb. 16: Die Installation läuft

Auf Wunsch kann ein automatischer Neustart eingerichtet werden. Im Anschluss startet die eigentliche Installation (hier z.B. der Internet Explorer 8). Das Ende der Installation wird entsprechend angezeigt.

Abb. 17: Die Installation läuft

Abb. 18: Die Installation wurde beendet

Verwandte Beiträge:

1. Microsoft-Updates ohne WSUS verteilen – Teil 1
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
2. Eigene Patches über WSUS ausrollen
   Die Windows Server Update Services (WSUS) verteilen in vielen Unternehmen...
3. Gezieltes installieren von Windows Updates via WSUS
   Jeden Monat fängt das Grauen von neuem an – MS...

Achtung! Zu der hier vorgestellten Software gibt es eine völlig neue Version. Bitte lest also auch diesen Artikel: http://www.faq-o-matic.net/2009/04/16/get-wsus-content-net-updates-flexibel/
(Stand: 16. April 2009)

In meinem Artikel "Microsoft-Updates ohne WSUS verteilen" (Teil 1 und Teil 2 hier zu finden) habe ich beschrieben, wie Microsoft-Updates auf Rechnern installiert werden können, die keinen direkten Zugang zum WSUS-Server haben. Was ist aber, wenn es noch nicht einmal einen WSUS-Server gibt?
 
Wahrscheinlich kennen viele das Problem: Man installiert sein Betriebssystem neu oder spielt ein Image zurück. In beiden Fällen werden die Dateien älter sein, weil die CD weit vor dem heutigen Datum erstellt bzw. das Image früher erstellt wurde. Nur wurden inzwischen Updates herausgebracht, die kritische Sicherheitslücken stopfen. Ohne diese Flicken ist es riskant bis gefährlich im Internet zu surfen; ich gehe hier dabei von einem Windows XP mit dem Service Pack 2 aus.

Und gerade hier liegt das Problem: Möchte man seinen Rechner auf den neuesten Stand bringen, damit man im Internet sicher unterwegs ist, muss man sich aber vorher mit diesem verbinden, um die Updates zu erhalten! Das Problem löst "Get WSUS Content Lite".

Es baut auf "Get WSUS Content" auf, ist aber darauf ausgelegt, Updates in ein persönliches Archiv zu laden, ohne einen WSUS-Server zu besitzen. Dabei hat man die Wahl, einen Rechner mittels des Microsoft Baseline Security Analyzers zu scannen oder ein externes Programm seiner Wahl einzusetzen. Der Vorteil von Get WSUS Content Lite liegt darin, dass es die Möglichkeit bietet, individuell seinen Rechner zu scannen und ein persönliches Updatearchiv anzulegen. Darüber hinaus kann man dann aus seinem Archiv Updates auf verschiedene Arten gezielt entnehmen. Ein weiterer Vorteil besteht darin, dass die gewählten Updates in der richtigen Reihenfolge (aufsteigend nach Datum) automatisch installiert werden. Darüber hinaus können Sie damit weitere Software installieren, z.B. Windows Mediaplayer 11, Windows Internet Explorer 7, das .NET-Framework 2, usw.

Microsoft Baseline Security Analyzer: Erste Wahl

Der Microsoft Baseline Security Analyzer ist die erste Wahl, denn er scannt den Rechner, auf dem er ausgeführt wird, nach sicherheitskritischen Updates. Dabei ist es nicht notwendig, auf die WGA-Prüfung zu achten, denn die Updates werden auf den Rechner heruntergeladen, auf dem das Programm ausgeführt wird. Das ist möglich, da der Microsoft Baseline Security Analyzer die Downloadlinks liefert.

Der größte Vorteil ist aber die individuelle Untersuchung des Rechners. Die anderen erhältlichen Programme enthalten meist nur Updates ohne WGA-Prüfung oder gleich alle sicherheitskritischen Updates, die jemals erschienen sind. Das ist aber in den meisten Fällen übertrieben, denn wenn man z.B. ein Windows XP System mit dem Service Pack 2 einsetzt, ist es nicht erforderlich, alle sicherheitsrelevanten Updates herunterzuladen, die vor der Veröffentlichung des Service Packs lagen. Aus diesem Grunde ist der Microsoft Baseline Security Analyzer die erste Wahl. So scannt er ebenfalls andere Produkte auf Sicherheitslücken, die aktuell auf dem Rechner installiert sind und von ihm unterstützt werden. Werden später weitere Programme installiert, so lässt sich einfach nach diesen Sicherheitsupdates scannen, in dem ein weiterer Scanvorgang durchgeführt wird.

Leider ist es nicht möglich, automatisch alle möglichen Updates zu erfassen, denn der Microsoft Baseline Security Analyzer erfasst nicht die optionalen Updates. Die diversen anderen Programme (z.B. c't Offline Update) erfassen sie ebenso nicht oder liefern nur Updates, die keiner WGA-Prüfung unterliegen. Somit ist es nötig, die restlichen Updates von Hand von den Microsoftservern herunterzuladen und in sein persönliches Updatearchiv einzubinden. Dennoch bietet Get WSUS Content Lite eine bequeme Möglichkeit, die meisten Updates individuell und automatisiert zu erfassen.

Im weiteren Verlauf gehe ich davon aus, dass das Programm gemäß Anleitung eingerichtet ist und alle notwendigen Dateien vorliegen.

Schritt für Schritt: Ermitteln der Updates

Starten Sie "Get WSUS Content Lite", indem Sie die Verknüpfung auf dem Desktop verwenden oder die Datei "GWC_lite.exe" unter C:\bin aufrufen.

Es zeigt sich das folgende Bild:

Abb. 1: Get WSUS Content Lite Hauptdialog

Die Oberfläche ist in mehrere Bereiche unterteilt, die sich wiederum in zwei Hauptkategorien unterscheiden lassen: Einmal die Konfiguration des Programms (linke Seite) und die Verarbeitung der Updates (rechte Seite).

Konfiguration des Programms

- Im ersten Bereich wird das zu verwendende Programm gewählt, welches die Sicherheitsupdates auf den Computer überträgt.
- Im zweiten Bereich geben Sie den Ordner an, in dem die Dateien abgelegt werden sollen. Dies ist Ihr persönliches Updatearchiv.
- Sollten Sie z.B. das Programm der c't ausgewählt haben, haben Sie die Möglichkeit die Windows-Version und die Office-Version auszuwählen. In den anderen Fällen entfällt dieser Schritt, da die Programme nicht so viele verschiedene Systeme gleichzeitig unterstützen.
- Im letzen Bereich auf der linken Seite geben Sie das Zielverzeichnis für die Verarbeitung an.

Verarbeitung der Updates

- Im ersten und zweiten Bereich wählen Sie den Umfang der Updates aus. Sie haben die Wahl zwischen allen Updates, die im persönlichen Updatearchiv liegen, Updates aus einem bestimmten Monat (bzw. Patchday) oder ein ganz bestimmtes Update. Hierbei können Sie einen frei wählbaren Suchbegriff eingeben.
- Benutzen Sie das c't Offline Update, können Sie die Sprache des Systems auswählen. Als häufigste Sprachen stehen Deutsch und Englisch zur Verfügung.
- Je nach Methode, wird auf unterschiedliche Weise der Status der Verarbeitung angezeigt.

Verwenden des Microsoft Security Baseline Analyzers

Wählen Sie den Punkt "Microsoft Baseline Security Analyzer 2.1". Andere nicht dazu passende Optionen werden deaktiviert.

Wählen Sie den Ordner, der Ihr persönliches Updatearchiv werden soll; geben Sie ebenfalls einen Zielordner an. Somit ist sichergestellt, dass im weiteren Verlauf keine unnötigen Fehlermeldungen auftauchen.

Klicken Sie auf "OK". Es erscheint das folgende Fenster:

Abb. 2: Auswahl der Scannermethode

"Get WSUS Content Lite" ermöglicht es dem Benutzer, den Rechner nach noch fehlenden Sicherheitsupdates zu durchsuchen oder nach schon bereits installierten. Um ein ganzheitliches Archiv anzulegen, ist der zweite Punkt bei der erstmaligen Verwendung zu wählen. Später wird nur noch Punkt Eins benötigt.

Der Rechner wird nun gescannt und es erscheint die Frage, ob die gerade ermittelten Updates in das persönliche Archiv heruntergeladen werden sollen. Der Download sieht wie folgt aus:

Abb. 3: Download der Updates

Damit wurden alle Sicherheitsupdates für diesen Rechner ermittelt. An den weiteren Patchdays braucht das persönliche Archiv nur noch aktualisiert zu werden.

Verwenden von anderen Programmen

Sollten Sie eines der anderen Programme verwenden wollen, so wählen Sie dieses aus (z.B. c't Offline Update 4, Winboard Updatebuilder 3, &).

Klicken Sie dann auf  "Externes Programm". Damit starten Sie das gewählte Programm. Im Falle des c't Offline Updaters wird die Datei "UpdateGenerator.exe" gestartet und im Falle des Winboard Updatebuilders die Datei "start.bat".

Sollten Sie ein Programm benutzen, das nicht dort aufgeführt ist, so wählen Sie "Ein anderes Programm" und klicken Sie auf "Externes Programm". Sie werden dazu aufgefordert, die .exe-Datei des Progamms anzugeben. Diese Information wird gespeichert und steht für spätere Aufrufe zur Verfügung. Das Programm wird im Anschluss daran gestartet.

Alle externen Programme haben gemeinsam, dass Sie Updates in ein bestimmtes Verzeichnis herunterladen. Dieses Verzeichnis ist das persönliche Updatearchiv. Sie müssen es "Get WSUS Content Lite" mitteilen. Denn daraus entnimmt es die Dateien für die Verarbeitung.

Auswahl der Updates für die Verarbeitung

Nachdem die Updates auf den Computer übertragen wurden, muss noch eine Auswahl getroffen werden. Sie haben die Wahl zwischen:

- allen Updates aus ihrem persönlichen Updatearchiv
- Updates aus einem bestimmten Monat
- einzelnen Updates

Im ersten Fall werden alle Updates aus ihrem persönlichen Updatearchiv in das Zielverzeichnis kopiert und dort weiterverarbeitet.

Im zweiten Fall werden alle Updates kopiert, deren Datum dem von Ihnen gewünschten entspricht.

Im letzten Fall können Sie ein frei wählbares Suchkriterium eingeben. Es werden alle Dateien kopiert, bei denen das Suchkriterium sich im Dateinamen wiederfindet. Dies ist besondern bequem bei KB-Artikelnummern.

Je nachdem, ob Sie das c't Offline Update gewählt haben, müssen Sie noch das System angeben, für das die Updates gedacht sind, ggf. auch eine Office-Version und die Sprache. Klicken Sie dann auf "OK", und die Dateien werden kopiert.

Im Anschluss daran startet das Programm für die Verarbeitung. Wie die Verarbeitung funktioniert, erfahren Sie im Artikel "Microsoft-Updates ohne WSUS verteilen – Teil 2".

Verwandte Beiträge:

1. Microsoft-Updates ohne WSUS verteilen – Teil 1
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
2. Microsoft-Updates ohne WSUS verteilen – Teil 2
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
3. Get WSUS Content .NET: Updates flexibel
   Updates sind wichtig – oder wie installiert man möglichst bequem...

Achtung! Zu der hier vorgestellten Software gibt es eine völlig neue Version. Bitte lest also auch diesen Artikel: http://www.faq-o-matic.net/2009/04/16/get-wsus-content-net-updates-flexibel/
(Stand: 16. April 2009)

Wer einen WSUS-Server im Netzwerk betreibt, kann sich glücklich schätzen. Dieser übernimmt die Aufgabe, Updates an alle Rechner im Netzwerk zu verteilen. Was ist aber, wenn bestimmte Computer das Netzwerk nicht erreichen können, z.B. bei Außendienstmitarbeitern? Dieses Problem löst "Get WSUS Content".

Aufbauend auf dem WSUS-Server ermittelt "Get WSUS Content", welche Updates für einen bestimmten Rech-ner erforderlich sind. Dies kann ein Referenzrechner sein, der exakt so konfiguriert ist, wie die PCs der Außen-dienstmitarbeiter. Diese Updates werden in einen frei wählbaren Ordner kopiert und dann weiterverarbeitet.

Am Ende liegt ein Medium vor, welches die Updates auf den Zielrechnern automatisch installiert, ohne dass der Benutzer eingreifen muss. Der Vorteil von "Get WSUS Content" liegt darin, dass der gerade angemeldete Be-nutzer diese Updates installieren kann, ohne dass er Administratorrechte benötigt. Die Verschaffung der Admi-nistratorrechte geschieht mittels einer Runas-Variante. Dabei wird das Passwort verschlüsselt hinterlegt, so dass der Benutzer dieses nicht einsehen kann. Außerdem ist ausgeschlossen, dass eine andere Anwendung gestartet werden kann, die die gleiche Bezeichnung wie das Installationsprogramm trägt, um so mit Administratorrechten ausgeführt zu werden. Die Runas-Variante prüft auf Bitebene, ob die auszuführende Datei der vorgesehen Datei entspricht. Ebenso kann "Get WSUS Content" auch mit Administratorrechten ausgeführt werden.

Der große Vorteil von "Get WSUS Content" liegt darin, dass es automatisch Listen generiert, die die Dateinamen der Updates enthalten. Diese Listen können später geändert werden, ohne dass die Schritte des Assistenten erneut vollständig durchlaufen werden müssen. Diese Listen liegen im Textformat vor und können somit mit dem Windows Editor bearbeitet werden. Der Benutzer hat mehrere Möglichkeiten selbst einzugreifen, um das Medium ohne den Assistenten später zu ändern.

Das Erstellen des Mediums läuft in mehreren Schritten ab. Im weiteren Verlauf wird davon ausgegangen, dass das Programm gemäß Anleitung eingerichtet ist, ein Referenzrechner vorliegt und das "Get WSUS Content" von einer Workstation ausgeführt wird.  Das Programm kann natürlich auch vom WSUS-Server aus bedient werden; dann ist aber der Punkt "Aufruf von einem Client aus" zu deaktivieren.

Ermitteln der Updates

Im ersten Schritt müssen die Updates ermittelt werden. Starten Sie "Get WSUS Content", es zeigt sich das fol-gende Bild:

Abb. 1: Get WSUS Content Hauptdialog (Schirmer-Hauptdialog-001.gif)

Klicken Sie auf "Extras anzeigen" und wählen Sie aus dem erscheinenden Listenfeld "Updates eines bestimmten Computers extrahieren". Klicken Sie auf "OK". Es zeigt sich der folgende Dialog:

Abb. 2: Updates eines bestimmten Computers auswählen

Hier stehen mehrere Kategorien zur Auswahl. Wenn ein Update durch den WSUS-Server verteilt wird, melden die Workstations verschiedene Statuskategorien. Diese sind:

• Fehlgeschlagen: Ein Update ist nicht korrekt auf der Workstation installiert worden
• Nicht installiert: Ein Update ist für die Workstation erforderlich, aber noch nicht vom WSUS-Server auf die Workstation heruntergeladen und auf derselben installiert worden
• Heruntergeladen: Ein Update ist für die Workstation erforderlich und auf die Workstation heruntergeladen, aber noch nicht installiert worden
• Installiert: Das Update ist auf der Workstation installiert worden
• Neustart erforderlich: Das Update ist installiert worden, es fehlt aber noch ein Neustart für die vollständige Installation
• Unbekannt: Der Status der Workstation ist unbekannt. Dies tritt auf, wenn die Workstation noch keinen Bericht geliefert hat
• Keine Einschränkung: Es werden alle gerade genannten Kategorien betrachtet. Der Status "Nicht erforder-lich" ist für dieses Programm nicht relevant und wird auch nicht verwendet.

Quelle: http://msdn2.microsoft.com/en-us/library/ms824306.aspx

Wählen Sie den Referenzcomputer aus dem Listenfeld, den Punkt "Keine Einschränkung"  und klicken Sie auf "1. Vorbereiten". Es erfolgt die Abfrage der WSUS-Datenbank über ein VBS-Skript, da die WSUS-API eine Ermittlung der Dateinamen nicht vorsieht. Dabei werden alle Updates ermittelt, die vom WSUS-Server für die ausgewählte Workstation für notwendig erachtet werden. Beachten Sie: Die Updates müssen für die Installation genehmigt sein und auf dem WSUS-Server physisch vorliegen. Erst dann können die Dateien kopiert werden!

Im nächsten Schritt wählen Sie "2. Ermitteln". Sie erhalten einen Hinweis über die Anzahl der Dateien; klicken Sie auf "OK". Im dem dann geöffneten Fenster sehen Sie die Outputdateien. Stimmt dort die Anzahl der Dateien mit der Anzahl aus dem Dialog überein, werden diese dann über die Schaltfläche "3. Umwandeln" zu einer Liste zusammengeführt.

Klicken Sie dann auf "4. Zurück".  Sie sind wieder im Hauptdialog. Auf Wunsch können Sie in die Outputdatei hineinsehen, in dem Sie auf "2. Simulation" klicken.  Klicken Sie dann auf "3. Kopieren". Alle Updates, die in der Liste stehen, werden nun aus den verschiedenen Verzeichnissen vom WSUS-Server in das von Ihnen ge-wählte Zielverzeichnis kopiert; dieser Vorgang kann je nach Bandbreite länger dauern.

Es liegen nun alle Updates vor, die auf dem Zielrechner installiert werden sollen. Wenn Sie nur Updates von einem bestimmten Datum wünschen, wählen Sie die Funktion "Anhand Datum extrahieren". Die Datei "Read-me.pdf" liefert eine genaue Anleitung.

Das Erstellen des Mediums erfolgt im zweiten Teil.

Das Programm findet sich im Download-Bereich von www.wsus.de unter diesem Link.

Verwandte Beiträge:

1. Microsoft-Updates ohne WSUS verteilen – Teil 2
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
2. Microsoft-Updates ohne WSUS verteilen – Teil 3
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...
3. Get WSUS Content .NET: Updates flexibel
   Updates sind wichtig – oder wie installiert man möglichst bequem...