Warum kann man in Windows 10 das Datum nicht mehr per Eingabeaufforderung ändern?

14 Februar 2019

Die Krux mit der Zeit bei Windows 10 oder warum zum Teufel kann ich meinem Windows nicht so einfach das Datum vorgeben, das ich möchte? Ach waren das noch schöne DOS-Zeiten. Man gab DATE ein, setzte das gewünschte Datum, startete seine Anwendung und konnte gemütlich arbeiten.

Vista brachte mit der UAC schon einige Änderungen mit, dass man zwingend Adminrechte zum Datumändern braucht usw. Aber Windows 10 in der aktuellen Ausführung (mind. seit 1607) treibt die Sache nochmal auf die Spitze! Dort gibt es sogenannte sichere Zeiten. Wehe, man befindet sich nicht in der “sicheren” Zeit, dann gibt es ganz schnell Chaos, Windows greift ein und stellt die richtige Zeit wieder her.

Im Grunde läuft die Geschichte so, man macht eine Admin-Eingabeaufforderung auf, gibt

DATE 10.10.18

ein, prüft diese mittels

DATE /t

bekommt meist das korrekte Datum angezeigt. Aber wehe die Zeitgötter sind gegen einen, dann startet man seine Anwendung mit der man in der Vergangenheit arbeiten möchte, doch unversehens hat man wieder die korrekte aktuelle Zeit.

Profis kommen dann und sagen: Ja man muss ja auch den Windows-Zeitgeberdienst W32Time ausschalten, also führt man noch ein

SC.EXE stop w32time

aus und probiert danach nochmal sein Glück. Klappt meist nicht, wenn definitiv nicht, liegt es vielleicht daran dass man sich in einer virtuellen Maschine befindet, da muss man z. B. noch den Hyper-V-Dienst für Zeitsynchronisierung ausschalten, also

SC.EXE stop vmictimesync

Vielleicht klappt es nun aber die meisten werden feststellen, Windows ist so schnell zurück bei der alten Zeit so schnell kann man manchmal gar nicht schauen.

Für die Behandlung von Daten seien hier noch der Vollständigkeit halber der Aufruf der GUI für die Datumsänderung genannt:

timedate.cpl

Und um in Powershell das Datum zu ändern, ohne die aktuelle Uhrzeit zu verlieren verwendet man:

set-Date "10.10.2018 $((Get-Date).ToLongTimeString())"

Die Abfrage der Zeitdienste in Windows sind mittels

get-service *time*

zu erhalten, wo W32Time, TimeBrokerSvc und bei Hyper-V VMs VMIcTimeSync auftauchen. Wobei mir die Rolle des TimeBrokerSync noch nicht klar ist.

Aber nun weiter im Thema. Um die Zufälligkeiten der Datumsrückstellung besser in den Griff zu bekommen, muss man Windows abgewöhnen bei der Kommunikation mit dem Internet SSL-Zertifikate zur Berechnung der Uhrzeit herzunehmen. Das Prinzip nennt sich Secure Time Seed of High Confidence (STSHC). Dabei handelt es sich nicht um ein typisches Microsoft Marketingbuzzword sondern eher um eine interne, und wie so oft, offiziell undokumentierte Sache. Einzig ein MS-Angestellter hat über das Prinzip ein paar Dinge geschrieben: https://blogs.msdn.microsoft.com/w32time/2016/09/28/secure-time-seeding-improving-time-keeping-in-windows/.

Kurz gesagt: Mit jeder verschlüsselten Kommunikation ins Internet kann Windows die Zeit korrigieren. Und das findet in Windows 10 mehr als häufig statt und erklärt auch das erratische Verhalten, welches man meist beobachten kann.

Man kann die aktuelle Einstellung durch folgende Zeile abfragen:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData

wird der Wert 1 geliefert ist die Zeitkorrektur durch SSL-Zertifikate aktiv, bei 0 ist sie ausgeschaltet.

Aktivieren (Vorgabe) kann man das Verhalten mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 1

und mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0

abschalten.

Läuft der W32Time-Dienst und aktiviert man das Logging z. B. mittels

w32tm /debug /enable /file:C:\temp\w32tm.log /entries:0-300 /size:1000000

dann findet man in w32tm.log solche Eintragungen, wenn STSHC eingreift und die Zeit umstellt:

152670 12:34:36.6488208s – Setting the system time because it is outside the secure time limits.
152670 12:34:36.6488464s -  Current system time:  12:34:36.648 10/10/2018
152670 12:34:36.6488666s -  Target system time:  12:34:36.455 2/11/2019
152712 12:34:36.4608379s -  (AUDIT) Time Jump of 3628799 seconds.
152712 12:34:36.4608764s – ClockDispln Discipline: *SET*SECURE*TIME*

Bei dem STSHC-Komplex sei auch noch dieser Registry Key genannt:

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\

der da die Properties

