Eine WinPE auf dem USB-Stick oder als CD/DVD ist außerordentlich praktisch. Man kann damit ein defektes Windows reparieren, seine Daten aus einem kaputten Rechner „rausholen“, ein System aus einem WIM-Image installieren, Images erzeugen und und und…

Zum Erzeugen einer solchen WinPE benötigt man entweder das Windows AIK (Automated Installation Kit) oder eben das ADK. In einer kurzen Anleitung möchte ich erklären, wie hier nun vorzugehen ist:

1.) Windows ADK herunterladen und installieren

Siehe hier: http://www.microsoft.com/de-de/download/details.aspx?id=30652

Bei der Installation reicht es, die „Windows Preinstallation Environment“ auszuwählen, der Rest ist hierzu nicht notwendig.

2.) Es gibt jetzt im Startmenü beim ADK eine „Umgebung für Bereitstellungs- und Imageerstellungstools“. Diese muss (evtl. als Administrator) gestartet werden

3.) In der sich nun öffnenden DOS-Box wird nun das Grundgerüst der WinPE erzeugt. Dazu verwendet man den Befehl:

copype.cmd [x86 | amd64] C:\WinPE

Der erste Parameter gibt an, ob die Umgebung für 32- oder 64-Bit gebaut wird. Mit einer 32-Bit-Variante ist man natürlich deutlich flexibler. Der zweite Parameter gibt an, wo die WinPE erzeugt werden soll, es habdelt sich hier um einen Pfad, der noch nicht existieren darf!

Nach dem Ausführen des Kommandos (welches einige Dateien kopiert) landet man im als Ziel angegebenen Ordner. Unter „media“ befindet sich nun das, was später Bestandteil der WinPE sein wird. Hier kann man weitere Tools hinzufügen, z.B. „imagex.exe“ (einfach mit in den media-Ordner kopieren):

copy "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\x86\DISM\imagex.exe" C:\WinPE\media\

4.) WinPE mit deutschem Tastaturlayout

Das „original“ WinPE ist in Englisch mit englischem Tastaturlayout – das kann stören. Mit ein wenig Arbeit lässt sich das deutsche Layout installieren und aktivieren. Dazu muss die boot.wim, welche sich im meda\sources-Pfad befindet mit dism.exe gemountet und verändert werden.

Das deutsche Language-Pack befindet sich in „C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de“

dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de\lp.cab"
dism /image:C:\WinPE\mount /Set-AllIntl:de-DE

Dieser befehl wollte abgeschlossen werden mit:

Das Eingabegebietsschema wurde festgelegt auf: de-DE
Das Systemgebietsschema wurde festgelegt auf: de-DE
Das Benutzergebietsschema wurde festgelegt auf: de-DE
Die Benutzeroberflächensprache wurde festgelegt auf: de-DE
Der Vorgang wurde erfolgreich beendet.

Sonst liegt ein Fehler vor…

Nun noch das Image zurückschreiben:

dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit

5.) Erzeugen der WinPE

Es gibt 2 Möglichkeiten: Einmal in Form einer ISO-Datei (für CD/DVD) oder direkt auf einen USB-Stick (Vorsicht: Dieser wird dabei formatiert, vorhandene Daten gehen verloren!)

Die beiden Befehle lauten:

MakeWinPEMedia /ISO C:\WinPE C:\WinPE\WinPE.iso

-> Für CD-ISO

MakeWinPEMedia /UFD C:\WinPE G:

-> Für USB-Stick/-HDD, G: ist der Buchstabe des USB-Datenträgers, hier kein \ verwenden

Das wäre es schon gewesen – die ISO bzw. der USB-Stick lassen sich jetzt booten…

Update vom 17.12.2017:

Für Windows ADK 10 ändern sich die Pfade und damit auch die Kommandos. Ich habe diese hier nochmal für 64 Bit (amd64) zusammengestellt. Dabei werden auch ein paar nützliche Pakete (u.a. PowerShell) hinzugefügt.

copype.cmd amd64 C:\WinPe
dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\lp.cab"

dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-NetFx.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-NetFx_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-PowerShell.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-PowerShell_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-Scripting.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-Scripting_de-de.cab"

dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit

MakeWinPEMedia /UFD C:\WinPE G:

Wenn man jetzt die Infos über die nicht mehr vorhandenen Sicherungen löschen will, um eine saubere “Statistik” zu haben, kann man sich eines PowerShell-Cmdlets bedienen: Remove-WBBackupSet.

Der Aufruf dazu sieht so aus:

Remove-WBBackupSet –MachineName SERVERNAME -KeepVersions 4

Der Parameter –KeepVersions gibg dabei an, wieviele der letzten Sicherungen man behalten möchte. Alternativ kann man mit –DeleteOldest die X ältesten Sicherungen entfernen.

