20 Sep 2016

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

von | Veröffentlicht 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

18 Nov 2015

Windows 10: Maus Stottern/ Hänger/ Ruckeln/ springt/ zuckt/…

von | Veröffentlicht in: 10, Hardware, Windows |

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.

image

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:

image

 

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:

image

 

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.