about_Windows_PowerShell_5.1

Kurzbeschreibung

Beschreibt neue Features, die in Windows PowerShell 5.1 enthalten sind.

Lange Beschreibung

Windows PowerShell 5.1 enthält wichtige neue Features, die ihre Verwendung erweitern, die Benutzerfreundlichkeit verbessern und Ihnen ermöglichen, Windows-basierte Umgebungen einfacher und umfassender zu steuern und zu verwalten.

Windows PowerShell 5.1 ist abwärtskompatibel. Cmdlets, Anbieter, Module, Snap-Ins, Skripts, Funktionen und Profile, die für Windows PowerShell 4.0, Windows PowerShell 3.0 und Windows PowerShell 2.0 entwickelt wurden, funktionieren in der Regel ohne Änderungen in Windows PowerShell 5.1.

• Neue Cmdlets: lokale Benutzer und Gruppen; Get-ComputerInfo
• PowerShellGet-Verbesserungen wie z. B. die Durchsetzung von signierten Modulen und die Installation von JEA-Modulen
• Bei PackageManagement wurde Unterstützung für Container, CBS-Setup, EXE-basiertes Setup und CAB-Pakete hinzugefügt
• Debuggingverbesserungen für DSC und PowerShell-Klassen
• Sicherheitsverbesserungen wie u. a. die Durchsetzung von katalogsignierten Modulen vom Pullserver und bei Verwendung von PowerShellGet-Cmdlets
• Antworten auf verschiedene Benutzeranfragen und zu Problemen

Windows PowerShell 5.1 ist standardmäßig unter Windows Server Version 2016 und höher und Windows-Clientversion 10 und höher installiert.

Sie können sich auch über Änderungen an Windows PowerShell 5.1 in "Neuigkeiten" in Windows PowerShell informieren.

PowerShell-Editionen

Ab Version 5.1 ist PowerShell in verschiedenen Editionen verfügbar, die unterschiedliche Funktionen mitbringen und zu unterschiedlichen Plattformen kompatibel sind.

• Desktop Edition: Basiert auf .NET Framework und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die auf vollständigen Fußabdruckeditionen von Windows wie Server Core und Windows Desktop ausgeführt werden.
• Core Edition: Basiert auf .NET Core und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die auf reduzierten Speicherbedarfseditionen von Windows wie Nano Server und Windows IoT ausgeführt werden.

Weitere Informationen zur Verwendung von PowerShell-Editionen

• Determine running edition of PowerShell using $PSVersionTable (Bestimmen der ausgeführten Edition von PowerShell mit $PSVersionTable)
• Filter Get-Module results by CompatiblePSEditions using PSEdition parameter (Filtern von Get-Module-Ergebnissen nach CompatiblePSEditions mithilfe des PSEdition-Parameters)
• Verhindern der Ausführung von Skripts außer bei Ausführung in einer kompatiblen Edition von PowerShell
• Deklarieren der Kompatibilität eines Moduls mit bestimmten Versionen von PowerShell

Katalog-Cmdlets

Im Modul "Microsoft.PowerShell.Security" wurden zwei neue Cmdlets hinzugefügt. Diese Cmdlets generieren und überprüfen Windows-Katalogdateien.

New-FileCatalog

New-FileCatalog erstellt eine Windows-Katalogdatei für den Satz von Ordnern und Dateien. Diese Katalogdatei enthält die Hashes aller Dateien in bestimmten Pfaden. Benutzer können den Satz von Ordnern zusammen mit den entsprechenden Katalogdateien verteilen, die diese Ordner darstellen. Diese Informationen helfen bei der Überprüfung, ob seit der Erstellung des Katalogs Änderungen an den Ordnern vorgenommen wurden.

