Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7.x

Windows PowerShell 5.1 basiert auf .NET Framework v4.5. Mit der Veröffentlichung von PowerShell 6.0 wurde PowerShell zu einem Open Source-Projekt, das auf .NET Core 2.0 basiert. Der Wechsel von .NET Framework zu .NET Core ermöglichte es PowerShell, zu einer plattformübergreifenden Lösung zu werden. PowerShell läuft unter Windows, macOS und Linux.

Es gibt einige Unterschiede in der PowerShell-Sprache zwischen Windows PowerShell und PowerShell. Die Unterschiede liegen vor allem in der Verfügbarkeit und dem Verhalten von PowerShell-Cmdlets zwischen Windows- und Nicht-Windows-Plattformen sowie in den Änderungen, die sich aus den Unterschieden zwischen dem .NET Framework und dem .NET Core ergeben.

In diesem Artikel werden die wesentlichen Unterschiede und grundlegenden Änderungen zwischen Windows PowerShell und der aktuellen Version von PowerShell zusammengefasst. Diese Zusammenfassung enthält keine neuen Features oder Cmdlets, die hinzugefügt wurden. In diesem Artikel wird auch nicht beschrieben, was sich zwischen den Versionen geändert hat. Ziel dieses Artikels ist es, den aktuellen Stand von PowerShell vorzustellen und zu erläutern, wie es sich von Windows PowerShell unterscheidet. Eine detaillierte Beschreibung der Änderungen zwischen den Versionen und der neuen Features finden Sie in den Artikeln zu den Neuerungen der einzelnen Versionen.

• Neuerungen in PowerShell 7.5
• Neuerungen in PowerShell 7.4
• Neuerungen in PowerShell 7.3
• Neuerungen in PowerShell 7.2
• Neuerungen in PowerShell 7.1
• Neuigkeiten in PowerShell 7.0
• Neuerungen in PowerShell 6.x

.NET Framework und .NET Core

PowerShell unter Linux und macOS verwendet .NET Core. Dabei handelt es sich um eine Teilmenge des vollständigen .NET Frameworks unter Microsoft Windows. Das ist wichtig, da PowerShell den direkten Zugriff auf die zugrunde liegenden Frameworktypen und Methoden bereitstellt. Folglich können Skripts, die unter Windows ausgeführt werden, nicht auf anderen Plattformen als Windows ausgeführt werden, da die Frameworks sich unterscheiden. Weitere Informationen zu Änderungen in .NET Core finden Sie unter Breaking Changes für die Migration von .NET Framework zu .NET Core.

Jedes neue Release von PowerShell basiert auf einer neueren Version von .NET. Es kann Breaking Changes in .NET geben, die sich auf PowerShell auswirken.

• PowerShell 7.5, basierend auf .NET 9.0
• PowerShell 7.4: Basiert auf .NET 8.0
• PowerShell 7.3: Basiert auf .NET 7.0
• PowerShell 7.2 (LTS-current): Basiert auf .NET 6.0 (LTS-current)
• PowerShell 7.1: Basiert auf .NET 5.0
• PowerShell 7.0 (LTS): Basiert auf .NET Core 3.1 (LTS)
• PowerShell 6.2: Basiert auf .NET Core 2.1
• PowerShell 6.1: Basiert auf .NET Core 2.1
• PowerShell 6.0: Basiert auf .NET Core 2.0

Mit der Einführung von .NET Standard 2.0 kann PowerShell viele herkömmliche Windows PowerShell-Module ohne Änderungen laden. Darüber hinaus enthält PowerShell 7 eine Windows PowerShell-Kompatibilitätsfunktion, mit der Sie Windows PowerShell-Module verwenden können, für die weiterhin das vollständige Framework erforderlich ist.

Weitere Informationen finden Sie unter:

• about_Windows_PowerShell_Compatibility
• Kompatibilität von PowerShell 7-Modulen

Zu beachtende .NET-Methodenänderungen

Während .NET-Methodenänderungen nicht spezifisch für PowerShell sind, können sie sich auf Ihre Skripts auswirken, insbesondere, wenn Sie .NET-Methoden direkt aufrufen. Außerdem gibt es möglicherweise neue Überladungen für Konstruktoren. Das kann sich auf die Erstellung von Objekten mit New-Object oder der [type]::new()-Methode auswirken.

.NET hat beispielsweise der [System.String]::Split()-Methode Überladungen hinzugefügt, die in .NET Framework 4.5 nicht verfügbar sind. Die folgende Liste zeigt die Überladungen für die in Windows PowerShell 5.1 verfügbare Split()-Methode:

PS> "".Split

OverloadDefinitions
-------------------
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

Die folgende Liste zeigt die Überladungen für die in PowerShell 7 verfügbare Split()-Methode:

"".Split

OverloadDefinitions
-------------------
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

In Windows PowerShell 5.1 können Sie ein Zeichenarray (char[]) als string an die Split()-Methode übergeben. Die Methode teilt die Zielzeichenfolge bei jedem Vorkommen eines Zeichens im Array auf. Der folgende Befehl teilt die Zielzeichenfolge in Windows PowerShell 5.1 auf, jedoch nicht in PowerShell 7:

# PowerShell 7 example
"1111p2222q3333".Split('pq')

1111p2222q3333

Um eine Bindung an die richtige Überladung zu erstellen, müssen Sie die Zeichenfolge in ein Zeichenarray umwandeln:

# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')

1111
2222
3333

Nicht mehr im Lieferumfang von PowerShell enthaltene Module

Aus verschiedenen Kompatibilitätsgründen sind die folgenden Module nicht mehr in PowerShell enthalten.

• ISE
• Microsoft.PowerShell.LocalAccounts
• Microsoft.PowerShell.ODataUtils
• Microsoft.PowerShell.Operation.Validation
• PSScheduledJob
• PSWorkflow
• PSWorkflowUtility

PowerShell-Workflow

Der PowerShell-Workflow ist ein Feature in Windows PowerShell, das auf Windows Workflow Foundation (WF) basiert und die Erstellung von stabilen Runbooks für lang andauernde oder parallelisierte Aufgaben ermöglicht.

Aufgrund der fehlenden Unterstützung für Windows Workflow Foundation in .NET Core haben wir den PowerShell-Workflow aus PowerShell entfernt.

Zukünftig soll die native Parallelität in der PowerShell-Sprache ohne Notwendigkeit des PowerShell-Workflows ermöglicht werden.

Wenn für die Fortsetzung eines Skripts nach dem Neustart des Betriebssystems Prüfpunkte erforderlich sind, empfehlen wir die Verwendung des Taskplaners, um beim Betriebssystemstart ein Skript auszuführen. Das Skript muss dabei jedoch seinen Status selbst verwalten (z. B. durch Speichern in eine Datei).

Aus PowerShell entfernte Cmdlets

