Archive for August 2017

Feststellen welches Programm das Entfernen eines USB-Gerätes unter Windows verhindert

30 August 2017

Wenn man unter Windows USB Geräte abmeldet bzw. auswirft, kann es passieren, dass man mit dieser schönen Meldung beglückt wird:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Das Gerät "USB-Massenspeichergerät" kann aufgrund eines unbekannten Fehlers nicht beendet werden. Entfernen Sie das Gerät nicht, solange es noch verwendet wird. Schließen Sie alle Programme, von denen das Gerät verwendet wird, und entfernen Sie es anschließend.
—————————
OK  
—————————

Unter Windows 7 sieht die Meldung etwas anders aus, ist aber genauso sinnlos:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Dieses Gerät wird gerade verwendet. Schließen Sie alle Programme oder Fenster, die möglicherweise das Gerät verwenden, und wiederholen Sie den Vorgang.
—————————
OK  
—————————

Tja, “Unbekannte Fehler” sind des Benutzers liebste Fehler! Selbst heute in Zeiten von Windows 10 hat es Microsoft noch nicht geschafft diese Meldung mit mehr sinnvollen Informationen zu versehen und kommt immer noch so kryptisch wie zu Windows XP-Zeiten daher.

Aber dank Powershell kann der gequälte Anwender sich etwas mehr Informationen beschaffen. Zumindest bei Windows 7 bis Windows 10.

Get-WinEvent -ProviderName Microsoft-Windows-Kernel-PnP -MaxEvents 5 | where {$_.TimeCreated.Date -eq (Get-Date).Date -and $_.id -eq 225} | ft TimeCreated, Message –Wrap

Denn es werden in der Ereignisanzeige in Windows tiefergehende Informationen zum Vorgang gespeichert und damit kann man in der Regel den Grund für obige Fehlermeldung herausfinden. Man muss nur beim Microsoft-Windows-Kernel-PNP Provider nach der EventID 225 suchen.

In diesem Fall bekommt man z. B.:

TimeCreated         Message
———–         ——-
30.08.2017 17:33:47 Die Anwendung \Device\HarddiskVolume4\Windows\System32\cmd.exe mit der Prozess-ID                     21832 hat das Entfernen oder Auswerfen für das Gerät                     USB\VID_1E68&PID_0035\BB00000XXXXXXX beendet.

angezeigt. D. h. cmd.exe, also die Eingabeaufforderung, mit der ProzessID 21832 hatte Zugriff auf den USB-Stick und verhinderte dadurch das Auswerfen.

Advertisements

Konvertieren von virtuellen Festplattenimages in VHD oder VHDX zur Verwendung in Hyper-V oder Azure

25 August 2017

Man bekommt immer wieder Images von anderen virtuellen Maschinen die man in Hyper-V einbinden möchte. Ich hatte hier schon mal auf ein Utility von Microsoft verlinkt: https://newyear2006.wordpress.com/2012/09/04/konvertieren-von-virtuellen-vmware-maschinen-in-virtuelle-hyper-v-maschinen/. Leider klappt der Link nicht mehr. Auf der Suche nach einer Alternative bin ich auf ein Image-Utility von Qemu gestoßen, welches im Prinzip alle gängigen Formate konvertieren kann. Ein weiterer Vorteil ist, dass es als Open Source vorliegt.

Hier die Binary: https://cloudbase.it/qemu-img-windows/ und hier der Source in github: https://github.com/cloudbase/qemu/. Hier gibt es die ausführliche Hilfe: https://qemu.weilnetz.de/doc/qemu-doc.html#qemu_005fimg_005finvocation.

Es werden alle gängigen Formate unterstützt:

Image-Format (schreibbar) qemu-img Parameter
QCOW2 (KVM, Xen) qcow2
QEMU qcow
QED (KVM) qed
raw raw
VDI (VirtualBox) vdi
VHD (Hyper-V) vpc
VMDK (VMware) vmdk
Linux dm-crypt/cryptsetup luks

Neben obigen Formaten, welche gelesen und geschrieben werden können, gibt es noch ein paar, welche nur gelesen werden können:

Image-Format (nur lesbar) qemu-img Parameter
Bochs x86 PC emulator bochs
Linux Compressed Loop image cloop
Apple disk image dmg
Parallels disk image format parallels

Zu jedem Format gibt es noch spezielle Parameter, eine Beschreibung dazu findet man hier: https://qemu.weilnetz.de/doc/qemu-doc.html#disk_005fimages_005fformats.