New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
 [-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

Katalogversionen 1 und 2 werden unterstützt. Version 1 verwendet den SHA1-Hashalgorithmus, um Dateihashes zu erstellen, Version 2 verwendet SHA256. Sie sollten Katalogversion 2 verwenden.

Um die Integrität der Katalogdatei (Pester.cat im obigen Beispiel) zu überprüfen, signieren Sie sie mit dem Cmdlet "Set-AuthenticodeSignature ".

Test-Dateikatalog

Test-FileCatalog überprüft den Katalog, der einen Satz von Ordnern darstellt.

Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
 [-CatalogFilePath] <String> [[-Path] <String[]>]
 [-WhatIf] [-Confirm] [<CommonParameters>]

Dieses Cmdlet vergleicht alle Dateihashes und ihre relativen Pfade in einem Katalog mit Dateien auf dem Datenträger. Wenn ein Konflikt zwischen Dateihashes und Pfaden erkannt wird, gibt er den Status als ValidationFailed. Benutzer können alle diese Informationen mithilfe des Parameters "Detailed " abrufen. Außerdem wird der Signaturstatus des Katalogs in der Signature-Eigenschaft angezeigt, was dem Aufrufen des Cmdlets "Get-AuthenticodeSignature " in der Katalogdatei entspricht. Benutzer können auch jede Datei während der Überprüfung mit dem Parameter FilesToSkip überspringen.

Die Datei „ModuleAnalysisCache“

Ab WMF 5.1 bietet PowerShell die Kontrolle über die Datei, die zum Zwischenspeichern von Daten über ein Modul verwendet wird, z. B. die exportierten Befehle.

Standardmäßig wird dieser Cache in der Datei ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache gespeichert. Der Cache wird in der Regel beim Start der Suche nach einem Befehl gelesen und einige Zeit nach dem Import des Moduls in einem Hintergrundthread geschrieben.

Um den Standardspeicherort des Caches zu ändern, legen Sie die Umgebungsvariable $env:PSModuleAnalysisCachePath vor dem Starten von PowerShell fest. Änderungen an dieser Umgebungsvariablen betreffen nur untergeordnete Prozesse. Der Wert sollte einen vollständigen Pfad (einschließlich Dateinamen) angeben, für den PowerShell die Berechtigung zum Erstellen und Schreiben von Dateien hat. Um den Dateicache zu deaktivieren, legen Sie diesen Wert auf einen ungültigen Speicherort fest, z. B.:

$Env:PSModuleAnalysisCachePath = 'nul'

Hiermit wird der Pfad auf ein ungültiges Gerät festgelegt. Wenn PowerShell nicht in den Pfad schreiben kann, wird kein Fehler zurückgegeben, aber Sie können die Fehlerberichterstattung mithilfe eines Ablaufverfolgungselements sehen:

Trace-Command -PSHost -Name Modules -Expression {
  Import-Module Microsoft.PowerShell.Management -Force
}

Beim Ausschreiben des Caches sucht PowerShell nach Modulen, die nicht mehr vorhanden sind, um einen unnötig großen Cache zu vermeiden. Sie können die Überprüfungen mithilfe der folgenden Einstellung deaktivieren:

$Env:PSDisableModuleAnalysisCacheCleanup = 1

Das Festlegen dieser Umgebungsvariable wird sofort im aktuellen Prozess wirksam.

Angeben der Modulversion

In WMF 5.1 verhält sich using module genauso wie andere modulbezogene Konstruktionen in PowerShell. Zuvor hatten Sie keine Möglichkeit, eine bestimmte Modulversion anzugeben. Wenn mehrere Versionen vorhanden waren, hat dies zu einem Fehler geführt.

In WMF 5.1:

• Sie können den Konstruktor „ModuleSpecification“ (Hashtabelle) verwenden. Diese Hashtabelle hat das gleiche Format wie Get-Module -FullyQualifiedName.

  Beispiel: using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

• Wenn mehrere Versionen des Moduls vorhanden sind, verwendet PowerShell dieselbe Auflösungslogik wie Import-Module und gibt keinen Fehler zurück.

Verbesserungen an Pester

WMF 5.1 schiffe mit Pester v3.4.0. Weitere Informationen zu dieser Version finden Sie im CHANGELOG im GitHub-Repository.