Powershell und das Datum bei länderspezifischen Einstellungen

29 September 2018

Die ganzen Datumsfunktionen von Powershell beruhen auf .Net Funktionen. Eigentlich sollte länderspezifische Formatierungen heutzutage keine Rolle mehr spielen, aber je nachdem welche Vorgehensweise man wählt, kann einem das Thema auf die Füße fallen und einen staunend zurück lassen. Ich will hier nicht auf die Details eingehen, das haben schon andere gemacht. Ich möchte nur eine einfache Variante zeigen, mit der man sich helfen kann aus dem Dilemma rauszukommen.

Fangen wir konkret an. Gegeben sei ein beliebiges Datum

$d = Get-Date

Gibt man nun $d aus erscheint dieses

Samstag, 29. September 2018 11:11:01

alles in der korrekte Form, da Get-Culture

LCID             Name             DisplayName
—-             —-             ———–
1031             de-DE            Deutsch (Deutschland)

liefert. Soweit so gut.

Blöd wird es nur, wenn man die Variable $d ausgeben möchte und zwar nicht in der direkten sondern indirekten Form:

$d

Samstag, 29. September 2018 11:11:01

"$d"
09/29/2018 11:11:01

Wie aus heiterem Himmel wird das amerikanische Datumsformat verwendet, genauer gesagt die Culture-Invariant-Form.

Wie lässt sich das Dilemma lösen? Es gibt zwei Möglichkeiten. Eigentlich drei, aber die Dritte Möglichkeit manuell “yyMMdd” usw. anzugeben ist am wenigsten praktikabel, weil man sich da unnötige Abhängigkeiten schafft. Nun zu den zwei Varianten.

Entweder man gibt am Anfang bereits ein Format mit:

$d=get-date -format "G"
$d
29.09.2018 11:11:01
"$d"
29.09.2018 11:11:01

oder man gibt das Format bei der Ausgabe durch Umwandlung bei ToString() mit:

$d=get-date
$d
Samstag, 29. September 2018 11:11:01
"$($d.ToString("G"))"
29.09.2018 11:11:01

Weitere Infos zum Thema findet man hier: https://stackoverflow.com/a/37603732 und hier https://stackoverflow.com/a/30541917. Bei diesem Thema kommt dann noch schnell die ganze Geschichte mit den Cultures hoch: https://stackoverflow.com/questions/49866108/issue-with-english-non-us-culture, wo es auch bei Powershell Core 6.x immer noch offene Punkte gibt: https://github.com/PowerShell/PowerShell/issues/3831 und https://github.com/PowerShell/PowerShell/issues/3833.

Advertisements

Kaputte oder hängende Windows Updates Offline unter WinPE oder WinRE mittels DISM deinstallieren

20 September 2018

Ab und an gibt es Probleme mit Updates von Windows, welche dazu führen, dass mit dem betreffenden Rechner nichts mehr anzufangen ist. Er fährt einfach nicht mehr hoch und die üblichen Mechanismen zur Reparatur funktionieren nicht. Der normale Weg ist dann eine komplette Neuinstallation. Solange man einen Hardwaredefekt ausschließen kann muss dies nicht immer sein. Man muss nur irgendwie Zugriff auf die Festplatte des nicht funktionierenden Systems bekommen. Am einfachsten geht es mittels WinPE oder WinRE.

Nun verwendet man DISM.EXE um mit Images zu arbeiten, allerdings muss man immer mittels Parameter sagen, um welches Images es sich handelt. Images bezieht sich in diesem Zusammenhang auf eine Windowsinstallation. Dazu muss zuerst in Erfahrung gebracht werden, unter welchem Laufwerksbuchstaben das zu betreuende Windows verfügbar ist. Anschließend wird DISM immer mit dem Parameter /image:<LW> aufgerufen, wobei <LW> der Laufwerksbuchstabe des zu bearbeitenden Windows ist.

