Erstellen einer Windows PE (WinPE) mit dem Windows Assessment and Deployment Kit (ADK)
UPDATE für Windows ADK siehe unten! - Ursprünglicher Artikel vom 18.10.2012
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:
1 | 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):
1 | 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"
1 2 3 | 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:
1 2 3 4 5 | 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:
1 | 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:
1 | MakeWinPEMedia /ISO C:\WinPE C:\WinPE\WinPE.iso |
-> Für CD-ISO
1 | 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | 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: |
Stand-alone DHCP-Server plus DHCP-Server in Domäne gleich Problem?!
Wenn man einen DHCP-Server betreibt, dann sollte dies bevorzugter Weise in einer Domäne geschehen – also mit dem DHCP-Server als Mitglied des Active Directory. Dort benötigt dieser eine Autorisierung, welche dafür sorgt, dass dieser Server dann auf eingehende Anfragen (DHCP Request) reagiert. Solange er nicht autorisiert ist, vergibt er auch keine Adressen. Soweit so gut.
Wenn man einen DHCP-Server NICHT in Active Directory integriert, kann man ihn auch nicht autorisieren, er verrichtet dennoch seine Dienste – bis er auf einen autorisierten Server trifft!
Dann nämlich wird der nicht autorisierte Server (der nicht Mitglied der Domäne ist) seinen Dienst einstellen und selbst wenn man ihn wieder manuell aktiviert sich sofort wieder abschalten.
Damit ist es also nicht so ohne Weiteres möglich, zwei DHCP-Server im selben Netz zu betreiben. Nun kann es aber sein, dass genau das gewünscht ist – weil die Server z.B. Adressen für unterschiedliche MAC-Adressen verteilen. Hier muss man also eingreifen und den nicht-autorisierten DHCP Server daran hindern, sich abzuschalten.
Das “Zauberwort” hier heißt “Rogue Detection” – und genau die muss deaktiviert werden.
Dies geht nicht über eine GUI, sondern muss über eine Registrierungswert geändert werden. Dieser heisst
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
\DisableRogueDetection
Mittels des folgenden Aufrufs lässt sich der Eintrag recht schnell anlegen:
reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DHCPServer\Parameters /v DisableRogueDetection /t REG_DWORD /d 1
Dieser Schlüssel ist sehr oberflächlich in folgendem KB-Artikel bei Microsoft beschrieben:
AutoAdminLogon für Windows Server 2012 R2 und andere OS
Manchmal besteht der Wunsch, auf einem Windows-System eine automatische Anmeldung nach dem (Neu)Start durchzuführen. Dies ist mit sehr einfachen Mitteln möglich und funktioniert sowohl bei Client- als auch Server-Betriebssystemen, auch bei älteren. Nötig ist dazu nur der Zugriff auf die Registry und ein passendes Benutzerkonto.
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…
PowerShell: Anmelde-Konto der Windows-Dienste überprüfen
Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:
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:
Windows Server 2012 R2: Netzwerk-Profil mit PowerShell von “Öffentlich” auf “Privat” ändern
Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln:
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:
WDS und SCCM oder 2x WDS parallel betreiben / Probleme mit PXE lösen
Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:
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!
Hyper-V und USB-Datenträger
Oft liest und hört man, dass Hyper-V nicht mit USB-Datenträgern umgehen kann/könne. Dies wird mit der Generation-2-VM unter Windows Server 2012 R2 (Hyper-V 4.0) anders. Dort ist es dank des “Erweiterten Sitzungsmodus” möglich, eine Hyper-V VM auch ohne Netzwerk per RDP anzusprechen und dabei auch Laufwerke mitzunehmen.
Aber: Auch unter den älteren Hyper-V-Versionen bzw. auch bei Generation-1-VMs lassen sich USB-Datenträger mit in die VM “hineinreichen”. Dies klappt allerdings leider nur dann, wenn sich der Datenträger als Festplattenlaufwerk präsentiert (i.A. also bei USB- und Firewire-Festplatten). Dazu muss folgendermaßen vorgegangen werden:
1. Datenträger am Host-System über die Datenträgerverwaltung offline schalten:
(Die Datenträger-Verwaltung erreicht man bei Windows 8 bzw. dem Server 2012 am einfachsten mit [WIN]+[X])
Dann kann man per Rechtsklick auf den gewünschten Datenträger diesen offline schalten:
2. Den Datenträger als Pass-Through-Disk an die Hyper-V VM als neues Laufwerk anbinden:
(Da Hyper-V mit dem SCSI-Controller auch hotplug-fähig ist, klappt dies sogar, während die VM läuft)
Statt einer vorhandenen virtuellen Festplatte wählt man eben unten eine physische Festplatte aus; hier werden nur Datenträger zur Auswahl angeboten, die beim Host offline sind.
3. Datenträger an der VM online schalten und benutzen:
In der Datenträgerverwaltung des Gast-Systems taucht nun eine Festplatte auf, die aber noch offline ist. Analog zum Offline-Schalten im ersten Schritt erfolgt hier nun die Online-Schaltung:
Anschließend steht die USB-Festplatte in der Gastbetriebssystem-Umgebung zur Verfügung:
Vor dem Trennen der USB-Platte sollte diese sauber (den bisherigen Weg rückwärts) ausgehangen werden, um Datenverlust o.ä. zu vermeiden.
PowerShell: Alle Windows-Updates automatisch entfernen
Das entfernen ALLER Windows-Updates von Hand ist sehr mühsam. Die PowerShell schafft hier abhilfe. Das folgende kleine Skript ermittelt alle installierten Windows-Updates und entfernt diese der Reihe nach:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | $hotfixes = Get-WmiObject -Class Win32_QuickFixEngineering | select hotfixid foreach($hotfix in $hotfixes) { $KBNummer = $hotfix.HotfixId.Replace("KB", "") $Kommando = "wusa.exe /uninstall /kb:$KBNummer /quiet /log /norestart" Write-Host ("Removing update with command: " + $Kommando) Invoke-Expression $Kommando While (@(Get-Process wusa -ErrorAction SilentlyContinue).Count -ne 0) { Start-Sleep 1 Write-Host "Waiting for update removal to finish ..." } } |
WSUS offline installieren / Abhängigkeiten automatisch installieren
Will man den WSUS-Server ohne eine Internetverbindung installieren, ist der klassische Weg über den Server-Manager ("Rolle hinzufügen") nicht geeignet, da dieser die notwendigen Daten aus dem Internet bezieht.
Als Alternative kann man sich das WSUS-Setup bei Microsoft frei herunterladen. Allerdings benötigt dieses einige Rollen und Rollendienste sowie Features, die man nun "von Hand" installieren muss (Beim Weg über den Servermanager wären sie automatisch mit ausgewählt worden).
Um nun diese Installation der Abhängigkeiten zu vereinfachen, ist dieses kurze PowerShell-Skript geeignet:
1 2 | Import-Module ServerManager Get-WindowsFeature OOB-WSUS | Select -exp DependsOn | Add-WindowsFeature |
Speicherhunger der WSUS-Datenbank (WID) begrenzen
Insbesondere in kleinen und mittleren Unternehmen läuft der Windows Server Update Service (WSUS) nicht auf einem vollwertigen SQL-Server, sondern auf einer Windows Internal Database, welche bereits Bestandteil des Windows Server 2008 (R2) ist, und somit direkt bei der Installation von WSUS mitinstalliert werden kann.
Das Problem: Wenn es um Arbeitsspeicher geht, verhält sich die WID wie ein "großer" SQL-Server - sie nimmt was sie bekommen kann.
Dieses Verhalten lässt sich beim regulären SQL-Server u.a. mit dem SQL Server Management Studio beeinflussen. Dieses Programm ist allerdings nicht Bestandteil der WID-Installation.
Die Lösung: Das frei erhältliche SQL Management Studio Express bietet genau diese Möglichkeiten.
Vorgehensweise:
1. SQL Management Studio Express downoaden
http://www.microsoft.com/de-de/download/details.aspx?id=8961
2. SQL Management Studio Express installieren
Ist nicht weiter schwer, einfach den Setup-Assistenten benutzen...
3. Verbindung zur WID aufbauen
Dazu muss das Management Studio u.U. als Administrator ausgeführt werden. Als Verbindungsziel wird
\\.\pipe\mssql$microsoft##ssee\sql\query
verwendet.
4a. Konfiguration mittels T-SQL
Nun müssen folgende beiden T-SQL Abfragen ausgeführt werden:
sp_configure 'show advanced options', 1;
reconfigure;
go
"Ausführen" anklicken
sp_configure 'max server memory', 256;
reconfigure;
go
(Den Wert 256 durch das gewünschte Maximum ersetzen )
"Ausführen" anklicken
4b. Konfiguration mittels GUI
Rechtsklick auf den obersten Eintrag im Objekt-Explorer, im Kontextmenü "Eigenschaften" auswählen
Im neu geöffneten Fenster den Bereich "Arbeitsspeicher" wählen und dort den minimalen und den maximalen Speicherwert eintragen.
Das war es schon gewesen. Evtl. muss die Datenbank neu gestartet werden...