Beim Versuch eine LibreOffice Erweiterung hinzuzufügen kommt die Fehlermeldung “Could not create Java implementation loader”

12 August 2018

Zum Einsatz kam eine recht neue LibreOffice Version 6.1.0.3 unter Windows 10. Installiert werden sollte die Grammatikhilfe LanguageTool. Dieses Add-On ist unter https://languagetool.org/#libreoffice zu finden.

Wenn man nun versucht in LibreOffice unter Extras->Extension Manager die heruntergeladene Erweiterung LanguageTool-4.2.oxt mittels Hinzufügen zu installieren, kann man diese Fehlermeldung erhalten:

Could not create Java implementation loader

Auf der LanguageTool-Seite steht bereits, dass Java 8 benötigt wird. Aber dies alleine reicht nicht aus, denn Java muss auch in LibreOffice aktiviert sein. Dazu ruft man im Menü Extras->Optionen auf und wählt den Eintrag LibreOffice->Erweitert aus. Hier muss man “Eine Java-Laufzeitumgebung verwenden” aktivieren.

Falls nicht bereits eine Laufzeitumgebung mit Version aufgeführt wird, muss diese noch ausgewählt werden. Man klickt auf Hinzufügen und wählt die passende Java-Runtime z. B. aus dem Verzeichnis C:\Programme\Java\jre1.8.0_181. Hier kann es passieren, dass die Plattformen von LibreOffice und Java-Laufzeitumgebung nicht zueinander passen. Dann erhält man diese Meldung:

Der von Ihnen ausgewählte Ordner enthält keine Java-Laufzeitumgebung. Bitte wählen Sie einen anderen Ordner.

D. h. bei einem 32-Bit LibreOffice benötigt man auch eine 32-Bit Java Laufzeitumgebung. Bei einer 64-Bit LibeOffice Version benötigt man die 64-Bit Java Laufzeitumgebung.

Advertisements

Server bootet nicht nach Installation einer Intel I350-T2V2 Netzwerkkarte

30 April 2018

Bei einer Aufrüstung eines Hyper-V Servers mit einer “Intel Ethernet Server Adapter I350-T2V2”-Karte bootete der Rechner nach dem Einstecken der Netzwerkkarte nicht mehr. Nicht einmal das BIOS des Rechners war erreichbar. Statt dessen erschien nur oben links ein blinkender Cursor auf schwarzem Hintergrund.

Der Server selber war schon etwas älter deshalb gab es keine BIOS-Updates. Was also tun? Die Beschreibung auf dieser Seite brachte die Lösung: https://communities.intel.com/thread/56362.

Im Prinzip war das Flashen der Firmware der Netzwerkkarte notwendig. Das passende Utility war dieses hier: https://downloadcenter.intel.com/download/19186, das sogenannte “Intel® Ethernet Connections Boot Utility, Preboot Images, and EFI Drivers”.

Jetzt wurde nur noch ein Rechner benötigt, der mit der Karte bootete, tatsächlich konnte ein anderer, älterer Windows-Rechner mit eingesteckter Karte problemlos booten. Damit konnte dann mittels (es war ein 32-Bit Windows, bei 64-Bit ist der Aufruf leicht anders)

BOOTUTILW32.EXE

die Netzwerkkarte ermittelt werden und mittels

BOOTUTILW32.EXE –up PXE –nic 1

aktualisiert werden. Zuvor musste aber noch die Datei BootIMG.FLB aus dem übergeordneten Verzeichnis in das Verzeichnis der BOOTUTILW32.EXE kopiert werden.

Mit dem Boot Utility wurde die Firmware der Netzwerkkarte von der Version 1.3.98 auf die Version 1.5.85 aktualisiert. Danach konnte der ursprüngliche Rechner mit der Netzwerkkarte problemlos gebootet und eingerichtet werden.

Hyper-V SecondaryStatusDescription meldet “The protocol version of the component…” bei VSS

11 April 2018

Auf einem Hyper-V 2016 Server wurde bei Windows VMs bei der Ausgabe von Get-VMIntegrationService beim VSS die Meldung “The protocol version of the component…” ausgegeben. Was bedeutet die Meldung genau und was ist die Lösung?

