Archive for the ‘Hyper-V’ Category

Bildschirminhalt einer virtuellen Maschine im Hyper-V Server abrufen

6 Dezember 2017

Wenn man auf einem Microsoft Hyper-V Server (https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-server-2016) unterwegs ist, also der frei verfügbaren Version, dann hat man manchmal das Problem, dass man wissen möchte, warum eine virtuelle Maschine noch nicht ansprechbar ist. Meist hat es mit einem Hänger oder mit blöden Updates zu tun. Falls man nun aber direkt auf der Konsole des Servers ist, dann gibt es keine direkten grafischen Mittel die passenden Infos abzurufen.

Aus diesem Grund hab ich ein Script gebastelt, damit man in Zukunft die passenden Funktionen direkt verfügbar hat. Hier zunächst die Ausgangslage, wie man das Bild einer virtuellen Maschine speichert (https://blogs.msdn.microsoft.com/virtual_pc_guy/2016/05/27/capturing-a-hyper-v-vm-screen-to-a-file/) daraus resultierte dieses abgewandelte Skript:

#
Add-Type -AssemblyName "System.Drawing"
Add-Type -AssemblyName "System.Windows.Forms"

function Get-VMScreenBMP {
    param
    (
        $VMName,
        $index=0
    )

    $VMCS = Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem -Filter "ElementName=’$($VMName)’"

    # Get the resolution of the screen at the moment
    $video = $VMCS.GetRelated("Msvm_VideoHead")
    If ($video.Count -gt 0) {
        If ($index -gt $video.Count) {
            $index = $video.Count
        }
        $x = $video.CurrentHorizontalResolution[$index]
        $y = $video.CurrentVerticalResolution[$index]

        $VMMS = Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_VirtualSystemManagementService

        # Get screenshot
        $image = $VMMS.GetVirtualSystemThumbnailImage($VMCS, $x, $y).ImageData

        # Transform into bitmap
        $BitMap = New-Object System.Drawing.Bitmap -Args $x,$y,Format16bppRgb565
        $Rect = New-Object System.Drawing.Rectangle 0,0,$x,$y
        $BmpData = $BitMap.LockBits($Rect,"ReadWrite","Format16bppRgb565")
        [System.Runtime.InteropServices.Marshal]::Copy($Image, 0, $BmpData.Scan0, $BmpData.Stride*$BmpData.Height)
        $BitMap.UnlockBits($BmpData)

        $BitMap
    } else {
        Write-Error "No Video Device found, VM not running?"
    }
}

Function Show-Screen([System.Drawing.Image]$img, $VMName) {
    $form = new-object Windows.Forms.Form
    $form.Text = "Screen from $VMName"
    $form.Width = $img.Size.Width;
    $form.Height =  $img.Size.Height;
    $pictureBox = new-object Windows.Forms.PictureBox
    $pictureBox.Width =  $img.Size.Width;
    $pictureBox.Height =  $img.Size.Height;

    $pictureBox.Image = $img;
    $form.controls.add($pictureBox)
    $form.Add_Shown( { $form.Activate() } )
    $form.ShowDialog()
}

Function Show-VMScreen ($vmName, $index=0) {

    $bmp=Get-VMScreenBMP $vmName $index
    Show-Screen $bmp $VmName

}

Function Save-VMScreen ($vmName, $index=0, $filename=($ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath(".\$($VMName)Screen.BMP"))) {
       
    $bmp=Get-VMScreenBMP $vmName $index
    $bmp.Save($filename)
   
}

Daraus ergeben sich die Funktionen:

# speichern in eine Datei
Save-VMScreen –VMName SampleVMName –Filename ".\test.bmp"

# direkte Ausgabe am Bildschirm
Show-VMScreen  –VMName SampleVMName

Man kann noch einen Parameter –Index angeben, dieser ist als Vorgabe 0 und spricht einen spezifischen Videohead an. Wie dieser genau definiert ist, ließ sich leider nicht herausfinden. Aber kurz gesagt, kann man damit höher aufgelöste Bilder erhalten.

Man kann sogar das aktuelle Bild in die Windows-Zwischenablage legen, damit man es für Dokuzwecke woanders wieder einfügen kann:

[System.Windows.Forms.Clipboard]::SetImage((Get-VMScreenBMP "SampleVMName"))

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.

Hardware direkt einer virtuellen Maschine im Hyper-V mittels Discrete Device Assignment zuordnen

3 Juni 2016

Microsoft experimentiert viel mit dem Hyper-V und baut ihn in alle Richtungen aus. So gab es ganz zu Beginn von Windows 10 Powershell Cmdlets, welche es erlaubten physische Hardware direkt einer virtuellen Maschine zuzuordnen https://charbelnemnom.com/2015/02/whats-new-in-powershell-for-hyper-v-in-windows-server-technical-preview-hyperv-powershell-vnext/. Dazu gab es die Cmdlets:

Get-Command *assigna*

Name                            Version Source
—-                            ——- ——
Add-VMAssignableDevice          2.0.0.0 Hyper-V
Add-VMHostAssignableDevice      2.0.0.0 Hyper-V
Dismount-VMHostAssignableDevice 2.0.0.0 Hyper-V
Get-VMAssignableDevice          2.0.0.0 Hyper-V
Get-VMHostAssignableDevice      2.0.0.0 Hyper-V
Mount-VMHostAssignableDevice    2.0.0.0 Hyper-V
Remove-VMAssignableDevice       2.0.0.0 Hyper-V
Remove-VMHostAssignableDevice   2.0.0.0 Hyper-V

Allerdings verschwanden diese Cmdlets wieder zum Release von Windows 10, weshalb sie bei diesem Vergleich nicht auftauchten: https://newyear2006.wordpress.com/2015/07/30/umgang-mit-verschiedenen-versionen-von-powershellmodulen-und-ermittlung-von-unterschieden/.

Per Zufall stolperte ich aber über diesen Blogeintrag https://techstronghold.com/blogs/virtualization/pass-through-wired-or-wireless-wi-fi-nic-to-vm-using-hyper-v-discrete-device-assignment-dda-in-windows-server-2016, der komische Dinge vollführte. Tatsächlich hat Microsoft obige Cmdlets mit Release von v1511 bei Windows 10 wieder eingeführt! Wobei die Dokumentation, stand heute, also ein halbes Jahr nach Erscheinen von v1511, absolut erbärmlich ist. Z. B. besteht die Dokumentation von Add-VMAssignableDevice nur aus einem Template. Keine Erklärung nix.

Nun ist das Thema an sich auch recht komplex, aber man könnte ja zumindest ein paar Links für weitergehende Informationen hinterlegen. So muss man sich alles selber ergooglen.

Im Prinzip geht es um Discrete Device Assignment, kurz DDA, auch bekannt als PCI Passthrough. Dies erlaubt einer VM den direkten Zugriff auf Hardware.

Hier findet man einen Hintergrundartikel dazu: https://blogs.technet.microsoft.com/virtualization/2015/11/19/discrete-device-assignment-description-and-background/. Obwohl die Cmdlets unter Windows 10 verfügbar sind, scheint nur unter Windows Server 2016 die Unterstützung aktiviert zu sein! Dies wird in diesem Artikel geschrieben: https://blogs.technet.microsoft.com/virtualization/2015/11/20/discrete-device-assignment-machines-and-devices/.

Selbst wenn man mit dem Server 2016 unterwegs ist, muss die Hardware DDA unterstützen, ein Script welches die Hardware daraufhin überprüft, ist hier zu finden: https://github.com/Microsoft/Virtualization-Documentation/blob/master/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1.

WLAN bzw. WIFI mit Hyper-V

3 Mai 2016

Endlich wird es einfacher möglich auf Windows 10 seinen WLAN-Adapter für VMs unter Hyper-V zu verwenden. Hier die passende Beschreibung: https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/user_guide/setup_nat_network?f=255&MSPPError=-2147217396

Leider geht es aber erst ab Build 14295 oder später.

Im Prinzip braucht man drei Powershell-Aufrufe:

New-VMSwitch
https://technet.microsoft.com/de-de/library/hh848455.aspx
New-NetIPAddress
https://technet.microsoft.com/en-us/library/hh826150.aspx
New-NetNat
https://technet.microsoft.com/de-de/library/dn283361(v=wps.630).aspx

Umgang mit verschiedenen Versionen von Powershellmodulen und Ermittlung von Unterschieden

30 Juli 2015

Microsoft hat mit Veröffentlichung von Windows 10 auch neue Cmdlets für Powershell eingeführt. Bei Windows 10 Pro und vergleichbaren Versionen, wo der Client Hyper-V enthalten ist, gibt es viele neue Cmdlets für die Verwaltung von virtuellen Maschinen. Interessant dabei ist, dass es eine neue Version des Hyper-V-Moduls gibt. Bis Windows 8.1 und Server 2012 R2 kam die Version 1.1 zum Einsatz und mit Windows 10 gibt es das Hyper-V-Modul in Version 2.0.0.0.

Aus Kompatibilitätsgründen macht es Sinn ein Modul mit einer spezifischen Version zu laden. Vor allem, wenn man z. B. vergleichen möchte, was sich in der neuen Version des Moduls verändert hat.

Welche Version aktuell geladen ist, bekommt man mit Get-Module heraus:

PS> get-module hyper-v

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     1.1        hyper-v                             {Add-VMDvdDrive,…

Mittels Remove-Module kann man das Modul entladen und mit Hilfe von Get-Module –Listavailable erhält man alle verfügbaren Versionen:

PS> Remove-Module hyper-v
PS> Get-Module -ListAvailable Hyper-V

    Verzeichnis: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}
Binary     1.1        Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMHardDiskDrive, Add-VMMigrationNetwork…}