Für die Module, die in PowerShell enthalten sind, wurden die folgenden Cmdlets aus verschiedenen Kompatibilitätsgründen oder aufgrund der Verwendung nicht unterstützter APIs aus PowerShell entfernt.

CimCmdlets

• Export-BinaryMiLog

Microsoft.PowerShell.Core

• Add-PSSnapin
• Export-Console
• Get-PSSnapin
• Remove-PSSnapin
• Resume-Job
• Suspend-Job

Microsoft.PowerShell.Diagnostics

• Export-Counter
• Import-Counter

Microsoft.PowerShell.Management

• Add-Computer
• Checkpoint-Computer
• Clear-EventLog
• Complete-Transaction
• Disable-ComputerRestore
• Enable-ComputerRestore
• Get-ComputerRestorePoint
• Get-ControlPanelItem
• Get-EventLog
• Get-Transaction
• Get-WmiObject
• Invoke-WmiMethod
• Limit-EventLog
• New-EventLog
• New-WebServiceProxy
• Register-WmiEvent
• Remove-Computer
• Remove-EventLog
• Remove-WmiObject
• Reset-ComputerMachinePassword
• Restore-Computer
• Set-WmiInstance
• Show-ControlPanelItem
• Show-EventLog
• Start-Transaction
• Test-ComputerSecureChannel
• Undo-Transaction
• Use-Transaction
• Write-EventLog

Microsoft.PowerShell.Utility

• Convert-String
• ConvertFrom-String

PSDesiredStateConfiguration

• Disable-DscDebug
• Enable-DscDebug
• Get-DscConfiguration
• Get-DscConfigurationStatus
• Get-DscLocalConfigurationManager
• Publish-DscConfiguration
• Remove-DscConfigurationDocument
• Restore-DscConfiguration
• Set-DscLocalConfigurationManager
• Start-DscConfiguration
• Stop-DscConfiguration
• Test-DscConfiguration
• Update-DscConfiguration

WMI v1-Cmdlets

Die folgenden WMI v1-Cmdlets wurden aus PowerShell entfernt:

• Register-WmiEvent
• Set-WmiInstance
• Invoke-WmiMethod
• Get-WmiObject
• Remove-WmiObject

Die Cmdlets des CimCmdlets-Moduls (auch bekannt als WMI v2) erfüllen dieselbe Funktion und bieten neue Funktionen und eine überarbeitete Syntax.

Cmdlet New-WebServiceProxy entfernt

.NET Core bietet keine Unterstützung für das Windows Communication Framework, das Dienste für die Verwendung des SOAP-Protokolls bereitstellt. Dieses Cmdlet wurde entfernt, weil es SOAP erfordert.

*-Transaction-Cmdlets entfernt

Die Verwendung dieser Cmdlets war sehr eingeschränkt. Es wurde entschieden, ihre Unterstützung einzustellen.

• Complete-Transaction
• Get-Transaction
• Start-Transaction
• Undo-Transaction
• Use-Transaction

*-EventLog-Cmdlets

Aufgrund der Verwendung von nicht unterstützten APIs wurden die*-EventLog-Cmdlets aus PowerShell entfernt. Unter Windows stehen Get-WinEvent und New-WinEvent zum Abrufen und Erstellen von Ereignissen zur Verfügung.

Cmdlets, die das Windows Presentation Framework (WPF) verwenden

NET Core 3.1 hat die Unterstützung für WPF hinzugefügt, sodass mit der Veröffentlichung von PowerShell 7.0 die folgenden Windows-spezifischen Features wiederhergestellt wurden:

• Show-Command-Cmdlet
• Out-GridView-Cmdlet
• ShowWindow-Parameter von Get-Help

DSC-Änderungen von PowerShell (Desired State Configuration)

Invoke-DscResource wurde als experimentelles Feature in PowerShell 7.0 wiederhergestellt.

Beginnend mit PowerShell 7.2 wurde das PSDesiredStateConfiguration-Modul aus PowerShell entfernt und im PowerShell-Katalog veröffentlicht. Weitere Informationen finden Sie im PowerShell-Teamblog in der Ankündigung.

Ausführbare PowerShell-Änderungen

powershell.exe in pwsh.exe umbenannt

Der binäre Name für PowerShell wurde von powershell(.exe) in pwsh(.exe) geändert. So können Benutzer PowerShell deterministisch auf Computern ausführen und parallele Installationen von Windows PowerShell und PowerShell unterstützen.

Weitere Änderungen in pwsh(.exe) im Vergleich zu powershell.exe:

• Der erste positionelle Parameter wurde von -Command in -File geändert. #!, auch Shebang genannt, wird damit nicht mehr in PowerShell-Skripts benötigt, die über Nicht-PowerShell-Shells auf Nicht-Windows-Plattformen ausgeführt werden. Damit können Sie auch Befehle wie pwsh foo.ps1 oder pwsh fooScript ausführen, ohne -File anzugeben. Beim Versuch, einen Befehl wie pwsh.exe -Command Get-Command auszuführen, muss für diese Änderung jedoch -c oder -Command explizit angegeben werden.
• pwsh akzeptiert den Schalter -i (oder -Interactive), um eine interaktive Shell anzuzeigen. Daher kann PowerShell als Standard-Shell auf Unix-Plattformen verwendet werden.
• Die Parameter -ImportSystemModules und -PSConsoleFile wurden aus pwsh.exe entfernt.
• pwsh -version wurde geändert, und Hilfe für pwsh.exe bei der Ausrichtung an anderen nativen Tools wurde integriert.
• Ungültige Argument-Fehlermeldungen für -File und -Command und mit den Unix-Standards konsistente Exitcodes
• Parameter -WindowStyle unter Windows hinzugefügt. Paketbasierte Installationsupdates auf Nicht-Windows-Plattformen werden direkt installiert.

Der abgekürzte Name ist ebenfalls mit der Benennung von Shells in anderen Plattformen als Windows konsistent.

Unterstützung der Ausführung eines PowerShell-Skripts mit dem bool-Parameter

Zuvor wurde bei der Verwendung von pwsh.exe, um ein PowerShell-Skript mithilfe von -File auszuführen, keine Möglichkeit bereitgestellt, $true/$false als Parameterwert zu übergeben. Die Unterstützung für $true/$false als analysierte Werte für Parameter wurde hinzugefügt. Switchwerte werden ebenfalls unterstützt.

Verbesserte Abwärtskompatibilität mit Windows PowerShell

Für Windows wurde Import-Module der neue Schalterparameter UseWindowsPowerShell hinzugefügt. Dieser Schalter erstellt in PowerShell 7 ein Proxymodul, das einen lokalen Windows PowerShell-Prozess verwendet, um alle in diesem Modul enthaltenen Cmdlets implizit auszuführen. Weitere Informationen finden Sie unter Import-Module.