Zum Auflisten der installierten Updates verwendet man:

DISM /Image:C: /Get-Packages


Paketidentität : Package_for_KB4456655~31bf3856ad364e35~amd64~~17134.281.1.1
Status : Installiert
Versionstyp : Update
Installationszeit : 11.09.2018 20:03

Paketidentität : Package_for_KB4457146~31bf3856ad364e35~amd64~~10.0.1.0
Status : Installiert
Versionstyp : Security Update
Installationszeit : 11.09.2018 20:04

Paketidentität : Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.228.1.6
Status : Abgelöst
Versionstyp : Security Update
Installationszeit : 15.08.2018 22:33

Paketidentität : Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.285.1.7
Status : Installiert
Versionstyp : Security Update
Installationszeit : 15.09.2018 03:07

Der Vorgang wurde erfolgreich beendet.

Hat man nun ein Problem mit einem Update dann deinstalliert man dies, indem man die Paketidentität angibt:

DISM /Image:C: /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35
~amd64~~17134.285.1.7

Am Ende sollte noch aufgeräumt werden:

DISM /Image:C: /CleanUp-Image /RevertPendingActions

Der Parameter RevertPendingActions kann auch in anderen Situationen angewandt werden: https://blogs.technet.microsoft.com/joscon/2009/10/15/getting-out-of-a-no-boot-situation-after-installing-updates-on-windows-7-2008r2/.

Wenn das Entfernen des letzten Updates nicht hilft, könnte das weitere Entfernen von Updates helfen.

Übrigens kann man obige Befehle auch auf eine laufende Instanz von Windows anwenden indem einfach anstatt /Image:C: /Online angibt.

Chrome unter Windows 10 ladet und baut Seiten nur langsam auf und bricht teilweise auch mit einer Fehlermeldung ERR_TIMED_OUT ab

4 September 2018

Chrome, der Marktführer unter den Browsern, kann in bestimmten Fällen ein seltsames Verhalten an den Tag legen. Beim Aufruf einer Seite baut diese nur sehr langsam oder gar nicht auf. Dabei sieht man unten links eine Statusmeldung mit dem Text

Sichere Verbindung wird hergestellt…

Vor allem bei Seiten die sich massenweise Tracking-Cookies oder Werbeinhalte aus verschiedensten Quellen holen, die also aus verschiedensten Domains Inhalte nachladen, kann dies ziemlich lange dauern. Im Extremfall führt es zu dieser Fehlermeldung:

ERR_TIMED_OUT

Der erste Gedanke für so einen Fall könnte eine Infektion des Rechners sein, wie hier jemand denkt: https://www.trojaner-board.de/189359-google-chrome-laedt-langsam-warten-diverse-homepages.html. Aber das konnte im aktuellen konkreten Fall ausgeschlossen werden. Auch war keiner der bekannten Antivirenscanner der Übeltäter. Weiter könnten noch Probleme mit IPv6 eine Rolle spielen oder einfach Probleme mit dem Router. Aber all diese Punkte lassen sich ganz schnell aus der Welt schaffen, indem man einfach prüft wie Edge reagiert. Mit Edge waren die Seiten ohne Probleme ladbar.

Auch Chrome zu deinstallieren und komplett neu zu installieren, explizit als 64-Bit Version, brachte keine Hilfe.

Es scheint also ein Chrome spezifisches Problem zu sein. Da Chrome gerne mit technischen Neuerungen glänzt, lag die Vermutung nahe, dass evtl. schon TLS 1.3 zum Einsatz kommt, aber das explizite Abschalten brachte auch keine Änderung. Sicher nutzen aktuelle Server nur selten TLS 1.3 aber es hätte ja sein können, dass eine Entscheidungsroutine ob 1.3 oder 1.2 verwendet wird Probleme machte. Aber wie gesagt brachte das auch nichts.