SecureTimeConfidence : 7
SecureTimeEstimated  : 131945739321311682
SecureTimeHigh       : 131945775321311682
SecureTimeLow        : 131945703321311682
SecureTimeTickCount  : 29139718

auflistet. High, Low und Estimated sind wieder interessant und sind zwei Stunden auseinander. Man kann die Werte in normale DateTime-Variablen konvertieren, muss aber noch 1600 dazu addieren, um aktuelle Werte zu erhalten. Die Vorgehensweise sieht so aus

([DateTime](Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\ -Name SecureTimeHigh).securetimehigh).AddYears(1600)

und ist hier beschrieben: http://byronwright.blogspot.com/2016/03/windows-10-time-synchronization-and.html.

Wenn man nun die SecureTimeLimits aus der Registry hernimmt, dann scheint immer gegen diese Verglichen zu werden, ob die Uhrzeit angepasst werden muss. Ist die aktuelle Uhrzeit des Rechners also außerhalb von Low und High wird sie auf Estimated gesetzt. Doch wie und wann werden High und Low gesetzt? Scheinbar beim Rauf- und Runterfahren des Rechners: http://byronwright.blogspot.com/2016/03/more-on-secure-time-for-windows-10.html. Wobei ich dies bisher noch nicht getestet habe.

Interessante Geschichte was mit der Zeitgebung durch SSL-Zertifikate passieren kann: https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_
jumping_back_on_windows_10_caused_by/
. Daraufhin gab es auch noch einen offiziellen KB-Artikel: https://support.microsoft.com/en-us/help/3160312/a-computer-that-is-running-windows-10-version-1511-reverts-to-a-previo.

Das ist sicherlich noch nicht alles was man zum Thema wissen müsste und sollte aber zumindest ein Anfang…

Ach, noch ein Dokument wegen Zeitsynckorrektheit von MS: http://windocs.blob.core.windows.net/windocs/WindowsTimeSyncAccuracy_Addendum.pdf, der Verweis auf den wichtigsten Zeit-Blog von MS: https://blogs.msdn.microsoft.com/w32time/ und noch die aktuelle MSDN-Doku zum Windows Zeitgeber Dienst: https://docs.microsoft.com/de-de/windows-server/networking/windows-time-service/windows-time-service-top.

Werbeanzeigen

Word 2016 und Probleme mit Rändern

10 Januar 2019

Auf der Suche nach einer Lösung für ein anderes Problem bin ich über diesen Thread gestolpert: https://answers.microsoft.com/en-us/msoffice/forum/all/bug-word-2016-fails-to-print-margins-correctly/22b484d4-f808-42e1-a2c0-b04de305edb3. Da geht es einfach mal wieder um die Unfähigkeit von Microsoft Probleme zu erkennen und darauf zu reagieren. Die Oberfrechheit ist aber am Ende der Moderator der trotz weiter bestehendem Problem den Thread einfach schließt!

Anscheinend könnte das manuelle Setzen des Compatiblitäts-Mode mittels

ActiveDocument.SetCompatibilityMode 14

helfen. https://docs.microsoft.com/en-us/office/vba/api/word.setcompatibilitymode.

Zeitsynchronisierung unter Windows forcieren

22 November 2018

Für die Zeit- und Datumseinstellungen gibt es w32tm.EXE unter Windows. In einem aktuellen Fall sollte nach Klick eines Eintrags die aktuelle Uhrzeit mit aktuellem Datum unter Windows 7 erzwungen werden.

Der erste Versuch war der Aufruf:

w32tm /resync

Aber da kam die Fehlermeldung:

Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
zu groß war. wurde nicht synchronisiert, da die erforderliche Zeitänderung

Mal abgesehen davon, dass es eine absolut unverständliche Meldung ist, ist die Lösung doch sehr einfach, man ruft einfach

w32tm /resync /force

auf und schon gehts. /force ist allerdings ein undokumentierter Parameter, aber Hauptsache er funktioniert. Als Meldung erscheint dann:

Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Befehl wurde erfolgreich ausgeführt.

Mann kann das ganze auch per Verknüpfung mittels Powershell initiieren da man Adminrechte bracht, werden diese auch gleich angefordert:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "& {Start-Process powershell.exe -Verb runas -ArgumentList ‚-Command ""& {Start-Service W32Time –v; w32tm.exe /resync  /force; "Aktuelle Zeit wurde gesetzt."; Start-Sleep -Seconds 5}"" ‚}"

Tar.exe unter Windows 10 der neue Tausendsassa

21 Oktober 2018

Mit Windows 10 v1803 wurde ein neues Utility-Programm von Microsoft ins Windows-System mitaufgenommen. Es handelt sich um TAR.EXE. Tar ist unter Linux im Dauereinsatz aber auch bei Mac OS X verfügbar. Bei Windows handelt es sich um ein reines 32- bzw. 64-Bit Windows Anwendungsprogramm und ist unter 32- und 64-Bit Windowsversionen vorhanden. Obwohl die EXE tar genannt wird, handelt es sich eigentlich um BSDTar, welches primär auch beim Mac zum Einsatz kommt. Die Besonderheit von BSDTar ist, dass es auf libarchive aufsetzt, d. h. viele Features werden durch libarchive definiert. Tar.EXE ist bereits bei einer einfachen Grundinstallation sofort verfügbar. Es hat auch nichts mit dem Windows Linux Subsystem zu tun, welches ihre eigenen tar-Programme mitbringen. tar ist bei Servern ab Windows Server 2019, auch beim Hyper-V Server. Leider fehlt die Unterstützung in WinPE. Hier die offizielle Ankündigung von Microsoft tar unterstützen zu wollen: https://blogs.technet.microsoft.com/virtualization/2017/12/19/tar-and-curl-come-to-windows/.

Um zu wissen was alles mit Tar möglich ist, gilt es zuerst die Version herauszufinden, dazu ruft man

tar –version

auf, welches

bsdtar 3.3.2 – libarchive 3.3.2 zlib/1.2.5.f-ipp

liefert. Hiermit wird obige Aussage bei tar handelt es sich um bsdtar verdeutlicht. Auch wird damit libarchive klar. Um nun die Möglichkeiten und den Versionstand besser verstehen zu können, kann man hier nachschauen: http://www.libarchive.org/. Zum aktuellen Zeitpunkt gibt es die Version 3.3.3, also ist Microsoft recht nahe am Original. Übrigens hat Windows 10 v1809 keine neuere Version mitgebracht, stellt sich die Frage, ob Microsoft zukünftig die Version aktualisieren wird oder ob die Version auf ewig bei 3.3.2 verharren wird. Der Source Code zur Version 3.3.2 ist hier zu finden: https://github.com/libarchive/libarchive/tree/v3.3.2.

Was kann man nun mittels tar unter Windows tun? Jede Menge, nicht umsonst die Überschrift. tar kann ZIP-Dateien erstellen, sogar ZIP64-Dateien, also ZIP-Dateien größer als 4GB, dadurch kann man komplette Platten mittels tar sichern. tar kann auch die Dateien mit AES-128 oder AES-256 verschlüsseln, somit kann man Sicherungen erstellen, verschlüsseln und bedenkenlos in die Cloud schieben. tar kann auch mit ISO-Dateien umgehen und diese sogar erstellen. tar kann aber nicht nur mit normalen und großen ZIP-Dateien umgehen, sondern unterstützt auch 7-Zip-Dateien. Daneben noch viele andere Formate mehr. Es soll auch mit CAB-Dateien umgehen können, aber meine Versuche hiermit sind alle gescheitert.

Nun ein paar Anwendungsbeispiele.

Erzeugt eine Test.ISO-Datei mit den beiden Dateien Datei1.txt und Datei2.txt:

tar -cf test.iso –format=iso9660 datei1.txt datei2.txt

Erzeugt eine Test.ZIP-Datei mit den beiden Dateien Datei1.txt und Datei2.txt, wobei die Test.ZIP-Datei zusätzlich AES-256 verschlüsselt und mit dem Passwort password versehen wird:

tar -cf test.zip –format=zip –options=encryption=aes256 –passphrase=password datei1.txt datei2.txt

Wie oben beschrieben darf die resultierende ZIP-Datei auch größer als 4GB haben, unterstützt also ZIP64.

Dieses Beispiel listet den Inhalt einer ISO-Datei auf:

tar -tvf test.iso

Die gleiche Variante stellt auch den Inhalt von ZIP-Dateien dar. tar versucht dabei unabhängig von der Endung das passende Format zu erkennen. Ein angeben des Formats mittels –format=zip ist nicht erlaubt und wird mittels Fehler quittiert.

Natürlich kann man Dateien auch extrahieren:

tar -xvf test.zip

entpackt alle in Test.ZIP enthaltenen Dateien.

So toll tar unter Windows auch ist, hab ich leider noch keinen Parameter finden können, über den ein Fortschrittsbalken oder Hinweis ausgegeben werden kann. Gerade bei größeren Dateien wäre dies absolut hilfreich. Auch ist der Einsatz von Filtern per Kommandozeile nicht so klar. Ein weiteres Problem sind Dateien die gesichert werden sollen, die gerade in Benutzung sind, hier bricht tar einfach mit einer Fehlermeldung ab. Leider fehlt die Unterstützung für –ignore-read-error.

Aber ist vielleicht alles nur eine Frage der Zeit…

Positiv festzuhalten gilt vor allem, tar löst nun das Problem, dass man seither mittels ZIP64 gepackte oder mittels AES-verschlüsselte Dateien nicht ohne Bordmittel öffnen bzw. erstellen konnte. Zumindest für Kommandliner geht dies nun.

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.

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.