Zur Anwendung kann man z. B.

qemu-img.exe convert source.img -O vhdx -o subformat=dynamic dest.vhdx

aufrufen.

Man kann auch den Parameter info verwenden um Informationen über ein Image zu erfahren.

C:\>qemu-img info test.img
image: test.img
file format: vhdx
virtual size: 127G (136365211648 bytes)
disk size: 4.0M
cluster_size: 33554432

Aber Vorsicht, man kann sich nicht immer voll auf die Infos verlassen, denn in Fällen wo unsinnige Daten verwendet werden, werden trotzdem Daten ausgegeben:

C:>echo "Nix da" > test.txt
C:>qemu-img info test.txt
image: test.txt
file format: raw
virtual size: 512 (512 bytes)
disk size: 11

Dabei muss der Hinweis auf das Dateiformat RAW nicht immer heißen, dass es kein gültiges Dateisystem ist! Es bedeutet vielmehr, dass qemu-img das Format nicht zuordnen kann.

Obwohl das Tool ziemlich mächtig ist, fehlt noch die Möglichkeit .GHO-Dateien von Symantec Ghost konvertieren zu können. Dazu gibt es über einen Umweg die Möglichkeit mittels Ghost in VMDK-Dateien und dann mittels qemu-img in VHDX zu konvertieren:

ghost64 -clone,mode=restore,src=source.gho,dst=image.vmdk -batch –sure
qemu-img.exe convert image.vmdk -O vhdx -o subformat=dynamic dest.vhdx

Damit wird Source.GHO in Dest.VHDX konvertiert.

Hier sind noch weitere Parameter für die Konvertierung bei Ghost beschrieben: https://www.symantec.com/connect/articles/converting-image-file-format-gho-vmdk-and-vmdk-gho.

Dank qemu-img hat man nun ein mächtiges Tool für Festplattenimages an der Hand.

REST Api Guidelines und OpenAPI

23 August 2017

Da heutzutage immer mehr Dienste direkt per HTTP-Aufrufe ansprechbar sind, haben alle großen Hersteller von Webdiensten mittlerweile API-Guidelines zur Erstellung dieser Dienste. Dies kann manchmal hilfreich sein, wenn es um kryptische Fehlermeldungen in Log-Dateien geht.

Hier der Verweis auf die API-Guidelines von Microsoft: https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md und von Google: https://cloud.google.com/apis/design/. Guidelines von Amazon konnte ich noch keine ausfindig machen, daher nur ein Link auf die aktuelle API: https://docs.aws.amazon.com/apigateway/api-reference/. Es gibt auch bereits Seiten, welche sich den Guidelines annehmen und diese wieder auf bestimmte Kriterien untersuchen zum besseren Vergleichen: http://apistylebook.com/design/guidelines/.