Mittels Import-Module kann man nun ein Modul laden:

PS> Import-Module Hyper-V
PS> Get-Module Hyper-V

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}

Man bekommt automatisch die neueste Version. Mit dem Parameter –RequiredVersion kann man nun eine spezifische Version laden:

Import-Module Hyper-V -RequiredVersion 1.1

Nun kann man mittels dieser Möglichkeit beide Versionen laden, die Cmdlets einer Variablen zuweisen und diese Vergleichen lassen:

PS> Import-Module Hyper-V -RequiredVersion 1.1
PS> $cV1 = Get-Command -Module Hyper-V
PS> Remove-Module Hyper-V
PS> Import-Module Hyper-V -RequiredVersion 2.0.0.0
PS> $cV2 = Get-Command -Module Hyper-V
PS> compare $cv1 $cv2

InputObject                              SideIndicator
———–                              ————-
Add-VMGroupMember                        =>
Add-VMNetworkAdapterRoutingDomainMapping =>
Add-VMSwitchTeamMember                   =>
Add-VMTPM                                =>
Disable-VMConsoleSupport                 =>
Enable-VMConsoleSupport                  =>
Get-VHDSet                               =>
Get-VHDSnapshot                          =>
Get-VMGroup                              =>
Get-VMHostCluster                        =>
Get-VMNetworkAdapterIsolation            =>
Get-VMSwitchTeam                         =>
Get-VMTPM                                =>
Get-VMVideo                              =>
New-VMGroup                              =>
Optimize-VHDSet                          =>
Remove-VHDSnapshot                       =>
Remove-VMGroup                           =>
Remove-VMGroupMember                     =>
Remove-VMSwitchTeamMember                =>
Rename-VMGroup                           =>
Set-VMHostCluster                        =>
Set-VMNetworkAdapterIsolation            =>
Set-VMNetworkAdapterRoutingDomainMapping =>
Set-VMSwitchTeam                         =>
Set-VMTPM                                =>
Set-VMVideo                              =>
Start-VMTrace                            =>
Stop-VMTrace                             =>
Update-VMVersion                         =>
Add-VmNetworkAdapterRoutingDomainMapping <=
Get-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterRoutingDomainMapping <=

