Archive for the ‘UEFI’ Category

Automatisches Konvertieren von MBR-Bootfestplatten in GPT-Bootfestplatten in Windows, besonders auch für Hyper-V VMs

26 August 2018

Seit einigen Jahren gibt es immer mehr UEFI-Systeme. Was aber macht man, wenn man noch auf alter Master-Boot-Record Technologie, kurz MBR basierende Systeme hat? Windows 10 bringt seit der Version v1703 ein neues Programm Namens MBR2GPT.EXE mit. Mittels dieses Programms kann man eine Konvertierung vollautomatisiert durchführen.

Hier die gute und ausführliche Dokumentation von MS: https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt. Im Normalfall geht man her, bootet ein Windows PE und führt dann MBR2GPT.EXE aus. Vor dem ersten Start von der konvertierten Festplatte muss man noch im UEFI-BIOS evtl. Einstellungen für den erfolgreichen Start mittels UEFI ändern.

Wie kann man dies nun auf virtuelle Maschinen vom Hyper-V anwenden? Muss man auch extra von WinPE booten oder gibt es eine Offline-Lösung? Tatsächlich gibt es diese, man kann also seine VHD oder VHDX-Images von MBR auf GPT-Partition umstellen, damit wird auch der Umstieg von Generation1-VMs auf Generation2-VMs möglich.

Die folgenden Schritte führt man also alle auf einem Host-System und nicht unter Windows PE durch. Zuerst geht man her und holt sich den Pfad der zu konvertierenden VHD-Datei:

$VMName = "win10Gen1"
$vm=get-vm $VMName
$vm.HardDrives[0].Path

Dann bindet man die VHD-Datei ein und ermittelt die zugehörige Disknummer:

Mount-VHD $vm.HardDrives[0].Path
$disk=get-disk|where location -eq $vm.HardDrives[0].Path
$disk.disknumber

Nun kann man prüfen, ob eine Konvertierung möglich ist:

.\MBR2GPT.EXE /allowFullOS /Validate /disk:$($disk.disknumber)

Dabei ist wichtig /allowFullOS anzugeben, da wir unter einem vollen Windows arbeiten. Wenn alles glatt geht, bekommt man z. B. diese Ausgabe:

MBR2GPT: Attempting to validate disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Nun kann man den eigentlichen Vorgang starten:

.\MBR2GPT.EXE /allowFullOS /Convert /disk:$($disk.disknumber)

und erhält nach Fertigstellung ungefähr diese Ausgabe:

MBR2GPT will now attempt to convert disk 1.
If conversion is successful the disk can only be booted in GPT mode.
These changes cannot be undone!

MBR2GPT: Attempting to convert disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Trying to shrink the system partition
MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Adding recovery boot entry
MBR2GPT: Fixing drive letter mapping
MBR2GPT: Conversion completed successfully
MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Nach diesem Vorgang muss nur noch die VHD-Datei getrennt werden:

Dismount-VHD $vm.HardDrives[0].Path

Nun muss man nur noch eine VM der Generation 2 erstellen und obige VHD-Datei dort einbinden und schon bootet man von GPT und kann nun sogar SecureBoot aktivieren.

Falls es Probleme mit MBR2GPT gibt, sei noch auf die beiden Dateien setuperr.log und setupact.log verwiesen, welche sich in C:\Windows befinden und nähere Infos für evtl. Probleme enthalten. Vor allem die setupact.log enthält viele Details zum Vorgang was MBR2GPT.EXE eigentlich so alles veranstaltet.

Schade ist allerdings, dass MBR2GPT.EXE nicht im Microsoft Hyper-V Server enthalten ist, leider auch nicht in der aktuellen Preview des kommenden Hyper-V Servers. Stellt sich aber die Frage, ob man die Version von Windows 10 benutzen kann? Kann man! MBR2GPT.EXE ist eine reine 64-Bit-Anwendung somit unter Microsoft Hyper-V Server einsetzbar. Es scheint genauso wie auf Windows 10 zu funktionieren, sobald man /allowFullOS angibt läuft es.

Jetzt fehlt eigentlich nur noch ein Script, welches eine VM Generation 1 hernimmt und in eine VM Generation 2 automatisch konvertiert.

Werbeanzeigen

UEFI Boot und Probleme ins BIOS/UEFI zu kommen

