The task XML is malformed

Mit Windows Server 2012 und Windows 8, also mit PowerShell 3 kam die Möglichkeit einen Task für den Windows Task Schedular mit PowerShell zu importieren.

Register-ScheduledTask -Xml .\VM-Export.xml -TaskName "VM-Export"

Diesen Aufruf quittiert Windows anschließend mit der Fehlermeldung (The task XML is malformed).

image

Der PowerShell-Befehl Register-ScheduledTask kann die XML-Datei nicht korrekt interpretieren, eine Lösung dazu (hier reicht auch schon der genaue Blick in den Screenshot) ist die XML-Datei über den folgenden Aufruf zu lesen.

Register-ScheduledTask -Xml (Get-Content .\VM-Export.xml |Out-String) -TaskName "VM-Export"

Enjoy it, b!

Moving Hyper-V Replikas

Seit der Hyper-V Version in Windows Server 2012 R2 lassen sich VMs im laufenden Betrieb auch ohne Failover Cluster verschieben. Das ist ziemlich Klasse und aus Sicht eines Schwaben schon ein Mega-Lob Winking smile Darüber hinaus gibt es noch die Möglichkeit eine Hyper-V Replikation zu erweitern (Extended Hyper-V Replication), also eine replizierte VM nochmals auf einen weiteren Hyper-V Host zu replizieren. Man hat damit also zwei Kopien einer VM.

Will man nun eine dieser Kopien verschieben, muss man auf eine Kleinigkeit aufpassen. Nach dem Verschieben muss nämlich, der Replica-Server angepasst werden. Ich zeige den Ablauf an einem Beispiel, damit klarer wird was ich meine.

Allgemein

Ich benenne meine Hyper-V Replikas immer um, indem ich ein “!” voran stelle. Die erste Replikation bekommt ein ! und die zweite Replikation !!, also:

  1. vm.sbsland.local (aktive VM)
  2. !vm.sbsland.local (erste Replika)
  3. !!vm.sbsland.local (zweite Replika)

Ausgangsituation

Wir haben eine VM (vm.sbsland.local) welche über insgesamt 3 Hosts repliziert wird.

image

Die VM (vm.sbsland.local) läuft auf dem Hyper-V Host 1 (cnoc.whisky.local) und wird von dort auf den Hyper-V Host 2 (nevis.whisky.local) repliziert. Auf diesem Host (nevis.whisky.local) wurde dann wiederum eine erweiterte Replikation (Extended Replication) auf den Hyper-V Host 3 (skye.whisky.local) eingerichtet.

Auf den Hyper-V Hosts sieht das nun wie folgt aus. Neben PowerShell habe ich noch jeweils den Hyper-V Manager / Replikation für die VM dargestellt.

cnoc.whisky.local:image

image

nevis.whisky.local:
image

image

Hier sehen wir neben der ersten (primary) Replikation auch die erweiterte (extended) Replikation.

skye.whisky.local:
image

image

Zielumgebung

Nun wollen wir den Hyper-V Host 2 (nevis.whisky.local) durch einen neuen Hyper-V Host ersetzen (mull.whisky.local). Eine erste Idee wäre natürlich einfach die Hyper-V Replikationen neu ein zu richten, das wollen wir aber nicht! Wir verschieben einfach die erste Replika der VM (!vm.sbsland.local) auf den neuen Hyper-V Host (mull.whisky.local).

image

Wie in der Abbildung zu sehen ist, wird die erste Replika (!vm.sbsland.local) der VM auf den neuen Host verschoben. Das kann über das Hyper-V Management oder aber über den folgenden PowerShell-Befehl erfolgen.

Move-VM -Name !vm.sbsland.local -DestinationHost mull.whisky.local -IncludeStorage -DestinationStoragePath 'd:\replicated virtual machines'

image

Nun haben wir auf dem Hyper-V Host 2 NEU (mull.whisky.local) die VM, aber noch mit dem alten Hyper-V Host 2 (nevis.whisky.local) eingetragenen Replika Server. Nach Ablauf des Intervalls für die Hyper-V Replikation geht diese in den Zustand Warning bzw. Critical.

image

Damit die Replikation wieder in Gang gesetzt werden kann, muss in der Konfiguration der !vm.sbsland.local der alte Hyper-V Host 2 (nevis.whisky.local) gegen den neuen Hyper-V Host (mull.whisky.local) ersetzt werden. Was über das Hyper-V Management oder über den folgenden PowerShell-Befehl erfolgen kann:

Set-VMReplication -VMName vm.sbsland.local -ReplicaServerName mull.whisky.local

Der Befehl muss dazu auf dem Hyper-V Host 1 (cnoc.whisky.local) ausgeführt werden.

image

Danach recht ein Resume-VMReplication um die Replikation wieder in Gang zu setzen.

image

image

So, nun läuft es wieder.

Enjoy it, b!