about_Windows_Powershell_5.1

  • Artikel

Kurze Beschreibung

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.

Informationen zum Installieren von Windows PowerShell 5.1 in älteren Versionen von Windows finden Sie unter Installieren und Konfigurieren von WMF 5.1. Lesen Sie unbedingt die Downloaddetails, und erfüllen Sie alle Systemanforderungen, bevor Sie Windows Management Framework 5.1 installieren.

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: Diese Edition basiert auf .NET Framework und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die unter Vollversionen von Windows wie Server Core und Windows Desktop ausgeführt werden.
  • Core-Edition: Diese Edition basiert auf .NET Core und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die unter funktionsreduzierten Versionen von Windows wie Nano Server und Windows IoT ausgeführt werden.

Weitere Informationen zur Verwendung von PowerShell-Editionen

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>]

Die 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.

Melden Sie sich mit dem Cmdlet Set-AuthenticodeSignature an, um die Integrität der Katalogdatei zu überprüfen (im obigen Beispiel: „pester.cat“).

Test-FileCatalog

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 Umgebungsvariable wirken sich nur auf untergeordnete Prozesse aus. Der Wert muss einen vollständigen Pfad (samt Dateiname) definieren, in dem PowerShell die Berechtigung zum Erstellen und Schreiben von Dateien hat. Zum Deaktivieren des Dateicaches kann dieser Wert auf einen ungültigen Speicherort festgelegt werden. Beispiel:

$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

In WMF 5.1 wurde die Version von Pester, die im Lieferumfang von PowerShell enthalten ist, von 3.3.5 auf 3.4.0 aktualisiert. Sie können die Änderungen in den Versionen 3.3.5 bis 3.4.0 überprüfen, indem Sie das CHANGELOG im GitHub-Repository überprüfen.

SCHLÜSSELWÖRTER

Neuerungen in Windows PowerShell 5.1