3 Dezember 2016

Bei aktuellen Rechnern mit ihren superschnellen Bootvorgängen kann es schon schwierig werden ins BIOS bzw. UEFI zu kommen. Man hämmert wie blöde auf irgendwelche F-Tasten, die man manchmal schon gar nicht mehr auf der Tastatur hat, um dann später festzustellen, es war die falsche oder man war mal wieder zu langsam. Hier eine Aufstellung von möglichen Tasten: http://www.isunshare.com/windows-password/how-to-set-your-computer-to-boot-from-usb-drive.html#opt4.

Windows
Für obiges Problem gibt es seit Windows 8 Abhilfe. Man konnte seither unter den PC-Einstellungen->Update und Sicherheit->Wiederherstellung den Erweiterten Start aufrufen. Da konnte man dann meist den Eintrag UEFI-Firmware Einstellungen unter Problembehandlung->Erweiterte Optionen aufrufen oder die Starteinstellungen ändern. Diese Möglichkeit ist gut aber als bekennender Commandliner nicht sehr befriedigend.

Nun hat Microsoft bereits bei Windows 8 beim Shutdownbefehl den Parameter /o eingeführt. Dieser kürzt die Sache deutlich ab und man gelangt direkt in den Bildschirm mit den Erweiterten Startmöglichkeiten. So gehts:

shutdown /r /o

Wer sich nun unter Windows 10 v1607 die Parameter des Shutdown-Befehls anschaut, der stellt fest, es gibt nun auch einen Parameter /fw, welcher für Firmware steht und Firmware steht wiederum für die ganze UEFI-Geschichte. Man kann also mittels

shutdown /r /fw

direkt in die UEFI-Einstellungen booten! Endlich ein sauber gesteuerter Zugriff ohne zig unnötige Menüs zwischendrin!

Übrigens noch ein Tipp: Es gibt Situationen, da hat man SetHC.EXE oder UTILMAN.EXE umgebogen. Hier ein Beispiel dafür: https://newyear2006.wordpress.com/2015/08/30/abgelaufene-aktivierungen-erschweren-einem-das-leben-unter-windows/. In diesem Fall funktioniert shutdown /r /o z. B. nicht. Man kann sich jedoch behelfen, wenn man statt shutdown /o einfach

reagentc.exe /boottore

verwendet. Hat den gleichen Effekt, funktioniert aber bisher in allen Situationen! Einzige Voraussetzung dafür ist ein korrekt eingerichtetes RecoveryEnvironment. Infos dazu erhält man über reagentc /info.

Linux
Wer nun mit Linux unterwegs ist welches bereits SystemD nutzt, der kommt mit diesem Befehl in die UEFI-Einstellungen:

systemctl reboot --firmware-setup

Hier noch ein paar erhellende Infos zu UEFI unter Linux, vor allem, wie man Firmwarevariablen erzeugen kann und wie man darauf zugreift: https://firmware.intel.com/blog/accessing-uefi-variables-linux.

Ein weiterer interessanter Link für Linux und UEFI: http://superuser.com/questions/519718/linux-on-uefi-how-to-reboot-to-the-uefi-setup-screen-like-windows-8-can.

Feststellen ob WinPE im UEFI- oder BIOS-Modus gestartet wurde

2 August 2016

Für die Konfiguration von Rechnern ist es wichtig, dass man sich im richtigen Firmwaremodus befindet. Früher war es immer das altgediente BIOS aber seit ein paar Jahren gibt es eben auch UEFI. Um nun unter dem Windows Preinstallation Environment (WinPE) feststellen zu können, in welchem Modus man sich befindet, gibt es einen Registrierungskey den man abfragen kann:

reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType

Man bekommt 0x1 für BIOS und 0x2 für UEFI zurück.

Wenn der Wert nicht ermittelbar ist, sollte man

WPEUtil.EXE UpdateBootInfo

vorab ausführen! Hinweis: Anders als in der Quelle angegeben wird beim Parameter UpdateBootInfo kein Schrägstrich verwendet!

Quelle: https://msdn.microsoft.com/de-de/library/dn293283.aspx.

Hier noch wie man die PE-Version selber abfragen kann: https://newyear2006.wordpress.com/2011/05/17/winpe-version-feststellen/.

