Ich muss öfters mal VHD in VHDX konvertieren. Dazu kann man natürlich den Hyper-V Manager benutzen oder – meine persönliche Vorliebe – die Powershell.

Um es im Hyper-V Manager zu erledigen, muss man die Aktion „Datenträger bearbeiten“ (Edit Disk) auswählen und dort die Quell-VHD-Datei selektieren. Danach ist der Menüpunkt „Konvertieren“ (Convert) zu wählen und dann das VHDX-Format anzugeben.

Deutlich schöner geht das in der Powershell:

Convert-VHD -Path c:\temp\source.vhd -DestinationPath c:\temp\destination.vhdx -VHDType Fixed

für eine VHDX mit fester Größe oder

Convert-VHD -Path c:\temp\source.vhd -DestinationPath c:\temp\destination.vhdx -VHDType Dynamic

für eine VHDX mit wachsender (dynamischer) Größe.

Hat man jetzt einen ganze Menge VHDs zu konvertieren kann man dies auch mit der Powershell automatisieren:

Set-Location c:\temp
gci -Filter *.vhd | foreach {Convert-VHD -Path $_.Name -DestinationPath „$($_.Basename).vhdx“ -VHDType Fixed}

vhdtovhdx

Dabei werden alle VHD-Dateien automatisch nacheinander in VHDX-Dateien (in diesem Fall mit fester Größe) konvertiert. Die Dateinamen bleiben hierbei gleich – nur die Dateiendung ändert sich natürlich. Es kann natürlich hier auch ein anderer Zielpfad eingegeben werden, z.B.:

gci -Filter *.vhd | foreach {Convert-VHD -Path $_.Name -DestinationPath „c:\vhdx\$($_.Basename).vhdx“ -VHDType Fixed}

Bei einer Migration von VMWare auf Hyper-V in der man virtuelle Maschinen übernimmt, muss man die VMDK-Dateien der VMs in VHD bzw. VHDX-Dateien umwandeln. Es gibt natürlich hier Tools wie den Starwind V2V Converter – aber wenn man mehrere VMDKs hat ist so ein graphisches Tool in dem ich für jede einzeln das Programm durchklicken muss natürlich nichts. Dafür gibt es beim Microsoft Virtual Machine Converter 2.0 schöne Powershell-Befehle mit denen man das erledigen – und natürlich auch scripten – kann.

Nach der Installation öffnet man eine Powershell als Administrator

Dann muss man erstmal die Module importieren

Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘

danach kann konvertiert werden – z.B:

convertTo-MvmcVhd -SourceLiteralPath C:\Migration\sv-db.vmdk -DestinationLiteralPath d:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx

Der Name der VHDX-Datei ist der der VMDK-Datei – hier also sv-db. Abgelegt wird die in unserem Beispiel also die sv-db-vhdx im Ordner d:\Hyper-V\VHDs.

Aussehen wird das dann zum Beispiel so:

mvmc

Das ganze kann man natürlich auch scripten:

cd /d c:\Migration
Import-Module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘
gci -Filter *.vmdk | foreach {ConvertTo-MvmcVhd -SourceLiteralPath $_.Fullname -DestinationLiteralPath D:\Hyper-V\VHDs -VhdType FixedHardDisk -VhdFormat vhdx}

Hier wird erst in den Ordner gegangen in dem die VMDK-Dateien liegen – hier also c:\Migration. Danach wird das Cmdlet geladen. mit gci (Alias für get-childitem) werden alle VMDK-Dateien aufgelistet und in den Konvertierungsbefehl geschickt. Es werden dann nacheinander alle VMDK-Dateien in unserem Zielordner (hier d:\Hyper-V\VHDs) als VHDX-Dateien konvertiert abgelegt.

Danach können die Maschinen angelegt werden.

Nähere Infos zu den Powershell-Befehlen gibt es in dem MVMC_cmdlets.doc beim Download.

Ich habe schon einige Exchange 2013 gesehen die Probleme mit dem Mailempfang hatten. Die Symptome waren folgende:

– Port 25 war sporadisch nicht verfügbar bzw. keine Verbindung möglich
– Mails bleiben in der Transport Queue auf beiden Seiten (Exchange 2013 und SMTP-Server der Gegenseite) hängen
– NDR´s (Non Delivery Reports) werden erstellt

Das ist ein typisches Fehlerbild wenn ein Empfangsconnector falsch erstellt wurde und somit zwei Dienste von Exchange 2013 (Microsoft Exchange FrontEnd Transport Service und Microsoft Exchange Transport Service) auf dem Port 25 laufen. Wie es richtig geht steht übrigens hier 😉

Um zu überprüfen ob dies zutrifft kann man folgendes tun:

In der Exchange Management Shell folgenden Befehl absetzten:

Get-ReceiveConnector | Where-Object {$_.Bindings -like „*:25“} | fl Identity, Bindings, TransportRole

Exchange2013RelayFalse

Hier ist schön zu sehen, dass der „Default Frontend Exch2013“ auf dem Port 25 und unter dem Dienst FrontendTransport läuft – aber der „Relay“ unter dem Dienst HubTransport lauft. Somit teilen sich 2 Dienste die komplett andere Aufgaben haben den gleichen Port -> Beide streiten sich um den Port 25.

Jetzt muss nur der Connector „Relay“ auch auf den richtigen Dienst gemappt weden:

Set-ReceiveConnector Relay –TransportRole FrontEndTransport

Exchange2013RelayRight

Danach vielleicht noch den die beiden Dienste neustarten

restart-service MSExchangeFrontEndTransport
restart-service MSExchangeTransport

– und schon funktioniert der Email-Empfang wieder problemlos!

Quelle: exchangemaster.wordpress.com