Dabei fällt auf, dass keine Cmdlets entfernt wurden, auch wenn es auf den ersten Blick so aussieht. Es wurde lediglich die Schreibweise bei den letzten vier Cmdlets von …-Vm… in …-VM… geändert.

Halten wir also fest, dies sind die neuen Cmdlets in Hyper-V 2.0.0.0:

Add-VMGroupMember
Add-VMNetworkAdapterRoutingDomainMapping
Add-VMSwitchTeamMember
Add-VMTPM
Disable-VMConsoleSupport
Enable-VMConsoleSupport
Get-VHDSet
Get-VHDSnapshot
Get-VMGroup
Get-VMHostCluster
Get-VMNetworkAdapterIsolation
Get-VMSwitchTeam
Get-VMTPM
Get-VMVideo
New-VMGroup
Optimize-VHDSet
Remove-VHDSnapshot
Remove-VMGroup
Remove-VMGroupMember
Remove-VMSwitchTeamMember
Rename-VMGroup
Set-VMHostCluster
Set-VMNetworkAdapterIsolation
Set-VMNetworkAdapterRoutingDomainMapping
Set-VMSwitchTeam
Set-VMTPM
Set-VMVideo
Start-VMTrace
Stop-VMTrace
Update-VMVersion

Hyper-V schnelles Backup einer VM und anschließende Probleme