Weitere Informationen dazu, welche Microsoft-Module mit PowerShell 7.0 funktionieren, finden Sie in der Tabelle zur Modulkompatibilität.

Microsoft Update-Unterstützung für Windows

Zusätzlicher PowerShell 7.2-Support für Microsoft Update. Wenn Sie dieses Feature aktivieren, erhalten Sie die aktuellen PowerShell 7-Updates in Ihrem üblichen Windows Update-Verwaltungsflow. Dies gilt sowohl für Windows Update for Business, WSUS und SCCM als auch für das interaktive Windows Update-Dialogfeld in den Einstellungen.

Das PowerShell 7.2 MSI-Paket enthält die folgenden Befehlszeilenoptionen:

• USE_MU: Diese Eigenschaft verfügt über zwei mögliche Werte:
  • 1 (Standardeinstellung): aktiviert Updates über Microsoft Update oder WSUS
  • 0 – automatische Updates über Microsoft Update oder WSUS werden nicht aktiviert
• ENABLE_MU
  • 1 (Standardeinstellung): aktiviert die Verwendung von Microsoft Update, automatischen Updates oder Windows Update
  • 0: keine Aktivierung der Verwendung von Microsoft Update, automatischen Updates oder Windows Update

Moduländerungen

Unterstützung von PowerShell als Unix-Standardshell

Unter Unix ist es Konvention, dass Shells -i für eine inaktive Shell akzeptieren und viele Tools dieses Verhalten erwarten (z.B. script und wenn PowerShell als Standardshell festgelegt wird) und die Shell mit dem Parameter -i aufrufen. Dies ist ein Breaking Change, da -i zuvor einfach verwendet werden konnte, um mit -inputformat übereinzustimmen. Nun muss hierfür -in verwendet werden.

Benutzerdefinierte Snap-Ins

PowerShell-Snap-Ins sind die Vorgänger von PowerShell-Modulen und sind in der PowerShell-Community nicht weit verbreitet.

Aufgrund der Komplexität der unterstützenden Snap-Ins und der zu geringen Verwendung in der Community werden benutzerdefinierte Snap-Ins in PowerShell nicht mehr unterstützt.

Experimentelle Featureflags

Aktivierter Support für PowerShell 6.2 für Experimentelle Features. Auf diese Weise können PowerShell-Entwickler neue Funktionen bereitstellen und Feedback erhalten, bevor der Entwurf abgeschlossen ist. Auf diese Weise vermeiden wir, dass wir bei der Weiterentwicklung des Entwurfs Breaking Changes vornehmen.

Verwenden Sie Get-ExperimentalFeature, um eine Liste der verfügbaren experimentellen Features abzurufen. Sie können diese Features mit Enable-ExperimentalFeature und Disable-ExperimentalFeature aktivieren oder deaktivieren.

Assembly wird vor dem Versuch, aus dem GAC geladen zu werden, aus dem Modulbasispfad geladen

Wenn ein binäres Modul die Modulassembly im GAC enthält, wurde die Assembly bisher aus dem GAC geladen, bevor versucht wurde, sie aus dem Modulbasispfad zu laden.

Überspringen der Überprüfung auf NULL-Elemente für Sammlungen mit einem Werttyp

Überspringen Sie beim Parameter Mandatory und bei den Attributen ValidateNotNull und ValidateNotNullOrEmpty die Überprüfung auf NULL-Elemente, wenn der Elementtyp der Sammlung ein Werttyp ist.

Beibehaltung von $? für ParenExpression, SubExpression und ArrayExpression

Dieser PR ändert die Art und Weise, wie wir Unterpipelines (...), Teilausdrücke $(...) und Arrayausdrücke @() kompilieren, sodass $? nicht automatisch true ist. Stattdessen hängt der Wert von $? vom Ergebnis der ausgeführten Pipeline oder Anweisungen ab.

Fix $? darf nicht $false sein, wenn der native Befehl in stderr schreibt

$? ist nicht auf $false festgelegt, wenn der native Befehl in stderr schreibt. Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr schreiben, einen Fehler zu melden. $? wird nur auf $false festgelegt, wenn der native Befehl einen Exitcode ungleich Null aufweist.

Veranlassen, dass $ErrorActionPreference sich nicht auf die stderr-Ausgabe nativer Befehle auswirkt

Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr schreiben, einen Fehler zu melden. Mit dieser Änderung wird die stderr-Ausgabe weiterhin in ErrorRecord-Objekten aufgezeichnet, die Runtime wendet $ErrorActionPreference jedoch nicht mehr an, wenn ErrorRecord aus einem nativen Befehl stammt.

Ändern von $OutputEncoding, um die UTF-8 NoBOM-Codierung statt ASCII zu verwenden

Die vorherige Codierung (ASCII, 7 Bit) würde in manchen Fällen zu falschen Änderungen der Ausgabe führen. Indem UTF-8 NoBOM als Standard festgelegt wird, wird die Unicode-Ausgabe mit einer Codierung beibehalten, die von den meisten Tools und Betriebssystemen unterstützt wird.

Vereinheitlichung von Cmdlets mit Parameter -Encoding mit dem Typ System.Text.Encoding

Der -Encoding-Wert Byte wurde aus den Cmdlets des Dateisystemanbieters entfernt. Der neue Parameter -AsByteStream wird nun verwendet, um anzugeben, dass ein Bytestream als Eingabe erforderlich ist oder dass die Ausgabe ein Bytestream ist.

Änderung der New-ModuleManifest-Codierung in UTF8NoBOM auf anderen Plattformen als Windows

Zuvor hat New-ModuleManifestpsd1-Manifeste in UTF-16 mit Bytereihenfolge-Marken erstellt, wodurch ein Problem für Linux-Tools entstand. Durch diese Änderung wird die Codierung auf anderen Plattformen als Windows von New-ModuleManifest in UTF (ohne Bytereihenfolge-Marken) geändert.

Entfernen von AllScope aus den meisten Standardaliasen

AllScope wurde aus den meisten Standardaliasen entfernt, um die Erstellung von Bereichen zu beschleunigen. In einigen häufig verwendeten Aliasen, in denen die Suche schneller ist, wurde AllScope beibehalten.

-Verbose und -Debug überschreibt nicht länger $ErrorActionPreference

Zuvor wurde das Verhalten von $ErrorActionPreference überschrieben, wenn -Verbose oder -Debug angegeben wurden. Durch diese Änderung wirken -Verbose und -Debug sich nicht mehr auf das Verhalten von $ErrorActionPreference aus.

Außerdem legt der -Debug-Parameter $DebugPreference auf Continue anstatt auf Inquire fest.

Veranlassen, dass $PSCulture Veränderungen der Kultur innerhalb der Sitzung konsistent widerspiegelt