Ein Punkt der beim Datenaustausch zwischen verschiedenen APIs für Verwirrung sorgen könnte, sind Datumsfelder. Bei Google ist die Rede von RFC3339 (http://tools.ietf.org/html/rfc3339), bei Microsoft von ISO8601. Beide sind sich ähnlich allerdings unterscheiden sie sich in ein paar Kleinigkeiten, die im Zweifel wie immer alles durcheinander bringen können: https://stackoverflow.com/questions/522251/whats-the-difference-between-iso-8601-and-rfc-3339-date-formats.

Wo findet man nun diese Guidelines angewendet? Z. B. hier: https://cloud.google.com/apis/docs/overview oder beim Microsoft Graph: https://developer.microsoft.com/de-de/graph/docs/concepts/overview.

Wenn wir schon dabei sind, muss ich noch OpenAPI nennen, welches in Zukunft auch größere Bedeutung bekommen dürfte: https://www.openapis.org/specification/repo bzw. https://swagger.io/specification/. Als alter Powersheller sollte ich dabei noch gleich auf PSSwagger verweisen: https://github.com/PowerShell/PSSwagger. Mit PSSwagger lassen sich aus bestehenden OpenAPI-Definitionen automatisch Cmdlets erstellen. Wer es allgemeiner benötigt kann auch AutoRest von MS verwenden: https://github.com/Azure/autorest.

Wer wendet nun OpenAPIs bereits an? Na z. B. Google: https://cloud.google.com/endpoints/docs/openapi/. Auch Microsoft ist bei seinen Azure-Bemühungen mit dabei und hat sich klar zu OpenAPI bekannt: https://blogs.msdn.microsoft.com/apimanagement/2016/10/24/swaggers-success-gives-birth-to-openapi/.

Mit der aktuellen OpenAPI Spezifikation 3.0 dürfte nun der API-Zug endgültig den Bahnhof verlassen und schnell Fahrt aufnehmen…

Wenn ich irgendetwas zum Thema vergessen habe sollte, findet man es sicher hier. https://design.apievangelist.com/.

Systemrechte unter Windows erlangen

17 August 2017

Schon seit Ewigkeiten ist bekannt wie man Systemrechte unter Windows erlangen kann. Aber das Ziel ist es – wie immer – es mit möglichst wenig Aufwand und am besten mit Bordmitteln zu erlangen. Zwar bringt jedes aktuelle Windows mittlerweile ein Recoverypartition mit aber man hat nicht immer unbedingt Zugriff im Bootvorgang darauf (z. B. bei gehosteten Webservern).

Der übliche Vorgang ist das Kopieren von CMD.EXE auf UTILMAN.EXE, OSK.EXE oder SETHC.EXE. Dies gelingt normalerweise nur, wenn man von einer Recoverypartition oder von WinPE bzw. eben WinRE-CD gebootet hat. Aus diesem Grund verwenden viele Sysinternals PSExec: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec.

Mit Adminrechten und etwas Gefummel in der Registry, bekommt man es auch mit Bordmitteln hin. Da es komfortabler ist dies per Script zu erledigen hier die nötigen Powershell-Anweisungen. Zuerst kopieren wir Utilman.exe und cmd.exe:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"

Nun benötigen wir den Zugriff auf den Registryschlüssel HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ um dort die Werte PeningFileRenameOperations und AllowProtectedRenames zu setzen.

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"

AllowProtectedRenames ist wichtig, sonst klappt der Vorgang nicht. Dies ist mal wieder einer von so vielen Registrywerten die nicht klar dokumentiert sind. Er wird im MSDN nur einmal im Zusammenhang mit VSS und der Wiederherstellung von Dateien der Windows File Protection genannt: https://msdn.microsoft.com/en-us/library/windows/desktop/aa381498(v=vs.85).aspx.

set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1

Jetzt muss man die zu kopierenden Dateien angeben. Da es aber kein klassischer Copy-Befehl sondern ein Move-Befehl ist, wo die Quelldatei nach dem Vorgang weg ist, verwenden wir die vorher erstellte Kopie von CMD.EXE. Dabei ist darauf zu achten, dass vor den Dateinamen noch eine spezielle Notation \??\ nötig ist. Leider gibt es keine Informationen darüber wann !\??! verwendet wird. Aber damit hat es immer funktioniert. Wichtig ist noch, dass es ein String-Array sein muss, damit die Werte in der Registry korrekt als REG_Multi_Sz gespeichert wird.

[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Nun muss nur noch der Rechner neu gestartet werden und schon steht einem eine Eingabeaufforderung mit Systemrechten zur Verfügung. Bei Verwendung von UTILMAN.EXE klickt man am Anmeldebildschirm einfach auf den Kreis mit den zwei Pfeilen und der Einblendung “Erleichterte Bedienung”.

Um die Änderung rückgängig zu machen, könnte man nun dieses Script verwenden, welche einfach die Kopie von Utilman.exe zurückkopiert:

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\Utilman.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Es geht aber noch einfacher, auch im Falle eines Fehlers zwischendrin, bemüht man einfach die Windows File Protection und beauftragt diese mit der Wiederherstellung der betreffenden Dateien:

# Falls was schiefgeht:
SFC /SCANFILE=C:\Windows\System32\cmd.exe
SFC /SCANFILE=C:\Windows\System32\utilman.exe

Jetzt nochmal das ganze Script um oben beschriebene Funktionalität zu erreichen:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"
$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Hier noch ein guter Blogartikel mit Registrybildern, wer es von Hand machen möchte: https://blog.cscholz.io/windows-72008-movefileex/. Eine weitere Methode anstatt PendingFileRenameOperations:
https://guyrleech.wordpress.com/2014/07/16/reasons-for-reboots-part-2-2/, einfachere Beschreibung: https://superuser.com/questions/1204878/how-can-i-tell-windows-to-overwrite-a-system-file-on-the-next-reboot.

Eine weitere Variante an Systemrechte zu gelangen ist hier beschrieben: https://newyear2006.wordpress.com/2013/01/01/eingabeaufforderung-mit-lokalen-systemdienst-rechten-unter-windows-8-und-windows-server-2012/.