Seit Windows 8.1 gibt es das administrative Startmenü (im englischen Power User Menü genannt), das man über Windows-Taste+X oder über das Kontextmenü des Startbuttons erreichen kann. Das Startmenü ist ausgesprochen praktisch, wenn es um das Aufrufen von administrativen Werkzeugen geht. Außerdem hat man hier die Möglichkeit, den Rechner sowohl herunterzufahren als auch eine Abmeldung durchzuführen, ohne unterschiedliche Menüs verwenden zu müssen.

Leider gibt es keine Bordmittel, um das Menü anzupassen. Prinzipiell kann man auf manuellem Weg mit ein paar Tricks die Einstellungen vornehmen, um eigene Tools im Menü zu verlinken. Es gibt aber auch einen angenehmen Weg, nämlich den Win+X-Editor. Er kann kostenlos bei WinAero heruntergeladen werden. Achten Sie darauf, dass Sie den richtigen Link erwischen, er ist ein wenig versteckt. Eine kleine Anleitung inklusiver der Handgriffe, die man ausführen muß, um die Anpassungen manuell durchzuführen, finden Sie bei Digital Citizen: All the ways to customize the WinX menu in Windows 10 (and Windows 8.1).

Heute habe ich das neue Kapitel über Group Policy Preferences für die Neuauflage meines Gruppenrichtlnienbuchs beendet. Dabei habe ich ein sehr schönes Beispiel für den Einsatz der Registry-Einstellungen gefunden.

Die Sprachleiste ist in den meisten Fällen ein sehr überflüssiges Feature, denn sie erlaubt das Umschalten zwischen verschiedenen Tastaturlayouts. Welchen Sinn das haben soll, ist mir bis heute verborgen geblieben, denn ich wechsel eigentlich nie mal zwischendurch für ein frischeres Erlebnis auf eine chinesische Tastatur. Trotz allem dürfen wir dieses tolle Feature seit vielen Windows-Generationen genießen. Wenn die Funktion einfach nur da wäre, wäre das ja nicht weiter schlimm, aber dummerweise implementiert Sie auch noch die unseelige Tastenkombination Shift+Alt, die das Tastaturlayout automatisch umschaltet. Wie viele Helpdesk-Tickets aufgrund eines versehentlich aktivierten englischen Tastaturlayouts aufgemacht wurden, möchte ich nicht wissen. Glücklicherweise hat Microsoft in der aktellen Version 1803 von Windows 10 zumindest eine Option vorgesehen, das hinzufügen weiterer Layouts zu überspringen.

Die Sprachleiste wird über die Registry gesteuert, und zwar über den Schlüssel HKEY_CURRENT_USER\Keyboard Layout\Preload. Hier ist für jede Sprache ein Werte hinterlegt, wobei der Wertname der Priorität entspricht, und der Wert selber den Sprachcode bestimmt. Bei ITProToday finden Sie eine Liste der Sprachcodes. Bei mir finden sich zwei Einträge in der Liste:

Der Wert 407 entspricht dem deutschen Layout, 409 ist das US-Englische Tastaturlayout.

Um die Sprachleiste zu entfernen, müssen Sie lediglich den kompletten Schlüssel Preload entfernen. Dies kann mit einem Powershell-Skript einfach erledigt werden, oder mit Gruppenrichtlinen-Einstellungen.

Wenn Ihnen der Taschenrechner unter Windows 10 fehlt, könnte das daran liegen, dass Sie alle Windows Apps deinstalliert haben. Denn der Taschenrechner ist seit Windows 10 keine Anwendung mehr, sondern wird als Universal App ausgeliefert. Wenn Sie weiterhin Zugriff auf den Windows Store haben, können Sie den Taschenrechner direkt daraus installieren.

https://www.microsoft.com/en-us/store/apps/windows-calculator/9wzdncrfhvn5

Wenn Sie auch keinen Zugriff auf den Store mehr haben, aber der Taschenrechner vor dem Entfernen bereits bei einem anderen Benutzer installiert war, können Sie mit dem Cmdlet "Get-AppxPackage" die App aus dem fremden Benutzer reinstallieren.Öffnen Sie hierzu eine Powershell mit Admin-Rechten und starten Sie die folgenden Kommandos:

$calc =  Get-AppxPackage -AllUsers -Name Microsoft.WindowsCalculator
Add-AppxPackage -DisableDevelopmentMode -Register $calc.InstallLocation)\AppXManifest.xml

Sollte auch das nicht funktionieren, hilft Ihnen nur, die Store-App von einem funktionierenden Windows zu kopieren und neu zu installieren.

Die Active Directory Domänen-Funktionsebene (Domain Functional Level, DFL) und die Forest-Funktionsebene (Forest Functional Level) sind zwei Begriffe, die oft missverstanden werden. Ich werde hier versuchen, ein wenig Licht ins Dunkel zu bringen.
Die Funktionsebene einer Domäne bzw. eines Forest bestimmt, welche AD-Funktionen genutzt werden können. Mit jeder neuen Version von Windows wurden auch neue AD-Funktionalitäten implementiert, von denen einige durch eine Schemaerweiterung aktiviert werden können, während andere voraussetzen, dass alle Domänencontroller des AD sich auf dem gleichen oder einem höheren Betriebssystemstand befinden. Um sicherzustellen, dass alte und neue DCs miteinander kommunizieren können, muss das System sich auf den kleinsten gemeinsamen Nenner einigen. Daher werden neue Funktionen nicht automatisch freigeschaltet, sondern müssen nach dem Herunterstufen aller alten Domänencontroller manuell aktiviert werden. Dabei unterscheidet man zwischen der Funktionsebene einer einzelnen Domäne - um sie zu ändern, müssen alle Domänencontroller der Domäne auf dem gleichen minimalen Stand sein - und der Funktionsebene des Forest, für dessen Änderung alle Domänencontroller des Forest (also alle Domänen) den Versionsstand erreicht haben müssen, der aktiviert werden soll. Um die aktuellen Funktionsebenen abzufragen, öffnen Sie auf einem Computer, auf dem die AD-Verwaltungstools installiert sind, eine Powershell-Konsole und geben folgende Befehle ein:

(Get-ADDomain).DomainMode
(Get-ADForest).ForestMode

Um sich alle Domänencontroller Ihrer Domäne mit Betriebssystemversion ausgeben zu lassen, verwenden Sie

Get-ADDomainController -Filter * | Select-Object Hostname,Operatingsystem

Für alle Domänencontroller aller Domänen verwenden Sie

Ü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"

Gestern bin ich auf ein merkwürdiges Phänomen gestossen. Nach der Installation eines WDS-Server (Windows Deployment Server) wollte der UEFI-PXE Boot nicht funktionieren. Das BIOS gab nur eine Meldung "TFTP-Error" und "No UEFI-compatible File system was found" aus. Der Boot per Legacy-Boot funktionerte aber einwandfrei. Nach einigem Hin- und her habe ich vor Verzweifelung Wireshark installiert. Untenstehend ein beispielhafter Mitschnitt:

Man sieht hier sehr schön, wie der Client eine IP-Adresse angeboten bekommt und auch annimmt (DHCP Ack). Danach startet der Client einen Read-Request per TFTP auf das Boot-File wdsmgfw.efi, das vom Server mit einer File Not Found Fehlermeldung beantwortet wird. Auf unserem Firmeneigenen WDS-Server ist das File vorhanden, wie ich nach kurzer Kontrolle feststellen konnte. Eine kurze Google-Recherche bestätigte dann die Vermutung - das File ist bei der Installation nicht in den Boot-Ordner kopiert worden, wo es aber hätte sein müssen. Ich habe das Phänomen noch nicht bis zum Ende verfolgt, aber ich vermute, der Fehler tritt bei einer Windows Server 2016 RTM-Installation auf.

Um das Problem zu lösen, müssen Sie nur die Datei wdsmgfw.efi in den Ordner "RemoteInstall\Boot\x64" Ihres WDS-Servers kopieren. Sie finden Sie unter %windir%\System32\RemInst\boot\x64\wdsmgfw.efi

Um den Computernamen zu ermitteln, kann man den Kommandozeilenbefehl Hostname verwenden. Es gibt in Powershell aber keine direkte Möglichkeit, den DNS-Namen eines Computers abzufragen. Hier hilft die DNS-Klasse aus dem .Net Framework aus:

