Alternative Datenströme sind eine erweiterte Funktion des NTFS-Dateisystems, die es erlaubt, beliebige Meta-Informationen über Dateien zusammen mit der Datei abzulegen. Windows verwendet z.B. einen Alternativen Datenstrom, um das MotW (Mark of the Web) zu speichern. Das MofW wird beim Download einer Datei automatisch gesetzt, damit Windows Sicherhe...
Virtuelle Festplatten (vhdx) als Datencontainer verwenden - nicht nur für VMs
Virtuelle Festplatten (Vhdx-Dateien) in Windows sind sehr praktisch. Man kann Sie nämlich nicht nur für virtuelle Maschinen verwenden, sondern auch als universelles Containerformat, um Daten zu transportieren oder sogar, um Windows aus einer VHD-Datei zu booten (s. Boot von VHD auf einem leeren Datenträger einrichten). Das Erstellen einer VHD-Datei ist allerdings etwas mühselig, weil man erst die Datei erstellen, dann einrichten und anschließend eine Partition erstellen muss. Da man das aber auch mit Powershell erledigen kann, und ich dieses Feature sehr oft verwende, habe ich eine kleine Funktion dafür geschrieben.
#requires -Modules Hyper-V, Storage -RunAsAdministrator
function Get-Freedrive
{
<#
.SYNOPSIS
Get-Freedrives lists the first free driveletter in the alphabet.
.DESCRIPTION
Get-Freedrive can be used to test for the first available free driveletter. The Parameter $inverse searches backwards through the alphabet.
.EXAMPLE
get-freedrive -inverse -startLetter Z
Starts the search with letter z searching backwards. Returns a character.
.NOTES
Version: 1.0
Author: Holger Voges
Date: 2018-08-17
www.netz-weise-it.training/weisheiten/
#>
[cmdletbinding()]
param(
# The letter to start the search from - default is C or Z, if -inverse is chosen
[char]$startLetter = 'C',
# Inverse forces a backwards search through the alphabet
[switch]$inverse
Powershell-Skriptmodule erstellen
Ein extrem cooles Features sind die in Powershell 2.0 eingeführten Module. Module sind Erweiterungen, die in Powershell geladen werden und weitere Cmdlets zur Verfügung stellen. Ab Powershell 3.0 können über das Modul-Autoloading Module sogar ohne weiteres zutun des Benutzers beim Starten einer Powershell automatisch geladen werden.
Module gibt es in Form von Binärmodulen, die z.B. in C# geschrieben werden, und in Form von sogenannten Skriptmodulen. Ein Skriptmodul ist dabei eigentlich nichts anderes als ein Powershell-Skript, dass global aufgerufen wird und im Normalfall Funktionen enthält, die dann wie Cmdlets gestartet werden können. Funktionen verhalten sich dabei wie ein Skript, dass überall in der Powershell-Konsole mit über den Namen aufgerufen werden kann, ohne dass man sich im Skriptpfad befinden müsste, da die Funktionen direkt in den Arbeitsspeicher geladen und von dort aus gestartet werden.
Ein Skriptmodule zu erstellen, ist sehr einfach und braucht auch keine erweiterten Powershell-Kenntnisse. Prinzipiell kann jedes beliebige Powershell-Skript wie ein Module verwendet werden, indem man es einfach über das Cmdlet Import-Module <Skriptdatei> startet. Sinniger ist es aber, das Skript als automatisch ladendes Skript abzulegen. Dazu muß die Skriptdatei in einem der Module-Ordner abgelegt werden, die von Powershell automatisch beim Starten geprüft werden. Welche Ordner Module-Ordner sind, legt dabei die Umgebungsvariable PSModulePath fest. Sie können die Modulorder in Powershell dabei übersichtlich anzeigen lassen, indem Sie sich mit der String-Methode Split() den String in seine Einzelpfade aufsplitten lassen. Geben Sie dafür folgende Codezeile in und bestätigen Sie mit Enter:
$env:psModulePath.split(";")
C:\Users\admin.NETZ-WEISE\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules
Wie Sie im Beispiel sehen können, verwendet Powershell standardmäßig drei Modul-Pfade - einen für Windows-eigene Module im Powershell-Ordner, einen für Nicht-Windows-Module unter "Program Files" und einen benutzerspezifischen im Dokumente-Ordner des Benutzers. Sie können Ihre eigenen Skripte als Module unter "Program Files" oder unter Documents ablegen, wenn das Module nur für den Benutzer zur Verfügung stehen soll. Legen Sie hierfür im Module-Ordner einen neuen Unterordner an, und speichern Sie Ihr Skript innerhalb dieses Ordners mit der Endung .psm1. Sie können als Beispiel die Funktion Replace-SharePath aus dem Tipp Windows Freigaben auf einen neuen Pfad migrieren verwenden. Als Dateinamen verwenden Sie den gleichen Namen wie für den Ordner. Das Modul "KleineHelfer" muß also als "%ProgramFiles%\WindowsPowershell\Modules\KleineHelfer\KleineHelfer.psm1" gepeichert werden. Beim Start der nächsten Powershell-Konsole wird Ihr Modul automatisch geladen. Ist das nicht der Fall, können Sie die Fehlermeldung erzwingen, indem Sie das Modul von Hand mit dem Parameter -force laden:
Emails in Exchange per Powershell suchen und löschen
Manchmal steht man vor der Aufgabe, das einzelne mails aus einem Benutzerpostfach gelöscht werden sollen, z.B. weil Sie Schadcode enthalten, oder auch, weil das Postfach geleert werden soll. Mit Hilfe der Exchange-eigenen Cmdlet Search-Mailbox geht das sehr einfach.
Starten Sie die Exchange Management-Shell. Eine Anleitung der Installation der Shell finden Sie im Artikel "Exchange Cmdlet in Powershell nutzen". Achten Sie darauf, dass Sie das Cmdlet "Search-Mailbox" nicht sehen, solange Sie nicht Mitglieder der Rolle "Mailbox Import Export" sind - das gilt sogar dann, wenn Sie als Organisationsadministrator angemeldet sind. Alternativ können Sie das Problem auch umgehen, indem Sie die Exchange-Snapins direkt importieren.
Anschliessend rufen Sie das Cmdlet Search-Mailbox auf. Der Parameter Identity gibt dabei an, welche Mailbox(en) Sie suchen. Alternativ können Sie die Mailboxen auch per Pipeline an Search-Mailbox übergeben. Mit Hilfe des Parameters -Searchquery geben Sie an, welche Nachrichten gesucht werden. Das Cmdlet verwendet für die Definition der Suchabfragen die KQL (Keyword Query Language). Ein einfaches Beispiel für eine Suche nach dem Begriff "Verrat" in allen mails aller mailboxen sieht so aus:
Get-Mailbox | Search-Mailbox -SearchQuery 'Verrat' -TargetMailbox 'Administrator' -TargetFolder 'NSA'
Multifaktor-Authentifzierung (MFA) in Office 365 aktivieren und einsetzen
Mit Office 365 steht Ihnen seit einiger Zeit die Möglichkeit zur Verfügung, eine Multifaktor-Authentifzierung zu aktivieren, um die Sicherheit beim Login zu erhöhen. Was MFA ist, warum man es aktivieren sollte und wie das geht, zeigt Ihnen dieser Artikel.
Was ist MFA?
MFA steht für Multifaktor-Authentifizierung und bezeichnet ein Verfahren, bei dem ein Benutzer sich über mehrere Kritieren identifizieren muß. Klassischerweise identifiziert man sich über eine Kennwort, aber die reine Kenntwortauthentifizierung ist aus verschiedenen Gründen nicht wirklich sicher, denn so ein Kennwort kann z.B. abhanden kommen (jemand hat den Sticker unter der Tastatur gefunden) oder gehackt werden. Das ist vor allem schon deshalb sehr unangenehm, weil Kennwörter aufgrund der Komplexität oft schwer zu merken sind und von vielen Benutzern einfach nur mit einem Zähler versehen werden. Mit Wörterbuchattacken ist es außerdem oft sehr einfach, ein Kennwort innerhalb kurzer Zeit zu hacken.
Die Idee hinter der Multifaktorauthentifizierung ist nicht neu. Schon Windows 2000 hat die Authentifizierung über Smartcards erlaubt. Mit MFA werden neben dem Geheimnis, das der Benutzer und der Anmeldeserver kennen (das Passwort), weitere Authentifzierungen gefordert. Bei der Smartcard ist das neben der PIN eben die Smartcard, die in den Leser geschoben werden muß. Bei RSA-Tokens ist das ein alle 30 Sekunden neu generierter Zahlencode. Der Vorteil liegt darin, dass die Kenntnis des Kennworts nicht ausreicht, um an die Benutzerdaten zu gelangen. Es wird mind. ein zweiter Faktor benötigt - in den meisten Fällen ein Stück "Hardware" - um die Authentifzierung abzuschließen. So ein Stück Hardware kann dabei prinzipiell alles sein, auch ein spezifisches Geräte. Das macht sich Microsoft z.B. mit Windows Passport zunutze, indem die Authentifizerung mit einer einfachen PIN durchgeführt wird, aber immer an ein spezifisches Geräte gebunden ist.
Meistens ist so ein Stück Hardware aber teuer. Ein RSA-Token kostet pro Token viel Geld, für Smartcards benötigt man neben der Smartcard auch noch ein Lesegerät. Heutzutage trägt aber fast jeder ein Token freiwillig überall mit sich herum - das Smartphone. Daher ist MFA heutzutage recht erschwinglich geworden. Einmalcodes, wie Sie von RSA-Tokens generiert werden, können nämlich z.B. auch durch die Microsoft Authenticator App generiert werden, die auf allen mobilen Plattformen (Windows Phone, Android, IOS) zur Verfügung steht. Alternativ können Tokens auch per SMS oder Anruf übertragen werden.
MFA in Office 365 aktivieren
Office 365 unterstützt über die Azure AD Integration seit einiger Zeit auch die MFA per Smartphone. Die Einrichtung hierfür ist recht simpel. Gehen Sie ins Office 365 Admin-Center, wählen Sie unter Users > Active Users einen Benutzer aus, und wählen Sie im Benutzermenü "Manage Multi-factor Authentication".
Office 365 - Email Weiterleitung einrichten
Um unter Office 365 eine Email-Weiterleitung einzurichten, melden Sie sich unter Outlook.office365.com mit Ihrem mail-Konto an. Klicken Sie oben rechts auf das kleine Zahnrad-Symbol, um in die Einstellungen zu kommen. Wählen Sie "Optionen" aus, und im folgenden Fenster im rechten Bereich "Ihre emails weiterleiten".
Office automatisch aktivieren
Office 2010 kann man automatisch installieren, indem man einen administrativen Installationspunkt erzeugt und dann ein msp-Paket erzeugt. Im msp-Paket kann man auch festlegen, dass Office 2010 beim ersten Start eine automatische Aktivierung durchführt. Dafür legen Sie im Menüpunkt Setup-Properties eine neue Eigenschaft "AUTO_ACTIVATE" mit dem Wert 1 an. Achten Sie darauf, dass die Auto-Aktivierung nur 1 mal durchgeführt wird! Wenn Sie also die Auto-Aktivierung testen, indem Sie z.B. Word starten, und Windows dann per Sysprep zurücksetzen, wird beim ersten Start von Office wieder ein Aktivierungsfenster gestartet!
Links:
Gruppenrichtlinien Einstellungen (Preferences) Logging aktivieren
Die Group Policy Preferences oder Einstellungen, wie es schlecht übersetzt im deutschen heißt, sind ein sehr mächtiges Feature, das ab Windows Vista standardmässig mitgeliefert wurde, um eine Alternative zu Login-Scripten zu lieferen. Die Einstellungen bieten sehr viele Möglichkeiten, wie z.B. das Targetting, um festzulegen, welcher Benutzer von einer Richtlinie betroffen sein soll. Wenn es allerdings zu unerwartetem Verhalten kommt, ist guter Rat erst mal teuer, denn die Voreinstellungen haben viele mögliche Fehlerquellen. Zum Glück kann man das Logging aktivieren.
Das Logging teilt sich in ein Event-Log basiertes Logging und ein erweitertes, Textdateibasiertes Tracing auf und wird für jede Komponente (Client Side Extension, CSE) einzeln aktiviert. Dies geschieht - natürlich - in einer Gruppenrichtlinie. Die Einstellungen finden Sie unter Computereinstellungen > Administrative Vorlagen > System > Group Policy > Logging and tracing. Hier haben Sie für jede CSE die Möglichkeit, die Konfiguration des Event-Loggins zu ändern - standardmässig werden Fehler und Warnings im Eventlog protokolliert - oder das Dateibasierte Tracing zu aktivieren.
Unter Event-Logging legen Sie fest, welche Informationen im Event-Log gespeichert werden sollen. Die von den Preferences erzeugen Logs werden im Anwendung-Log gespeichert! Mehr Informationen zu den Log-Einträgen für Preferences finden Sie in der Knowledge-Base.
Um ein erweitertes Log-File zu erzeugen, müssen Sie das Tracing aktivieren. Die Systemvariable %COMMONAPPDATA% ist eine Variable, die von den Preferences gesetzt wird (keine echte Umgebungsvariable) und verweist auf den Ordner ProgamData. Achten Sie darauf, dass dieser Ordner erst mit Vista angelegt wurde! Im Beispiel habe ich das Logging für das User-Laufwerksmapping aktiviert und anschließend ein Laufwerksmapping über die Group Policy Preferences aktiviert. Das erzeugte Trace-File finden Sie unten zum Download.
Zugriff auf SQL-Server per SMO mit Powershell - ohne SMO-Installation!
SQL-Server lassen sich mit Hilfe der SMO-Erweiterungen (Server Management Objects) des SQL-Servers per Powershell wunderbar verwalten. Einen ganzen Satz von Beispielen finden Sie z.B. auf unserer Website unter Dokus. Für den Einsatz von SMO muß SMO allerdings erst einmal installiert werden. Dies geschieht entweder bei der SQL-Server Installation, indem Sie unter der Feature-Auswahl "Client Tools SDK" auswählen, oder indem Sie von der Microsoft-Website aus dem Feature-Pack Download "SharedManagementObjects.msi" und "SQLSysCLRTypes.msi" herunterladen und installieren. Oder Sie bauen sich alternativ ein Powershell-Modul, dass die notwendigen dll´s enthält und von selbst nachlädt. Alles, was Sie hierzu benötigen, sind die beiden Downloads aus dem Feature Pack, und eine Powershell Modul-Datei. Hierfür bietet sich passenderweise eine Manifest-Datei (.psd1) an.
Aber fangen wir von vorne an. SMO ist ein Feature, dass Microsoft eingeführt hat, um die Verwaltung von SQL-Servern aus dem .NET-Framework zu erleichtern. Anstatt über SQL-Befehle kann man per SMO programmatisch über Objekte auf den SQL-Server zugreifen. Und da man mit Powershell auf alles zugreifen kann, was das .Net-Framework zur Verfügung stellt, kann man natürlich auch SMO nutzen. Tatsächlich tun Sie das sogar bereits, wenn Sie mit der SQL-Server Konsole für Powershell (SQLPS) arbeiten, denn das besondere an dieser Konsole ist vor allem, dass beim Starten von SQLPS automatisch die SMO-Assemblies geladen werden.
Unschön an SMO ist, dass auf jedem Rechner, auf dem Sie Ihre SQL-Server Powershell-Scripte laufen lassen möchten, SMO installiert sein muß. Allerdings läßt sich dieses Problem mit einem kleinen Trick umgehen, denn tatsächlich muß die SMO-Funktionalität gar nicht installiert werden - Sie benötigen nur die dll-Dateien, die die SMO-Funktionalität zur Verfügung stellen. Und die erhalten Sie, wenn Sie die beiden oben angegebenen msi-Pakete auf einem beliebigen Rechner installieren. Die SMO-Assemblies finden Sie nach der Installation standardmässig im Ordner %ProgramFiles% unter "Microsoft SQL Server\<Version>\SDK\Assemblies", wobei Version der internen Versionsnummer des SQL-Servers entspricht. Bei einer Standardinstallation von SMO für SQL Server 2014 wäre das also Beispielsweise:
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\
Kopieren Sie den Ordner Assemblies. Weiterhin benötigen Sie die "Microsoft.SqlServer.SqlClrProvider.dll", an die allerdings nicht so einfach heran zu kommen ist. Sie ist im Global Assembly Cache installiert und wird standardmässig aus der Explorer-Ansicht gefiltert. Sie müssen den Filter deaktivieren. Starten Sie hierfür den Registieriungseditor und setzen Sie die folgenden Wert:
Der „Key-Trick“: Hardware-KVM-Switches per Tastatur steuern
Das Ende der Schreibtisch-Gymnastik Jeder, der zwei PCs an einem Arbeitsplatz nutzt, kennt das Gerät: Der KVM-Switch (Keyboard, Video, Mouse). Meistens klebt er unter dem Schreibtisch oder versteckt sich hinter dem Monitor. Das Problem? Das manuelle Drücken der physischen Taste stört den Workflow. Was viele nicht wissen: Fast jeder moderne KVM-Swit...
Den Klingel-Sound in der WSL Bash deaktivieren
Hat man das Windows Subsystem für Linux installiert und arbeitet in der Bash mit der Kommandozeilenergänzung per Tabulator, wird man ein ziemlich nerviges Sound-Feedback in Form eines Pings kaum überhören können. Um den Ping abzuschalten, muß man die Datei /etc/inputrc editieren und die Konfigurations-Schlüssel bell-style auf none setzen - nor...
Monitor-Umschaltung per Script - DDC/CI statt Hardware-KVM
Warum teure Hardware kaufen, wenn das Protokoll gratis ist?
Warum sollte man 100 € für einen DisplayPort-KVM ausgeben, der das Bildsignal oft verschlechtert, wenn der Monitor selbst mehrere Eingänge hat? Die Lösung heißt DDC/CI (Display Data Channel). Damit lässt sich der Monitor direkt vom Betriebssystem aus steuern – ganz ohne Knöpfe am Gehäuse.
Schritt 1: Identifikation per Seriennummer
In einem Multi-Monitor-Setup ist Präzision Pflicht. Wir nutzen die Seriennummer (z. B. deines Dell U2717D), damit nur der korrekte Monitor umschaltet.
Windows: ControlMyMonitor (NirSoft - ControlMyMonitor)
Mit diesem Tool lesen wir die VCP-Codes aus. Zuerst müssen wir unseren Monitor auswählen (1.) und anschließend den Code für dieEingangsquelle (2.) finden.
Der Code für die Eingangsquelle ist fast immer die 60.
Anschließend können wir die möglichen Werte sehen, die zu den Eingangsquellen gehören:;
Windows Server 2016 Startmenü findet keine Programm
Wie man viele Probleme mit dem Windows 10 Startmenü lösen kann, habe ich im Artikel "Suchen im Windows 10 Startmenü findet keine installierten Programme" bereits beschrieben. Leider tritt ein ähnliches Problem auch bei Windows Server 2016 auf, was das Startmenü ziemlich ad-absurdum führt. Mein erster Tipp hierzu: Verwenden Sie die Kachelanzeige, um häufig verwendete Programm einfach zu hinterlegen.
Das eigentliche Problem der Suche im Startmenü unter Windows Server 2016 besteht darin, dass das Startmenü in Windows jetzt als Datenbank implementiert ist. Die Programme im Menü werden indexiert und in der Datenbank abgelegt. Der Zugriff findet dann über Cortana statt. Auf dem Windows Server 2016 hat Microsoft aber den Suchdienst deaktiviert, der die Suche durch die Datenbank erst ermöglicht. Nach langem Recherchieren habe ich einen Thread gefunden, der das Problem und die Lösung beschreibt. beschreibt. Ein Microsoft-Mitarbeiter hierzu:
The “Windows Search” service is set to ‘Disabled’ by default on Windows Server 2016. This is because indexing of the volumes can negatively impact / break server scenarios, such as Cluster Shared Volumes (CSV) and running Remote Desktop Session Host (RDSH) with multiple simultaneous sessions. The side effect of the Windows Search service being disabled is that using Cortana with Start Menu searches has a degraded experience.
Windows Server is optimized to ensure server scenarios are rock solid, which may include trade-off's over shell user experience. If you plan to use Windows Server 2016 as your client desktop machine, you could re-enable the Windows Search service.
Sie können das Problem mit dem Startmenü also einfach beheben, indem Sie die Dienstkonfiguration gehen und den Suchdienst starten oder einfach folgendes Powershell-Kommando verwenden:
Die Existenz einer OU testen mit Powershell
Leider bietet das Powershell AD-Modul keine Möglichkeit, auf das Vorhandensein einer Organizational Unit zu testen. Diese Funktion lässt sich aber einfach nachrüsten.
Grundsätzlich kann man die Existenz einer OU testen, indem man einfach das Cmdlet Get-OrganizationalUnit verwendet. Prüft man die Abfrage in einer IF-Bedingung, wird der Scriptblock des IF ausgeführt, wenn die OU existiert. Das Ganze hat allerdings einen Haken, denn Get-ADOrganizationalUnit bricht die Skriptverarbeitung mit einem unbehandelten Fehler ab, wenn die OU nicht existiert.
If ( Get-ADOrganizationalUnit -Identity "OU=test,DC=Netz-Weise,DC=DE" ) { $true }
get-adorganizationalUnit : Directory object not found
Dieses Verhalten kann man sich zunutze machen, indem man die Ausführung des Get-ADOrganizationalUnit mit Try-Catch ausführt. Wird ein unbehandelter Fehler ausgeführt, wird die Catch-Block aufgerufen und ausgeführt. In diesem muß man jetzt nur noch einen $False zurück liefern.
function Test-ADOrganizationalUnit
Zertifikate mit Powershell inklusive des privaten Schlüssels als pfx-Datei exportieren
Im letzten Tipp habe ich gezeigt, wie man Zertifikate mit Powershell Base64-kodiert aus dem Zertifikatsspeicher exportieren kann. Wenn man versucht, mit dem Cmdlet Export-Certificate eine pfx-Datei zu erstellen, - die pfx-Datei ist ein Container, der neben dem Zertifikat auch den privaten Schlüssel enthält und tatsächlich eigentlich das PKCS #12-Formate enthält - stellt man allerdings fest, dass das Cmdlet dazu nicht in der Lage ist. Tatsächlich ist es aber kein Problem - man muß nur das richtige Cmdlet verwenden. Denn zum Export als .pfx-Datei verwendet man Export-PFXCertificate. Die Datei muß allerdings mit einem Kennwort gesichert werden, um den privaten Schlüssel zu sichern:
$pwd = ConvertTo-SecureString -String "geheim" -AsPlainText -Force
Get-ChildItem -Path Cert:\CurrentUser\My\ | Where-Object { $_.subject -eq "cn=NWCertRoot" } |
Export-PfxCertificate -FilePath $home\NwcertRoot.pfx -Password $pwd
DHCP-Proxy, WDS-Server, DHCP-Option 60,66 und 67 und was das mit PXE-Boot zu tun hat
Über wenig Dinge liest man so viel falsches wie über den PXE-Netzwerkboot und wie man den DHCP-Server korrekt konfigurieren muss, um einen Computer aus dem Netzwerk zu starten. Für die ungeduldigen hier zuerst die Konfiguration, die Erklärung folgt danach.
Richten Sie einen DHCP-Server ein. Installieren Sie den WDS-Server auf dem DHCP-Server und lassen Sie den WDS-Server die Konfigurationsarbeit auf dem DHCP-Server erledigen. Der WDS-Server wird dann auf dem DHCP-Server selbständig die Option 60 (PXE-Client) setzen. Wenn Sie den WDS-Server auf einem separaten Server installieren, müssen Sie _NICHTS_ weiter tun. Sie müssen auf dem DHCP-Server weder die Option 60 setzen, noch die Option 66 (TFPT-Server) und 67 (Bootfile). Wenn der WDS-Server und die zu installierenden Clients sich nicht im gleichen Netz befinden, muß der WDS-Server allerdings wie ein DHCP-Server im DHCP-Relay-Agent oder bei Cisco als IP-Helper konfiguiert sein. Der Client findet den WDS-Server dann von selbst und bootet aus dem Netzwerk. Tut er das nicht, liegt es nicht an den DHCP-Optionen!
Was genau passiert beim DHCP-Boot?
Wenn Sie einen Computer über das Netzwerk booten möchten, benötigen Sie einen DHCP-Server und einen TFPT-Server. TFPT ist das Trivial File Transfer Protocol, das im Gegensatz zu FTP Daten per UDP überträgt und ohne Authentifizierung funktioniert. Wenn ein Client einen PXE-Boot initialisiert, schickt er einen DHCP-Request ins Netzwerk, zusammen mit der Information, dass er per PXE booten möchten. Der DHCP-Request wird, wenn er einen DHCP-Server erreicht, mit einem DHCP-Offer beantwortet. Die Antwort beinhaltet die angebotene IP-Adresse, sowie weitere DHCP-Optionen. Prinzipiell kann der DHCP-Server über die Option 66 und 67 dem Client auch einen Bootserver sowie ein Bootfile mitschicken, und das wird auch funktionieren, ist aber nicht notwendig und verursacht zusätzlichen Konfigurationsaufwand. Denn der WDS-Server fungiert als DHCP-Proxy. Das bedeutet, dass er die Anfrage des PXE-Clients ebenfalls beanwortet, allerdings schickt er keine IP-Adresse zurück, sondern nur die Option 66 und 67 mit den Bootfiles, die er zur Verfügung stellt. Das Bootfile ermittelt er selbständig aus seiner Konfiguration. Wichtig ist nur, dass der DHCP-Request beim WDS-Server ankommt. Da der DHCP-Request als Broadcast vom Client verschickt wird, muß die Anfrage also, sofern der WDS-Server nicht im gleichen Netzwerk steht wie der Client, ein DHCP-Weiterleitungsdienst wie der IP-Helper auf dem Router das Datenpaket per Unicast an den WDS-Server weiterleiten. Der WDS wird also genauso auf dem IP-Helper eingetragen wie der DHCP-Server selbst.
Die Option 60, die der WDS-Server bei einer gleichzeitigen Installation im IP-Scope des DHCP-Servers setzt, hat eine andere Funktion. Der DHCP-Proxy funktioniert nämlich wie der DHCP-Server und nutzt auch den gleichen Port ( UDP 67). Wenn der WDS und der DHCP auf dem gleichen Server laufen, muß der WDS-Server einen anderen Port verwenden. Er verwendet dann UDP-Port 4011. Damit der Client auch auf Port 4011 hört und die Konfiguration des DHCP-Proxys akzeptiert, wird die Option 60 vom DHCP-Server gesetzt.
Sollte Ihr Client trotz allem nicht vom WDS-Server booten, kann diese eine andere Ursache haben. Lesen Sie dafür auch den Artikel "Der PXE-Client startet nicht von WDS-Server - No UEFI-compatible file system found"
Default Shell in Server Core auf Powershell ändern
Wenn Sie sich in Windows Server Core einloggen, wird als Standard-Shell die Cmd.exe geöffnet. Das ist zwar unkritisch, da Sie den Server-Core im Normalfall eh nur remote konfigurieren, aber trotz allem manchmal nervig. So lange Microsoft die Standard-Shell nicht endlich auf Powershell umstellt, hilft es, die Default-Shell in der Registry anzupassen. Hierfür ersetzen Sie unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell explorer.exe durch Powershell.exe. Das geht ganz einfach über regedit, denn der Registry-Editor kann unter Server-Core direkt ausgeführt werden, oder Sie benutzen folgendes Powershell-Kommando:
Set-ItemProperty -Path HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\ -Name Winlogon -Value Powershell.exe
Die Shell wird für alle Benutzer auf den neuen Wert gesetzt, ist jetzt also der neue Default.
Wie Sie das Tastaturlayout in Server Core ändern, finden Sie unter Tastarlayout in Windows Server Core umstellen.
Binärdaten in der Registry speichern mit Powershell
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
Die Fenster-Rahmen bei Windows wieder einblenden
Seit Windows Server 2019 und Windows 10 werden Fensterrahmen nicht mehr angezeigt. Diese Designentscheidung finde ich schon aus ästhetischen Gründen fragwürdig, aus ergonomischer Sicht ist es jedenfalls völlig daneben, da man, wenn man mehrere Fenster übereinander legt, die Fenster kaum noch zu unterscheiden sind. Glücklicherweise gibt es...
Zufällige (Komplexe) Kennwörter erzeugen mit Powershell
Update: Eine Version mit Hilfe des .NET-Frameworks finden Sie im Artikel Sichere Kennwörter in Powershell generieren, jetzt mit dem .NET Framework
Kennwörter braucht man in Skripten an allen Ecken und Enden, speziell dann, wenn man Benutzer erstellen möchten. Bei einer größeren Anzahl von Konten kann da ein Skript ganz hilfreich sein, dass zufällige Kennwörter generiert. Das ist mit Powershell relativ einfach gemacht. Alles, was man benötigt, ist eine Funktionalität zum Erstellen von Zufallswerten und die Möglichkeit, Zahlen in Buchstaben umzuwandeln. Das Cmdlet Get-Random liefert Zufallszahlen zurück:
Get-Random -Min 10 -Max 100
Die vollständige Auflistung der Funktionen Get-Random können Sie in der Powershell-Hilfe nachlesen. Für uns interessant ist der Parameter -Inputobject, über den man Get-Random ein Array mit Werten übergeben kann, aus denen der Zielwert gewählt wird.
$ZufallsListe = 65..90
$Zufallszahl = Get-Random -InputObject $Zufallsliste