Archive for März 2018

Schnelle Übersicht der Switchzuordnungen von VMs bei einem Hyper-V Server

28 März 2018

Beim Testen von verschiedenen Netzen oder Betriebssystemen auf einem Hyper-V Server verliert man meistens nach einiger Zeit den Überblick über die Switch-Zuordnungen. Leider hat die Management-Konsole von Haus aus nur einfache Einstellungsmöglichkeiten aber keine Übersicht.

Aber man kann sich ja mittels Powershell behelfen. Mit dieser kleinen Zeile bekommt man aufgelistet welcher Switch mit welcher VM verbunden ist:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}} | sort Switch | select Switch, VMName, IPAddresses

Wird die Darstellung auch zu unübersichtlich, dann bietet es sich an, dass man Out-GridView verwendet, damit man schnell suchen und neu sortieren kann:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}} | sort Switch | select Switch, VMName, IPAddresses| Out-GridView

Taucht in der Spalte Switch kein Name auf, dann ist der betreffenden VM auch kein Switch zugeordnet. Gibt es mehrere Namen, dann hat die VM mehrere Netzwerkkarten eingebaut und kann mit verschiedenen Netzen kommunizieren oder hat evtl. Teaming aktiviert.

Außerdem könnte noch bei der Übersicht der Switchtype interessant sein:

get-vm| Select @{N="VMName";E={$_.Name}},@{N="Switch";E={$_.NetworkAdapters.Switchname}},@{N="IPAddresses";E={$_.Networkadapters.IPAddresses}},@{N="SwitchType";E={(Get-VMSwitch $_.NetworkAdapters.SwitchName).SwitchType}} | sort Switch | select Switch, VMName, IPAddresses, SwitchType

Advertisements

Powershell Fehlermeldung ConvertFrom-Json : Ungültiger JSON-Primitiv: ..

26 März 2018

Beim Versuch eine absolut simple JSON-Datei in Windows Powershell 5.1 einzulesen erschien die Fehlermeldung:

ConvertFrom-Json : Ungültiger JSON-Primitiv: ..
In Zeile:1 Zeichen:1
+ ConvertFrom-Json .\settings.json
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-Json], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.ConvertFromJsonCommand

Ich bin schon mehrfach über dieses Problem gestolpert, wie andere auch, jedoch war es noch nie so klar wie in diesem Fall, woran das Problem liegt. Wieso das Problem so offensichtlich gelöst werden konnte, lag daran, dass die JSON-Datei absolut simple war:

{
"files.encoding": "cp850"
}

Obwohl die Datei offensichtlich korrekt aussieht, beschwert sich ConvertFrom-JSON. Als ich mir dann die Datei in Hex angeschaut habe, wurde aber schnell offensichtlich was das Problem ist:

PS > Format-Hex .\settings.json

           Pfad: .\settings.json

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   7B 0A 20 20 20 20 22 66 69 6C 65 73 2E 65 6E 63  {.    "files.enc
00000010   6F 64 69 6E 67 22 3A 20 22 63 70 38 35 30 22 0A  oding": "cp850".
00000020   7D                                               }

Ich gebe zu, die Darstellung ist unter aller sau, Danke WordPress, aber das Entscheidende ist zu sehen. Es sind die markierten 0A für den Zeilenumbruch. 0A weil es sich um eine Datei aus der Linuxwelt handelt, da ist 0A als Zeilenumbruch üblich. Hat sich leider bis zur Version 5.1 von Powershell nicht bei Microsoft herumgesprochen. Erst Powershell 6 Core arbeitet hier korrekt.

Wenn ich nun also vor dem Aufruf mit ConvertFrom-Json die Zeilenumbrüche in Windowsverträgliche umwandle, dann klappt auch die JSON-Konvertierung:

(Get-Content .\settings.json) -replace 0x10, (0x13,0x10) |ConvertFrom-Json

files.encoding
————–
cp850

Hier der Beweis, dass die anderen Zeilenumbrüche gesetzt sind:

PS > (Get-Content .\settings.json) -replace 0x10, (0x13,0x10) |out-string | Format-Hex

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   7B 0D 0A 20 20 20 20 22 66 69 6C 65 73 2E 65 6E  {..    "files.en
00000010   63 6F 64 69 6E 67 22 3A 20 22 63 70 38 35 30 22  coding": "cp850"
00000020   0D 0A 7D 0D 0A                                   ..}..

