Weisheiten - der Netz-Weise Blog

Grundsätzlich unterscheidet man zwischen Textdateien und Binärdateien. Technisch gesehen sind beide Dateitypen Bitströme, also Reihen von aufeinanderfolgenden Bits. Textdaten werden allerdings nach einem festen Muster kodiert. Jeweils ein Block von 8 oder 16 Bits (oder je nach Codierung auch mehr) werden zu einem Zeichen zusammengefasst. Die klassische Codierung ist dabei die sehr alte ASCII-Codierung, die ein Zeichen in jeweils 7 Bit codiert und insgesamt 8 Bit für die Speicherung verwendet. Wenn man Get-Content verwendet, um eine Textdatei einzulesen, versucht Get-Content automatisch, die Datei als Text zu interpretieren und darzustellen. 

get-content -Path $einv:Windir\lsasetup.log
[ 1 1 / 4 1 5 : 3 1 : 1 4 ] 5 9 6 . 6 0 0 > - I n L s a p S e t R a n d o m D o m a i n S i d ( )

[ 1 1 / 4 1 5 : 3 1 : 1 4 ] 5 9 6 . 6 0 0 > - L s a p G e n e r a t e R a n d o m D o m a i n S i d : R t l A l l o c a t e A n d I n i t i a l i z e S i d r e t u r n e d 0 x 0

Die Ausgabe dieses Beispiels sieht allerdings sehr merkwürdig aus - Powershell hat zwischen jedes Zeichen ein Leerzeichen gesetzt. Das liegt daran, dass die Datei in UTF16 und nicht in ASCII codiert ist. UTF16 ist eine Form der Unicode-Codierung, die statt 8 16 Bit verwendet, um ein Zeichen zu speichern. Dadurch wird es möglich, eine deutlich größere Zahl von Zeichen zu codieren. UTF16 ist abwärtskompatibel zu ASCII, verwendet also für die ersten 127 Zeichen die gleiche Muster. Das zweite Bit wird beim Einlesen mit ASCII-Codierung dann als Leerzeichen interpretiert. Das Problem lässt sich lösen, indem man Get-Content mti dem Parameter -Endoding anweist, den Text als UTF16 zu dekodieren. 

get-content -Path .\lsasetup.log -Encoding Unicode
[11/ 4 15:31:14] 596.600> - In LsapSetRandomDomainSid()
[11/ 4 15:31:14] 596.600> - LsapGenerateRandomDomainSid: RtlAllocateAndInitializeSid returned 0x0

Das sieht schon viel besser aus. Wenn man mit Get-Content allerdings versucht, eine Binärdatei einzulesen, versucht Get-Content, auch den Binärcode in Textzeichen zu übersetzen. Das ist allerdings sinnlos, da der Binärcode ein Bitstrom ist und keinen Text darstellt. Das Ergebnis ist Kauderwelsch. 

In den letzten beiden Artikeln habe ich gezeigt, wie man mit Powershell Binärdaten einlesen kann. Die eingelesenen Daten können auch in der Registry gespeichert werden, und zwar direkt binär oder Base64-codiert als String. Diese Beispiele stammen aus einem Webcast, den ich für die Firmat Netwrix unter dem Titel "Die Windows Registry als Angriffsvektor" am 2. Mai gehalten habe. Die Aufzeichnung kann man unter https://www.netwrix.com/webinars.html#featured anschauen. 

Um Daten direkt im Binärformat zu speichern, legen Sie einen neuen Registry-Wert mit dem Cmdlet New-Itemproperty an. Der Schlüssel (Ordner), in dem der Wert erzeugt werden soll, muß dafür existieren.

$FindExe = Get-Content -Path C:\Windows\System32\find.exe -Encoding Byte -Raw
$RegKey = New-Item -Path Registry::Hkey_local_machine\SOFTWARE -Name NetzWeise
New-ItemProperty -Path $RegKey.PSPath -Name Find -Value $FindExe -PropertyType Binary

Um die Datei wieder als Exe-Datei zu speichern, lesen Sie den Schlüssel einfach aus. 

$FindBinaryData = (Get-ItemProperty -Path Registry::Hkey_Current_User\SOFTWARE\NetzWeise -Name Find).Find
Set-Content -Value $FindExe -Path c:\temp\find.exe -Encoding Byte