In Windows PowerShell wird der aktuelle Kulturwert zwischengespeichert, was dazu führen kann, dass der Wert nicht mehr mit der nach dem Sitzungsstart geänderten Kultur synchronisiert ist. Dieses Zwischenspeicherverhalten wurde in PowerShell Core behoben.

Explizit angegebenem benannten Parameter erlauben, denselben über das Splatting von Hashtabellen zu ersetzen

Mit dieser Änderung werden die benannten Parameter aus dem Splatting an das Ende der Parameterliste verschoben, sodass sie erst nach dem Binden aller explizit angegebenen benannten Parameter gebunden werden. Die Parameterbindung für einfache Funktionen löst keinen Fehler aus, wenn ein angegebener benannter Parameter nicht gefunden werden kann. Unbekannte benannte Parameter sind an den $args-Parameter der einfachen Funktion gebunden. Durch Verschieben des Splattings an das Ende der Argumentliste wird die Reihenfolge geändert, in der die Parameter in $args angezeigt werden.

Beispiele:

function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}

Im vorherigen Verhalten ist MyPath das dritte Argument in der Argumentliste und daher nicht an -Path gebunden. Aus diesem Grund wird MyPath zusammen mit Blah = "World" in $args platziert.

PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath

Mit dieser Änderung werden die Argumente aus @hash an das Ende der Argumentliste verschoben. MyPath wird zum ersten Argument in der Liste, sodass es an -Path gebunden ist.

PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World

Sprachenänderungen

NULL-Sammeloperator ??

Der NULL-Sammeloperator ?? gibt den Wert seines linken Operanden zurück, wenn er nicht NULL ist. Andernfalls wertet er den rechten Operanden aus und gibt sein Ergebnis zurück. Der Operator ?? wertet seinen rechten Operanden nicht aus, wenn der linke Operand mit ungleich NULL auswertet wird.

$x = $null
$x ?? 100

100

Im folgenden Beispiel wird der rechte Operand nicht ausgewertet.