Hostname # Zeigt den Netbios-Computernamen an
$ComputerSystem = [System.Net.Dns]::GetHostByName(($env:computerName))

Das zurückgelieferte Objekt hat drei Eigenschaften, Hostname, Aliases und Addresslist

HostName          Aliases AddressList
--------          ------- -----------
DC1.netz-weise.eu {}      {10.1.0.200}

Unter Windows 10 kann es vorkommen, dass das Herunterfahren des Systems einen Neustart auslöst, anstatt das Gerät auszuschalten. Die Ursache ist vermutlich ein fehlerhafter Treiber, der Windows daran hindert, in den Energiesparmodus zu wechseln. Es handelt sich hierbei um eine neue Funktion, die mit Windows 8 eingeführt wurde, und die als Schnellstartmodus bezeichnet wird. Anstatt das System vollständig herunter zu fahren, wird der aktuelle Benutzer nur abgemeldet und das System dann in den Hibernation-Mode (Ruhezustand) versetzt. Im Ruhezustand wird der Inhalt des Arbeitsspeichers in die Datei hiberfil.sys geschrieben und beim Einschalten wieder gestartet. Dadurch muß beim Hochfahren des Systems nicht mehr das Gerät initialisiert werden, sonden es wird nur noch der letzte Zustand geladen, was deutlich schneller geht.

Wenn ein Fehlerhafter Treiber, eine Fehlerhafte Datei oder ein Bug in Windows das Herstellen des Ruhezustands verhindert, schaltet sich der Rechner nicht ab, sondern öffnet sofort wieder das Anmeldefenster. Um das Problem temporär zu lösen, können Sie den Rechner zwingen, komplett herunter zu fahren, indem Sie beim Klicken auf den Eintrag "Herunterfahren" die Shift-Taste gedrückt halten. Alternativ können Sie den Rechner mithilfe der Kommandozeile ausschalten. Erstellen Sie sich dazu ein Batch-Datei (eine Textdatei mit der Endung .cmd oder .bat) und schreiben Sie folgenden Befehl in die Datei:

Shutdown /s /t 0

Der Shutdown-Befehl fährt den Rechner immer komplett herunter, es sei denn, sie geben explizit den Parameter /hybrid mit an.

Um den Fehler zu beheben, stehen Ihnen, je nach Ursache, mehrere Möglichkeiten zu Auswahl. Wenn es sich um ein Problem des Betriebssystems handelt, dass nach einem Update aufgetreten ist, hilft es vielleicht schon, die neuesten Windows-Updates einzuspielen. Hilft das nicht, versuchen Sie die Gerätetreiber zu akutalisieren. Übliche Verdächtige sind die Netzwerkkarte, die Grafikkarte oder die Chipsatztreiber.

Eine Datei umzubenennen ist mit Powershell mit Hilfe des Cmdlets Rename-Item relativ einfach möglich. Sie müssen nur den Namen der Datei und den neuen Namen angeben:

Rename-Item -Path C:\temp\Test.txt -NewName Produktion.txt

Es gibt aber auch die Möglichkeit, mehrere Dateien in einem Rutsch umzubenennen. Hierfür können Sie die umzubennenden Dateien per Pipeline an Rename-Item weiterleiten und neuen Namen über einen Skriptblock definieren:

Get-ChildItem -Path C:\Skripte\*.ps1 | Rename-Item -NewName { $_.basename + ".txt"  }

In diesem einfachen Beispiel werden alle Dateien mit der Endung .ps1 im Ordner c:\Skripte in .txt umbenannt - $_ ist ein Platzhalter für die einzelnen Dateien, .basename beinhaltet den Dateinamen ohne Dateiendung.

Wenn man in Powershell ein ausführbares Programm starten möchte, kann man das normalerweise machen, indem man den direkten Pfad in der in der Konsole einfach aufruft. Genauso kann man ein Programm in einem Script direkt referenzieren.

C:\programme\7zip\7z.exe

Problematischer wird das, wenn der Pfad, in dem sich das Programm befindet, Leerzeichen enthält. Der Programmpfad muß dann in Anführungszeichen gesetzt werden, wird nun aber als String interpretiert und kann nicht mehr direkt aufgerufen. Powershell gibt stattdessen einfach nur den String zurück.

'C:\Program Files\7Zip\7z.exe'
C:\Program Files\7Zip\7z.exe