Sie möchten sich auf einen Computer per RDP remote aufschalten, aber RDP ist nicht aktiviert? Kein Problem, solange der Computer per Powershell-Remoting erreichbar ist. RDP ist nämlich über einen einzigen Registry-Eintrag steuerbar. Er heißt fDenyTSConnections und gehört zum Schlüssel Hkey_Local_Machine\System\CurrentControlSet\Control\Terminal Server. Setzen Sie ihn auf 0, so werden RDP-Verbindungen nicht mehr blockiert. Die Einstellung wirkt sofort, ein Neustart ist nicht notwendig, allerdings blockiert die Windows Firewall den Port 3389 dann weiterhin. Es gibt eine Gruppe von Regeln mit dem sprechenden Namen "RemoteDesktop", die Sie aktivieren müssen, um die Ausnahmen für eingehende RDP-Verbindungen inklusive Remote-Unterstützung zu aktivieren. Das geht mit Powershell in zwei Zeilen:

$RdpKey = "Registry::Hkey_Local_Machine\System\CurrentControlSet\Control\Terminal Server"
Set-ItemProperty -Path $RDPKey -Name "fDenyTSConnections" –Value 0
Enable-NetFirewallRule -DisplayGroup "RemoteDesktop"

Ja, Sie haben natürlich Recht, das sind 3 Zeilen, aber nur, um den Code hier ein wenig übersichtlicher darstellen zu können. ;-)

Wenn Sie am betroffenen Rechner sitzen, können Sie das natürlich auch von Hand machen. Sitzen Sie nicht an der betreffenden Maschine, aber Powershell-Remoting ist aktiviert (ab allen Servern ab 2012 Standard), können Sie das aber per Invoke-Command auch aus der Ferne erledigen. Das kann man natürlich auch wieder ein eine Funktion packen und in ein Modul speichern. Als einfache Funktion könnte das so aussehen - auch gleich mit Unterstützung für SSL.