Beim weiteren Durchforsten des Internets kam dann auch einmal jemand und meinte, man müsse den Kryptographiedienst (Dienstname CryptSvc) von Windows neu starten. Da beim Aufbau einer sicheren Verbindung die Kryptographie eine Rolle spielt, war dies nicht so abwegig und brachte wohl auch eine Beschleunigung. Allerdings wenn Chrome verlassen und neu gestartet wurde, war alles wieder beim alten.

Bei weiterer Recherche kam dann dieser Bug von Chrome zutage: https://bugs.chromium.org/p/chromium/issues/detail?id=838707, “Win10 Spring Update 1803 causes ERR_TIMED_OUT”. Hier sind alle Probleme exakt beschrieben, auch dass Windows 10 v1803 zum Einsatz kam war der Fall.

In dem Bug-Thread werden einige Problemlösungen angedeutet, die effektivste Methode scheint aber zu sein, wenn der Kryptographiedienst mit anderen Rechten gestartet wird. Infos zur Aufgabe des Kryptographiedienstes: https://docs.microsoft.com/en-us/windows-server/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server#cryptographic-services. Standardmäßig wird er mit dem Netzwerkdienst-Konto (NT AUTHORITY\NETWORK SERVICE) gestartet. Wenn man nun bei den Eigenschaften des Dienstes dies auf Lokales Systemkonto (NT AUTHORITY\SYSTEM) ändert, dann scheint Chrome zufrieden zu sein und läuft wieder normal schnell.

In Powershell sieht diese Änderung so aus:

$svc = Get-WmiObject Win32_Service –filter "name=’CryptSvc’"
$svc.Change($null,$null,$null,$null,$null,$null,"LocalSystem", $null)
$svc.StopService()
$svc.StartService()

Eine weitere Variante das Problem zu lösen ist in der Registrierung rumzutoben und z. B. ProtectedRoot zu löschen aber das wäre noch sensibler als die Berechtigung des Diensts zu ändern.

Nicht auszuschließen ist, dass es sich evtl. um ein Problem im Zusammenhang mit Spectre handelt… Wer weiß das heute schon?

Gruppenrichtlinien in Windows einfach finden mittels Policy Plus

2 September 2018

Häufig hat man das Problem, dass man eine englische Beschreibung für eine Gruppenrichtlinie hat. Damit man sich nicht wundsucht die betreffende Eintragung in Deutsch zu finden, kann man die Suchfunktion in Policy Plus verwenden.

Z. B. Gibt es dieses Jahr ein Problem in Zusammenhang mit RDP und CredSSP. https://audministrator.wordpress.com/2018/08/23/windows-10-credssp-encryption-oracle-remediation-error-using-rpp/. Dort tauchte als eindeutiger Begriff Oracle auf. Um nun diesen Eintrag schnell finden zu können, ladet man sich Policy Plus herunter: https://github.com/Fleex255/PolicyPlus und sucht dort nach Oracle.

Policy Plus ist ein absolut geniales Hilfsprogramm um schneller als mit der unhandlichen MMC mit Gruppenrichtlinien zu arbeiten.

Wie kann man m3u8 Dateien in Powershell herunterladen

30 August 2018

Leider ist m3u8 kein eindeutig definiertes Format. Aber es wird oft für Streaming von MP4 und ähnlichen verwendet.

Hier ein einfaches Beispiel wie man die Teile aus einer .m3u8-Datei mittels Powershell herunterladen kann:

$m3u8 = "http://irgendwoher.net/Video.m3u8&quot;
$m3u8Local = ".\video.m3u8"
Invoke-WebRequest -UseBasicParsing –Uri $m3u8 –OutFile $m3u8Local

Die m3u8-Datei besteht dann aus irgendwelchen Textzeilen:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:7
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:6.006,
afis4sqr_00103518-16×9-720p-720p-3000k_00001.ts
#EXTINF:6.006,
afis4sqr_00103518-16×9-720p-720p-3000k_00002.ts
#EXTINF:6.006,
afis4sqr_00103518-16×9-720p-720p-3000k_00003.ts
#EXT-X-ENDLIST