Zuerst dachte ich an ein Problem mit Updates der Hyper-V Integration Services. Da aber die betreffende VM eine Windows 10 Maschine war und diese automatisch die Updates für die Integrationskomponenten bekommt, war die Meldung etwas komisch. https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/Manage-Hyper-V-integration-services#integration-service-maintenance.

Mehr Informationen kann man sich anschauen mittels

(Get-VMIntegrationService VMName).SecondaryOperationalStatus

hier wird dann ein “ProtocolMismatch” gemeldet, den genaueren Text bekommt man mittels

(Get-VMIntegrationService VMName).SecondaryStatusDescription

Dieser lautet:

The protocol version of the component installed in the virtual machine does not match the version expected by the hosting system

Aber was ist jetzt das Problem? Schaut man sich mittels Get-VM die Daten der VM an, dann fällt die Version auf:

Name         State   CPUUsage(%) MemoryAssigned(M) Uptime           Status             Version
—-         —–   ———– —————– ——           ——             ——-
VMName Running 1           2546              01:28:49.6250000 Operating normally 5.0

Dazu muss man wissen, dass bei Server 2016 Version 8 bei neuen VMs verwendet wird. In diesem Fall stammte die VM aber von einem Server 2012 R2 und da gab es maximal Version 5.0.

Nachdem dann mittels

Update-VMVersion VMName

die Version auf die aktuelle 8.0 aktualisiert wurde, verschwand auch die dubiose Protokollfehlermeldung. ABER Vorsicht! Man bekommt zwar mehr Möglichkeiten durch Version 8.0 allerdings verliert man auch das einsehbare XML-Format der Konfigurationsdateien. Auch kann man VMs nicht mehr mit älteren Hyper-V Servern verwenden!

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

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!

Trusted Platform Module (TPM) unter Windows und SpecVersion ermitteln

13 Februar 2018

Um Passwörter und Geheimnisse abzusichern werden immer mehr Hardwaremodule eingesetzt. Eines dieser Module ist z. B. TPM. Die Aufgabe eines Trusted Platform Module ist es bestimmte Schlüssel und Geheimnisse abzuspeichern. Es ist zwar meist ein Hardwaremodul aber es kann im Innern doch auch wieder per Software updatebar sein. Ich hatte bereits vor Jahren versucht TPM unter Hyper-V mit ans laufen zu bekommen https://newyear2006.wordpress.com/2014/05/15/hyper-v-vms-trusted-platform-module-und-das-problem-mit-den-virtual-smart-cards/.  Damals gab es aber noch keine Unterstützung im Hyper-V. Dies sieht heute anders aus. Dadurch kann man sich nun mit TPM beschäftigen, ohne sich viel Gedanken machen zu müssen. Wo TPM bei Windows 10 zum Einsatz kommt, kann man hier nachlesen: https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/how-windows-uses-the-tpm.

Eine Frage die sich schnell ergibt, wenn man sich damit beschäftigt, ist, welche Version hat man eigentlich? Gängig sind Version 1.2 oder 2.0. Ruft man mittels TPM.MSC also die “Trusted Platform Module”-Management (TPM)-Konsole auf, dann kann man dort unter TPM-Herstellerinformationen die Spezifikationsversion einsehen. Schön, aber wie geht das auch per Commandline? Da gibt es eigentlich das Cmdlet Get-Tpm:

PS > Get-Tpm

TpmPresent                : True
TpmReady                  : True
ManufacturerId            : 1297303124
ManufacturerIdTxt         : MSFT
ManufacturerVersion       : 8213.275
ManufacturerVersionFull20 : 8213.275.21.18466

ManagedAuthLevel          : Full
OwnerAuth                 : R8yRy4e6DfK2hDS/EbQxdhA=
OwnerClearDisabled        : False
AutoProvisioning          : Enabled
LockedOut                 : True
LockoutHealTime           : 10 minutes
LockoutCount              : 0
LockoutMax                : 31
SelfTest                  : {}

Hier hätte ich erwartet, dass SpecVersion auftaucht, doch leider tut sie es nicht. Ok wir haben ja Powershell, vielleicht versteckt sich die Info woanders:

Get-Command -Module TrustedPlatformModule -ParameterName *spec*

Aber da kommt leider auch nix raus. Zumindest in der Version 2.0 der Cmdlets aus dem TrustedPlatformModule-Modul.

