Archive for September 2018

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.