Windows 8.1 Backup mit WBADMIN bricht mit Fehler “Auf das bereitgestellte Sicherungsvolume konnte nicht zugegriffen werden” ab, bzw. Fehlercode 0x807800C5

19 Dezember 2015

Viele der Gründe, die hier beschrieben sind http://www.borncity.com/blog/2013/11/11/windows-8-1-backup-probleme-bei-uefigpt-datentrgern/ können zutreffen. Aber meine Theorie ist folgende.

Eine Sicherung, eines Windows 8.1 Rechners mit UEFI Installation und 40GB Platte, mittels

wbadmin START backup -backupTarget:\\NAS2\Freigabe\Sicherungen -include:c: -allCritical -quiet

funktionierte nicht und brachte immer die Fehlermeldung:

Fehler beim Sichern des Volumes "\\?\GLOBALROOT\Device\HarddiskVolume2\": Auf das bereitgestellte Sicherungsvolume konnte nicht zugegriffen werden. Wiederholen Sie den Vorgang.

bzw.

Fehler beim Sichern des Volumes "\\?\GLOBALROOT\Device\HarddiskVolume2\": Der angegebene Sicherungsdatenträger wurde nicht gefunden.

Dadurch wurde bereits im Sicherungsverzeichnis auf einem NAS eine ESP-Partition angelegt. Das wird später noch wichtig!

Zunächst wurde mittels VSSADMIN untersucht, ob es Probleme mit den Providern gibt. Aber nichts in der Richtung.

Dann kam mir die Schattenkopie-Speichergröße mit 3% etwas mickrig vor:

C:\>vssadmin list shadowstorage
vssadmin 1.1 – Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

(C) Copyright 2001-2013 Microsoft Corp.

Schattenkopie-Speicherassoziation
   Für Volume: (C:)\\?\Volume{ce1bcdaa-9909-464e-2002-4893f5c7566e}\
   Schattenkopie-Speichervolume: (C:)\\?\Volume{ce1bcdaa-9909-464e-2002-4893f5c7566e}\
   Verwendeter Schattenkopie-Speicherbereich: 1,48 GB (3%)
   Zugewiesener Schattenkopie-Speicherbereich: 1,75 GB (4%)
   Max. Schattenkopie-Speicherbereich: 1,18 GB (3%)

Also die Größe auf 10% und 3,95GB erhöht:

vssadmin resize shadowstorage /For=C: /On=C: /MaxSize=10%

Wieder versucht, wieder selbe Fehlermeldung.

Nach verschiedenen anderen nutzlosen Aktionen, den obigen Born-Artikel gefunden und studiert. Viele Aktionen scheinen dann zu klappen, wenn die Partitionsgröße verändert wurde.

Oben hatte ich schon die ESP-Partition im Sicherungsverzeichnis erwähnt. Da dachte ich mir, weil es eh noch keine Historie gab, lösch doch einfach mal das bisher angelegte Backup-Verzeichnis. BANG!

Das war es, nun klappte alles. Was ich durch Vergrößern des Shadowstorage-Bereich und Löschen des Backup-Verzeichnis geschafft habe, schafften andere durch das Ändern der Parititionsgröße? Nur eine Idee, leider keine Zeit zum Nachprüfen.

Weitere Leidensgenossen:
http://superuser.com/questions/663782/windows-8-1-insufficient-storage-available-to-create-shadow-copy

Nachdem nun ein zweiter Rechner das gleiche Problem zeigte, kann ich nun bestätigen, dass die Maßnahme mit Shadowstorage vergrößern und löschen des Sicherungszielverzeichnis die Lösung bringt.

Hier noch weitere Infos. In den Windows Backup Ereignissen wird folgendes Problem aufgezeichnet:

Get-WinEvent -LogName Microsoft-Windows-Backup | select –first 3

   ProviderName: Microsoft-Windows-Backup

TimeCreated                     Id LevelDisplayName Message
———–                     — —————- ——-
18.12.2015 22:12:08             14 Informationen    Die Sicherung ist abgeschlossen.
18.12.2015 22:12:08              5 Fehler           Fehler bei der um ?2015?-?12?-?18T21:11:37.607836100Z gestartete…
18.12.2015 22:11:37              1 Informationen    Die Sicherung wurde gestartet.

Wenn man sich den Fehler näher anschaut, erscheint:

Fehler bei der um ?2015?-?12?-?18T21:11:37.607836100Z gestarteten Sicherung. Fehlercode:
"0x807800C5" ("Fehler beim Vorbereiten des Sicherungsabbilds eines der Volumes im
Sicherungssatz."). Suchen Sie in den Ereignisdetails nach einer Lösung, beheben Sie das
Problem, und führen Sie die Sicherung erneut aus.

Windows OEM Key aus BIOS/UEFI bzw. ACPI per Powershell auslesen oder wo kommt der Windowskey für die Aktivierung her?

30 Juni 2014

Letzthin war ich doch etwas geschockt, als es darum ging, einem neuen Rechner Windows 8.1 Update 1 beizubringen. Nicht dass jetzt die Installation unmöglich gewesen wäre aber ein paar Details haben mich etwas stutzig gemacht.

Zunächst muss ich sagen, es handelt sich um einen fertigen ASUS-Tower. Dieser wird mit Windows 7 vorinstalliert ausgeliefert. Da aber Windows 8 drauf sollte und dabei gleich die neueste Fassung mit 8.1 Update 1, wollte ich über die übliche Methode diese Version installieren: https://newyear2006.wordpress.com/2013/09/13/windows-8-1-mit-product-key-von-windows-8-installieren/ indem ich die Installation über einen Microsoft-Demokey vornehmen wollte. Bei der Vorbereitung machte ich mich dann auf die Suche nach dem Windows 8 Key. Aber was soll ich sagen? Es gab keinen! Weder auf dem Tower aufgeklebt noch auf den DVDs oder sonstwo.

OK, es gibt ja die Möglichkeit den Key auf die DVD zu verpacken. Also DVD untersucht und die WIM-Dateien mittels 7zip angeschaut aber nix. Keine Datei mit einem Key. Was geht hier ab?

Ich gebs zu, ich hab dann doch von der Original-DVD Windows 8 installiert. Aber nur um zu sehen, ob später ein Key eingetragen ist. Siehe da, die Installation flutscht durch, ohne nach dem Key zu fragen und führt bei Internetverbindung gleich noch die Aktivierung durch. Das nenn ich ja mal Service! Aber genau diesen Service möchte ich am allerwenigsten.

Die Herausforderung
Jetzt wird es aber interessant. Also auf der DVD ist kein Key zu finden. Aber Windows ist nach der Installation aktiviert. Wie geht das? Wo kommt der Key für die Aktivierung her? Hat es Microsoft etwa eingesehen, dass dieses ganze Zwangsaktivierungsgedöns langfristig deren Untergang ist und aktiviert einfach so? Oder ist die Sache irgendwie an das ASUS-Bios bzw. ASUS UEFI Umgebung gebunden?

Mit der letzten Vermutung kommen wir der Sache näher aber zu meiner Überraschung ganz anders, als ich ursprünglich gedacht hatte. Es hat tatsächlich etwas mit UEFI zu tun aber es wird nicht einfach ein Hersteller ermittelt und dieser freigeschaltet, sondern jeder Rechner bringt seinen eigenen Key im ACPI mit! Dies ist auch keine Besonderheit von ASUS sondern alle Hersteller LENOVO, ACER, DELL usw. alle scheinen diese Variante mittlerweile zu praktizieren!

Die verfügbaren Tools
Hier der erste Artikel bei dem ich über die Sache gestolpert bin: http://www.zdnet.com/will-bios-embedded-windows-8-product-keys-cause-reinstall-troubles-7000008226/. Dieser bestätigte also schon mal, dass es tatsächlich so ist, dass der OEM-Key im BIOS hinterlegt ist. Dann ging es weiter: Wenn der da hinterlegt wird, dann kann man den ja irgendwie auslesen: http://www.nextofwindows.com/how-to-retrieve-windows-8-oem-product-key-from-bios/. Hier kommt neben den üblichen Verdächtigen wie Nirsoft auch RWEverything (http://rweverything.com/download/) zur Sprache, welches ich bisher noch nicht kannte. Der Link bei nextofwindows hat auch ein Python-Script parat. In diesem Script kommen interessante Win32-Funktionen zum Einsatz um den OEM-Key auszulesen! Hier das Script auf Github: https://github.com/christian-korneck/get_win8key#files. Python ist gut aber Powershell wäre besser! http://www.eightforums.com/installation-setup/35444-laptop-encrypted-key-uefi-bios-how-obtain-iso-2.html hat einen Powershellfetzen und spricht mittels WMI den SoftwareLicensingService an, welcher mittels OA3xOriginalProductKey den Key anscheinend auslesen kann. Nur leider klappte dies bei mir nie!

Die Hintergründe
Microsoft hat scheinbar schon lange die Möglichkeit vorgesehen, Daten aus dem BIOS bzw. aus dem Firmwarebereich auszulesen. So gibt es z. B. die Win32-Funktion EnumSystemFirmwareTables bereits seit Windows XP mit 64-Bit und generell seit Windows Vista. Macht auch Sinn, da ja ab Windows Vista durch die Umstellungen der Systemsicherheit vieles abgeschottet und umgebaut wurde. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724259(v=vs.85).aspx. Mittels EnumSystemFirmwareTables und GetSystemFirmwareTable kann man nun die nötigen Daten aus der Firmware auslesen. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724379(v=vs.85).aspx. Diese Funktionen nutzt auch das Pythonskript um den Key auszulesen.

Dazu gibt es auch eine offizielle Beschreibung der Speicherstruktur: http://msdn.microsoft.com/en-us/library/windows/hardware/dn653305(v=vs.85).aspx. Microsoft nennt es Microsoft Software Licensing Tables, welche im ACPI-Bereich unter den Systembeschreibungstabellen zu finden ist. Das Dokument spezifiziert davon zwei, einmal SLIC-Table und einmal MSDM-Table. Obwohl das Tabellenformat identisch ist, ist der Unterschied, dass SLIC für VolumeLicenseKeys und MSDM für individuelle Keys gedacht ist.

Bei Tests hat sich herausgestellt, dass Lenovo wie Asus und wahrscheinlich die meisten Hardwarehersteller MSDM benutzen. Dies zeigen auch die vielen Scripte, die es zum Auslesen gibt, welche sich ausschließlich immer auf MSDM beziehen. Interessant dabei ist natürlich, dass bei der Herstellung der Rechner jeder einzelne mit seinem individuellen Key versehen wird! Okay, früher waren es die individualisierten Keyaufkleber aber durch diese Methode können ja im Prinzip viel mehr Dinge auf dem Rechner aktiviert oder individualisiert werden. Denken wir jetzt an nichts Böses, sondern einfach mal an die bei der Bestellung hochgeladene, individuelle Startgrafik.

Powershell Fassung
Auf der weiteren Suche nach einer Fassung in Powershell, bin ich über diese Variante gestolpert: http://winaero.com/blog/how-to-get-the-windows-product-key-without-using-third-party-software/. Auf den ersten Blick genau was ich wollte aber leider wird nur wieder der Key aus der Registrierung ausgelesen, wie man es früher gemacht hat.

Diese Variante war auch ganz hilfreich und enthält noch mehr Infos zu verschiedenen Gegebenheiten und verschiedene Sourcecodes und Scripte: http://forums.mydigitallife.info/threads/43788-C-C-VB-NET-Read-MSDM-license-information-from-BIOS-ACPI-tables/page3.

Aber am Ende war keine Powershellfassung dabei. Also selber machen! Warum eigentlich Powershell? Ja warum? Weil Powershell wird solange da sein, wie sich Microsoft über Wasser halten kann und es ist bei jedem neuen Rechner von Haus aus mit an Bord! Sogar Windows RT bringt es mit. In der reinen Lehre gibt es also nichts anderes.

Also hier der Code:

$SFTCode = @"

 

[DllImport("kernel32")] public static extern uint EnumSystemFirmwareTables (uint FirmwareTableProviderSignature, IntPtr pFirmwareTableBuffer, uint BufferSize);

[DllImport("kernel32")] public static extern uint GetSystemFirmwareTable   (uint FirmwareTableProviderSignature, uint FimrwareTableID, IntPtr pFirmwareTableBuffer, uint BufferSize);

 

"@

 

$SFT = Add-Type -MemberDefinition $SFTCode -Name "SFTKlasse" -Language CSharp -UsingNamespace "System.Reflection", "System.Diagnostics", "System.Collections.Generic" -PassThru

 

# 0x41435049=ACPI ? https://github.com/michaelforney/coreboot/blob/master/src/include/cbmem.h

$firmwareTableProviderSignature = 0x41435049

$StructSize = $SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, [IntPtr]::Zero, 0)