Also was tun? Wie immer liegt die Lösung im WMI, denn dort kann man die Klasse Win32_Tpm finden, zunächst brauchen wir aber eine einfache Möglichkeit um alle Namespaces zu durchlaufen:

Function Get-NamespaceRecursive ($namespace) {
$nss=Get-CimInstance -Namespace $namespace -ClassName __NAMESPACE
$nss | % {"$namespace/$($_.Name)"; Get-NamespaceRecursive "$namespace/$($_.Name)" }
}

Mit dieser können wir mittels diesem Aufruf alle verfügbaren Namespaces ermitteln und dort nach TPM Ausschau halten:

$ns=Get-NamespaceRecursive "root"
$tpm=$ns| % {Get-CimClass -Namespace $_ -ClassName *} | where CimClassName -match tpm

   NameSpace: ROOT/CIMV2/Security/MicrosoftTpm

CimClassName                        CimClassMethods      CimClassProperties
————                        —————      ——————
Win32_Tpm                           {IsEnabled, IsOwn… {IsActivated_Initial…

Damit erhalten wir zwei Treffer, einer davon Win32_TPM. Diesen schauen wir uns genauer an:

(Get-CimClass -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).CimClassProperties | where name -match specversion

Name               : SpecVersion
Value              :
CimType            : String
Flags              : Property, NullValue
Qualifiers         : {Description, Implemented}
ReferenceClassName :

Also Volltreffer. Es gibt sie also, die gesuchte Information.

Um in Zukunft die SpecVersion des TPM zu ermitteln verwendet man diesen einfachen Aufruf:

wmic /namespace:\\root\CIMV2\Security\MicrosoftTpm path Win32_Tpm get /value

IsActivated_InitialValue=TRUE
IsEnabled_InitialValue=TRUE
IsOwned_InitialValue=TRUE
ManufacturerId=1297303124
ManufacturerIdTxt=MSFT
ManufacturerVersion=8213.275
ManufacturerVersionFull20=8213.275.21.18466
ManufacturerVersionInfo=496f5420536f6674776172652054504d00
PhysicalPresenceVersionInfo=1.3
SpecVersion=2.0, 0, 1.15

Ups, das war der falsche Befehl 🙂 Bin da etwas in alte Zeiten ohne Powershell abgerutscht… Trotz allem könnte obiger Befehl in Situationen wichtig sein, wenn man mittels WinPE oder WinRE unterwegs ist und kein Powershell an Bord hat. In diesem Fall sollte man aber noch drvload x:\windows\inf\tpm.inf im Hinterkopf behalten, denn ohne Treiber geht evtl. nix. Zurück aber zum Thema.

Gemeint war dieser:

(Get-CimInstance -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).SpecVersion
2.0, 0, 1.15

Schön nun haben wir Version 2.0, 0, 1.15 und das bedeutet nun? Ist es 2.0 oder eine verkappte 1.2 Version? Tja, Aufklärung gibt es auf der Microsoft Seite zur Win32_Tpm-Klasse https://msdn.microsoft.com/en-us/library/windows/desktop/aa376484, dort steht:

The version of the Trusted Computing Group (TCG) specification that the TPM supports. This value includes the major and minor TCG specification version, the specification revision level, and the errata revision level. All values are in hexadecimal. For example, a version information of "1.2, 2, 0" indicates that the device was implemented to TCG specification version 1.2, revision level 2, and with no errata.

When the data is unavailable, "Not Supported" is returned.

Aha, wir bekommen also ziemlich viel geboten. Nur stellt sich die Frage, was für Erratas und Revisionen gibt es? Nun, wenn man beim Informationsimperium anfragt, dann bekommt man diese Seite geliefert: https://trustedcomputinggroup.org/tpm-library-specification/. Übrigens hatte ich die Trusted Computing Group schon mal mit SED im Programm: https://newyear2006.wordpress.com/2016/10/01/self-encrypting-drives-sed-und-probleme-mit-gelschten-bitlocker-partitionen/.

Obige SpecVersion mit 2.0, 0, 1.15 sagt also aus, dass wir es mit der 2.0er-Familie, dem Level 0 und der Revision 01.16 vom Oktober 2014 zu tun haben. Wobei die Angaben sich mit der Beschreibung von Microsoft oben nicht decken.

Hier die aktuell bekannten Versionen:

Familie/Version Level Revision vom
2.0 0 01.38 September 2016
2.0 0 01.16 Oktober 2014
2.0 0 00.99 Oktober 2013
2.0 0 00.96 März 2013
1.2 2 116  
1.2 2 103  
1.2   94  
1.2   85  
1.2   62  
1.1b      

Die Werte für 1.2 sind von hier: https://trustedcomputinggroup.org/tpm-main-specification/.

Wer sich tiefergehend mit TPM 2.0 beschäftigen möchte, der sollte sich unbedingt die Architekturbeschreibung und die Einrichtungsrichtlinien anschauen, https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf und https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf.

TPM 2.0 und Linux sind dann nochmal ein Thema für sich: https://blog.hansenpartnership.com/tpm2-and-linux/.

Nicht zu vergessen sind auch die CVEs mit TPMs, welche es zu beachten gibt: https://www.google.de/search?q=cve+tpm.

Apple iPhone taucht nicht im Windows Explorer auf, kein Zugriff auf Bilder möglich weil MTP fehlt

9 Februar 2018

Auf einem Rechner mit Windows 10 v1709 (64-Bit) schloss man per USB ein iPhone 7 an, es tauchte aber kein Eintrag im Windows Explorer auf. iTunes mit der aktuellen Version war auch installiert, also sollten alle Treiber aktuell verfügbar sein. Das manuelle aktualisieren der Treiber im Gerätemanager wurde auch immer nur mit der Meldung bestätigt, dass man bereits den aktuellen Treiber hat. Was tun?

Die Lösung ist relativ simpel. Man muss nur im Gerätemanager bei den USB-Controllern auf den Eintrag “Apple Mobile Device USB Driver” gehen und die Eigenschaften öffnen. Nun geht man auf das Register Treiber und klickt auf “Treiber aktualisieren”. Im nächsten Dialog klickt man “Auf dem Computer nach Treibern suchen” und dann auf “Aus einer Liste der verfügbaren Treiber auf meinem Computer auswählen”. Es stehen nun zwei Treiber zur Auswahl, der bereits bekannte “Apple Mobile Device USB Driver” und der “MTP-USB-Gerät”-Treiber. Wir wählen den MTP-Treiber. Wird der Treiber installiert, taucht automatisch im Gerätemanager der Eintrag “Tragbare Geräte” auf unter dem dann “Apple iPhone” zu sehen ist.

Nun ist auch das iPhone im Windows Explorer zu finden und nach Freigabe vom iPhone kann man nun problemlos auf den DCIM-Ordner des iPhone zugreifen.

Wichtige Unterschiede zwischen Powershell 5.1 und Powershell Core 6.x bei Invoke-WebRequest und Invoke-RestMethod

3 Februar 2018

Wenn man Invoke-WebRequest oder Invoke-RestMethod unter Powershell Core 6.x benutzt, sollte man im Zweifel nachfolgendes wissen. Die Namen sind die gleichen aber im Hintergrund haben sich einige Dinge geändert.

Ein sehr ausführlicher Artikel beschreibt die Unterschiede der Web-Cmdlets hier: https://get-powershellblog.blogspot.de/2017/11/powershell-core-web-cmdlets-in-depth.html.

So werden z. B. Header Variablen in Powershell Core strenger überprüft, siehe https://get-powershellblog.blogspot.com/2017/11/powershell-core-web-cmdlets-in-depth.html#L08. Um bestehende Scripte möglichst einfach weiterverwenden zu können, könnte man diese Umgebungsvariable setzen:

$PSDefaultParameterValues[‚Invoke-RestMethod:SkipHeaderValidation‘] = $true
$PSDefaultParameterValues[‚Invoke-WebRequest:SkipHeaderValidation‘] = $true

Damit kann man die strikte Header Prüfung abschalten.

Man muss sich auch bewusst sein, dass nun die Rückgabetypen andere sind als bisher. Man sollte also obigen Artikel unter https://get-powershellblog.blogspot.de/2017/11/powershell-core-web-cmdlets-in-depth.html#L09 genauer studieren. Vor allem kann dadurch teilweise die Logik eines Scripts einen ganz anderen Pfad bekommen!!

Nicht weniger wichtig ist das geänderte Verhalten bei Fehlern und Statuscodes: https://get-powershellblog.blogspot.com/2017/11/powershell-core-web-cmdlets-in-depth.html#L13.

Der zweite Artikel in der Blogserie beschreibt welche Features in Powershell Core 6.x im Vergleich zu Windows Powershell 5.1 nicht mehr vorhanden sind. https://get-powershellblog.blogspot.de/2017/12/powershell-core-web-cmdlets-in-depth.html.

Der wichtigste Punkt dabei ist, dass Invoke-WebRequest und Invoke-RestMethod nun keine file:// bzw. ftp://-Protokollle mehr unterstützen!! Nur noch http:// bzw. https:// werden unterstützt. Der zweite wichtige Punkt ist, dass ParsedHTML nicht mehr unterstützt wird, dieser Punkt ist logisch, weil auf den anderen Platformen kein Internet Explorer mit seinem DOM zur Verfügung steht. Dritter Punkt ist die komplette Abwesenheit von New-WebServiceProxy zur Abfrage von SOAP-Endpunkten.

Ein größeres Thema könnten Zertifikate werden, denn aufgrund der Crossplattform-Unterstützung kommen unterschiedliche Bibliotheken zum Einsatz, wo nicht alle Informationen in .Net Core durchgereicht werden und somit Powershell Core nicht zur Verfügung stehen!

OK den Wegfall von SSL 3.0 sollte zu verschmerzen sein, was allerdings blöd ist, ist der Wegfall der Unterstützung von ServicePointManager https://get-powershellblog.blogspot.com/2017/12/powershell-core-web-cmdlets-in-depth.html#L12. Diese Methode hatte früher hier z. B. Anwendung gefunden: https://newyear2006.wordpress.com/2014/07/26/bei-powershell-ssltls-zertifikate-prfung-einfach-ignorieren/. Eine mögliche Lösung ist allerdings Artikel 3 der Serie bei Parameter –SkipCertificateCheck beschrieben.

Der dritte Teil der Blogserie beschreibt Erweiterungen bzw. neue Features die bei Powershell Core in Invoke-WebRequest und Invoke-RestMethod Einzug gehalten haben https://get-powershellblog.blogspot.de/2017/12/powershell-core-web-cmdlets-in-depth_24.html.

Insgesamt haben die beiden Cmdlets 12 neue Parameter erhalten. Die wahrscheinlich wichtigsten sind die Unterstützung für OAuth Authentifizierung und Link-Parameter um REST-Aufrufen über mehrere Ergebnisseiten folgen zu können.

Darüberhinaus wird es mit Powershell Core 6.1.x noch weitere tolle neue Features geben, vor allem bezogen auf Formulare, siehe hier: https://get-powershellblog.blogspot.de/2018/01/powershell-core-61-web-cmdlets-roadmap.html.

Hyper-V Ereignisanzeige-Einträge erklärt

24 Januar 2018

Klappt bei einem Hyper-V etwas nicht, dann helfen auch mal die Ereigniseintragungen von Windows zur Problemlösung. Allerdings gibt es nicht einen, sondern je nach Problem verschiedene Eventlogs. Hier eine aktuelle Übersicht mit kurzen Beschreibungen für 2016: https://blogs.technet.microsoft.com/virtualization/2018/01/23/looking-at-the-hyper-v-event-log-january-2018-edition/

Hier noch die Verwendung in Powershell:

Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-VMMS
Get-WinEvent -ProviderName Microsoft-Windows-VHDMP

Ausgabe alle verfügbaren Hyper-V LogProvider (ok, VHDMP fehlt):

Get-WinEvent -ListProvider *hyper-v*

Noch kurz zur Verwendung der Cmdlets: Wenn man sich vertippt, erhält man diese Meldung:

PS> Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisanbieter gefunden, der "Microsoft-Windows-Hyper-V-GibtesNicht" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-GibtesNicht
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Hyper-V-GibtesNicht:String) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingProvidersFound,Microsoft.PowerShell.Commands.GetWin
EventCommand

Wohingegen, wenn man einen gültigen Ereignisanbieter verwendet, aber keine Ereigniseinträge vorhanden sind, diese Meldung erscheint:

PS > Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
Get-WinEvent : Es wurden keine Ereignisse gefunden, die den angegebenen Auswahlkriterien entsprechen.
In Zeile:1 Zeichen:1
+ Get-WinEvent -ProviderName Microsoft-Windows-Hyper-V-Config
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEvent
Command