Archive for the ‘Recovery’ Category

Wiederherstellungsumgebung WinRE.WIM aus Windows ISO-Datei extrahieren

2 Juli 2017

Für bestimmte Zwecke benötigt man die WinRE.WIM-Datei. WinRE ist die Wiederherstellungsumgebung für Windows. WinRE gibt es quasi seit Windows Vista und wurde Version um Version weiter ausgebaut. WinRE.WIM findet vor allem bei aktuellen Windows 10 und Windows Server 2016 Systemen Anwendung.

Um WinRE.WIM zu erhalten gibt es verschiedene Wege. Der einfachste ist auf einem bestehenden System die versteckte Wiederherstellungspartition mit einem Laufwerksbuchstaben zu versehen und dann unter X:\Recovery\WindowsRE mittels

attrib –s –h winre.wim

die WinRE.WIM-Datei sichtbar zu machen. Danach kann man sie wegkopieren.

Allerdings kann es Fälle geben, da möchte man sicher sein, dass die WinRE.WIM-Datei vom Original stammt. In diesem Fall kann man die WinRE.WIM-Datei aus bestehenden ISO-Dateien herauskopieren. Allerdings ist dieser Weg nicht sofort offensichtlich, denn es muss zunächst die ISO-Datei und zusätzlich die INSTALL.WIM-Datei eingehängt werden.

Auf einem aktuellen Windows 10 System mit Powershell-Unterstützung sieht der Vorgang z. B. so aus:

#Requires –RunAsAdministrator
# ISO-Datei sollte als absoluter Pfad angegeben werden, keine Remotelaufwerke, sonst klappt es manchmal nicht:
$iso=’D:\ISOs\de_windows_10_multiple_editions_
version_1703_updated_march_2017_x86_dvd_
10191741.iso‘
$im=Mount-DiskImage -ImagePath $iso -PassThru
If ($im.Attached) {
  $isoDrive=(Get-DiskImage –DevicePath $im.DevicePath | Get-Volume).DriveLetter
}

So nun sollte $isoDrive den Laufwerksbuchstaben des eingehängten ISO-Images haben. Mit diesem kann man dann weiterarbeiten und die Install.Wim einhängen:

# Verzeichnis zum Einhängen von Install.WIM anlegen
md $env:TEMP\WinRE
Mount-WindowsImage -ImagePath "$($isoDrive):\sources\install.wim" -Index 1 -path "$env:Temp\WinRE" -ReadOnly

Nach dem Kopiervorgang kann man nun auf die WinRE.WIM zugreifen:

dir $env:Temp\WinRE\windows\System32\Recovery\Winre.wim

Man könnte sie z. B. in das ADK für WinPE kopieren, damit man eine individuelle RettungsCD erstellen kann:

# bei x86:
copy $env:Temp\WinRE\windows\System32\Recovery\Winre.wim "${env:ProgramFiles(x86)}\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\en-us"

# oder bei x64:
copy $env:Temp\WinRE\windows\System32\Recovery\Winre.wim "${env:ProgramFiles(x86)}\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x64\en-us"

Hat man die Datei dann wegkopiert, sollte man die Umgebung noch wieder aufräumen, damit alles seine Ordnung hat:

Dismount-WindowsImage  -path $Env:Temp\WinRE  -Discard
DisMount-DiskImage -ImagePath $iso

Advertisements

Windows Emergency Management Services (EMS) Konsole

25 September 2015

Mal wieder so eine Sache, die es schon jahrelang gibt, auf die man dann per Zufall stößt. Man kann mittels Emergency Management Services Rechner neu starten, die eigentlich einen Bluescreen darstellen. Offenbar geht dann auch noch Powershell, irgendwie. Da gerade die Zeit fehlt tiefergehende Tests zu machen, hier einfach mal die einschlägigen Ressourcen zum Thema:

https://www.myotherpcisacloud.com/post/Windows-Emergency-Management-Services

Mit dieser (USB):

Bcdedit.exe /EMS ON /EMSSETTINGS BIOS

bzw. dieser (RS-232):

Bcdedit.exe /EMS ON /EMSSETTINGS EMSPORT:COM2 EMSBAUDRATE:9600

Änderung vor einem Problem, kommt man auf die Kiste von extern wieder drauf und es meldet sich die Special Administration Console (SAC), wo man dann eine herkömmliche Shell hat.

Hier bestätigt tatsächlich jemand, dass dort auch Powershell möglich ist: http://serverfault.com/questions/554298/windows-serial-console.

Hier noch Beschreibungen zu den BCDEdit.EXE und EMS-Parameter: https://msdn.microsoft.com/en-us/library/ff542282%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Weitere Infos von MS: http://social.technet.microsoft.com/wiki/contents/articles/2469.windows-server-emergency-management-resources.aspx

Windows 8.1 Images auf neuesten Stand bringen

