CDC 2020 am 13. und 14.05.2020 in Hanau

Wieder Hanau?! Ja…ok…die Stadt mit einem kleinen Problem an verfügbaren Hotelzimmer…aber: Kleinigkeiten…das Conference Center ist wieder einmal die Städte der CDC Germany geworden…zum dritten Mal in Folge!

So langsam weiß man ja auch, dass man wenn man ein nettes Hotelzimmer haben will, eben frühzeitig buchen muss…

Btw: Auch wir haben es heute wieder getan…6 Mitarbeiter der TrinityComputer.de GmbH werden nächstes Jahre erneut an der CDC (und dem vermutlich wieder am Vortrag stattfindenden Hyper-V-Communitytreffen) teilnehmen!

Wir freuen uns! Smile

Highest Level technical Content von Top Speakern sind wieder einmal garantiert, wenn Carsten und seine Firma die MVP Kollegen aus der ganzen Welt nach Hanau einladen!

Hyper-V, Azure, HCI, AD, Server, Hardware Lösungen, Backup,…alle werden vermutlich wieder vertreten sein und wer nicht teilnimmt, egal ob als Teilnehmer oder Sponsor/Hersteller, macht was falsch! Definitiv!

cdc2020

Wer dabei sein will sollte sich beeilen, die SuperEarly Bird Phase für Wiederholungstäter läuft gerade noch, und die Tickets sind beliebt… 3 Tage “technische Schulung” für Geek/Nerd Mitarbeiter für unter 400 EUR zzgl. ggf. Hotelkosten sind für Systemhäuser mit Fokus auf Microsoft Infrastruktur geradezu ein Schnäppchen und daher ein “must-buy” oder “shutupandtakemymoney” Deal!!

Hier gehts zur CDC Webseite mit Ticketbuchung:

https://www.cdc-germany.de/#tickets

S2D Storagepool in Windows Server 2019 erweitern

Wir betreiben einige Server 2019 Storage Spaces Direct aka Azure Stack HCI Cluster und sind auf folgendes nicht ganz einfach zu findendes Thema gestoßen:

Erweiterung des StoragePools und letztlich Volumes in einem zwei Knoten Cluster mit Nested Mirrored Reciliency (NestedMirror, DoubleMirror, oder wie auch immer man es nennen mag).

Get-VirtualDisk | Get-StorageTier

Bzw eingeschränkter

Get-VirtualDisk -FriendlyName s2* | Get-StorageTier

clip_image001

Hat 10TB Kapazität aktuell, es sind, durch Tausch einiger SSDs durch welche desselben Typs, aber mit größerer Kapazität, (siehe andere zukünftiges Smile Posting) im Pool jetzt aber noch knapp 9TB (ohne Redundanzen) im Pool ungenutzt:

clip_image002

Die kann man aber nicht einfach grafisch über den Servermanager hinzufügen:

clip_image003

Auch über das AdminCenter habe ich keine Möglichkeit gefunden…

Mittels Powershell (über den aktuellen Besitzerknoten (!!!!), also den mit Schreibzugriff, des Pools) geht es aber:

Zuerst lassen wir uns mal die aktuelle Größe des StorageTiers im Pool Anzeigen:

Get-VirtualDisk -FriendlyName s2* | Get-StorageTier | ft FriendlyName, @{Label=’Freespace(GB)‘;Expression={$_.Size/1GB}} -AutoSize

(Wobei ‚Freespace(GB)‘ hier wohl besser ‚CurrentSize(GB)‘, also „aktuelle Größe“ heißen sollte…das war in der von mir genutzten englischsprachigen Referenz leider so angegeben)

Also besser:

Get-VirtualDisk -FriendlyName s2* | Get-StorageTier | ft FriendlyName, @{Label=’CurrentSize(GB)‘;Expression={$_.Size/1GB}} -AutoSize

clip_image004

Dann kann die Größe einfach erhöht werden:

Get-VirtualDisk -FriendlyName s2* | Get-StorageTier | Resize-StorageTier -Size 12TB

(hier muss die neue Komplettgröße (!!!) angeben werden, nicht die Menge um die erweitert werden soll!)

clip_image005

Eine weitere Abfrage mit:

Get-VirtualDisk | Get-StorageTier

Zeigt dann die neue Größe von hier 12TB an.

clip_image006

Anschließend zeigt z.B. der Servermanager, ggf. nach refresh, auch schon die neue Größe an:

clip_image007

Abschließend muss die Partition dann noch in der Datenträgerverwaltung erweitert werden:

(im Shot schon erfolgt)

clip_image008

Quelle/Inspiriert von: https://bcthomas.com/2016/10/expanding-storage-spaces-direct-volumes/

Fehler beim Hinzufügen zuvor bereits an VMSwitches gebundener Netzwerkadapter

eingetragen in: 2019, Hyper-V, SDN, Windows

Durch eine Reinstallation (Rolle entfernen und wieder hinzufügen) der Hyper-V Rolle wurden die SET VMSwitches entfernt.

Dann konnte man die Netzwerkkarten nicht einfach wieder einem neuen VMSwitch, z.B. mittels Powershell und dem New-VMSwitch Befehl, hinzufügen:

clip_image001

Fehler: “New-VMSwitch : Fehler beim Hinzufügen von Verbindungen für den virtuellen Ethernet-Switch.
Der externe Ethernet-Adapter „Intel(R) I350 Gigabit Network Connection xyz“ ist bereits an das Protokoll für virtuelle Microsoft-Switches gebunden.”

Nur wie entfernt man die NICs von der alten VMSwitch, welche es ja nicht mehr gibt:

clip_image002

Ein Get-VMSwitch ist „leer“…

Lösung:

Man kann einfach in den Eigenschaften der betroffenen Netzwerkadapter die Adapter wieder vom SET Protokoll „entbinden“:

clip_image003

Die Option „Hyper-V extensible Virtual Switch“ deaktivieren, dann werden automatisch die anderen (Standard) Elemente wieder aktiv und die Netzwerkkarte kann anschließend erfolgreich wieder einem VMSwitch hinzugefügt werden:

clip_image004

Hyper-V Cluster Replication Broker setup failed with IPv6 error 0x80071709

eingetragen in: Clustering, Hyper-V

Quick fix for an issue we recently had on a customers Windows 2012 R2 Hyper-V cluster

clip_image001

clip_image002

clip_image003

clip_image004

clip_image005

[Window Title] Fehler [Main Instruction] Vorgangsfehler [Content] Die Änderungen an der IPv6-Adresse „IP-Adresse: <nicht konfiguriert>“ konnte nicht gespeichert werden. [^] Details ausblenden [OK] [Expanded Information] Fehlercode: 0x80071709 Es stehen zwei oder mehr für eine Ressourceneigenschaft angegebene Parameterwerte in Widerspruch

Hyper-V-Replikatbroker

Netzwerkname:

RepBrokPSCL

Organisationseinheit:

CN=Computers,DC=ps,DC=local

IP-Adresse:

IPv6-Adresse auf 2003:a:117f:ad31::/64

IP-Adresse:

192.168.0.217

Gestartet

15.05.2019 18:21:22

Abgeschlossen

15.05.2019 18:21:26

Gruppe „RepBrokPSCL“ wird erstellt.

Hyper-V-Replikatbroker-Ressourcen werden erstellt.

Hyper-V-Replikatbroker Ressourcen werden konfiguriert.

Hyper-V-Replikatbroker-Netzwerk wird konfiguriert.

Gültigkeit der Clientzugriffspunkt-Einstellungen wird überprüft.

Netzwerknamenressource wird konfiguriert.

Neue IP-Adressressourcen werden konfiguriert.

Fehler beim Erstellen von „Hyper-V-Replikatbroker“.

Fehler beim Erstellen eines Clientzugriffspunkts für „RepBrokPSCL“.

Fehler beim Speichern der Änderungen am Clientzugriffspunkt.

Fehler beim Aktualisieren von IP-Adressressourcen.

Geänderte Eigenschaften für „IP-Adresse 2003:a:117f:ad31::“ können nicht gespeichert werden.

Es stehen zwei oder mehr für eine Ressourceneigenschaft angegebene Parameterwerte in Widerspruch

Vorheriger Clusterstatus wird wiederhergestellt.

clip_image006

Cause and Fix:

IPv6 is enabled on two internal NICs and Cluster Test reports IP adresses in same subnet on multiple Networkadapters:

Die Adapter „Heartbeat“ und „Ethernet 2“ auf dem Knoten „PSCN1.ps.local“ besitzen IP-Adressen im selben Subnetz.

Mehrere Netzwerkadapter auf dem Knoten „PSCN1.ps.local“ haben Adressen im selben Subnetz. Vom Failoverclustering wird nur ein Netzwerkadapter pro Subnetz verwendet. Es wird empfohlen, dass Sie Adapter in unterschiedlichen Subnetzen konfigurieren oder einen NIC-Teamvorgang verwenden, um mehrere physikalische Adapter in einem einzelnen logischen Adapter zu kombinieren.

Die Adapter „Heartbeat“ und „Ethernet 2“ auf dem Knoten „PSCN2.ps.local“ besitzen IP-Adressen im selben Subnetz.

Mehrere Netzwerkadapter auf dem Knoten „PSCN2.ps.local“ haben Adressen im selben Subnetz. Vom Failoverclustering wird nur ein Netzwerkadapter pro Subnetz verwendet. Es wird empfohlen, dass Sie Adapter in unterschiedlichen Subnetzen konfigurieren oder einen NIC-Teamvorgang verwenden, um mehrere physikalische Adapter in einem einzelnen logischen Adapter zu kombinieren.

Quick Fix:

Disable IPv6 on one of the NICs in every node:

clip_image007

In our case we choose to disable IPv6 on the Heartbeat network the fomer IT supporter had setup for the cluster:

(although I generally don’t like disabling IPv6 at all, but for the matter of a migration off this cluster it was an acceptable, cause only short term lived, workaround for us)

clip_image008

clip_image009

After this, setup of replication broker role was successfully on the cluster:

clip_image010

Hope this helps others having the same issue to quick fix it.
We happily did fix this and could move on with migration of the VM to Server 2019 after this.

Powershell: Hyper-V hosts mit ausstehenden Neustarts (pending Reboots) erkennen, evakuieren und automatisiert Neustarten

eingetragen in: Hyper-V, Powershell, Windows

Versetzt Hyper-V hosts mit pending reboots in den Wartungsmodus, startet diese neu und deaktiviert anschließend den Wartungsmodus wieder
Damit einher geht die Evakuierung der VMs vor dem Reboot und eine abschließende Clusteroptimierung:

 

<#———————————————————————————
Reboot-PendingBootSCVMHosts Skript
Versetzt Hyper-V hosts mit pending reboots in den Wartungsmodus, startet diese neu und deaktiviert anschließend den Wartungsmodus wieder
Damit einher geht die Evakuierung der VMs vor dem Reboot und eine abschließende Clusteroptimierung
Ersteller:       Oliver Sommer
———————————————————————————#>

Clear-Host

$VMHostNoClusters = $null
 $VMHostNoClusters =@()

$VMHosts = $null
 $VMHosts =@()

<# ---- Start Auskommentieren bei Verwendung der automatischen Hostliste weiter unten.       -----
 ## ---- Bei Verwendung der auto Hostliste einfach das in der nächsten Zeile am Ende nach # folgende > entfernen! -----
 #

$VMHosts += "Host012"
$VMHosts += "Host023"

<# ---- Ende Auskommentieren bei Verwendung der Auto Hostliste weiter unten -----#>

<# ---- Start Auskommentieren bei Verwendung der manuellen Hostliste weiter oben.            -----
 ## ---- Bei Verwendung der manuellen Hostliste einfach das in der nächsten Zeile am Ende nach # folgende > entfernen! -----
 #>

# Automatisiertes Bestimmen welche Hosts 'Pending Reboots' haben:

Write-Host "Alle Host der Domäne auf pending Reboot prüfen:" -ForegroundColor Green

$AllVMHosts = Get-SCVMHost

foreach ($AllVMHost in $AllVMHosts)
 {
 Write-Host
 Write-Host "Bestimme pending Reboot für: " $AllVMHost
 $PendingHost = Invoke-WmiMethod -ComputerName $AllVMHost -Namespace "ROOT\ccm\ClientSDK" -Class CCM_ClientUtilities -Name DetermineIfRebootPending

If ($PendingHost.RebootPending -eq $true)
 {
 write-Host "Pending reboot: " $PendingHost.RebootPending -ForegroundColor Yellow
 $VMHosts += $PendingHost.__SERVER
 Write-Host "Füge" $PendingHost.__SERVER "der abzuarbeitenden Hyper-V Host Liste hinzu!"
 }
 Else
 {
 write-Host "Pending reboot: " $PendingHost.RebootPending -ForegroundColor Green
 }
 }

<# ---- Ende Auskommentieren bei Verwendung der manuellen Hostliste weiter oben -----
 #>

Write-Host
 Write-Host "Hyper-V Hosts mit Pending reboot:" -ForegroundColor Yellow

foreach ($VMHost in $VMHosts)
 {
 Write-Host $VMHost

# Hole Hostobjekt zu jedem Host mit Pending Reboot, der Clustermitglied ist
 $VMHostobject = Get-SCVMHost -ComputerName $VMHost
 if ($VMHostobject.HostCluster -eq $null)
 {
 $VMHostNoClusters += $VMHost
 }
 }

# Warnung ausgeben, falls nicht geclusterte Hosts erkannt wurden:
 If ($VMHostNoClusters -ne $null)
 {
 Write-Host
 Write-Host "Hosts die nicht Teil eines Hyper-V Clusters sind werden Fehler beim Wartungsmode Job erzeugen!" -ForegroundColor Red
 Write-Host "Die nicht geclusterten Server lauten:" -ForegroundColor Yellow
 Write-Host $VMHostNoClusters -ForegroundColor Yellow
 Write-Host
 }

# Cluster array variable init, für späteres ClusterOptimizing
 $VMHostClusters = $null
 $VMHostClusters =@()

#Write-Host ------------------------------------------------
 Write-Host
 Write-Host "Start der Abarbeitung:" -ForegroundColor Yellow

ForEach ($VMHost in $VMHosts)
 {
 $VMHostobject = Get-SCVMHost -ComputerName $VMHost
 Write-Host
 write-host Durchlauf für $VMHost : -ForegroundColor Green

$MModeHost = $false

Write-Host Bestimmen ob Host $VMHost bereits im MaintenanceMode ist...
 If ($VMHostobject.Overallstate -eq "MaintenanceMode")
 {
 $MModeHost = $true
 Write-Host $VMHost ist bereits im MaintenanceMode! -ForegroundColor Yellow
 }
 Else
 {
 Write-Host $VMHost bisher NICHT in MaintenanceMode!
 }

If ($VMHostobject.HostCluster.Name -ne $null)
 {
 Write-Host
 write-host $VMHost ist Node im Cluster $VMHostobject.HostCluster.Name
 $VMHostClusters += $VMHostobject.HostCluster.Name

<# Falls der Host durch Netbackup oder anderes VMs im (locked) mode haben sollte, hilft die folgende
 # Kill VMMs und start VMMs Routine ggf. dabei die VMs doch verschieben zu können
 #

# Kill Prozess Virtual Maschine Management Service
 Write-Host
 Write-Host Kill Prozess VMMs auf $VMHost
 Invoke-Command -ScriptBlock {Stop-Process -name vmms -Force} -ComputerName $VMHost

# Start Prozess VMMs
 Write-Host
 Write-Host Start Prozess VMMs auf $VMHost
 Invoke-Command -ScriptBlock {Start-Process vmms} -ComputerName $VMHost

Write-Host
 Write-Host 10 Sekunden Pause zum Start des VMMs Service und Erkennen in SCVMM
 Start-Sleep -Seconds 10
 #

# Refresh Host, damit die SCVMM Verbindung wieder hergestellt ist bevor
 # Maintenance Mode aktiviert wird

Write-Host
 Write-Host Führe Refresh-VMHost aus um die SCVMM Verbindung nach Kill VMMs sicherzustellen
 Read-SCVMHost -VMHost $VMHost >$null
 #>

# Maintenance Mode im Cluster
 Write-Host
 write-Host Evakuierung und Wartungsmode von $VMHost wird eingeleitet.... -ForegroundColor Yellow

If ($MModeHost -eq $false)
 {
 Disable-SCVMHost -VMHost $VMHost -MoveWithinCluster >$null
 }

If ($VMHostobject.Overallstate -eq "MaintenanceMode")
 {
 Write-Host
 write-Host Neustart von $VMHost wird eingeleitet.... -ForegroundColor Yellow
 Restart-SCVMHost -VMHost $VMHost -Confirm:$false >$null

# Härteres Herunterfahren via iRMC/iLO mit -UseOutOfBandChannel ggf. wie folgt:
 # Restart-SCVMHost -VMHost $VMHost -UseOutOfBandChannel -RunAsynchronously
 }

If ($MModeHost -eq $false)
 {
 # Maintenance Mode beenden
 Write-Host
 write-Host Wartungsmode von $VMHost wird beendet.... -ForegroundColor Yellow
 Write-Host
 Enable-SCVMHost -VMHost $VMHost -RunAsynchronously >$null
 }
 Else
 {
 Write-Host $VMHost "befand sich vor dem Skritplauf schon im Maintenancemode, daher wird dieser nicht beendet..." -ForegroundColor Yellow
 }
 }
 else
 {
 Write-Host
 write-host $VMHost ist nicht geclustered!! -ForegroundColor Red
 }

write-host ------------------------------

}

# Cluster array variable sortieren und mehrfache Einträge entfernen, für anschließendes ClusterOptimizing
 $Clusters2Optimize = $VMHostClusters | Sort-Object -Unique

Write-Host
 Write-Host "Alle Cluster der Hyper-V Hosts mit Pending Reboots:"
 Write-Host $Clusters2Optimize

ForEach ($VMHostcluster in $Clusters2Optimize)
 {
 Write-Host
 Write-Host Opimierung für $VMHostcluster starten... -ForegroundColor Yellow

$hostCluster = Get-SCVMHostCluster -Name $VMHostcluster
 Start-SCDynamicOptimization -VMHostCluster $hostCluster >$null
 }

#>

CDC–Cloud & Datacenter Conference Germany 2017

eingetragen in: Hyper-V, Vorträge

Am 4. und 5.Mai 2017 findet die zweite CDC Germany in München in den Räumen der Microsoft Deutschland statt:

https://www.cdc-germany.de/

image

Als erfahrender Besucher von community und kommerziell betriebenen technischen Veranstaltungen und Konferenzen sticht die CDC besonders positiv hervor!

Man hat nicht das Gefühl Marketing-Foliensätze von vertrieblich getriebenen, halbtechnischen Vortragenden, wie auf so mancher Herstellerveranstaltung, präsentiert zu bekommen, sondern es werden extrem tiefgehend technische Themen betrachtet und vor allem auch Grenzen und Probleme der Produkte offen angesprochen.