Die TS-Dateien sind Sequenzen aus der MP4-Datei. Man erhält alle TS-Eintragungen z. B. so:

$ts = Get-Content $m3u8Local | where {$_ -notmatch "#.*"}

Damit werden alle Kommentarzeilen, die mit # beginnen entfernt.

Nun muss man aus $m3u8 Url den Stammpfad ermitteln.

$url = $m3u8.Substring(0,$m3u8.LastIndexOf(‚/‘))

Nun kann man mit dem Stammpfad von $m3u8 und den TS-Dateinamen die einzelnen Teile herunterladen:

$ts | % {Invoke-Webrequest -UseBasicParsing -Uri "$url/$_" -OutFile $_ -Verbose}

Um am Ende aus den einzelnen .TS-Dateien eine komplette .MP4-Datei zu bekommen kann man z. B. FFMPEG benutzen: https://www.ffmpeg.org/download.html. So bekommt man mit diesem Aufruf eine MP4-Datei:

.\ffmpeg.exe –i $m3u8Local -c copy -bsf:a aac_adtstoasc video.mp4

Man hätte aber auch hergehen können und gleich alles ffmpeg überlassen Zwinkerndes Smiley:

ffmpeg –i $m3u8 -c copy -bsf:a aac_adtstoasc .\video.mp4

Aber über den Umweg Powershell war es doch viel schöner. Vor allem hat die Powershell-Lösung auch den Vorteil, dass man die Headerzeilen und den Agenten verändern kann, falls nötig. Ach? Das geht mit ffmpeg auch? Na egal…

Automatisches Konvertieren von MBR-Bootfestplatten in GPT-Bootfestplatten in Windows, besonders auch für Hyper-V VMs

26 August 2018

Seit einigen Jahren gibt es immer mehr UEFI-Systeme. Was aber macht man, wenn man noch auf alter Master-Boot-Record Technologie, kurz MBR basierende Systeme hat? Windows 10 bringt seit der Version v1703 ein neues Programm Namens MBR2GPT.EXE mit. Mittels dieses Programms kann man eine Konvertierung vollautomatisiert durchführen.

Hier die gute und ausführliche Dokumentation von MS: https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt. Im Normalfall geht man her, bootet ein Windows PE und führt dann MBR2GPT.EXE aus. Vor dem ersten Start von der konvertierten Festplatte muss man noch im UEFI-BIOS evtl. Einstellungen für den erfolgreichen Start mittels UEFI ändern.

Wie kann man dies nun auf virtuelle Maschinen vom Hyper-V anwenden? Muss man auch extra von WinPE booten oder gibt es eine Offline-Lösung? Tatsächlich gibt es diese, man kann also seine VHD oder VHDX-Images von MBR auf GPT-Partition umstellen, damit wird auch der Umstieg von Generation1-VMs auf Generation2-VMs möglich.

Die folgenden Schritte führt man also alle auf einem Host-System und nicht unter Windows PE durch. Zuerst geht man her und holt sich den Pfad der zu konvertierenden VHD-Datei:

$VMName = "win10Gen1"
$vm=get-vm $VMName
$vm.HardDrives[0].Path

Dann bindet man die VHD-Datei ein und ermittelt die zugehörige Disknummer:

Mount-VHD $vm.HardDrives[0].Path
$disk=get-disk|where location -eq $vm.HardDrives[0].Path
$disk.disknumber

Nun kann man prüfen, ob eine Konvertierung möglich ist:

.\MBR2GPT.EXE /allowFullOS /Validate /disk:$($disk.disknumber)

Dabei ist wichtig /allowFullOS anzugeben, da wir unter einem vollen Windows arbeiten. Wenn alles glatt geht, bekommt man z. B. diese Ausgabe:

MBR2GPT: Attempting to validate disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Nun kann man den eigentlichen Vorgang starten:

.\MBR2GPT.EXE /allowFullOS /Convert /disk:$($disk.disknumber)

und erhält nach Fertigstellung ungefähr diese Ausgabe:

MBR2GPT will now attempt to convert disk 1.
If conversion is successful the disk can only be booted in GPT mode.
These changes cannot be undone!

MBR2GPT: Attempting to convert disk 1
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Trying to shrink the system partition
MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Adding recovery boot entry
MBR2GPT: Fixing drive letter mapping
MBR2GPT: Conversion completed successfully
MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Nach diesem Vorgang muss nur noch die VHD-Datei getrennt werden:

Dismount-VHD $vm.HardDrives[0].Path

Nun muss man nur noch eine VM der Generation 2 erstellen und obige VHD-Datei dort einbinden und schon bootet man von GPT und kann nun sogar SecureBoot aktivieren.

Falls es Probleme mit MBR2GPT gibt, sei noch auf die beiden Dateien setuperr.log und setupact.log verwiesen, welche sich in C:\Windows befinden und nähere Infos für evtl. Probleme enthalten. Vor allem die setupact.log enthält viele Details zum Vorgang was MBR2GPT.EXE eigentlich so alles veranstaltet.

Schade ist allerdings, dass MBR2GPT.EXE nicht im Microsoft Hyper-V Server enthalten ist, leider auch nicht in der aktuellen Preview des kommenden Hyper-V Servers. Stellt sich aber die Frage, ob man die Version von Windows 10 benutzen kann? Kann man! MBR2GPT.EXE ist eine reine 64-Bit-Anwendung somit unter Microsoft Hyper-V Server einsetzbar. Es scheint genauso wie auf Windows 10 zu funktionieren, sobald man /allowFullOS angibt läuft es.

Jetzt fehlt eigentlich nur noch ein Script, welches eine VM Generation 1 hernimmt und in eine VM Generation 2 automatisch konvertiert.

S.M.A.R.T Daten von Festplatten und SSDs abfragen

25 August 2018

Falls man Probleme mit Festplatten bekommt, dann helfen oft genauere Informationen zum Problem. Hier bin ich schon Mal kurz auf dieses Thema eingegangen: https://newyear2006.wordpress.com/2016/10/31/laufwerk-unter-windows-auf-mgliche-probleme-prfen/. Im Zweifel benötigt man aber mehr Daten oder noch besser eine Möglichkeit direkt ein Gerät prüfen zu können. Seit Jahren gibt es die Open Source Software SmartMonTools https://sourceforge.net/projects/smartmontools/. Sie ist auf allen bekannten System verfügbar. Für spezielle Einsatzbereiche z. B. beim Microsoft Hyper-V Server gibt es sogar extra eine reine 64-Bit Version. Das tolle an SmartMonTools ist, dass diese aktiv gepflegt werden und nun anfangen NVME-Geräte mit abzudecken.

Installation
Die aktuelle Version ladet man sich am zuverlässigsten beim Github-Mirror herunter: https://github.com/smartmontools/smartmontools/releases. Man bekommt zwar eine Setup-EXE heruntergeladen, muss diese aber nicht ausführen und kann statt dessen direkt mit 7Zip die benötigten Dateien herausholen. Im Grunde wird nur SmartCtl.exe benötigt.

Übersicht verfügbarer Laufwerke
Um eine Übersicht der ansprechbaren Laufwerke zu bekommen, ruft man

.\smartctl.exe –scan

auf und erhält z. B.

/dev/sda -d ata # /dev/sda, ATA device
/dev/sdb -d ata # /dev/sdb, ATA device
/dev/sdc -d ata # /dev/sdc, ATA device
/dev/sdd -d ata # /dev/sdd, ATA device
/dev/sde -d ata # /dev/sde, ATA device
/dev/sdf -d ata # /dev/sdf, ATA device
/dev/sdg -d sat # /dev/sdg [SAT], ATA device