Bei dem Aufruf wird es aber sehr wahrscheinlich zu vielen Fehlern kommen, wie man im Screenshot sieht. Da die Sicherungen nicht mehr erreichbar sind, das Cmdlet aber eigentlich die Files dazu löschen würde, muss man sich hier zusätzlich des –Force Parameters bedienen:

Dabei wird die Tatsache, dass die Sicherungen auf der ausgefallenen Platte nicht mehr erreichbar sind, ignoriert und nur der Verweis auf diese Sicherungen entfernt.

Mit dem Aufruf Get-WBBackupSet kann man sich nochmal ausgeben lassen, wieviele Sicherungen Windows Server Backup “kennt”:

https://youtu.be/4bCeqfhoW0c

Häufig kommt es dann aber bei dieser Server-Version später beim Booten der aufzuzeichnenden Maschine zu einem Fehler:

Dieser Fehler tritt dann auf, wenn man:

• auf einem Windows Server 2012 R2 (mit oder ohne Update1) im WDS ein Startabbild (Boot Image) auf Basis eines Windows Server 2012 R2 MIT Update1 oder Windows 8.1 MIT Update1 hinzufügt (dabei ist es dann später egal, auf welchem Startabbild das Aufzeichnungsabbild basiert)
• auf einem Windows Server 2012 (“R1”) im WDS ein Startabbild auf Basis eines Windows Server 2012 R2 mit Update1 oder Windows 8.1 mit Update1 erzeugt

Der Fehler würde NICHT auftreten, wenn man vor dem Erzeugen des Aufzeichnungsabbildes noch nie ein Startabbild von Windows 8.1 Update1 oder Windows Server 2012 R2 Update1 importiert hatte.

Natürlich kann man den Fehler aber auch anderweitig umgehen bzw. beheben:

Dazu hinterlegt man zunächst das gewünschte Startabbild (dabei spielt es keine Rolle, ob bisher ein Update-1-Startabbild hinterlegt wurde oder nicht, das zu hinterlegende Abbild selbst darf auch von einer Update-1-Version stammen):

Danach erzeugt man aus diesem ein Aufzeichnungsabbild:

Dabei sollte man dass entstehende Abbild nicht direkt dem WDS Server hinzugefügt wird:

Anschließend muss das entstandene WIM-File (in meinem Beispiel “C:\aufz.wim”) mittels DISM gemountet werden:

Für das Mounten verwendet man einen Aufruf in dieser Form:

dism /Mount-Wim /WimFile:C:\aufz.wim /index:1 /MountDir:C:\mount

(Achtung: Keine Leerzeichen nach den Doppelpunkten!)

Im Anschluss kann die Datei direkt wieder “unmounted” werden (ohne dass sie dabei inhaltlich wirklich verändert wurde):

Hierzu wird folgender Aufruf verwendet:

dism /Unmount-Wim /MountDir:C:\mount /commit

Das nun neu erzeugte WIM-File kann jetzt als funktionsfähiges Aufzeichnunge-/Startabbild auf dem WDS-Server hinterlegt werden:

Nun kann eine (Test-)Maschine per PXE gebootet werden, es sollte nun, da es mehrere Startabbilder gibt, eine Auswahl möglich sein:

Wenn man das Aufzeichnungsabbild gewählt und die Maschine komplett gebootet hat sollte in etwa folgendes Menü zu sehen sein:

Nun kann die Festplatte der (Test-)Maschine aufgezeichnet werden. Wichtig ist dabei allerdings, dass dies nur funktioniert, wenn man das dort laufende Betriebssystem vorher mit sysprep vorbereitet hat.

Als erstes wird der Registrierungseditor mittels “regedit.exe” geöffnet:

Dort muss zu dem Schlüssel unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon navigiert werden.

Abschließend sind folgende Schlüssel nötig (alle als Zeichenfolge, REG_SZ)

• AutoAdminLogon = “1”
• DefaultUserName = BENUTZER
• DefaultPassword = PASSWORT
• DefaultDomainName = DOMÄNE

So etwa wie im Screenshot…

Das war es schon gewesen. Beim nächsten Neustart ist die automatische Anmeldung aktiv…

Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.

Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]

[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]

[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]

Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.

Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.

Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx 

Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.

Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).

Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):

Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.

Glücklicherweise kündigt sich das bereits vorab an:

Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.

Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.

Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:

Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!

(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)

Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!

Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:

(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)

Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.

Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.

Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:

Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:

Was bleibt nun also? Eine Abfrage mittels WMI!

Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:

Will man statt den “internen” (teil kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:

Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName

Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage:

Auch mit Hilfe der Windows PowerShell kann man dies sehen…

… und ändern!

Mit Hilfe des Aufrufs

Set-NetConnectionProfile –InterfaceIndex # –NetworkCategory Private

wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen:

Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.

Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).

Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:

Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):

Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!

Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:

Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:

Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.

Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!