Da viele REST-APIs von Linuxrechnern auch JSON-Dateien verteilen und davon auszugehen ist, dass diese ihre JSON-Dateien mit den unter Linux-üblichen Zeilenumbrüchen versehen, ist davon auszugehen, dass das Problem auch bei einfachen Invoke-WebRequest zum Thema wird, wie hier https://stackoverflow.com/questions/24453320/invalid-json-primitive-error-when-converting-json-file oder hier https://stackoverflow.com/questions/47908382/convertfrom-json-invalid-json-primitive-%C3%AF.

Wie gesagt mit Powershell Core 6.x ist das Thema ebenfalls erledigt.

Probleme mit Windows 10 Feature Update weil ein alter Treiber das Update auf 1709 zunichte machte

16 März 2018

Bei einem Windows 10 Rechner mit v1703 sollte auf auf das Fall Creator Update v1709 aktualisiert werden. Doch dies war nicht möglich. Egal welche Variante probiert wurde, es klappte einfach nicht. Installiert war die 32-Bit-Variante, ob dies mit dem Problem zu tun hat, konnte nicht ermittelt werden. Was aber im weiteren Verlauf noch von Bedeutung sein wird, ist, dass es sich um einen Rechner handelt der bereits Windows Vista und Windows 7 davor gesehen hat und über Jahre hinweg immer mittels Windows-Updates aktualisiert wurde.

Der eigentliche v1709-Updatevorgang lief sogar zu fast 100% durch. Doch am Anfang wurde nach einem Neustart das Update immer rückgängig gemacht. Übliche Troubleshootversuche wie https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors brachte leider nichts.

Es wurde dann auch die setupact.log-Datei analysiert, welche im Verzeichnis "C:\$WINDOWS.~BT\Sources\Panther" zu finden ist. Dort war lediglich diese Fehlerinformation zu finden:

Error                 SYSPRP ActionPlatform::DeleteValue: Error from RegOpenKeyExW on key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Sysprep\OfflineState; dwRet = 0x13

Aber es gibt scheinbar keine Informationen darüber. Lediglich ein MSDN-Foreneintrag https://social.msdn.microsoft.com/Forums/de-DE/ee8c7041-930c-4a2e-9720-e6b49a05c67f/windows-10-fcu-update-fails-with-registry-key-delete-of-sysprep-offlinestate?forum=win10itprosetup mit ähnlicher Konstellation deutete etwas an, dass es an einem Treiber liegen müsse.

Nachdem einige Versuche fehlgeschlagen sind, wurde die Sache erst nach weiteren zwei Monaten in Angriff genommen. Nach normalen Windows Updates tauchte beim erneuten Versuch das Featureupdate zu installieren auf einmal diese Meldung auf:

"Windows could not configure one or more system components"

Aufgrund der Meldung und dieses Artikels https://social.technet.microsoft.com/Forums/en-US/1b5b24b7-a0f0-4955-9f44-32a977643aef/windows-10-fall-creator-upgrade-1709-stops-at-45-with-windows-could-not-configure-one-or-more?forum=win10itprosetup wurde weiter gesucht. Ein Eintrag sagt, man solle sich die Datei $Windows.~bt\Sources\Rollback\setupapi\setupapi.dev.log genauer anschauen. Tatsächlich waren darin Fehler vermerkt.

Eigentlich sollte Windows 10 vor einem Update prüfen, ob die Treiber alle verfügbar sind und entsprechend ein Update von vornherein ablehnen, wenn etwas nicht passt. Aber vielleicht ist der Computer mal wieder nicht schlau genug seine Probleme selber zu lösen.

Tatsächlich  brachte die Suche nach unnötigen Treibern die Lösung. So wurde mittels pnputil.exe zunächst die vorhandenen Treiberdateien aufgelistet.

pnp-util /enum-drivers

Dabei tauchten einige alte NDIS-Treiber, also Netzwerkkartentreiber auf. Im obigen Forums-Artikel gibt es viele, die auf einmal nach abstöpseln von WLAN-Adaptern erfolgreich das Update einspielen konnten. Also die alten NDIS und andere unsinnige alte Treiber mittels

pnputil /delete-driver oemx.inf /force 

gelöscht, wobei x bei oemx.inf immer eine Zahl die bei enum-drivers ermittelt wurde, darstellt.

Am Ende hat doch tatsächlich die Installation geklappt!