Direkt durch Hersteller gestellte Vortragende machen das in der klaren Art und Weise auf Veranstaltungen leider nur sehr selten.

Trotz der notwendigen Professionalität der Veranstaltung, welche auf anderen Community Events manchmal etwas zu untergeordnet ist, kommt auch das von mir sehr geschätzte sogenannte „Networking“ nicht zu Kurz und hat reichlich Raum. Der Veranstaltungsort hat dies durch seine offene aber auch zusammenhängende Gestaltung des Vortrags- und Partnerbereichs sehr gefördert. Ich hoffe das wird in 2017 am neuen Ort in München auch wieder so gut klappen.

Mein Ticket habe ich schon am ersten Tag der EarlyBird Phase gebucht und noch weitere Mitarbeiter unserer Firma für die Reise nach München begeistern können, so dass wir mit 400% der Personen teilnehmen werden wie zuletzt! Smile

Inplace Upgrade von TP5 auf die RTM Version von Windows Server 2016

eingetragen in: 2016, Hyper-V, Windows

Zum Ende der Betaphase von Windows Server 2016 stellte sich die Frage, ob unsere produktiven Testsysteme Smile alle neu aufgesetzt werden mussten oder ob man ggf. ein Inplace Upgrade von der TP5 auf RTM machen kann.

Heute hatte ich Gelegenheit dies relativ gefahrlos an einem Backupserver einfach mal zu testen:
(kurz Form des Ergebnis –> Geht!)

image

image

image

image

imageimageimageimageimageimageimage

image

Also VMs heruntergefahren und Update dann fortgesetzt.image

imageimageimage

Zur Info:
Es handelte sich um Hyper-V Hosts mit wenigen VMs drauf.

Replikationseinstellungen und auch sowas wie die Windows Server Sicherungs Einstellungen blieben erhalten und weiterhin aktiv.

imageimage

image

SCVMM 2012 R2: "Install Virtual Guest Services" does not install current version of VMGuest Additions

eingetragen in: 2016, Hyper-V, Powershell

Durch Installation u.a. der für Hyper-V empfohlenen Hotfixes aus der Liste unter https://support.microsoft.com/en-us/kb/2974503 wurden die Hyper-V Virtual Maschine Additions (aka vmguest.iso, VMAdditions, Hyper-V Additions, etc.) auf den Hyper-V Hosts (hier Hyper-V 2012 R2) aktualisiert.
Dies erfolgt z.B. durch den Hotfix 3063283.

Im vorliegenden Fall auf Version 6.3.9600.17831 oder kurz 17831.

Da SCVMM (System Center Virtual Maschine Manager 2012 R2) eingesetzt wird, sollten die VMs (virtuellen Maschinen) über die Funktion “Install Virtual Guest Services” unter “VMs and Services” aktualisiert werden.

Leider stellte sich heraus, dass VMM diesen Job zwar angeblich erfolgreich ausführte, aber die Version der “VMAdditions” der VMs sich nicht änderte, sprich auf dem alten Stand vor 17831 verblieb.

„SCVMM 2012 R2 CU8 aktualisiert die virtuellen Maschinen nicht mit der auf den Hyper-V (Datacenter 2012 R2) Hosts aktualisierten VM Guest Services, sondern anscheinend mit der vorherigen (alten) Version.

oder auch

Set-SCVirtualMaschine -VM <VMname> -InstallVirtualizationGuestServices $True

Ist zwar erfolgreich, aber aktualisiert die Guest Services nicht, aka die Versionsnummer in SCVMM bleibt gleich, auch nach einem Reboot und SCVMM Refresh der VM.“

 

Auffällig scheint das evtl. 2012 (also nicht 2012 R2) VMs sehr wohl aktualisiert werden können, da wir aber nur eine kleine Anzahl 2012er VMs haben können wir das aktuell nicht so ohne weiteres bestätigen.

Das Issue scheint als Bug schon bei MS gelandet zu sein:

https://www.experts-exchange.com/questions/28896823/How-do-I-upgrade-the-version-of-Hyper-V-Integration-Services-that-SCVMM-2012-R2-offers-to-VMs.html

Erst ein Case beim Microsoft Support brachte aber die Gewissheit, das es sich wirklich um einen bereits bekannten Bug handelt:

Bug 6653803:[RFH] : VM addition upgrades fail after patching hosts with Hyper-V hotfix 3063283

https://microsoft.visualstudio.com/DefaultCollection/WSSC/_workitems?id=6653803&_a=edit

Repro Details

1.  Please detail the exact steps needed to repro this problem. This includes:

· Detailed repro steps

· Hardware configuration

· Network infrastructure / configuration

· Operating system version

· SC product version (including UR upgrades)

a. VMM 2012 R2 UR8 on Windows Server 2012 R2.

b. Hyper-V host running Windows Server 2012 R2.

c. Guest VM running Windows Server 2012 R2.

d. Apply hotfix 3063283 on the host.

e. Shut down the VM.

f. In VMM Console, select the VM and click Install Virtual Guest Services.

g. In job history, wait for the „Change properties of a virtual machine“ job to complete.

h. Start and refresh the VM.

Expected:  VM Additions show as 6.1.7601.17514

Actual:  VM Additions show as 6.1.7601.17514

Bis auf die, im vorliegenden Fall neueren Versionsnummern 17831 deckte sich das Verhalten mit der Problemstellung beim Kunden.

Als Workaround empfiehlt MS die alternative Verteilung der VMAddtions z.B. mittels SCCM oder auf dem manuellen Wege über das Anhängen der VMGuest.iso an jede VM und dann geskripted oder manuelles Einloggen in die VM und Installieren der Additions auf dem Wege. Letzteres erfordert leider Login und Adminrechte in den VMs, die wir bei dem Kunden nicht auf allen VMs haben, weshalb dieser Workaround nicht praktikabel erschien.

Letztes haben wir uns für folgenden Workaround entscheiden, welche die gewünschte Funktionalität unter SCVMM wieder herstellt:

Manually copy vmbus.sys from vmguest.iso to the %windir%\System32\drivers folder on the Hyper-V hosts.

Später, bzw. ggf. auf Anfrage, gerne das Powershell skript zum Kopieren der vmbus.sys auf alle Hyper-V Hosts einer SCVMM Umgebung.

Hier nur mal die entscheidende Zeile, welche die Datei kopiert:

Copy-Item -Path \\Server\freigabe\quelldatei\vmbus.sys -Destination \\$VMHost\C$\Windows\System32\Drivers

Migration aller VMs eines Hyper-V Hosts per Powershell

eingetragen in: Hyper-V, Powershell, VMM

Mit dem folgenden Powershell snipplet werden alle VMs eines Hyper-V Hosts (hier eines Clusterknotens, –HighAvailablity $true) auf einen anderen Hyper-V Host migriert.
Mittels des –RunAsyncronously attributes kann festgelegt werden, ob eine VM nach der Anderen oder so viele wie die Migrationseinstellungen der Host gleichzeitig zulassen migriert werden:

$SourceHost = Get-SCVMHost | where { $_.Name -eq „<souceHost-FQDN>“ }

$TargetHost = Get-SCVMHost | where { $_.Name -eq „<TargetHost-FQDN>“ }

# alle VMs des Sourcehost bestimmen

$VMs = Get-SCVirtualMachine -VMHost $SourceHost

#Schleife um alle VMs (asynchron) zu migrieren

ForEach($VM in $VMs)

{

Move-SCVirtualMachine -VM $VM -VMHost $TargetHost -HighlyAvailable $true -RunAsynchronously

}