23 April 2015

Wenn man meint bei einem Hyper-V mal schnell eine Sicherung einer VHD zu machen (ohne einen Snapshot zu erstellen) und die VHD wegkopiert, dem kann es passieren, dass beim Zurückkopieren der VHD und anschließendem Start der VM folgender Fehler auftaucht:

[Window Title]
Verbindung mit virtuellen Computern

[Main Instruction]
Anwendungsfehler beim Versuch, den Status von "XSlave" zu ändern.

[Content]
Fehler beim Starten von "XSlave".

Microsoft Emulated IDE Controller (Instanz-ID {83F8638B-8DCA-4152-9EDA-2CA8B33039B4}): Fehler "Allgemeiner "Zugriff verweigert"-Fehler" beim Einschalten.

Das IDE/ATAPI-Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler"

Das -Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler"

[Expanded Information]
Fehler beim Starten von "XSlave" (ID des virtuellen Computers 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B).

"XSlave" Microsoft Emulated IDE Controller (Instanz-ID {83F8638B-8DCA-4152-9EDA-2CA8B33039B4}): Fehler "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005) beim Einschalten (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B).

"XSlave": Das IDE/ATAPI-Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005). (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B)

"XSlave": Das -Konto verfügt über keine ausreichenden Berechtigungen zum Öffnen von Anlage "C:\VMs\XSlave\XSlave.vhd". Fehler: "Allgemeiner "Zugriff verweigert"-Fehler" (0x80070005). (ID des virtuellen Computers: 9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B)

[V] Details einblenden  [Schließen]

In diesem Fall hilft der Datei die passenden Rechte mittels ICACLS zu geben, maßgeblich:

icacls x1slave.vhd /grant "NT Virtueller Computer\9B8A8FFF-F35E-4F55-8971-E3B662AE7E3B:(R,W)"

Näheres findet man hier: https://support.microsoft.com/en-us/kb/2249906/en.

VirtualBox Probleme mit 64-Bit Gast und das Ding mit dem Client-Hyper-V

31 Oktober 2014

Als bekennender Hyper-Vler bin ich über ein Problem gestoßen. Es ging darum eine virtuelle Maschine zu haben, über die man problemlos auf den USB Port losgehen kann. Leider ist da Hyper-V auch in aktuellen Ausprägungen nicht so der Bringer. Also nimmt man einen anderen VM-Host, wie in diesem Fall VirtualBox von Oracle: https://www.virtualbox.org/.

Nach der Installation war es aber nicht möglich ein 64-Bit Gastsystem aufzusetzen. Nach dem üblichen Überprüfen der BIOS-Einstellungen, damit auch die nötigen Virtualisierungseinstellungen aktiv waren, funktionierte es immer noch nicht. Dann diesen Artikel gelesen: https://forums.virtualbox.org/viewtopic.php?f=1&t=62339. Aha Hyper-V! Aber der läuft doch gar nicht!?!?

PS C:\Windows\system32> Get-Service -DisplayName *hyper*

Status   Name               DisplayName
——   —-               ———–
Stopped  vmicguestinterface Hyper-V-Gastdienstschnittstelle
Stopped  vmicheartbeat      Hyper-V-Taktdienst
Stopped  vmickvpexchange    Hyper-V-Datenaustauschdienst
Stopped  vmicrdv            Hyper-V-Remotedesktopvirtualisierun…
Stopped  vmicshutdown       Hyper-V-Dienst zum Herunterfahren d…
Stopped  vmictimesync       Hyper-V-Dienst für Zeitsynchronisie…
Stopped  vmicvss            Hyper-V-Volumeschattenkopie-Anforderer
Stopped  vmms               Hyper-V-Verwaltung für virtuelle Co…