[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()

1/10/2020

Der NULL-Sammelzuordnungsoperator??=

Der NULL-Sammelzuordnungsoperator??= weist den Wert seines rechten Operanden dem linken Operanden nur zu, wenn der linke Operand mit NULL ausgewertet wird. Der Operator ??= wertet seinen rechten Operanden nicht aus, wenn der linke Operand mit ungleich NULL auswertet wird.

$x = $null
$x ??= 100
$x

100

Im folgenden Beispiel wird der rechte Operand nicht ausgewertet.

[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()

1/10/2020

Bedingter NULL-Operator

Hinweis

Dieses Feature wurde von „Experimentell“ in „Mainstream“ in PowerShell 7.1 verschoben.

Ein bedingter NULL-Operator erlaubt den Memberzugriff ?. oder Elementzugriff ?[] auf seinen Operanden nur dann, wenn dieser Operand mit ungleich NULL ausgewertet wird. Andernfalls gibt er NULL zurück.

Da PowerShell erlaubt, dass ? Teil des Variablennamens ist, ist für die Verwendung dieser Operatoren die formale Angabe des Variablennamens erforderlich. Daher ist es nötig, {} um die Variablennamen herum zu platzieren, wie z. B. ${a} oder wenn ? Teil des Variablennamens ${a?} ist.

Im folgenden Beispiel wird der Wert von PropName zurückgegeben.

$a = @{ PropName = 100 }
${a}?.PropName

100

Das folgende Beispiel gibt NULL zurück, ohne dass versucht wird, auf den Membernamen PropName zuzugreifen.

$a = $null
${a}?.PropName

Auf ähnliche Weise wird der Wert des Elements zurückgegeben.

$a = 1..10
${a}?[0]

1

Wenn der Operand NULL ist, wird nicht auf das Element zugegriffen und NULL zurückgegeben.

$a = $null
${a}?[0]

Hinweis

Die Syntax des Variablennamens ${<name>} sollte nicht mit dem $()-Subexpression-Operator verwechselt werden. Weitere Informationen finden Sie im Abschnitt „Variablenname“ von about_Variables.

&-Operator für Auftragssteuerung hinzugefügt

Wenn Sie ein & am Ende einer Pipeline einfügen, wird die Pipeline als PowerShell-Auftrag ausgeführt. In diesem Fall wird ein Auftragsobjekt zurückgegeben. Wird die Pipeline als Auftrag ausgeführt, kann sie mithilfe aller Standard-*-Job-Cmdlets verwaltet werden. Die in der Pipeline verwendeten Variablen (außer der prozessspezifischen) werden automatisch in den Auftrag kopiert, sodass Copy-Item $foo $bar & funktioniert. Der Auftrag wird auch im aktuellen Verzeichnis statt im Basisverzeichnis des Benutzers ausgeführt.

Neue Methoden/Eigenschaften für PSCustomObject

Wir haben neue Methoden und Eigenschaften zu PSCustomObject hinzugefügt. PSCustomObject enthält nun eine Count/Length-Eigenschaften wie andere Objekte.

$PSCustomObject = [pscustomobject]@{foo = 1}

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Diese Vorgehensweise umfasst auch ForEach- und Where-Methoden, mit denen Sie nach PSCustomObject-Elementen ausführen und filtern können:

$PSCustomObject.ForEach({$_.foo + 1})

2

$PSCustomObject.Where({$_.foo -gt 0})

foo
---
  1

Konvertierungen von PSMethod in einen Delegaten

Sie können eine PSMethod in einen Delegaten konvertieren. Dadurch kann nun beispielsweise PSMethod[M]::DoubleStrLen als Delegatwert an [M]::AggregateString übergeben werden:

class M {
    static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }

    static [long] AggregateString([string[]] $values, [func[string, int]] $selector) {
        [long] $res = 0
        foreach($s in $values){
            $res += $selector.Invoke($s)
        }
        return $res
    }
}

[M]::AggregateString((gci).Name, [M]::DoubleStrLen)

Verhalten beim Zeichenfolgenvergleich in PowerShell 7.1 geändert

PowerShell 7.1 basiert auf .NET 5.0, wodurch folgender Breaking Change eingeführt wurde:

• Verhaltensänderungen beim Vergleichen von Zeichenfolgen ab .NET 5

Ab .NET 5.0 ignorieren kulturunabhängige Zeichenfolgenvergleiche nicht druckbare Steuerzeichen.

Beispielsweise werden die folgenden beiden Zeichenfolgen als identisch betrachtet:

# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"

True

Neue Cmdlets

Neues Get-Uptime-Cmdlet

Das Get-Uptime-Cmdlet gibt die seit dem letzten Start des Betriebssystems verstrichene Zeit zurück. Dieses Cmdlet wurde in PowerShell 6.0 eingeführt.

Neues Remove-Alias-Cmdlet

Das Remove-Alias-Cmdlet entfernt einen Alias aus der aktuellen PowerShell-Sitzung. Dieses Cmdlet wurde in PowerShell 6.0 eingeführt.

Neues „Remove-Service“-Cmdlet

Das Remove-Service-Cmdlet entfernt einen Windows-Dienst in der Registrierung und in der Dienstdatenbank. Das Remove-Service-Cmdlet wurde in PowerShell 6.0 eingeführt.

Neue Markdown-Cmdlets

Markdown ist eine Standardsprache zum Erstellen von lesbaren Nur-Text-Dokumenten mit grundlegender Formatierung, die in HTML gerendert werden kann.

Die folgenden Cmdlets wurden in PowerShell 6.1 hinzugefügt:

• ConvertFrom-Markdown – Konvertieren des Inhalts einer Zeichenfolge oder einer Datei in ein MarkdownInfo-Objekt.
• Get-MarkdownOption – Gibt die aktuellen Farben und Stile zurück, die zum Rendern von Markdown-Inhalten in der Konsole verwendet werden.
• Set-MarkdownOption – Gibt die aktuellen Farben und Stile zurück, die zum Rendern von Markdown-Inhalten in der Konsole verwendet werden.
• Show-Markdown – Zeigt Markdown-Inhalte in der Konsole oder als HTML an

Neues Test-Json-Cmdlet

Das Test-Json-Cmdlet testet, ob eine Zeichenfolge ein gültiges JavaScript-Objektnotation -Dokument (JSON) ist und optional überprüfen kann, ob das JSON-Dokument für ein angegebenes Schema verwendet wird.

Das Cmdlet wurde in PowerShell 6.1 eingeführt

Neue Cmdlets zur Unterstützung experimenteller Features

Die folgenden Cmdlets wurden in PowerShell 6.2 hinzugefügt, um experimentelle Features zu unterstützen.

• Disable-ExperimentalFeature
• Enable-ExperimentalFeature
• Get-ExperimentalFeature

Neues Join-String-Cmdlet

Das Join-String-Cmdlet kombiniert Objekte aus der Pipeline in eine einzelne Zeichenfolge. Dieses Cmdlet wurde in PowerShell 6.2 hinzugefügt.

Neue Ansicht ConciseView und neues Cmdlet Get-Error

PowerShell 7.0 verbessert die Anzeige von Fehlermeldungen, um die Lesbarkeit von Interaktions- und Skriptfehlern mithilfe einer neuen Standardansicht namens ConciseView zu optimieren. Die Ansichten sind vom Benutzer über die Einstellungsvariable $ErrorView auswählbar.

Wenn bei ConciseView ein Fehler nicht von einem Skript- oder Parserfehler herrührt, handelt es sich um eine einzeilige Fehlermeldung:

Get-Childitem -Path c:\NotReal

Get-ChildItem: Cannot find path 'C:\NotReal' because it does not exist

Wenn der Fehler während der Skriptausführung auftritt oder ein Analysefehler ist, gibt PowerShell eine mehrzeilige Fehlermeldung zurück. Diese enthält den Fehler, einen Zeiger und eine Fehlermeldung, die angibt, wo der Fehler in dieser Zeile vorliegt. Wenn das Terminal keine farbigen Escapesequenzen nach ANSI (VT100) unterstützt, werden keine Farben angezeigt.

Die Standardansicht in PowerShell 7 ist ConciseView. Die vorherige Standardansicht war NormalView, die Sie durch Festlegen der Einstellungsvariablen $ErrorView auswählen können.

$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView

Hinweis

Die neue Eigenschaft ErrorAccentColor wird zu $Host.PrivateData hinzugefügt, um die Änderung der Akzentfarbe der Fehlermeldung zu unterstützen.

Das neue Get-Error-Cmdlet bietet auf Wunsch eine vollständige Detailansicht des vollqualifizierten Fehlers. Standardmäßig zeigt das Cmdlet die vollständigen Details, einschließlich innerer Ausnahmen, des zuletzt aufgetretenen Fehlers an.

Das Cmdlet Get-Error unterstützt die Eingabe aus der Pipeline unter Verwendung der integrierten Variablen $Error. Get-Error zeigt alle weitergeleiteten Fehler an.

$Error | Get-Error

Das Cmdlet Get-Error unterstützt den Parameter Newest, mit dem Sie angeben können, wie viele Fehler aus der aktuellen Sitzung angezeigt werden sollen.

Get-Error -Newest 3 # Displays the lst three errors that occurred in the session

Weitere Informationen finden Sie unter Get-Error.

Änderungen an Cmdlets

Parallele Ausführung zu ForEach-Object hinzugefügt

DasForEach-Object-Cmdlet, das Elemente in einer Sammlung iteriert und in PowerShell 7.0 beginnt, zeichnet sich nun dank des neuen Parameters Parallel durch integrierte Parallelität aus.

Standardmäßig verwenden parallele Skriptblöcke das aktuelle Arbeitsverzeichnis des Aufrufers, der die parallelen Aufgaben gestartet hat.

In diesem Beispiel werden 50.000 Protokolleinträge aus 5 Systemprotokollen auf einem lokalen Windows-Computer abgerufen:

$logNames = 'Security','Application','System','Windows PowerShell','Microsoft-Windows-Store/Operational'

$logEntries = $logNames | ForEach-Object -Parallel {
    Get-WinEvent -LogName $_ -MaxEvents 10000
} -ThrottleLimit 5

$logEntries.Count

50000

Der Parameter Parallel gibt den Skriptblock an, der für jeden Eingabeprotokollnamen parallel ausgeführt wird.

Der neue Parameter ThrottleLimit begrenzt die Anzahl der zu einer bestimmten Zeit parallel ausgeführten Skriptblöcke. Der Standardwert ist 5.

Verwenden Sie die Variable $_, um das aktuelle Eingabeobjekt im Skriptblock darzustellen. Verwenden Sie den Bereich $using:, um Variablenverweise an den ausgeführten Skriptblock zu übergeben.

Weitere Informationen finden Sie unter ForEach-Object.

Überprüfen von system32 nach kompatiblen integrierten Modulen unter Windows

Im Update 1809 für Windows 10 und im Update für Windows Server 2019 wurden eine Reihe von integrierten PowerShell-Modulen aktualisiert, um sie als mit PowerShell kompatibel zu kennzeichnen.

Beim Starten von PowerShell wird automatisch $windir\System32 als Teil der PSModulePath-Umgebungsvariable mit einbezogen. Allerdings werden Module nur dann Get-Module und Import-Module verfügbar gemacht, wenn CompatiblePSEdition als kompatibel mit Core gekennzeichnet ist.

Mit dem Switch-Parameter -SkipEditionCheck können Sie dieses Verhalten so überschreiben, dass alle Module angezeigt werden. Außerdem wurde der Tabellenausgabe eine PSEdition-Eigenschaft hinzugefügt.

-lp-Alias für alle -LiteralPath-Parameter

Wir haben einen Standardparameteralias -lp für alle integrierten PowerShell-Cmdlets erstellt, die einen -LiteralPath-Parameter aufweisen.

Korrigieren von Get-Item -LiteralPath a*b, wenn a*b nicht vorhanden ist, um Fehler zurückzugeben

Zuvor wurde ein -LiteralPath-Cmdlet im Hintergrund beendet, wenn ein Platzhalter es wie -Path behandelt und dieser keine Dateien findet. Korrekterweise sollte -LiteralPath ein Literal sein, sodass ein Fehler angezeigt wird, wenn die Datei nicht vorhanden ist. Die Änderung besteht darin, dass Platzhalter, die mit -Literal verwendet werden, als Literal behandelt werden.

Festlegung des Arbeitsverzeichnisses auf das aktuelle Verzeichnis in Start-Job

Das Start-Job-Cmdlet verwendet jetzt das aktuelle Verzeichnis als Arbeitsverzeichnis für den neuen Auftrag.

Entfernung von -Protocol aus *-Computer-Cmdlets

Aufgrund von Problemen mit dem RPC-Remoting in CoreFX (insbesondere auf anderen Plattformen als Windows) und zur Gewährleistung einer konsistenten Remotingumgebung in PowerShell wurde der Parameter -Protocol aus den \*-Computer-Cmdlets entfernt. DCOM wird für das Remoting nicht mehr unterstützt. Die folgenden Cmdlets unterstützen nur das WSMAN-Remoting:

• Rename-Computer
• Restart-Computer
• Stop-Computer

Entfernung von -ComputerName aus *-Service-Cmdlets

Der Parameter -ComputerName wurde aus *-Service-Cmdlets entfernt, um die konsistente Verwendung von PSRP zu fördern.

Get-Content -Delimiter sollte kein Trennzeichen in den zurückgegebenen Zeilen enthalten

Zuvor war die Ausgabe bei der Verwendung von Get-Content -Delimiter inkonsistent und unpraktisch, da weitere Verarbeitung der Daten erforderlich ist, um das Trennzeichen zu entfernen. Durch diese Änderung wird das Trennzeichen aus den zurückgegebenen Zeilen entfernt.

Änderungen an Format-Hex

Der Parameter -Raw ist nun kein Vorgang mehr (d.h. er führt keine Aktion aus). In Zukunft werden alle Ausgaben mit einer echten Darstellung von Zahlen angezeigt, die alle Bytes des jeweiligen Typs enthält. Dies war die Aufgabe des -Raw-Parameters vor dieser Änderung.

Behebung eines Tippfehlers im Eigenschaftenname von Get-ComputerInfo

BiosSerialNumber wurde fälschlicherweise als BiosSeralNumber geschrieben und wurde in die richtige Schreibweise geändert.

Hinzufügen der Cmdlets Get-StringHash und Get-FileHash

Diese Änderung besteht darin, dass einige Hashalgorithmen von CoreFX nicht unterstützt werden und deshalb nicht mehr verfügbar sind.

• MACTripleDES
• RIPEMD160

Hinzufügung der Überprüfung von Get-*-Cmdlets, wenn mein Übergeben von „$null“ alle Objekte statt eines Fehlers zurückgegeben werden

Das Übergeben von $null an eines der folgenden Cmdlets löst nun einen Fehler aus:

• Get-Credential -UserName
• Get-Event -SourceIdentifier
• Get-EventSubscriber -SourceIdentifier
• Get-Help -Name
• Get-PSBreakpoint -Script
• Get-PSProvider -PSProvider
• Get-PSSessionConfiguration -Name
• Get-Runspace -Name
• Get-RunspaceDebug -RunspaceName
• Get-Service -Name
• Get-TraceSource -Name
• Get-Variable -Name

Unterstützung für das erweiterte W3C-Protokolldateiformat in Import-Csv hinzugefügt

Zuvor konnte das Cmdlet Import-Csv nicht verwendet werden, um die Protokolldateien direkt im erweiterten W3C-Protokollformat zu importieren. Hierfür waren zusätzliche Aktionen erforderlich. Durch diese Änderung wird das erweiterte W3C-Protokollformat unterstützt.

Import-Csv wendet PSTypeNames beim Import an, wenn die Typinformationen in der CSV-Datei vorhanden sind

Zuvor behielten exportierte Objekte, die Export-CSV mit TypeInformation verwenden und mit ConvertFrom-Csv importiert wurden, die Typinformationen nicht bei. Durch diese Änderung werden die Typinformationen zum Member PSTypeNames hinzugefügt, wenn Sie in der CSV-Datei vorhanden sind.

-NoTypeInformation ist der Standardwert bei Export-Csv

Zuvor gab das Cmdlet Export-CSV einen Kommentar als erste Zeile aus, der den Typnamen des Objekts enthielt. Die Änderung schließt die Typinformationen standardmäßig aus, da sie von den meisten CSV-Tools nicht verstanden werden. Diese Änderung wurde aufgrund des Feedbacks von Kunden vorgenommen.

Verwenden Sie -IncludeTypeInformation, um das vorherigen Verhalten beizubehalten.

* kann jetzt im Registrierungspfad für Remove-Item verwendet werden

Zuvor wurde ein -LiteralPath-Cmdlet im Hintergrund beendet, wenn ein Platzhalter es wie -Path behandelt und dieser keine Dateien findet. Korrekterweise sollte -LiteralPath ein Literal sein, sodass ein Fehler angezeigt wird, wenn die Datei nicht vorhanden ist. Die Änderung besteht darin, dass Platzhalter, die mit -Literal verwendet werden, als Literal behandelt werden.

Group-Object sortiert jetzt die Gruppen

Im Rahmen der Leistungsverbesserung gibt Group-Object jetzt eine sortierte Auflistung der Gruppen zurück. Obwohl Sie sich auf die Reihenfolge nicht verlassen sollten, könnte diese Änderung zu einer Teilung führen, wenn Sie die erste Gruppe anzeigen möchten. Wir haben entschieden, dass diese Leistungsverbesserung die Änderung wert wäre, weil sich die Abhängigkeit vom früheren Verhalten nur geringfügig auswirkt.

Standardabweichung in Measure-Object

Die Ausgabe von Measure-Object enthält jetzt eine StandardDeviation-Eigenschaft.

Get-Process | Measure-Object -Property CPU -AllStats

Count             : 308
Average           : 31.3720576298701
Sum               : 9662.59375
Maximum           : 4416.046875
Minimum           :
StandardDeviation : 264.389544720926
Property          : CPU

Get-PfxCertificate -Password

Get-PfxCertificate verfügt jetzt über den Password-Parameter, der ein SecureString übernimmt. Dadurch kann er ohne Benutzereingriff verwendet werden:

$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '

$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint

Entfernen der more-Funktion

Bisher enthielt PowerShell unter Windows eine Funktion mit dem Namen more, die more.com mit einschloss. Diese Funktion wurde nun entfernt.

Zudem wurde die help-Funktion so geändert, dass unter Windows more.com verwendet wird bzw. auf anderen Plattformen der unter $env:PAGER angegebene Standardpager des Systems.

Zurückleiten der Benutzer zum aktuellen Arbeitsverzeichnis im Laufwerk mit cd DriveName:

Bisher wurden Benutzer zum Standardspeicherort für das Laufwerk geleitet, wenn sie mit Set-Location oder cd zu einem PowerShell-Laufwerk (PSDrive) zurückkehren wollten. Benutzer werden jetzt zum letzten bekannten aktuellen Arbeitsverzeichnis für die jeweilige Sitzung geleitet.

Zurück zum vorherigen Verzeichnis mit cd -

C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>

Oder unter Linux:

PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>

cd und cd -- wechseln auch zu $HOME.

Update-Help als Nicht-Administrator

Aufgrund der großen Nachfrage muss nun Update-Help nicht mehr als Administrator ausgeführt werden. Über Update-Help wird die Hilfe jetzt standardmäßig in einen benutzerdefinierten Ordner gespeichert.

Where-Object -Not

Durch das Hinzufügen des -Not-Parameters zu Where-Object können Sie ein Objekt in der Pipeline nach dem Nichtvorhandensein einer Eigenschaft oder eines leeren oder NULL-Eigenschaftswerts filtern.

Dieser Befehl gibt z.B. alle Dienste zurück, die über keine definierten abhängigen Dienste verfügen:

Get-Service | Where-Object -Not DependentServices

Änderungen an Web-Cmdlets

Die zugrunde liegende .NET-API der Web-Cmdlets wurde in System.Net.Http.HttpClient geändert. Diese Änderung bietet viele Vorteile. Diese Änderung führte jedoch zusammen mit der mangelnden Interoperabilität mit Internet Explorer dazu, dass einige Breaking Changes in Invoke-WebRequest und Invoke-RestMethod auftraten.

• Invoke-WebRequest unterstützt nun ausschließlich die grundlegende HTML-Analyse. Invoke-WebRequest gibt immer ein BasicHtmlWebResponseObject-Objekt zurück. Die Eigenschaften ParsedHtml und Forms wurden entfernt.
• Die BasicHtmlWebResponseObject.Headers-Werte entsprechen nun String[] statt String.
• BasicHtmlWebResponseObject.BaseResponse ist nun ein System.Net.Http.HttpResponseMessage-Objekt.
• Die Response-Eigenschaft von Web-Cmdlet-Ausnahmen ist nun ein System.Net.Http.HttpResponseMessage-Objekt.
• Die strenge RFC-Headeranalyse wird nun standardmäßig für den -Headers- und -UserAgent-Parameter durchgeführt. Dies kann mit -SkipHeaderValidation umgangen werden.
• Die URI-Schemas file:// und ftp:// werden nicht mehr unterstützt.
• Die System.Net.ServicePointManager-Einstellungen werden nicht mehr berücksichtigt.
• Derzeit ist keine zertifikatbasierte Authentifizierung unter macOS verfügbar.
• Das Verwenden eines -Credential- statt einem http://-URI führt zu einem Fehler. Verwenden Sie einen https://-URI, oder geben Sie den -AllowUnencryptedAuthentication-Parameter an, um den Fehler zu unterdrücken.
• -MaximumRedirection erzeugt nun einen Fehler mit Abbruch, wenn Umleitungsversuche die angegebene Grenze überschreiten, anstatt die Ergebnisse der letzten Umleitung zurückzugeben.
• In PowerShell 6.2 wurde eine Änderung an der standardmäßigen UTF-8-Codierung für JSON-Antworten vorgenommen. Wenn für eine JSON-Antwort kein Zeichensatz angegeben wird, muss die Standardcodierung gemäß RFC 8259 UTF-8 lauten.
• Standardcodierung für application-json-Antworten auf UTF-8 festgelegt
• Hinzufügen des -SkipHeaderValidation-Parameters zum Zulassen von Content-Type-Headern, die nicht mit den Standards kompatibel sind
• Hinzufügen des -Form-Parameters zur Unterstützung von vereinfachter multipart/form-data-Unterstützung
• Kompatible Verarbeitung von Beziehungsschlüsseln ohne Beachtung der Groß-/Kleinschreibung
• Hinzufügen des -Resume-Parameters zu Web-Cmdlets

„Invoke-RestMethod“ gibt nützliche Informationen zurück, wenn keine Daten zurückgegeben werden

Wenn eine API nur null zurückgibt, hat Invoke-RestMethod dies als die Zeichenfolge "null" statt $null serialisiert. Diese Änderung korrigiert die Logik in Invoke-RestMethod, um das gültige JSON-Literal mit Einzelwert null ordnungsgemäß als $null zu serialisieren.

Web-Cmdlets geben eine Warnung aus, wenn -Credential über nicht verschlüsselte Verbindungen gesendet wird

Bei der Verwendung von HTTP werden Inhalte mit Kennwörtern als Klartext gesendet. Durch diese Änderung wird dies standardmäßig nicht zugelassen, außerdem wird ein Fehler zurückgegeben, wenn Anmeldeinformationen auf unsichere Weise weitergeleitet werden. Die Benutzer können dies umgehen, indem Sie den Parameter -AllowUnencryptedAuthentication verwenden.

Dafür sorgen, dass -OutFile-Parameter in Web-Cmdlets wie -LiteralPath funktionieren

Ab PowerShell 7.1 funktioniert der OutFile-Parameter der Web-Cmdlets wie LiteralPath und verarbeitet keine Platzhalter.

API-Änderungen

Entfernung der AddTypeCommandBase-Klasse

Die AddTypeCommandBase-Klasse wurde aus Add-Type entfernt, um die Leistung zu verbessern. Diese Klasse wird nur vom Cmdlet Add-Type verwendet, sodass es keine Auswirkungen auf die Benutzer geben sollte.

VisualBasic als unterstützte Sprache in Add-Type entfernt

Bisher konnte Visual Basic-Code mit dem Add-Type-Cmdlet kompiliert werden. Visual Basic wurde jedoch nur selten mit Add-Type verwendet. Daher wurde diese Funktion nun entfernt, um die Größe von PowerShell zu reduzieren.

Entfernung der Unterstützung von RunspaceConfiguration

Zuvor konnten Sie bei der programmgesteuerten Erstellung eines PowerShell-Runspaces mithilfe der API die veraltete Klasse RunspaceConfiguration oder die neueren InitialSessionState-Klassen verwenden. Durch diese Änderung wurde die Unterstützung für RunspaceConfiguration entfernt, sodass nur noch InitialSessionState unterstützt wird.

CommandInvocationIntrinsics.InvokeScript bindet Argumente an $input anstatt an $args

Die falsche Position eines Parameters führte dazu, dass die Argumente als Eingabe statt als Argumente übergeben wurden.

Entfernung von ClrVersion- und BuildVersion-Eigenschaften aus $PSVersionTable

Die ClrVersion-Eigenschaft von $PSVersionTable ist bei CoreCLR nicht hilfreich. Endbenutzer sollten diesen Wert nicht verwenden, um die Kompatibilität zu bestimmen.

Die BuildVersion-Eigenschaft war an die Windows-Buildversion gebunden, die auf Nicht-Windows-Plattformen nicht verfügbar ist. Verwenden Sie die GitCommitId-Eigenschaft, um die genaue Buildversion von PowerShell abzurufen.

Implementierung der Analyse von Unicode-Escapesequenzen

`u#### oder `u{####} wird in das entsprechende Unicode-Zeichen konvertiert. Verwenden Sie das Hochkommazeichen ( ``u), um ein Literal ( `u) auszugeben.

Problem mit der Bindung von Parametern mit ValueFromRemainingArguments in PowerShell-Funktionen

ValueFromRemainingArguments gibt nun die Werte als Array statt als Einzelwert, der ein Array darstellt, zurück.

Verwendung von CommandTypes.Workflow und WorkflowInfoCleaned bereinigt

Bereinigen Sie Code in Bezug auf die Verwendung von CommandTypes.Workflow und WorkflowInfo in System.Management.Automation.

Diese geringfügigen Breaking Changes betreffen hauptsächlich den Code der Hilfeanbieter.

• Ändern Sie die öffentlichen Konstruktoren von WorkflowInfo in „internal“. Wir unterstützen den Workflow nicht mehr, sodass es sinnvoll ist, das Erstellen von Workflow-Instanzen zu unterbinden.
• Entfernen Sie den Typ System.Management.Automation.DebugSource, da er nur für das Debuggen von Workflows verwendet wird.
• Entfernen Sie die Überladung von SetParent aus dem Debugger der abstrakten Klasse, der nur für das Debuggen von Workflows verwendet wird.
• Entfernen Sie dieselbe Überladung von SetParent aus der abgeleiteten Klasse RemotingJobDebugger.

Zurückgegebenes Ergebnis nicht in PSObject umschließen, wenn ScriptBlock in einen Delegaten konvertiert wird

Wenn ScriptBlock in einen Delegattyp konvertiert wird, der im C#-Kontext verwendet werden soll, führt das Umschließen des Ergebnisses in PSObject zu unnötigen Problemen:

• Wenn der Wert in den Rückgabetyp des Delegaten konvertiert wird, wird PSObject im Wesentlichen entpackt. PSObject ist daher nicht erforderlich.
• Wenn der Rückgabetyp des Delegaten object ist, wird er in PSObject umschlossen, was die Verwendung in C#-Code erschwert.

Nach dieser Änderung entspricht das zurückgegebene Objekt dem zugrunde liegenden Objekt.

Unterstützung für das Remoting

PowerShell-Remoting (PSRP) mit WinRM auf Unix-Plattformen erfordert NTLM/Negotiate oder die Standardauthentifizierung über HTTPS. PSRP unter macOS unterstützt nur die Standardauthentifizierung über HTTPS. Die Kerberos-basierte Authentifizierung wird für Nicht-Windows-Plattformen nicht unterstützt.

PowerShell unterstützt das PowerShell-Remoting (PSRP) ebenfalls auf allen Plattformen (Windows, macOS, Linux) über SSH. Weitere Informationen finden Sie unter SSH-Remoting in PowerShell.

PowerShell Direct für Container versucht zunächst pwsh zu verwenden

PowerShell Direct ist eine Funktion von PowerShell und Hyper-V, mit der Sie ohne Netzwerkverbindung oder einem anderen Remoteverwaltungsdienst eine Verbindung zu einem virtuellen Hyper-V-Computer oder Container herstellen können.

Bisher wurde die Verbindung von PowerShell Direct mithilfe der integrierten Windows PowerShell-Instanz im Container hergestellt. Nun versucht PowerShell Direct zunächst, verfügbare pwsh.exe-Dateien der PATH-Umgebungsvariable dafür zu verwenden. Ist pwsh.exe nicht verfügbar, greift PowerShell Direct wieder auf powershell.exe zurück.

Enable-PSRemoting erstellt jetzt separate Remotingendpunkte für Vorschauversionen

Enable-PSRemoting erstellt jetzt zwei Konfigurationen für Remotesitzungen:

• Eine für die Hauptversion von PowerShell, Beispiel: PowerShell.6. Auf diesen Endpunkt kann nach geringfügigen Aktualisierungen als systemweite Sitzungskonfiguration von PowerShell 6 zurückgegriffen werden.
• Eine versionsspezifische Sitzungskonfiguration, z.B. PowerShell.6.1.0.

Dieses Verhalten ist hilfreich, wenn Sie mehrere Versionen von PowerShell 6 auf einem Computer installiert und zugänglich haben möchten.

Darüber hinaus verfügen Vorschauversionen von PowerShell nun über eigene Remotesitzungskonfigurationen, wenn Sie das Enable-PSRemoting-Cmdlet ausgeführt haben:

C:\WINDOWS\system32> Enable-PSRemoting

Die Ausgabe sieht möglicherweise anders aus, wenn Sie nicht zuvor WinRM eingerichtet haben.

WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.

In diesem Fall werden möglicherweise separate PowerShell-Sitzungskonfigurationen für die Vorschau und stabile Builds von PowerShell 6 sowie für jede einzelne Version angezeigt.

Get-PSSessionConfiguration

Name          : PowerShell.6.2-preview.1
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : PowerShell.6-preview
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6.1.0
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Für SSH unterstützte user@host:port-Syntax

SSH-Clients unterstützen in der Regel eine Verbindungszeichenfolge im Format user@host:port. Durch das Hinzufügen von SSH als Protokoll für PowerShell-Remoting ist nun Unterstützung für dieses Format der Verbindungszeichenfolge enthalten:

Enter-PSSession -HostName fooUser@ssh.contoso.com:2222

Deaktivieren von Telemetrie nur mit einer Umgebungsvariable

PowerShell sendet beim Starten grundlegende Telemetriedaten an Microsoft. Diese enthalten den Namen und die Version des Betriebssystems sowie die Version von PowerShell. Dadurch wird erkennbar, in welchen Umgebungen PowerShell verwendet wird und welche neuen Funktionen und Problembehebungen Vorrang haben sollten.

Wenn Sie diese Telemetriedaten nicht senden möchten, legen Sie die Umgebungsvariable POWERSHELL_TELEMETRY_OPTOUT auf true, yes oder 1 fest. Die Datei DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY wird zum Deaktivieren der Telemetrie nicht mehr unterstützt.