Function Enable-RemoteDesktop
{
param(
  [String]$computername,

Wenn eine virtuelle Maschine in Hyper-V von einem Host auf einen anderen per Import übertragen werden soll, müssen alle virtuellen Switche, an die die Maschine auf dem Quellhost angeschlossen war, auf dem Zielhost existierten. Existieren bedeutet in diesem Fall, dass ein Switch mit identischem Namen vorhanden sein muß. Ist das nicht der Fall, quittiert Hyper-V den Import mit einer Fehlermeldung:

Es ist ein Fehler beim Import aufgetreten
Der virtuelle Computer kann aufgrund von Konfigurationsfehlern nicht importiert werden. Verwenden Sie "Compare-VM", um den virtuellen Computer zu reparieren

Compare-VM ist ein Powershell-Kommando, dass zusammen mit dem Hyper-V Modul ausgeliefert wird, und das vor dem Import angewendet werden kann, um zu prüfen, ob es Probleme bei der Konfiguration gibt. Dafür pipen Sie das vmcx-File der virtuellen Maschine einfach in Compare-VM. Man erhält dann ein Rückgabeobjekt mit den Konfigurationsdetails der VM:

PS > Dir M:\Hyper-V\LON-AP1\Virtual Machines\4C9790D7-48CD-4D31-8BA2-02D8C9C245AE.vmcx | compare-VM

CheckpointPath     : M:\Hyper-V\LON-AP1\Snapshots
VM                 : VirtualMachine (Name = 'LON-AP1') [Id = '4c9790d7-48cd-4d31-8ba2-02d8c9c245ae']
OperationType      : ImportVirtualMachine
Destination        : R1WS3
Path               : M:\Hyper-V\LON-AP1\Virtual Machines\4C9790D7-48CD-4D31-8BA2-02D8C9C245AE.vmcx
SnapshotPath       : M:\Hyper-V\LON-AP1\Snapshots
VhdDestinationPath : M:\Hyper-V\LON-AP1\Virtual Hard Disks
VhdSourcePath      :
Incompatibilities  : {33012}

Kürzlich habe ich mein BCDEdit-Modul wieder angefasst, um einige Funktionen zu überarbeiten. Das Modul erstellt dabei dynamisch Objekte aus dem BCD-Store, indem es per regulärem Ausdruck die Ausgaben von bcdedit.exe einliest, auftrennt und als Objekt zurückgibt.

Dummerweise sind aber nicht alle BCD-Einträge gleich. Einige Eigenschaften werden von BCDedit nur angezeigt, wenn Sie auch tatsächlich gesetzt sind. Um in einer If-Abfrage keine Fehlermeldung zu bekommen, wenn die Eigenschaft gar nicht existiert - die Fehlermeldung kann auch nicht unterdrückt werden, da es sich um einen terminierenden Fehler handlet - muss vorher geprüft werden, ob die Eigenschaft vorhanden ist. Das geht tatsächlich sehr einfach, ist aber gut versteckt. Denn an jedem Objekt hängt ein verstecktes Memberset namens psobject, das nur angezeigt wird, wenn man get-Member mit dem Parameter -force aufruft.

get-childitem C:\Windows | get-member -force

 PSObject beinhaltet Metainformationen über das Object, unter anderem eine Auflistung aller Eigenschaften.

Wenn Sie versuchen, Ihr Systemlaufwerk mit Bitlocker zu verschlüsseln, und Sie erhalten direkt nach dem Aufruf die Fehlermeldung "Das System kann die angegebene Datei nicht finden" fehl, prüfen Sie, ob im Ordner %Windir%\System32\Recovery eine Datei ReAgent.xml Datei liegt und benennen Sie sie z.B. in ReAgent.old um. Danach sollte die Verschlüsselung klaglos starten. 

Wenn Sie externe Email-Adressen auf eine Office 365 Mail-erteilergruppe weiterleiten wollen, müssen Sie für die externen Adressen zuerst einen Kontakt in Office 365 einrichten. Wechseln Sie hierzu im Administrativen Portal (Microsoft 365 admin Center) auf den Menüpunkt "Benutzer - Kontakte" und fügen Sie für die externen Kontakte Email-Adresse und Anzeigenamen hinzu. Wenn der Benutzer in der Organisation nicht im Adressbuch auftauschen soll, wählen Sie den Schieberegler "In meiner Organisation ausblenden" aus. 

 Anschliessend fügen Sie unter Gruppen -> Gruppen eine neue Gruppe hinzu. Wählen Sie als Gruppentyp "Verteilung" aus, geben Sie unter Grundlagen einen Anzeigenamen für die Gruppe an, unter Einstellungen legen Sie die Email-Adresse fest und wählen Sie den Haken "Personen außerhalb miener Organisation das Senden von E-Mails an diese Verteilergruppe gestatten" aus, wenn die Adresse auch von außerhalb Ihrer Organisation angesprochen werden soll. Der Anzeigename wird nur für die Anzeige im Portal und im Adressbuch verwendet. 

Jedes Mal, wenn Windows Update einen neuen Suchvorgang startet, protokolliert es alle Schritte. Bis Windows 8 fand das in der Datei WindowsUpdate.log im  %windir% statt, aber unter Windows 10 hat Microsoft diese Datei durch ein Ereignisprotokoll ersetzt. Prinzipiell ist die Idee gut, nur dummerweise loggt der Update-Dienst dort nicht im Klartext, so dass man mit den Daten nichts anfangen kann. Stattdessen muß man sich mit Powershell aus diesem Log wieder eine Log-Datei erzeugen lassen. Dies geschieht mit dem Cmdlet Get-WindowsUpdatelog. Gibt man zusätlich den Parameter -LogPath an, kann man festlegen, wohin das Log-File geschrieben wird. Standardmäßig wird die Datei auf dem Desktop des Users abgelegt.

Get-WindowsUpdateLog -LogPath c:\Temp\WindowsUpdate.log

Achten Sie darauf, den Dateinamen mit anzugeben. Das Cmdlet läuft sonst trotzdem durch, erzeugt aber keine Datei!

Die Datei wird sehr lang und ist nicht so einfach zu analysieren. Zum Glück kommt einem Powershell hier zur Hilfe. Ich habe eine kleine Funktion geschrieben, die mit Hilfe eines regulären Ausdrucks die Daten in Powershell-Objekte umwandelt, so dass die Daten z.B. in einem Gridview weiter analysiert werden können.

Function Show-UpdateLog {
param(
    [Parameter(Mandatory=$true)]
    $LogPath
)

Eine Hashtable ist eine Schlüssel-Wertepaar-Liste zum Speichern von Konfigurationsinformationen. Solche Schlüssel-Wertepaare findet man überall, z.B. in ini-Dateien zur Konfiguration von Anwendungen. Die Windows Systemregistrierung ist nichts weiter als eine sehr große ini-Datei.

Hashtable werden in Powershell genau wie eine ini-Datei erstellt, allerdings in geschweifte Klammern eingeschlossen und mit einem @ eingeführt:

Eine Hash-Table ist immer unsortiert, die Rückgabe erfolgt also in zufälliger Reihenfolge. Seit Powershell 3 kann man aber auch eine sortierte Hashtable erstellen, indem man [ordered] in der Defintion vor die Hash-Table schreibt:

Wenn man so eine Hash-Table jetzt aber an einen Parameterblock übergibt und den Datentyp [Hashtable] erzwingen möchte, erhält man wieder eine unsortierte Hash-Table, da es sich bei einer sortierten Hashtable um einen eigenen Datentyp handelt und Powershell eine automatische Konvertierung durchführt.

Das Problem besteht darin, dass eine sortierte und eine unsortierte Hashtable zwei unterschiedliche Datentypen sind. Geben Sie stattdessen [System.Collections.Specialized.OrderedDictionary] statt [Hashtable] als Datentyp an, funktioniert alles wie geschmiert. Die Funktion sieht dann so aus:

Dies ist ein Auschnitt aus der Neuauflage meines Gruppenrichtlinien-Buchs "Gruppenrichtlinien in Windows Server 2019 und Windows 10, das vermutlich im Oktober 2018 erscheinen wird

Übermittlungsoptimierung oder Delivery Optimiziation (DO) ist ein neues Feature, das Microsoft mit Windows 10 eingeführt hat, und das die Menge an Daten, die von Windows Update und dem Windows Store heruntergeladen werden, massiv reduziert. Das Verfahren basiert auf Peer To Peer Technologie, Clients teilen bereits heruntergeladene Daten also mit anderen Clients (Peers) im gleichen Netzwerk (oder auch über das Internet). Dafür werden Dateien in Blöcke aufgeteilt, gehashed (es wird eine eindeutige ID erzeugt), und dann Blockweise verteilt anstatt als Monolithische Datei. Damit ein Client tatsächlich nur Original-Daten erhält, sind die Dateien digital signiert, der Client kann also nach Empfang der kompletten Datei prüfen, ob er ein unverändertes Update erhalten hat.

Wenn ein Client ein Update von einem Update-Server herunterladen möchte und die Übermittlungsoptimierung aktiviert ist, erhält er vom Update-Service über die URL *.do.dsp.mp.microsoft.com eine Liste von Rechnern, die bereits Blöcke der Update-Datei bezogen haben. Auf Windows 10 Pro und Enterprise ist die Einstellung dabei standardmäßig so konfiguriert, dass ein PC Daten nur von Peers aus seinem eigenen lokalen Netzwerk empfängt (s. Bild 1.2). Der Update-Service ermittelt über die IP des sich verbindenden Rechners (normalerweise die öffentliche IP des Routers oder Proxys, über den der Client sich verbindet), mit welchen Peers er Daten austauschen darf. Zusätzlich greift der Dienst auf die AD-Standortdaten zurück oder, wenn diese nicht verfügbar sind, auf die Domäne. Man kann diese automatische Gruppierung aber auch überschreiben und manuell festlegen, welche Clients miteinander Daten austauschen dürfen, indem man eine Group-ID festlegt. Die Group-ID wird dann als einziges Kriterium verwendet, um zu ermitteln, welche Clients Daten austauschen dürfen. Das ist wichtig, wenn man bereits mit IPv6 arbeitet (alle Clients haben eine öffentliche IP-Adresse) oder der Zugriff nach außen über Proxy-Arrays oder Load-Balancing stattfindet, so dass ein Standort nicht über eine eindeutige ID verfügt. Die Group-ID ist eine GUID (Globally Unique Identifier), die man z.B. mit dem Powershell-Cmdlet New-GUID zufällig generieren kann.

Die Übermittlungsoptimierung arbeitet höchst effizient und teilt Daten deutlich schneller als die Alternative Branchcache. Sind die Daten erst einmal im lokalen Netzwerk, dauert es nur Sekunden, bis Clients lokale Peers als Quelle verwenden können. Die Daten werden dann mit voller lokaler Netzwerkgeschwindigkeit geteilt. Der Übermittlungsoptimierungsdienst verwendet hierfür Port 7680 im lokalen Netzwerk, für den Datentausch mit Internet-Peers Port 3544 (Teredo-Protokoll, eine IPv6-Übergangstechnologie).

Übermittlungsoptimierung ist vor allem für große Dateien effektiv und kostet außerdem Client-Ressourcen, weshalb Branch-Cache standardmäßig erst aktiviert wird, wenn der Client mindestens über 4 GB RAM und 32 GB freien Speicherplatz auf dem Cache-Laufwerk verfügt. Alle diesen Daten können über Gruppenrichtlinien angepasst werden, die Sie in der Computerkonfiguration unter ADMINISTRATIVE VORLAGEN - WINDOWS-KOMPONENTEN - WINDOWS UPDATE - ÜBERMITTLUNGSOPTIMIERUNG finden.