try

{

    $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

}

catch [OutOfMemoryException]

{

    throw Error[0]

}

 

$buffer = New-Object Byte[]($StructSize)

$SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, $StructPtr, $StructSize)

[Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

[Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

if (([System.Text.Encoding]::ASCII).GetString($buffer).Contains("MSDM"))

{

    $firmwareTableMSDMID = 0x4d44534d

 

    $StructSize = $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, [IntPtr]::Zero, 0)

    try

    {

        $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

    }

    catch [OutOfMemoryException]

    {

        throw Error[0]

    }

 

    $buffer = New-Object Byte[]($StructSize)

    $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, $StructPtr, $StructSize)

    [Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

    [Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

    $encoding = [System.Text.Encoding]::GetEncoding(0x4e4)

 

    $key = $encoding.GetString($buffer, 56, 29)

}

$key

Wie immer gilt, von der Formatierung nicht abschrecken lassen, sondern einfach Copy&Paste und loslegen. Übrigens es werden keine Admin-Rechte benötigt! Da einiges durcheinander geht, hier noch der Gist-Verweis: https://gist.github.com/newyear2006/5578386bf4793a334f85#file-getacpi-oemkey-ps1

Würde mich freuen, wenn der eine oder andere seine Erfahrungen im Kommentarbereich verewigen könnte, um ein Gefühl dafür zu bekommen, welche Hersteller die Variante unterstützen.

Zusätzlich interessiert mich besonders:

PS > ([System.Text.Encoding]::ASCII).GetString($buffer)

Dies gibt einen String aus, mit den auf dem Rechner verfügbaren Firmwaretabellen.

Noch ein Hinweis:
Falls es nach dem Copy&Paste zu einem Fehler wie diesem hier kommt:

0×41435049 : Die Benennung "0×41435049" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen

Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

In Zeile:12 Zeichen:35

+ $firmwareTableProviderSignature = 0×41435049

+ ~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (0×41435049:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

dann bitte das x bei 0x41434049 löschen und nochmal eingeben. Scheint eine nette Anomalie von WordPress zu sein.

Neue GHOST-Version in Form von GSS Version 3 im Anmarsch?

29 August 2012

Seit Jahren hat sich in Sachen GHOST von Symantec nichts getan. Aber es ist einfach ein hilfreiches Tool, welches selbst noch aktuell mit Windows 8 und Server 2012 hilfreiche Dienste leisten kann.

Da sich seit Jahren nichts mehr getan hat, bin ich seit einiger Zeit auf der Suche nach Alternativen, wie z. B. hier https://newyear2006.wordpress.com/2012/07/02/ghost32-exe-ersatz-mittels-windows-8-bzw-winpe-4-oder-wie-erstelle-ich-ein-festplattenimage-mit-windows-bordmitteln/ oder hier https://newyear2006.wordpress.com/2010/11/21/ghost-enterprise-ersatz/ und hier https://newyear2006.wordpress.com/2007/02/09/festplatten-clonen-mit-windows-vista-dvd-und-robocopy/.

Aktuelle Entwicklungen wie UEFI-Boot, native 4K-Sektoren, VHD und VHDX machen den Umgang mit Ghost immer schwieriger.

Nun hat sich aber in einem Symantec-Forum etwas erstaunliches abgespielt, hier der Auszug von jon_sharp:

Hello everyone. I just wanted to introduce myself as the new Product Manager for GSS, so you know where I’m coming from.

While Nigel is correct that it has been some time since we’ve released a new version of GSS. I want to assure you, though, that we have a release planned for next year. There is no plan to replace GSS with Deployment Solution. Though that might have been the plan at some point, it isn’t the plan as of today. I apologize to the community at large that this information hasn’t been shared before now.

I know GSS has gone through a rocky past couple of years, but we (Symantec) believe there’s tremendous value in continuing work on GSS. Please take this as the official word from Symantec, because that’s what it is. 🙂

Thanks,
Jon

http://www.symantec.com/connect/forums/ghost-solution-suite-or-wds

Es gibt zwar Verzögerungen aber anscheinend wird an einer neuen Version gearbeitet. Also mal schauen wie sich die Sache entwickelt.

Windows Server 2008 R2 Software Raid 1 (Mirror) korrekt einrichten egal ob BIOS oder UEFI

12 März 2012

Eine Sache die leicht unterschätzt wird, ist das korrekte Einrichten eines Softwareraids unter Windows Server. Hier eine tolle Schritt für Schritt Anleitung von Microsoft, wo auf alle wichtigen Aspekte eingeht und vor allem die Unterschiede wegen BIOS und UEFI berücksichtigt.

Configuring Disk Mirroring for Windows Server 2008 R2: http://www.microsoft.com/download/en/details.aspx?amp;displaylang=en&id=23476

UEFI fähige WinPE DVD erstellen

16 Februar 2011

Dieser Artikel beschreibt die passenden Parameter um eine DVD für BIOS oder UEFI Modus bootbar zu machen: http://support.microsoft.com/kb/947024/en-us

Gespiegelte Boot Partitionen Einrichten mit GPT Datenträgern unter Windows Server 2008

16 Februar 2011

Eine ziemlich detaillierte Schritt für Schritt Anleitung wie man einen dynamischen, gespiegelten GPT-Bootdatenträger unter Windows Server 2008 einrichtet, beschreibt dieser Knowledge Base Artikel: http://support.microsoft.com/kb/951985/en-us

Oder das gleiche für 2003: http://support.microsoft.com/kb/814070/en-us

GPT-Boot-Datenträger mit Diskpart einrichten

16 Februar 2011

MBR und 16bit ade, jetzt schlägt die Stunde von 64bit und UEFI. Es gibt noch nicht viele Informationen über GPT-Datenträger zum momentanen Zeitpunkt. Man muss sich noch alle möglichen Infos aus allen Ecken zusammentragen. GPT steht übrigens für GUID Partition Table. MSR steht für Microsoft Reserved Partition und ESP für EFI System Partition.

Die wichtigsten Begriffe im Zusammenhang mit GPT, MSR und ESP werden hier geklärt: http://www.microsoft.com/whdc/device/storage/gpt_faq.mspx

Schema eines GPT-Datenträgers: http://www.microsoft.com/whdc/device/storage/gpt-on-x64.mspx

Nochmal eine schematische Darstellung von GPT-Datenträgern in Verbindung mit der Aufteilung der Partitionen: http://blogs.technet.com/b/askcore/archive/2010/10/08/gpt-in-windows.aspx

Aber eines ist sicher: GPT bringt viele Vorteile bei der Festplattenverwaltung und dass moderne Festplatten optimal angesprochen werden können (Thema Alignment). Dazu noch UEFI mit 64bit Code wo vorhandenen Speicher, der in der Regel im Überfluss da ist, nun auch optimal verwenden kann. Endlich lässt sich der Flaschenhals mit dem Ruhezustandsmodus entschärfen.

Trotz aller Vorteile ergeben sich noch ewig viele Fragen.

Als erste wäre dies: Wie erstellt man einen GPT-Datenträger unter Windows 7? Ganz einfach, mittels

CONVERT GPT

Allerdings darf davor keine Partition auf der Platte vorhanden sein, also löscht man diese mittels CLEAN.

GPT-Datenträger sind aber ganz anders aufgebaut und benötigen neben der eigentlichen Datenpartition gleichmal zwei zusätzliche Verwaltungspartitionen EFI-Systempartition und MSR.

Schön dargestellt und wie man diese einrichtet, stellt dieser Artikel dar: http://technet.microsoft.com/de-de/library/dd744301(v=WS.10).aspx

Tipp: Achso, GPT mag Vorteile bringen und gibt es schon relativ lange, allerdings werden die Kinderkrankheiten in Verbindung mit UEFI Bootvorgängen erst gerade ausgemerzt. Man sollte also nach Möglichkeit sein 64bit Windows 7 mit der GPT-Bootpartition erst einrichten, wenn man ein Windows 7 mit integriertem Service Pack 1 Installationsdatenträger hat.

Beispiel: http://support.microsoft.com/kb/975535/ 
und http://support.microsoft.com/kb/979374

Weitere Probleme: VHD-Boot ist nicht möglich: http://www.delltechcenter.com/page/uEFI+Boot+to+VHD oder mögliche Probleme mit Hyper-V: http://www.mcseboard.de/virtualisierung-82/windows-server-backup-efi-maschine-hyper-v-nutzen-167416.html

Wird alles noch richtig spaßig!