2 Mai 2015

Hier die offizielle Beschreibung, wie man Images von Windows 8.1 auf den aktuellen Stand bringen kann: https://technet.microsoft.com/en-us/library/dn622020.aspx?f=255&MSPPError=-2147217396.

Dies ist vor allem wichtig, wenn man seinen Rechner auffrischen oder sein Windows über die windowseigene Funktion neu aufsetzen lassen möchte. Führt man obige Anweisungen nicht durch, landet man schnell bei Windows 8.

Aber Vorsicht bei kleineren Geräte mit <= 32GByte Festplatte, da sollte man die Sache nicht anwenden. Der Artikel über WIMBoot geht darauf ein: https://technet.microsoft.com/en-us/library/dn594399.aspx. Microsoft hat damals auch das Disklayout umgestellt, wie die Partitionen künftig aufgeteilt werden sollen.

Wiederherstellen Ihrer persönlichen Dateien nach einer benutzerdefinierten Installation von Windows Vista oder Windows 7

11 Februar 2011

Eine einfache Reparaturinstallation wie unter Windows XP gibt es unter Windows Vista und Windows 7 nicht mehr. Allerdings hilft dieser Artikel, seine Daten wieder zu finden, falls man doch über eine bestehende Installation neu installieren muss: http://support.microsoft.com/kb/932912/en

Wichtig: Der englische Artikel ist zum momentanen Zeitpunkt neuer und detaillierter!

Offline Transfer von Windows Dateien mittels USMT und WinPE

12 November 2010

Dieses Dokument beschreibt Schritt für Schritt wie man Daten eines Offlinesystem per WinPE mittels USMT übernehmen kann:

http://technet.microsoft.com/en-us/library/ee126219(WS.10).aspx

Hier noch einige Hinweise und mögliche Fehlerbeschreibungen mit Lösungen: http://blogs.technet.com/b/askds/archive/2010/02/18/usmt-4-and-winpe-common-issues.aspx

Hier die normale Beschreibung: http://technet.microsoft.com/en-us/library/dd560758(v=WS.10).aspx

Beschreibung was alles mitgenommen wird: http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx#BKMK_4

Wenn die Übernahme nicht klappt, fehlen vielleicht die Manifestdateien: http://blogs.technet.com/b/askds/archive/2010/08/25/don-t-mess-about-with-usmt-s-included-manifests.aspx

Reparaturinstallation unter Windows Vista doch möglich?

15 Januar 2009

Wer eine volle Version von Windows Vista hat, kann evtl. doch eine Reparaturinstallation durchführen. Wie schon in https://newyear2006.wordpress.com/2006/11/20/reparaturinstallation-unter-windows-vista/ beschrieben gibt es eigentlich keine Reparaturinstallation mehr, wie man sie von Windows XP kennt.

Wessen Rechner aber noch Hochfährt und einigermaßen passabel läuft, aber doch bestimmte Macken an den Tag legt, der könnte mit der Reparaturinstallation glücklich werden. Der Trick bei der Geschichte ist, dass man ein Upgrade von Windows Vista auf Windows Vista ausführt.

Dabei ist zu beachten, dass diese Möglichkeit in der Regel nicht mit OEM Versionen von den großen Computerherstellern funktioniert, sondern man benötigt eine sogenannte Retail Version der Vista DVD. Weiters ist zu beachten, das wenn bereits SP1 installiert ist die DVD bereits SP1 enthalten sollte. Ebenso sollte der Rechner noch soweit hochfahren, das man das Setup von der DVD starten kann. Die Methode funktioniert mit 32bit wie auch mit 64bit.

Die einzelnen Schritte sind hier beschrieben: http://www.vistax64.com/tutorials/88236-repair-install-vista.html

Ausgabe von Einträgen aus der Windows Ereignisanzeige eines Offlinesystems

4 November 2008

Wenn man einen Rechner hat dessen Hardware OK aber dessen Windows System nicht mehr startet, dann hilft oft die Verwendung von Windows PE 2.x oder der Windows Vista DVD mit Computerreparaturoptionen und der Eingabeaufforderung weiter.

Oft ist es sinnvoll zu sehen, welche Ereignisse als letztes eingetreten sind. Dazu protokolliert Windows Vista jede Menge Infos in der Ereignisanzeige. Aber in einem Offlineszenario ist der Zugriff auf die Ereignisanzeige nicht so einfach. Aber wie immer gibt es eine Lösung.

Seit Windows Vista gibt es das Commandline Tool WEVTUTIL.EXE mit diesem lassen sich die EVTX-Dateien welche die Ereignisanzeigedaten enthalten auswerten. Das WEVTUTIL-Tool ist mächtig dafür aber auch kompliziert zu bedienen. Es findet übrigens auch Verwendung beim Windows Server 2008 Core.