Die Lösung bietet der Ausführungsoperator &, der Powershell anweist, den folgenden String direkt auszuführen:

Vor kurzem bin ich auf einen interessanten Artikel von Mike Robbins gestoßen, den ich hier noch einmal kurz zusammengefasst wiedergeben möcht.

Variablen haben in Powershell normalerweise nur eine begrenzten Lebensdauer, die vom Scriptblock definiert ist, in dem Sie deklariert wurde. Sobald der Scriptblock beendet wird, in dem eine Variable deklariert wurde, wird auch die Variable wieder freigegeben. Hierzu ein kleine Beispiel:

$TestVariable = 'Hallo vom Script'
function Test-Scope
{
  $TestVariable = 'Hallo aus der Funktion'
  $TestVariable
}
Test-Scope
$Testvariable

Wie sieht die Ausgabe des Skripts aus und was ist der Inhalt der Testvariablen zu den unterschiedlichen Zeitpunkten?

Das Skript gibt diese Ausgabe zurück:

Wenn Sie mit "Fremdapplikationen" wie Multifunkitionsdruckern oder aus einem Skript Mails über die Microsoft-eigenen Office 365 Exchange-Server versenden wollen, haben Sie grundsätzlich drei Möglichkeiten: Den anonymen Mailversand, den Versand über ein authentifiziertes Benutzerkonto oder einen dezidierten Connector. In dieser Beschreibung möchte ich mich auf die ersten zwei, weil vermutlich häufigesten, konzentrieren. Den vollständigen Artikel von Microsoft zur Einrichtung aller drei Methoden inklusive des Connectors finden Sie unter "Links" am Ende des Textes.

Die einfachste Variante, um mails zu verschicken, ist ein Postfach in Office 365 anzulegen, also einen neuen Benutzer. Danach können Sie sowohl interne mails (also innerhalb Ihrer O365-Organisation) als auch externe Mails verschicken. Sie verwenden für den Mailversand den Server smtp.office365.com und müssen eine Anmeldung mit Benutzername und Kennwort des Postfachbenutzers durchführen. Hier ein kleines Beispiel mit Powershell:

$Password = Convertto-Securestring -String 'Passwort' -AsPlainText -Force
$credential = New-Object PSCredential("Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.",$Password)
Send-MailMessage -SmtpServer smtp.office365.com -Port 587 -UseSsl -Subject 'Ein Fehler ist aufgetreten' -Body 'fehler' -from Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.' -To Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.' -Credential $credential

Alternativ kann für den Versand auch Port 25 verwendet werden, bevorzugt ist aber Port 587, der für TLS-Verschlüsselung verwendet wird.

Der Nachteil dieser Variante ist, dass Sie ein Postfach und damit eine Benutzerlizenz benötigen. Außerdem ist die Menge der mails, die pro Minute verschickt werden können, auf 30 eingeschränkt. Alternativ können Sie aber auch direkt versenden, ohne eine Postfach zu verwenden. Diese Variante funktioniert aber nur für internen Mailversand - Office 365 leitet keine Mails an Benutzer außerhalb Ihrer Organisation weiter.

Der Scriptblock in Powershell stellt standardmäßig einen Param-Block zur Verfügung, über den Parameter an Skripte und Funktionen übergeben werden können. Erweiterte Funktionen bieten darüber hinaus einen ganze Reihe von Parameter-Optionen, um das Verhalten der Parameter steuern zu können. Eine manchmal sehr hilfreiche, unbekannte Parameter-Option ist DontShow, mit der man verhindern kann, dass ein Parameter in Intellisense angezeigt wird.Das kann z.B. nütlich sein, wenn man Hilfsfunktionen baut, die allgemein nutzbar (öffentlich) sind, bei denen bestimmte Hilfsparameter aber nur unter ganz bestimmten Spezialfällen sinnvoll sind. Geben Sie bei den Parameter-Optionen einfach DontShow mit an:

function Test-HiddenParam
{
Param(
   [Parameter(DontShow)]
   [string]$hiddenParameter
)

$hiddenParameter
}

Send-Mailmessage ist ein sehr nützliches Cmdlet, um Emails direkt aus Powershell an einen Mailserver zu senden. Er steht seit Powershell 2.0 zur Verfügung und vermeidet so, dass man sich direkt mit dem [System.net.mail]-Typ herumschlagen muß. Allerdings zeigt das Cmdlet ein sehr merkwürdiges Fehlerverhalten.