angezeigt. Ruft man auf diesem System

Get-PhysicalDisk | select friendlyname, model

in Powershell auf, so erhält man diese Ausgabe

friendlyname  model
————  —–
PhysicalDisk5 WDC WD10JPVT-16A1YT0
PhysicalDisk6 Elements 25A1
PhysicalDisk1 Samsung SSD 850 PRO 1TB
PhysicalDisk4 WDC WD10JPVT-16A1YT0
PhysicalDisk0 INTEL SSDSC2CW480A
PhysicalDisk3 Samsung SSD 840 EVO 1TB
PhysicalDisk2 Samsung SSD 840 EVO 1TB

Das ist ein schönes durcheinander. Wenn man nun aber eine gewisse Interoperabilität haben möchte, muss man einfach dieses Mapping anwenden:

/dev/sda => PhysicalDisk0
/dev/sdb => PhysicalDisk1
/dev/sdc => PhysicalDisk2
usw.

Diese Regel gilt in den meisten Fällen. Ausnahmen sind in der Anleitung unter Windows am Anfang beschrieben.

Um einfacher Skripte mittels Powershell und SmartMonTools schreiben zu können, habe ich dieses Script erstellt:

Damit kann man ganz einfach zwischen den beiden Formaten hin und her konvertieren:

Convert-LinuxDeviceAndWinPhysicalDrive "/dev/sda"

gibt PhysicalDrive0 zurück und

Convert-LinuxDeviceAndWinPhysicalDrive "PyhsicalDrive0"

gibt /dev/sda zurück.

Allgemeine Informationen zu einem Laufwerk abfragen
Bevor man ins Detail geht, möchte man vielleicht sich vergewissern, dass man das richtige Laufwerk bearbeitet oder anschaut, dies erfolgt mit dem Parameter –i

.\smartctl.exe -i /dev/sdb

dabei erhält man z. B. diese Ausgabe:

smartctl 6.6 2017-11-05 r4594 [x86_64-w64-mingw32-2012r2] (sf-6.6-1)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 PRO 1TB
Serial Number:    S222NXBG110522B
LU WWN Device Id: 5 001138 8302afec0
Firmware Version: EXM02B6Q
User Capacity:    1.024.209.543.168 bytes [1,02 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Aug 25 21:04:37 2018 WEDT
SMART support is: Available – device has SMART capability.
SMART support is: Enabled

S.M.A.R.T. Daten abfragen
Will man nun S.M.A.R.T.-Informationen zu einem Laufwerk haben, so kann man ganz einfach

.\smartctl.exe -A /dev/sdb

verwenden. Dies liefert – je nach Laufwerk – z. B. diese Daten:

smartctl 6.6 2017-11-05 r4594 [x86_64-w64-mingw32-2012r2] (sf-6.6-1)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, http://www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   099   099   010    Pre-fail  Always       -       7
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       15905
12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       2
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       20
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   099   099   010    Pre-fail  Always       -       7
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   099   099   010    Pre-fail  Always       -       7
187 Uncorrectable_Error_Cnt 0x0032   095   095   000    Old_age   Always       -       49984
190 Airflow_Temperature_Cel 0x0032   079   100   000    Old_age   Always       -       21
195 ECC_Error_Rate          0x001a   199   199   000    Old_age   Always       -       49984
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   100   100   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       13132430686

Anleitung
Eine umfangreiche Anleitung mit vielen weiteren Beispielen findet sich auf der Wiki Seite, hier der Link zur aktuellen Version: https://www.smartmontools.org/browser/tags/RELEASE_6_6/
smartmontools/smartctl.8.in
. Zur neuesten Fassung – das ist aber die in der Entwicklung befindlichen Version – gelangt man über: https://www.smartmontools.org/browser/trunk/smartmontools/smartctl.8.in

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.

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!