PS C:\Windows\system32>

Dann Hirn eingeschaltet und an BCDEdit erinnert, dass es dort zig Einstellmöglichkeiten zum Hyper-V gibt. http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

OK, dann mal nachgeschaut:

bcdedit /enum

Dabei wurde folgendes ausgegeben:

Windows-Startladeprogramm
————————-
Bezeichner              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 8.1
locale                  de-DE
inherit                 {bootloadersettings}
recoverysequence        {4b6f8314-5573-15e4-b299-de2a5ae3ac48}
integrityservices       Enable
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4b6f8312-5575-15e4-b299-de2a5ae3ac48}
nx                      OptIn
bootmenupolicy          Standard
hypervisorlaunchtype    Auto

Ja alles klar. HypervisorLaunchtype steht auf Auto und sollte entweder nicht da sein oder auf Off stehen.

Hier wird beschrieben wie man einen weiteren Eintrag im Bootmenü generieren kann: http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

Dadurch kann man beim Rechnerstart auswählen, ob der Hyper-V Hypervisor aktiviert werden sein soll oder nicht.

Entscheidend dabei sind:

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
Dadurch wird ein weiterer Eintrag ins Bootmenü geschrieben. Die GUID
ff-23-113-824e-5c5144ea sieht aber bei jedem anders aus. Es stellt nur
eine eindeutige Kennung dar.

Da aktuelle Rechner recht schnell beim Booten sind, hilft ein weiterer BCDEdit Befehl in Zukunft den richtigen Eintrag beim Start automatisch auszuwählen:

bcdedit.exe /bootsequence {ff-23-113-824e-5c5144ea}


shutdown.exe /r /t 0 /f

Damit wird der Rechner mit dem neuen Bootmenüeintrag gestartet.

Man könnte dies nun über Powershell automatisieren aber der BCD WMI Provider hat so scheinbar seine Tücken: https://social.technet.microsoft.com/Forums/scriptcenter/en-US/18094085-781f-4649-8ff8-331388097911/how-to-get-boot-configuration-data-bcd-information-out-of-wmi-with-powershell?forum=ITCG

Hyper-V-VMMS Ereignisanzeige Fehler 19510 Problem mit Installationsdatenträger für die Integrationsdienste und Fehler 0x80070020

28 Juli 2014

Wer einen Hyper-V Server am Laufen hat, dem könnte diese wie immer vielsagende Fehlermeldung über den Weg laufen:

Das Image des Installationsdatenträgers für die Integrationsdienste konnte nicht aktualisiert werden: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (0x80070020).

Alles klar? Ich klicke auf Onlinehilfe und bekomme:

—————————
Ereignisanzeige
—————————
Die Onlinehilfe des Ereignisprotokolls kann nicht angezeigt werden, da der Standardbrowser nicht gestartet werden konnte.Klasse nicht registriert
—————————
OK  
—————————

Wird halt immer besser! Saftladen.

Powershell angeworfen und dieses angeschaut, man hat ja einen Riecher:

(get-vm).dvddrives

und dies bekommen:

VMName       Path
——       —-
AndroidX86   C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
AndroidX86-2 C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
Test
UbuntuTest
VistaTest    C:\WINDOWS\system32\vmguest.iso
W2K12R2Core

OK, ausgehend von der obigen Meldung mit den Integrationsdiensten macht es Sinn. Denn scheinbar will der Rechner die VMGUEST.ISO aktualisieren, kann es aber nicht, weil diese gerade bei einer VM in Benutzung ist. Dieser Fehler dürfte in Client-Hyper-V Umgebungen sicherlich häufiger auftreten.

Hyper-V VMs, Trusted Platform Module und das Problem mit den Virtual Smart Cards

15 Mai 2014

Von Microsoft gibt es endlich mal wieder tolles, neues Spielzeug. Seit Windows 8 gibt es sogenannte Virtual Smart Cards. Von der Funktion her reagieren sie wie echte Smartcards, allerdings hat man sie im Rechner. Vor ein paar Tagen wurde nun Windows Phone 8.1 vorgestellt und siehe da, Windows Phone 8.1 ist nun auch Virtual Smart Card fähig!