Wenn man versucht, Verbindungsfehler abzufangen, ist ein erster vernünftiger Ansatz, einfach auf den Parameter -Errorvariable zurückzugreifen:

Send-Mailmessage -SmtpServer mail.meineFirma.de -Subject 'Warnung' -Body 'Hier kommt die Maus' -From 'Elefant@netz-weise.xyz' -to 'Maulwurf@netz-weise.xyz' -ErrorVariable Fehlermeldung
If ( $Fehlermeldung ) { $Fehlermeldung.Exception.Message }

Tritt ein Fehler auf, wird dieser direkt in der Variablen $Fehlermeldung gespeichert. Achtung, bei der Angabe der Fehlervariablen wird kein $-Zeichen angegeben!

In letzter Zeit beschäftige ich mich wieder intensiv mit dem MDT, um unsere Schulungs-Rechner mit neuen Windows 10 Images zu versehen. Dafür habe ich ein kleine Powershell-Funktion geschrieben, den den Autologon für einen Benutzer setzt (s.u.). Sie kann den Autologon aktivieren. Leider funktioniert die Funktion nicht innerhalb eines Konfigurationsskriptes im MDT, da nach erfolgter Installation das Aufräumskript Scripts\LTICleanup.wsf den Autologon entfernt. Um den Autologon beizubehalten oder ändern zu können, suchen Sie den Text

     '//----------------------------------------------------------------------------
     '//  Clear the autologon registry keys
     '//----------------------------------------------------------------------------

und kommentieren Sie die nachfolgenden Zeilen bis zum nächsten Kommentarblock mit dem ' aus.