http://technet.microsoft.com/en-us/library/cc732848.aspx

Führt man WEVTUTIL im Offlineszenario direkt aus, z. B. per

WEVTUTIL GLI SYSTEM

dann erhält man eine Fehlermeldung:

Fehler beim Lesen der Protokollstatusinformationen für Protokoll „SYSTEM“. Die Anforderung wird nicht unterstützt.

Wenn wir schon bei Fehlermeldungen sind, in einem normalen System bekommt man die Meldung

Fehler beim Lesen der Protokollstatusinformationen für Protokoll „systems“. Der angegebene Kanal wurde nicht gefunden. Prüfen Sie die Kanalkonfiguration.

wenn man z. B. systems anstatt system angegeben hat.

Gibt man eine falsche Datei oder eine Datei im alten W2K oder XP Format an, wird folgende Fehlermeldung angezeigt:

Fehler beim Lesen der Protokollstatusinformationen für Protokoll „SysEvent.Evt“.  Die Daten sind unzulässig.

Eine gültige Anzeige für den Parameter GLI sieht z. B. so aus:

creationTime: 2008-04-19T18:28:16.715Z
lastAccessTime: 2008-04-19T18:28:16.715Z
lastWriteTime: 2008-11-01T18:32:06.845Z
fileSize: 20975616
attributes: 32
numberOfLogRecords: 48475
oldestRecordNumber: 178373

Zurück zum Offlineszenario. Das Problem hier ist, dass wenn man WEVTUTIL benutzt, sich alles auf das WinPE System bezieht. Dort wird in der Regel das virtuelle Laufwerk X: angelegt, wo sich unter X:\WINDOWS\SYSTEM32\WINEVT\LOGS die LOG-Dateien befinden sollten. Doch das Verzeichnis ist leer. Für PE Systeme müssen allerdings Ereignisse nicht wirklich gespeichert werden, da es sich sowieso nur um temporäre Daten handelt.

Da man ja aber auf eine kaputte Standardinstallation zugreifen möchte, findet man also die EVTX-Dateien unter C:\WINDOWS\SYSTEM32\WINEVT\LOGS und durch einen speziellen Parameter /LF:TRUE, den viele WEVTUTIL Kommandos verstehen, kann man WEVTUTIL direkt auf Dateien mit der Endung EVTX loslassen.

So ist die korrekte Syntax für Infos über die SYSTEM-Ereignisse (der Pfad C:\WINDOWS\SYSTEM32\WINEVT\LOGS\SYSTEM.EVTX wurde leider umgebrochen, gehört aber immer alles in eine Zeile):

WEVTUTIL GLI C:\WINDOWS\SYSTEM32\WINEVT\LOGS\SYSTEM.EVTX /LF:TRUE

So und nun ans eingemachte. Eigentlich interessieren einen ja primär Fehler und Warnungen, diese bekommt man mit folgendem Konstrukt:

WEVUTIL QE C:\WINDOWS\SYSTEM32\WINEVT\LOGS\SYSTEM.EVTX /LF:TRUE /F:TEXT /Q:“*[System/Level=2]“

Damit werden alle Fehler aufgelistet die im Offlinesystem protokolliert wurden. Ist man an den Warnungen interessiert, verwendet man folgende Zeile:

WEVUTIL QE C:\WINDOWS\SYSTEM32\WINEVT\LOGS\SYSTEM.EVTX /LF:TRUE /F:TEXT /Q:“*[System/Level=3]“

Da im Extremfall ziemlich viele Infos ausgegeben werden, sollte man die Daten in eine Datei umlenken (pipen) um sie dann mit NOTEPAD anzuschauen.

Der Parameter /Q ist durch die Verwendung von XPath ziemlich mächtig, dafür aber auch etwas kompliziert. Weitere Infos zu Abfragen findet man hier: http://msdn.microsoft.com/en-us/library/aa385231(VS.85).aspx

Übrigens durch weglassen des Parameters /F:TEXT bekommt man reinstes XML, was für Dokumentations oder Auswertungszwecke interessant sein kann.

Was ist wenn das Offlinesystem Windows XP oder Windows 2000 sein sollte? Beide verwenden ein älteres von NT-Stammendes Format mit der Endung EVT. Das Verzeichnis für Windows XP lautet: C:\WINDOWS\SYSTEM32\CONFIG und bei Windows 2000: C:\WINNT\SYSTEM32\CONFIG. Mit dem Kommando EPL kann man auch dieses Problem lösen, der Artikel http://blogs.technet.com/askperf/archive/2007/10/12/windows-vista-and-exported-event-log-files.aspx beschreibt wie man das alte EVT- ins neue EVTX-Format konvertieren kann.

Noch weitere Infos zur Vertiefung mit Abfragen: http://technet.microsoft.com/de-de/magazine/cc160886.aspx