OK, wenn man drüber nachdenkt, dann kommt man schnell zum Punkt: Toll was soll die Sache, wenn dann jeder kurz mal meine Smartcards kopieren kann, der irgendwie Zugriff auf meinen Rechner oder Handy hat?

Da kommt nun TPM ins Spiel. Im Businessbereich schon seit Jahren in vielen Rechnern eingebaut und oft unbenutzt, hat TPM mittlerweile Version 2 erreicht. Übrigens vergleichbares bei ARM nennt sich TrustZone. Auf jeden Fall handelt es sich dabei um einen speziellen Speicherbereich, auf dem z. B. auch Privatkeys sicher gespeichert werden können sollen. Android unterstützt diese Hardwarespeicherung auch seit Version 4.3 mit dem sogenannten Hardware Credential Store.

Um sich nun mit diesen interessanten Dingen beschäftigen zu können, kann man selber Smartcards anlegen. Üblicherweise macht man heutzutage alles in VMs. Aber leider fehlt es an diesem Ende mal wieder. Der aktuelle Hyper-V Server 2012 R2 unterstützt zwar SecureBoot bei Generation 2 VMs allerdings bringt er keine Unterstützung von TPM innerhalb von virtuellen Maschinen mit. Schade, sehr schade.

So führt die Verwendung von TPMVSCMGR.EXE dazu:

tpmvscmgr create /name MyVSC /pin default /adminkey random /generate

Standard—PIN verwenden: 12345678
TPM—Smartcard wird erstellt…
Komponente für virtuelle Smartcards wird initialisiert…
Komponente für virtuelle Smartcards wird erstellt…
Fehler beim Erstellen der Komponente für virtuelle Smartcards.
         (0x80090030) Das Gerät, das von diesem kryptografischen Anbieter angefordert wird, kann nicht verwendet werden.

Dieser Artikel bestätigt auch nochmal das Fehlen von TPM in VMs in der aktuellen Version: http://blogs.technet.com/b/jhoward/archive/2013/11/04/hyper-v-generation-2-virtual-machines-part-7.aspx. Schade.

Wenn man bestimmte übergeordnete Instanzen bei Microsoft außer acht lässt und man zunächst davon ausgeht, dass TPM die Privatkeys sicher speichert, dann könnte man es mittels dieser Technologie endlich schaffen sich per Handy mittels Bluetooth über die virtuelle Smartcard anzumelden. Da ja nun mittels Bluetooth 4.0 LE auch der Abstand der Geräte über das ProximityProfile ermittelbar ist, kann man z. B. definieren, dass das Handy immer im Bereich von 30-40cm zum Rechner sein muss, ansonsten wird automatisch der Lockscreen aktiv. Klar klappt das erst perfekt, wenn man mehrere Bluetoothsignalgeber an verschiedenen Stellen hat, aber die Dinger werden immer billiger und kleiner. Daraus resultiert dann quasi ein Inhouse GPS.

Davon spricht man schon ewig aber nun hat man wahrscheinlich alle Komponenten beieinander um so etwas sinnvoll umsetzen zu können. Oh, hab ich was von Windows 9 gehört? Ähm nö, gibts doch noch gar nicht.

Allgemein zu Virtual Smart Cards unter Windows: http://technet.microsoft.com/en-us/library/dn593708.aspx
Der Blog-Eintrag der VSC in Windows Phone 8.1 benennt: http://blogs.windows.com/windows/b/business/archive/2014/04/02/building-the-mobile-workplace-with-windows-and-windows-phone.aspx
Das dahinterliegende Management Protokoll: http://msdn.microsoft.com/library/hh880895.aspx
TPMVSCMGR.EXE-Beschreibung: http://technet.microsoft.com/en-us/library/dn593707.aspx

Niemals eine virtuelle Maschine bei Microsoft Hyper-V im Rootverzeichnis hinterlegen

10 Februar 2014

Nun gibt es einen offiziellen KB-Artikel zum Thema VMs und Rootverzeichnis. Dies ist egal mit welcher Version von Hyper-V ein No-Go!

http://support.microsoft.com/kb/2928127/en-us?sd=rss&spid=16796