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:
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:
Ein Get-VMSwitch ist „leer“…
Lösung:
Man kann einfach in den Eigenschaften der betroffenen Netzwerkadapter die Adapter wieder vom SET Protokoll „entbinden“:
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:
Zeigt maxEnvelopeSizekb von 500 oder ähnlich…Fehlermeldung verweist auf 512kb Größe des WinRM Paketes, also zu klein!
Fix
(Nur unter Admin CMD.exe, nicht in der Powershell machbar!!)
winrm set winrm/config @{MaxEnvelopeSizekb=“8192″}
Größe von 8192kb hatte ich in einem Posting als Empfehlung gefunden, setzt hier ggf. andere Werte ein, welche für euch funktionieren/sinnvoll erscheinen…
Dann die Anzeige im Servermanager refreshen/aktualisieren und die Nodes können sich gegenseitig wieder als Online sehen und per winrm abfragen:
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
}
#>
Zum Ende der Betaphase von Windows Server 2016 stellte sich die Frage, ob unsere produktiven Testsysteme 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!)
Also VMs heruntergefahren und Update dann fortgesetzt.
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.
Von einer UNC/Freigabe geöffnete und ausgeführte PS Skripte führen zum o.g. Fehler. Lokale Kopien derselben Skripte funktionieren einwandfrei.
Dieses Problem könnte durch eine fehlerhafte GPO der „InternetExplorer“ Settings verursacht worden sein.
Man kann unter den IE „Internetoptionen“ auf der Registerkarte „Sicherheit“ unter „lokales Intranet“ sichere „Sites“ eintragen, dort könnten z.B. die lokalen Domänen mit den UNC Pfaden eingetragen werden.
Ist diese aber leer, so ist die entsprechende GPO evtl. nicht korrekt gescoped (ggf. auf „authenticated user“).
Im vorliegenden Fall wurde die GPO zur Überarbeitung auf einen einzelnen Rechner gescoped und beim Veröffentlichen dann nicht korrekt um-/eingestellt.
Ich hatte seit einiger Zeit das interessante Phänomen, dass immer wenn ich meinen Rechner neugestartet, aus dem Ruhezustand oder Energiesparmodus aufgeweckt habe (oder einfach auch quasi gefühlt immer wenn ich anfing den Rechner zu benutzen), der Mauszeiger sich nur stotternd und mit starken Verzögerungen über den Bildschirm bewegt hat. Dabei war es egal, ob ich die Funkmaus (Microsoft Arc Touch Bluetooth) oder das Touchpad oder den TrackPoint verwendet habe. Auch ein Ausschalten einzelner oder mehrerer Zeigegeräte (Maus, Pad, Point) zeigte keine Wirkung, das Stottern blieb. Das Problem verschwand aber sobald ich den Taskmanager (taskmgr) aufrief, z.B. über STRG+ALT+ENTF oder rechtsklick auf die Taskleiste, und im Vordergrund, also als aktive Anwendung) laufen hatte. Sobald der Taskmanager im Hintergrund war, fing die Maus umgehend wieder an zu stottern.
Symptome:
Mauszeiger bleibt im Takt von 0,3-0,5 Sekunden „hängen“ und springt dann weiter
Mauszeiger bleibt stehen und bewegt sich dann soweit weiter wie die Maus bewegt wurde
Mauszeiger bewegt sich verzögert immer noch weiter bis zur Endposition, obwohl das Zeigegerät schon lange in Ruhe ist (nicht mehr bewegt wurde)
sobald der Taskmanager aufgerufen wird und als aktive Anwendung fokussiert ist, verschwindet das Stottern kurzzeitig, kehrt aber zurück sobald der Fokus nicht mehr auf dem Taskmanager liegt
Erinnert gefühlt habe ich mich dabei an frühere Erfahrungen mit Remote KVM Lösungen wie iLO/IRMC/VNC/RDP/Teamviewer/etc., wenn eine sehr langsame bzw. mit hohen Latenzen behaftete Internetverbindung oder WAN Verbindung wie ISDN zu dem entfernten Rechner bestand. Ein Arbeiten mit diesen Sprüngen und Verzögerungen der Maus war nahezu unmöglich bzw. erforderte sehr viel Geduld bei der Positionierung derselben.
Nachdem das Problem auch mit dem Windows 10 TH2 nicht verschwand, sondern eher (gefühlt) noch schlimmer wurde fand ich dann heute, nach einiger Recherche, die Lösung zu meinem Problem, welches wohl auch viele andere, unter anderem viele Besitzer von Acer PCs/AllinOne, HP und Lenovo Geräten haben, in diesem englisch sprachigen Forumsbeitrag: http://www.tenforums.com/drivers-hardware/14107-windows-10-mouse-lagging.html
Kurz gesagt ist eine App des Soundkarten Treibers der Firma Realtek für das Problem verantwortlich, die FMAPP.exe unter c:\Program Files\Realtek\Audio\HDA\.
Diese fand ich im Taskmanager unter den Prozessen:
per Rechtsklick mit der, dort ja nicht stotternden, Maus kann man den Task beenden, was bei mir zu einer umgehenden Normalisierung der Mausbewegungen führte:
Damit die App nicht beim nächsten Windows Start automatisch wieder gestartet wurde, habe ich die ausführbare Datei im oben genannten Pfad (c:\Program Files\Realtek\Audio\HDA\) in FMAPP.exe.org, also um die Endung .org erweitert, umbenannt.
Ich habe, so wie viele Benutzer des Forums auch berichteten, bisher keine Nachteile festgestellt, insbesondere die Soundausgabe funktioniert bisher weiterhin wie gewünscht und erwartet.
Die Aufgabe hier war letztlich verhältnismäßig simpel:
Ändere (ersetze) die bisherige DNS Server Konfiguration aller VMs einer Umgebung in vorgegebene neue DNS Server.
Eine tolle Aufgabe für ein kleines PowerShell-Skript (oder einen Praktikanten 🙂 ) dachte ich mir und schrieb das folgende PS Script zusammen:
(inline Kommentare sollten zur Erläuterung ausreichend sein)
Clear-Host
# AD Computer Suchkriterien definieren, damit nicht alle geändert werden, nach Bedarf anzupassen
# Get—ADComputer -FiIter {OperatingSystem —Like ‚*Server*‘ -and Name -like „VM*“‚} select —Expand DNSHostName
$ServerVMs = Get—ADComputer -Filter {OperatingSystem —Like ‚*Server*‘ -and Name -like ‚VM*‘} | select —Expand DNSHostName
# neue DNS Server in Array SDNS schreiben
# weitere DNS Server durch weitere += Zeilen hinzufügen falls nötig!
In der aktuellen TP3 von Windows Server 2016 gibt es (leider) die MinimalGUI Setupoption nicht mehr, sondern nur noch “Core” oder “Full GUI”, wobei letzteres alles mögliche installiert, also z.B. auch Handschrifterkennung und Mediageschichten, die für eine RemoteDesktop (Terminalserver) Installation sinnvoll sein mögen, aber nicht für die meisten anderen Server:
Bei Core gibt es den Servermanager nicht, der in der MinimalGUI Variante vorheriger Betaversionen autoamtisch installiert wurde.
ich habe die MinimalGUI Variante zu schätzen gelernt, da man damit eigentlich alles administrative machen konnte was ich bisher benötigt habe, ohne viel Ballast in der Installation zu haben.
Also habe ich mit dem aktuellen TP3 Build 10514 einfach wieder die Variante ohne GUI (Core) installiert und mit folgendem Befehl die Servermanager GUI nachinstalliert:
Open Start menu and type (search) for “Free up”, which should return the “Free up disk space by deleting unnecessary files” control panel item:
Start and let it scan your disk for files that might be deleted without harming the functionality of your system.
It will return a list like this:
If you also want to remove the windows.old and .bt folder you need to also scan for “Systemfiles” using the button that requires administrative rights.
It will return a list of potentially unneeded files and folders and lets you pick and choose which ones you want to keep or remove from your installation.
One of these should be “Previous Windows installation(s)” which has had a size of 17.7GB and eventually even 31.3GB on my disk as you can see here:
Also the “temporary Windows installation files” might be safely deleted and seem to correspondent with the $Windows.~BT folder:
Clicking ok, let’s you think about it again by asking the “are u sure” question:
It might not totally remove the Windows.old folder, but almost. (it left some files with a total of 1.4MB behind on my computer, which I moved to a TEMP folder to get them out of sight on the root of C till I have time to take over ownership and than be able to delete those leftovers, too.