function Set-AutomaticLogon
{
<#
.Synopsis
    Enables Windows Autologon or removes it
.DESCRIPTION
    This function enables Windows Autologon via Registry-Keys or disables it. It is similar
    to the Netplwiz.exe Command
.EXAMPLE
    Set-AutomaticLogon -Enabled -Username Student -Password Password
    Adds an Autologon-Key to the Registry.
.EXAMPLE
    Set-AutomaticLogon -Disabled
    Disables the automatic Logon by removing the User-Password and disabling the Logon-key.
#>
param
(
    [parameter(Mandatory=$True,
               ParameterSetName='Enabled')]
    [switch]$Enabled,

    [parameter(Mandatory=$True,
               ParameterSetName='Disabled')]
    [Switch]$Disabled,

Das Microsoft Deyployment Toolkit 2013 hat in der aktuellen Version 8443 einen Bug, der die Tasksequenz "Sysprep and Capture" funtionsunfähig macht. Leider hat Microsoft den Bug bisher nicht durch eine aktualisierte Version bereinigt. Man kann sich aber schnell selbst behelfen, denn es handelt sich um fehlerhaften VBS-Code in der Datei ZTIUtility.vbs im Ordner Scripts im Root des Deployment-Shares. Ersetzen Sie in Zeile 3327 den Code 

If (oTS.SelectSingleNode("//step[@type='BDD_InstallOS']") is nothing) and (oTS.SelectSingleNode("//step[@type='BDD_UpgradeOS']") is nothing) then

durch

if (oTS.SelectSingleNode("//step[@type='BDD_InstallOS' and @disable='false']") is nothing) and (oTS.SelectSingleNode("//step[@type='BDD_UpgradeOS' and @disable='false']") is nothing) then

Danach sollte die Tasksequenz problemlos durchlaufen.

Links
https://community.spiceworks.com/topic/1924854-mdt-8443-sysprep-capture-task-not-working

In meinem Blogeintrag Zufällige (Komplexe) Kennwörter erzeugen mit Powershell vom 23.04 habe ich gezeigt, wie man komplexe Kennwörter mit Powershell generieren kann, indem man zufällige Zeichen mit Get-Random erzeugt. Aber es geht auch einfacher, denn das .NET-Framework bietet bereits eine fertige statische Methode zum generieren von Kennwörtern, die man in Powershell nur noch laden muß. Die Methode heißt GeneratePassword und befindet sich in der [System.Web]-Assembly. Die Assembly ist in Powershell allerdings nicht standardmäßig geladen. Dies kann man mit dem Cmdlet Add-Type erledigen: 

Add-Type -AssemblyName System.web

Nun können Sie die Methode GeneratePassword aus der Klasse [System.Web.Security.Membership] aufrufen. Der Aufruf erfolgt über [Klasse]::Methodenname(Parameter):

[System.Web.Security.Membership]::GeneratePassword(10,3)

Die beiden Parameter 10 und 3 bestimmen die Anzahl der Zeichen sowie die nicht-Alphanumerischen Zeichen, die das Kennwort enthalten muß. 

Das Cmdlet Search-ADAccount ist das Schweizer Messer des AD-Administrators. Es zeigt gesperrte Konten genauso an wie deaktiviert Konten, ablaufende Konten und Konten, deren Kennwort niemals abläuft. Der vielleicht hilfreichste Parameter ist aber -AccountInactive, der Konten anzeigt, die sich schon lange nicht mehr in der Domäne angemeldet haben. Grundsätzlich kann man dieses auch mit Get-ADUser und Get-ADComputer lösen, aber das ist aufwändiger und außerdem muß man auch darauf achten, welches AD-Attribut man auswertet, denn es gibt mehrere Eigenschaften, die die letzte Anmeldung speichern, aber nicht alle sind gleich gut geeignet. Eine gute Auflistung der Attribute und deren Unterschiede finden Sie im Technet-Wiki. 

Um inaktive Konten anzuzeigen, nutzen Sie einfach

Search-ADAccount -AccountInactive

Der Parameter findet sowohl Benutzer- als auch Computerkonten, die sich seit 60 Tagen nicht mehr angemeldet haben. Wenn Sie nur Benutzer suchen, verwenden Sie den Parameter -Usersonly, wenn Sie die Zeitspanne angeben wollen, benutzen Sie den Parameter Timespan, gefolgt von den Tagen seit dem letzten Login:

Search-ADAccount -AccountInactive -TimeSpan 90 -UsersOnly

In Powershell ist es oft  notwendig, einen Secure-String zu erzeugen. SecureStrings werden z.B. zum Erstellen eines AD-Benutzers verwendet, oder für alle möglichen Arten von Anmeldeinformationen. Das Geheimnis eines SecureStrings besteht darin, dass er über die Microsoft DPAPI (Data Protection API) durch das Konto des Benutzers geschützt ist, der den SecureString erzeugt hat. Dadurch kann nur er auf das Kennwort des SecureStrings zugreifen. 

Manchmal gibt es aber die Situation, in der man das Kennwort eines Securestrings gerne wieder im Klartext hätte. Als Beispiel dafür soll Read-Host herhalten, das Benutzereingaben von der Konsole liest. Ruf man Read-Host mit dem Parameter -Prompt auf, kann man den Benutzer zu einer Eingabe auffordern: 

$Password = Read-Host -Prompt "Bitte geben Sie ein Kennwort ein"

Das Kennwort wird als String in der Variablen $Password gespeichert. Leider wird das Kennwort aber bei der Eingabe im Klartext angezeigt. Das kann man über den Parameter -AsSecurestring verhindern. Dadurch wird die Eingabe in einen SecureString konvertiert und die Eingabe wird durch das * maskiert:

$Password = Read-Host -Prompt "Bitte geben Sie ein Kennwort ein" -AsSecureString
Bitte geben Sie ein Kennwort ein: ********

Wenn Sie Datums- und Zeitwerte speichern, gibt es ein ISO-Format, das Kulturunabhängig funktioniert. Es hat folgende Form:

yyyy-MM-dd HH:mm:ss (Jahr 4-stellig, Monat 2-stellig, Tag 2-stellig, Stunden im 24-Stunden Format, Minuten und Sekunden 2-stellig)

Sie können das Datumsformat mit Powershell im ISO-Format angeben, indem Sie den Format-Parameter verwenden: 

Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
2017-04-17 22:31:30

Speichern Sie das Datum in einer Variablen, erstellen Sie ein Datetime-Objekt. Der-Format-Befehl hat auf das Datetime-Objekt keine Auswirkungen, sondern bezieht sich nur auf die Ausgabe. Sie können das Datum also auch folgendermaßen Kulturunabhängig erzeugen: