about_Preference_Variables

Kurze Beschreibung

Variablen, die das Verhalten von PowerShell anpassen.

Lange Beschreibung

PowerShell enthält eine Reihe von Variablen, mit denen Sie das Verhalten anpassen können. Diese Einstellungsvariablen funktionieren wie die Optionen in GUI-basierten Systemen.

Die Einstellungsvariablen wirken sich auf die PowerShell-Betriebssystemumgebung aus, und alle Befehle werden in der Umgebung ausgeführt. Einige Cmdlets verfügen über Parameter, mit denen Sie das Einstellungsverhalten für einen bestimmten Befehl außer Kraft setzen können.

In der folgenden Tabelle sind die Einstellungsvariablen und deren Standardwerte aufgeführt.

Variable	Standardwert
$ConfirmPreference	High
$DebugPreference	SilentlyContinue
$ErrorActionPreference	Continue
$ErrorView	ConciseView
$FormatEnumerationLimit	4
$InformationPreference	SilentlyContinue
$LogCommandHealthEvent	$false (nicht protokolliert)
$LogCommandLifecycleEvent	$false (nicht protokolliert)
$LogEngineHealthEvent	$true (protokolliert)
$LogEngineLifecycleEvent	$true (protokolliert)
$LogProviderHealthEvent	$true (protokolliert)
$LogProviderLifecycleEvent	$true (protokolliert)
$MaximumHistoryCount	4096
$OFS	Leerzeichen (" ")
$OutputEncoding	UTF8Encoding-Objekt
$ProgressPreference	Continue
$PSDefaultParameterValues	@{} (leere Hashtabelle)
$PSEmailServer	$null (keine)
$PSModuleAutoLoadingPreference	All
$PSNativeCommandArgumentPassing	Windows unter Windows, Standard unter Nicht-Windows
$PSNativeCommandUseErrorActionPreference	$false
$PSSessionApplicationName	'wsman'
$PSSessionConfigurationName	'http://schemas.microsoft.com/powershell/Microsoft.PowerShell'
$PSSessionOption	PSSessionOption-Objekt
$PSStyle	PSStyle-Objekt
$Transcript	$null (keine)
$VerbosePreference	SilentlyContinue
$WarningPreference	Continue
$WhatIfPreference	$false

PowerShell enthält die folgenden Umgebungsvariablen, die Benutzereinstellungen speichern. Weitere Informationen zu diesen Umgebungsvariablen finden Sie unter about_Environment_Variables.

• $env:PSExecutionPolicyPreference
• $env:PSModulePath

Hinweis

Änderungen an Einstellungsvariablen gelten nur für den Bereich, den sie vornehmen, und alle untergeordneten Bereiche davon. Sie können beispielsweise die Auswirkungen des Änderns einer Einstellungsvariablen auf eine einzelne Funktion oder ein Skript beschränken. Weitere Informationen finden Sie unter about_Scopes.

Arbeiten mit Einstellungsvariablen

In diesem Dokument werden die einzelnen Einstellungsvariablen beschrieben.

Geben Sie den Namen der Variablen ein, um den aktuellen Wert einer bestimmten Einstellungsvariable anzuzeigen. Der folgende Befehl zeigt z. B. den Wert der $ConfirmPreference Variablen an.

 $ConfirmPreference

High

Verwenden Sie zum Ändern des Werts einer Variablen eine Zuordnungsanweisung. Die folgende Anweisung ändert z. B. den Wert des $ConfirmPreference Parameters in "Medium".

$ConfirmPreference = "Medium"

Die von Ihnen festgelegten Werte sind spezifisch für die aktuelle PowerShell-Sitzung. Um Variablen in allen PowerShell-Sitzungen effektiv zu machen, fügen Sie sie ihrem PowerShell-Profil hinzu. Weitere Informationen finden Sie unter about_Profiles.

Remotearbeit

Wenn Sie Befehle auf einem Remotecomputer ausführen, unterliegen die Remotebefehle nur den Im PowerShell-Client des Remotecomputers festgelegten Einstellungen. Wenn Sie beispielsweise einen Remotebefehl ausführen, bestimmt der Wert der Variablen des Remotecomputers $DebugPreference , wie PowerShell auf das Debuggen von Nachrichten reagiert.

Weitere Informationen zu Remotebefehlen finden Sie unter about_Remote.

$ConfirmPreference

Bestimmt, ob PowerShell Sie vor dem Ausführen eines Cmdlets oder einer Funktion automatisch zur Bestätigung auffordert.

Die $ConfirmPreference Variable verwendet einen der ConfirmImpact Enumerationswerte: "Hoch", "Mittel", "Niedrig" oder "None".

Cmdlets und Funktionen werden einem Risiko von "Hoch", "Mittel" oder "Niedrig" zugewiesen. Wenn der Wert der $ConfirmPreference Variablen kleiner oder gleich dem Risiko ist, das einem Cmdlet oder einer Funktion zugewiesen ist, fordert PowerShell Sie automatisch zur Bestätigung auf, bevor Sie das Cmdlet oder die Funktion ausführen. Weitere Informationen zum Zuweisen eines Risikos zu Cmdlets oder Funktionen finden Sie unter about_Functions_CmdletBindingAttribute.

Wenn der Wert der $ConfirmPreference Variablen "None" lautet, fordert PowerShell Sie nie automatisch auf, bevor Sie ein Cmdlet oder eine Funktion ausführen.

Wenn Sie das Bestätigungsverhalten für alle Cmdlets und Funktionen in der Sitzung ändern möchten, ändern Sie $ConfirmPreference den Wert der Variablen.

Verwenden Sie den Confirm-Parameter eines Cmdlets oder einer Funktion, um den $ConfirmPreference Parameter "Confirm" eines Cmdlets außer Kraft zu setzen. Um eine Bestätigung anzufordern, verwenden Sie -Confirm. Um die Bestätigung zu unterdrücken, verwenden Sie -Confirm:$false.

Gültige Werte von $ConfirmPreference:

• Keine: PowerShell fordert nicht automatisch auf. Verwenden Sie den Parameter "Confirm" des Cmdlets oder der Funktion, um die Bestätigung eines bestimmten Befehls anzufordern.
• Niedrig: PowerShell fordert vor dem Ausführen von Cmdlets oder Funktionen mit geringem, mittlerem oder hohem Risiko zur Bestätigung auf.
• Mittel: PowerShell fordert vor dem Ausführen von Cmdlets oder Funktionen mit einem mittleren oder hohen Risiko zur Bestätigung auf.
• Hoch: PowerShell fordert vor dem Ausführen von Cmdlets oder Funktionen mit hohem Risiko zur Bestätigung auf.

Ausführliche Erläuterung

PowerShell kann Sie automatisch zur Bestätigung auffordern, bevor Sie eine Aktion ausführen. Wenn z. B. das Cmdlet oder die Funktion das System erheblich beeinflusst, um Daten zu löschen oder eine erhebliche Menge von Systemressourcen zu verwenden.

Remove-Item -Path C:\file.txt

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\file.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"):

Die Schätzung des Risikos ist ein Attribut des Cmdlets oder der Funktion, das als ConfirmImpact bezeichnet wird. Benutzer können sie nicht ändern.

Cmdlets und Funktionen, die möglicherweise ein Risiko für das System darstellen, weisen einen Confirm-Parameter auf, den Sie verwenden können, um eine Bestätigung für einen einzelnen Befehl anzufordern oder zu unterdrücken.

Die meisten Cmdlets und Funktionen behalten den Standardwert von Medium für ConfirmImpact bei. $ConfirmPreference ist standardmäßig auf "Hoch " festgelegt. Daher ist es selten, dass Befehle automatisch zur Bestätigung auffordern, wenn Benutzer den Parameter "Confirm " nicht angeben. Um die automatische Bestätigungsaufforderung auf weitere Cmdlets und Funktionen zu erweitern, legen Sie den Wert auf $ConfirmPreference "Mittel" oder "Niedrig" fest.

Beispiele

In diesem Beispiel wird der Effekt des Standardwerts der $ConfirmPreference Variablen " Hoch" gezeigt. Der Wert "Hoher Wert" bestätigt nur Cmdlets und Funktionen mit hohem Risiko. Da die meisten Cmdlets und Funktionen mittleres Risiko darstellen, werden sie nicht automatisch bestätigt und Remove-Item gelöscht. Durch Hinzufügen -Confirm zu den Eingabeaufforderungen wird der Benutzer zur Bestätigung aufgefordert.

$ConfirmPreference

High

Remove-Item -Path C:\temp1.txt

Wird -Confirm verwendet, um eine Bestätigung anzufordern.

Remove-Item -Path C:\temp2.txt -Confirm

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\temp2.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All
[?] Help (default is "Y"):

Das folgende Beispiel zeigt die Auswirkung des Änderns des Werts von $ConfirmPreference "Mittel" in "Mittel". Da die meisten Cmdlets und Funktionen mittleres Risiko darstellen, werden sie automatisch bestätigt. Um die Bestätigungsaufforderung für einen einzelnen Befehl zu unterdrücken, verwenden Sie den Parameter Confirm mit einem Wert von $false.

$ConfirmPreference = "Medium"
Remove-Item -Path C:\temp2.txt

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\temp2.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All
[?] Help (default is "Y"):

Remove-Item -Path C:\temp3.txt -Confirm:$false

$DebugPreference

Bestimmt, wie PowerShell auf das Debuggen von Nachrichten reagiert, die von einem Skript, Cmdlet oder Anbieter oder von einem Write-Debug Befehl in der Befehlszeile generiert werden.

Die $DebugPreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Einige Cmdlets zeigen Debugmeldungen an, die in der Regel technische Meldungen für Programmierer und technische Supportmitarbeiter sind. Das Debuggen von Nachrichten wird standardmäßig nicht angezeigt, Sie können jedoch Debuggingmeldungen anzeigen, indem Sie den Wert von $DebugPreferenceändern.

Sie können den allgemeinen Debug-Parameter eines Cmdlets verwenden, um die Debugmeldungen für einen bestimmten Befehl anzuzeigen oder auszublenden. Weitere Informationen findest du unter about_CommonParameters.

Die folgenden Werte sind gültig:

• Break – Geben Sie den Debugger ein, wenn ein Fehler auftritt oder wenn eine Ausnahme ausgelöst wird.
• Stopp: Zeigt die Debugmeldung an und beendet die Ausführung. Schreibt einen Fehler in die Konsole.
• Inquire: Zeigt die Debugmeldung an und fragt Sie, ob Sie den Vorgang fortsetzen möchten.
• Fortfahren: Zeigt die Debugmeldung an und wird mit der Ausführung fortgesetzt.
• SilentlyContinue: (Standard) Kein Effekt. Die Debugmeldung wird nicht angezeigt, und die Ausführung wird ohne Unterbrechung fortgesetzt.

Wenn der Befehl zum Generieren einer Debugmeldung konfiguriert ist, ändert das Hinzufügen des allgemeinen Debugparameters zu einem Befehl den Wert der $DebugPreference Variablen in "Weiter".

Beispiele

In den folgenden Beispielen wird gezeigt, wie sich die Werte $DebugPreference ändern, wenn ein Write-Debug Befehl in der Befehlszeile eingegeben wird. Die Änderung wirkt sich auf alle Debugnachrichten aus, einschließlich von Cmdlets und Skripts generierten Nachrichten. Die Beispiele zeigen den Debugparameter , der die Debugmeldungen im Zusammenhang mit einem einzelnen Befehl anzeigt oder ausblendet.

Dieses Beispiel zeigt den Effekt des Standardwerts der $DebugPreference Variablen SilentlyContinue. Standardmäßig wird die Debugmeldung des Write-Debug Cmdlets nicht angezeigt, und die Verarbeitung wird fortgesetzt. Wenn der Debug-Parameter verwendet wird, überschreibt er die Einstellung für einen einzelnen Befehl. Die Debugmeldung wird angezeigt.

$DebugPreference

SilentlyContinue

Write-Debug -Message "Hello, World"

Write-Debug -Message "Hello, World" -Debug

DEBUG: Hello, World

In diesem Beispiel wird der Effekt des Werts $DebugPreference "Weiter" veranschaulicht. Die Debugmeldung wird angezeigt, und der Befehl wird weiterhin verarbeitet.

$DebugPreference = "Continue"
Write-Debug -Message "Hello, World"

DEBUG: Hello, World

In diesem Beispiel wird der Debug-Parameter mit einem Wert verwendet, um $false die Nachricht für einen einzelnen Befehl zu unterdrücken. Die Debugmeldung wird nicht angezeigt.

Write-Debug -Message "Hello, World" -Debug:$false

In diesem Beispiel wird der Effekt $DebugPreference gezeigt, der auf den Stop-Wert festgelegt wird. Die Debugmeldung wird angezeigt, und der Befehl wird beendet.

$DebugPreference = "Stop"
Write-Debug -Message "Hello, World"

DEBUG: Hello, World
Write-Debug : The running command stopped because the preference variable
 "DebugPreference" or common parameter is set to Stop: Hello, World
At line:1 char:1
+ Write-Debug -Message "Hello, World"

In diesem Beispiel wird der Debug-Parameter mit einem Wert verwendet, um $false die Nachricht für einen einzelnen Befehl zu unterdrücken. Die Debugmeldung wird nicht angezeigt, und die Verarbeitung wird nicht beendet.

Write-Debug -Message "Hello, World" -Debug:$false

In diesem Beispiel wird der Effekt $DebugPreference gezeigt, der auf den Inquire-Wert festgelegt wird. Die Debugmeldung wird angezeigt, und der Benutzer wird zur Bestätigung aufgefordert.

$DebugPreference = "Inquire"
Write-Debug -Message "Hello, World"

DEBUG: Hello, World

Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [?] Help (default is "Y"):

In diesem Beispiel wird der Debug-Parameter mit einem Wert verwendet, um $false die Nachricht für einen einzelnen Befehl zu unterdrücken. Die Debugmeldung wird nicht angezeigt, und die Verarbeitung wird fortgesetzt.

Write-Debug -Message "Hello, World" -Debug:$false

$ErrorActionPreference

Bestimmt, wie PowerShell auf einen nicht beendeten Fehler reagiert, ein Fehler, der die Verarbeitung des Cmdlets nicht beendet. Beispielsweise an der Befehlszeile oder in einem Skript, Cmdlet oder Anbieter, z. B. bei den vom Write-Error Cmdlet generierten Fehlern.

Die $ErrorActionPreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Sie können den allgemeinen Parameter "ErrorAction" eines Cmdlets verwenden, um die Einstellung für einen bestimmten Befehl außer Kraft zu setzen.

Die folgenden Werte sind gültig:

• Break – Geben Sie den Debugger ein, wenn ein Fehler auftritt oder wenn eine Ausnahme ausgelöst wird.
• Weiter: (Standard) Zeigt die Fehlermeldung an und führt die Ausführung fort.
• Ignorieren: Unterdrückt die Fehlermeldung und führt den Befehl weiterhin aus. Der Wert "Ignorieren" ist für die Verwendung pro Befehl vorgesehen, nicht für die Verwendung als gespeicherte Einstellung. Ignore ist kein gültiger Wert für die $ErrorActionPreference Variable.
• Inquire: Zeigt die Fehlermeldung an und fragt Sie, ob Sie den Vorgang fortsetzen möchten.
• SilentlyContinue: Kein Effekt. Die Fehlermeldung wird nicht angezeigt, und die Ausführung wird ohne Unterbrechung fortgesetzt.
• Stopp: Zeigt die Fehlermeldung an und beendet die Ausführung. Zusätzlich zum generierten Fehler generiert der Stop-Wert ein ActionPreferenceStopException-Objekt für den Fehlerdatenstrom.
• Anhalten: Hält einen Workflowauftrag automatisch an, um weitere Untersuchungen zu ermöglichen. Nach der Untersuchung kann der Workflow fortgesetzt werden. Der Suspend-Wert ist für die Verwendung pro Befehl vorgesehen, nicht für die Verwendung als gespeicherte Einstellung. Das Anhalten ist kein gültiger Wert für die $ErrorActionPreference Variable.

$ErrorActionPreferenceund der ErrorAction-Parameter wirkt sich nicht darauf aus, wie PowerShell auf Beendigungsfehler reagiert, die die Verarbeitung von Cmdlets beenden. Weitere Informationen zum allgemeinen ErrorAction-Parameter finden Sie unter about_CommonParameters.

Viele native Befehle schreiben in stderr als alternativen Stream für weitere Informationen. Dieses Verhalten kann beim Durchsehen von Fehlern Verwirrung verursachen, oder die zusätzlichen Ausgabeinformationen können für den Benutzer verloren gehen, wenn $ErrorActionPreference auf einen Zustand festgelegt ist, der die Ausgabe unterdrückt.

Ab PowerShell 7.2 werden Fehlereinträge, die von systemeigenen Befehlen umgeleitet werden, z. B. bei Verwendung von Umleitungsoperatoren (2>&1), nicht in die $Error Variable geschrieben, und die Einstellungsvariable $ErrorActionPreference wirkt sich nicht auf die umgeleitete Ausgabe aus.

PowerShell 7.3 hat ein experimentelles Feature hinzugefügt, mit dem Sie steuern können, wie Nachrichten stderr verarbeitet werden.

Weitere Informationen finden Sie unter $PSNativeCommandUseErrorActionPreference.

Beispiele

Diese Beispiele zeigen den Effekt der verschiedenen Werte der $ErrorActionPreference Variablen. Der ErrorAction-Parameter wird verwendet, um den $ErrorActionPreference Wert außer Kraft zu setzen.

Dieses Beispiel zeigt den $ErrorActionPreference Standardwert " Continue". Es wird ein nicht beendeter Fehler generiert. Die Meldung wird angezeigt, und die Verarbeitung wird fortgesetzt.

# Change the ErrorActionPreference to 'Continue'
$ErrorActionPreference = 'Continue'
# Generate a non-terminating error and continue processing the script.
Write-Error -Message  'Test Error' ; Write-Host 'Hello World'

Write-Error: Test Error
Hello World

Dieses Beispiel zeigt den $ErrorActionPreference Standardwert Inquire. Es wird ein Fehler generiert, und es wird eine Aufforderung zur Aktion angezeigt.

# Change the ErrorActionPreference to 'Inquire'
$ErrorActionPreference = 'Inquire'
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'

Confirm
Test Error
[Y] Yes  [A] Yes to All  [H] Halt Command  [S] Suspend  [?] Help (default is "Y"):

Dieses Beispiel zeigt den $ErrorActionPreference Satz auf SilentlyContinue. Die Fehlermeldung wird unterdrückt.

# Change the ErrorActionPreference to 'SilentlyContinue'
$ErrorActionPreference = 'SilentlyContinue'
# Generate an error message
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'
# Error message is suppressed and script continues processing

Hello World

In diesem Beispiel wird der $ErrorActionPreference Satz auf "Stopp" dargestellt. Außerdem wird das zusätzliche Objekt angezeigt, das für die $Error Variable generiert wurde.

# Change the ErrorActionPreference to 'Stop'
$ErrorActionPreference = 'Stop'
# Error message is generated and script stops processing
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'

# Show the ActionPreferenceStopException and the error generated
$Error[0]
$Error[1]

Write-Error: Test Error

ErrorRecord                 : Test Error
WasThrownFromThrowStatement : False
TargetSite                  : System.Collections.ObjectModel.Collection`1[System.Management.Automation.PSObject]
                              Invoke(System.Collections.IEnumerable)
StackTrace                  :    at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
                                 at Microsoft.PowerShell.Executor.ExecuteCommandHelper(Pipeline tempPipeline,
                              Exception& exceptionThrown, ExecutionOptions options)
Message                     : The running command stopped because the preference variable "ErrorActionPreference" or
                              common parameter is set to Stop: Test Error
Data                        : {System.Management.Automation.Interpreter.InterpretedFrameInfo}
InnerException              :
HelpLink                    :
Source                      : System.Management.Automation
HResult                     : -2146233087

Write-Error: Test Error

$ErrorView

Bestimmt das Anzeigeformat von Fehlermeldungen in PowerShell.

Die $ErrorView Variable verwendet einen der ErrorView Enumerationswerte: NormalView, CategoryView oder ConciseView.

Die folgenden Werte sind gültig:

• ConciseView: (Standard) Stellt eine präzise Fehlermeldung und eine umgestaltete Ansicht für erweiterte Modul-Generatoren bereit. Ab PowerShell 7.2 ist der Fehler aus der Befehlszeile oder einem Skriptmodul eine fehlermeldung. Andernfalls erhalten Sie eine mehrzeilige Fehlermeldung, die den Fehler enthält, und einen Zeiger auf den Fehler, der anzeigt, wo er in dieser Zeile auftritt. Wenn das Terminal virtuelles Terminal unterstützt, werden ANSI-Farbcodes verwendet, um Farbakzent bereitzustellen. Die Akzentfarbe kann geändert werden unter $Host.PrivateData.ErrorAccentColor. Verwenden Sie Get-Error das Cmdlet für eine umfassende detaillierte Ansicht des vollqualifizierten Fehlers, einschließlich innerer Ausnahmen.

  ConciseView wurde in PowerShell 7 hinzugefügt.

• NormalView: Eine detaillierte Ansicht, die für die meisten Benutzer entwickelt wurde. Besteht aus einer Beschreibung des Fehlers und dem Namen des Objekts, das am Fehler beteiligt ist.

• CategoryView: Eine prägnante, strukturierte Ansicht, die für Produktionsumgebungen entwickelt wurde. Das Format ist wie folgt:

  {Category}: ({TargetName}:{TargetType}):[{Activity}], {Reason}

Weitere Informationen zu den Feldern in CategoryView finden Sie unter ErrorCategoryInfo-Klasse.

Beispiele

In diesem Beispiel wird gezeigt, wie ein Fehler angezeigt wird, wenn der Wert $ErrorView der Standardeinstellung "ConciseView" ist. Get-ChildItem wird verwendet, um ein nicht vorhandenes Verzeichnis zu finden.

Get-ChildItem -path 'C:\NoRealDirectory'

Get-ChildItem: Can't find path 'C:\NoRealDirectory' because it doesn't exist.

In diesem Beispiel wird gezeigt, wie ein Fehler angezeigt wird, wenn der Wert $ErrorView der Standardeinstellung "ConciseView" ist. Script.ps1 wird ausgeführt und löst einen Fehler aus Get-Item der Anweisung aus.

./Script.ps1

Get-Item: C:\Script.ps1
Line |
  11 | Get-Item -Path .\stuff
     | ^ Can't find path 'C:\demo\stuff' because it doesn't exist.

In diesem Beispiel wird gezeigt, wie ein Fehler angezeigt wird, wenn der Wert von $ErrorView " NormalView" geändert wird. Get-ChildItem wird verwendet, um eine nicht vorhandene Datei zu finden.

Get-ChildItem -Path C:\nofile.txt

Get-ChildItem : Can't find path 'C:\nofile.txt' because it doesn't exist.
At line:1 char:1
+ Get-ChildItem -Path C:\nofile.txt

In diesem Beispiel wird gezeigt, wie derselbe Fehler angezeigt wird, wenn der Wert von $ErrorView " CategoryView" geändert wird.

$ErrorView = "CategoryView"
Get-ChildItem -Path C:\nofile.txt

ObjectNotFound: (C:\nofile.txt:String) [Get-ChildItem], ItemNotFoundException

In diesem Beispiel wird veranschaulicht, dass sich der Wert $ErrorView nur auf die Fehleranzeige auswirkt. Die Struktur des Fehlerobjekts, das in der $Error automatischen Variablen gespeichert ist, wird nicht geändert. Informationen zur $Error automatischen Variablen finden Sie unter about_automatic_variables.

Der folgende Befehl verwendet das ErrorRecord-Objekt , das dem neuesten Fehler im Fehlerarray, Element 0 zugeordnet ist, und formatiert die Eigenschaften des Objekts in einer Liste.

$Error[0] | Format-List -Property * -Force

PSMessageDetails      :
Exception             : System.Management.Automation.ItemNotFoundException:
                          Cannot find path 'C:\nofile.txt' because it does
                          not exist.
                        at System.Management.Automation.SessionStateInternal.
                          GetChildItems(String path, Boolean recurse, UInt32
                          depth, CmdletProviderContext context)
                        at System.Management.Automation.ChildItemCmdlet
                          ProviderIntrinsics.Get(String path, Boolean
                          recurse, UInt32 depth, CmdletProviderContext context)
                        at Microsoft.PowerShell.Commands.GetChildItemCommand.
                          ProcessRecord()
TargetObject          : C:\nofile.txt
CategoryInfo          : ObjectNotFound: (C:\nofile.txt:String) [Get-ChildItem],
                          ItemNotFoundException
FullyQualifiedErrorId : PathNotFound,
                          Microsoft.PowerShell.Commands.GetChildItemCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

$FormatEnumerationLimit

Bestimmt, wie viele aufgezählte Elemente in einer Anzeige enthalten sind. Diese Variable wirkt sich nicht auf die zugrunde liegenden Objekte aus, nur auf die Anzeige. Wenn der Wert kleiner $FormatEnumerationLimit als die Anzahl der aufgezählten Elemente ist, fügt PowerShell eine Auslassungspunkte (...) hinzu, um nicht angezeigte Elemente anzugeben.

Gültige Werte: Ganze Zahlen (Int32)

Standardwert: 4

Beispiele

In diesem Beispiel wird gezeigt, wie Sie die $FormatEnumerationLimit Variable verwenden, um die Anzeige von aufgezählten Elementen zu verbessern.

Der Befehl in diesem Beispiel generiert eine Tabelle, in der alle auf dem Computer ausgeführten Dienste in zwei Gruppen aufgelistet sind: eine für die Ausführung von Diensten und eine für beendete Dienste. Sie verwendet einen Get-Service Befehl, um alle Dienste abzurufen, und sendet dann die Ergebnisse über die Pipeline an das Group-Object Cmdlet, das die Ergebnisse nach dem Dienststatus gruppiert.

Das Ergebnis ist eine Tabelle, die den Status in der Spalte "Name " und die Prozesse in der Spalte "Gruppe " auflistet. Wenn Sie die Spaltenbeschriftungen ändern möchten, verwenden Sie eine Hashtabelle, siehe about_Hash_Tables. Weitere Informationen finden Sie in den Beispielen in "Format-Table".

Suchen Sie den aktuellen Wert von $FormatEnumerationLimit.

$FormatEnumerationLimit

4

Alle Nach Status gruppierten Dienste auflisten. Es gibt maximal vier Dienste, die in der Spalte "Gruppe " für jeden Status aufgelistet sind, da $FormatEnumerationLimit der Wert 4 ist.

Get-Service | Group-Object -Property Status

Count  Name       Group
-----  ----       -----
60     Running    {AdtAgent, ALG, Ati HotKey Poller, AudioSrv...}
41     Stopped    {Alerter, AppMgmt, aspnet_state, ATI Smart...}

Um die Anzahl der aufgelisteten Elemente zu erhöhen, erhöhen Sie den Wert auf $FormatEnumerationLimit 1000. Verwenden Get-Service sie die Dienste und Group-Object zeigen Sie sie an.

$FormatEnumerationLimit = 1000
Get-Service | Group-Object -Property Status

Count  Name       Group
-----  ----       -----
60     Running    {AdtAgent, ALG, Ati HotKey Poller, AudioSrv, BITS, CcmExec...
41     Stopped    {Alerter, AppMgmt, aspnet_state, ATI Smart, Browser, CiSvc...

Wird Format-Table mit dem Wrap-Parameter verwendet, um die Liste der Dienste anzuzeigen.

Get-Service | Group-Object -Property Status | Format-Table -Wrap

Count  Name       Group
-----  ----       -----
60     Running    {AdtAgent, ALG, Ati HotKey Poller, AudioSrv, BITS, CcmExec,
                  Client for NFS, CryptSvc, DcomLaunch, Dhcp, dmserver,
                  Dnscache, ERSvc, Eventlog, EventSystem, FwcAgent, helpsvc,
                  HidServ, IISADMIN, InoRPC, InoRT, InoTask, lanmanserver,
                  lanmanworkstation, LmHosts, MDM, Netlogon, Netman, Nla,
                  NtLmSsp, PlugPlay, PolicyAgent, ProtectedStorage, RasMan,
                  RemoteRegistry, RpcSs, SamSs, Schedule, seclogon, SENS,
                  SharedAccess, ShellHWDetection, SMT PSVC, Spooler,
                  srservice, SSDPSRV, stisvc, TapiSrv, TermService, Themes,
                  TrkWks, UMWdf, W32Time, W3SVC, WebClient, winmgmt, wscsvc,
                  wuauserv, WZCSVC, zzInterix}

41     Stopped    {Alerter, AppMgmt, aspnet_state, ATI Smart, Browser, CiSvc,
                  ClipSrv, clr_optimization_v2.0.50727_32, COMSysApp,
                  CronService, dmadmin, FastUserSwitchingCompatibility,
                  HTTPFilter, ImapiService, Mapsvc, Messenger, mnmsrvc,
                  MSDTC, MSIServer, msvsmon80, NetDDE, NetDDEdsdm, NtmsSvc,
                  NVSvc, ose, RasAuto, RDSessMgr, RemoteAccess, RpcLocator,
                  SCardSvr, SwPrv, SysmonLog, TlntSvr, upnphost, UPS, VSS,
                  WmdmPmSN, Wmi, WmiApSrv, xmlprov}

$InformationPreference

Mit der $InformationPreference Variablen können Sie Die Einstellungen für den Informationsstrom festlegen, die Benutzern angezeigt werden sollen. Insbesondere Informationsmeldungen, die Sie Befehlen oder Skripts hinzugefügt haben, indem Sie das Cmdlet "Write-Information " hinzufügen. Wenn der InformationAction-Parameter verwendet wird, überschreibt der Wert den Wert der $InformationPreference Variablen. Write-Information wurde in PowerShell 5.0 eingeführt.

Die $InformationPreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Die folgenden Werte sind gültig:

• Break – Geben Sie den Debugger ein, wenn Sie in den Informationsdatenstrom schreiben.
• Stopp: Stoppt einen Befehl oder ein Skript an einem Vorkommen des Write-Information Befehls.
• Inquire: Zeigt die Informationsmeldung an, die Sie in einem Write-Information Befehl angeben, und fragt dann, ob Sie den Vorgang fortsetzen möchten.
• Weiter: Zeigt die Informationsmeldung an und wird fortgesetzt.
• SilentlyContinue: (Standard) Kein Effekt. Die Informationsmeldungen werden nicht angezeigt, und das Skript wird ohne Unterbrechung fortgesetzt.

$Log*-Ereignis

Die Log*-Ereigniseinstellungsvariablen bestimmen, welche Ereignistypen in das PowerShell-Ereignisprotokoll in Ereignisanzeige geschrieben werden. Standardmäßig werden nur Modul- und Anbieterereignisse protokolliert. Sie können jedoch die Log*-Ereigniseinstellungsvariablen verwenden, um Ihr Protokoll anzupassen, z. B. das Protokollieren von Ereignissen zu Befehlen.

Die Log*-Ereigniseinstellungsvariablen sind wie folgt:

• $LogCommandHealthEvent: Protokolliert Fehler und Ausnahmen bei der Befehlsinitialisierung und -verarbeitung. Der Standardwert ist $false (nicht protokolliert).
• $LogCommandLifecycleEvent: Protokolliert das Starten und Beenden von Befehlen und Befehlspipelines und Sicherheits exceptions in der Befehlsermittlung. Der Standardwert ist $false (nicht protokolliert).
• $LogEngineHealthEvent: Protokolliert Fehler und Fehler von Sitzungen. Der Standardwert ist $true (protokolliert).
• $LogEngineLifecycleEvent: Protokolliert das Öffnen und Schließen von Sitzungen. Der Standardwert ist $true (protokolliert).
• $LogProviderHealthEvent: Protokolliert Anbieterfehler, z. B. Lese- und Schreibfehler, Nachschlagefehler und Aufruffehler. Der Standardwert ist $true (protokolliert).
• $LogProviderLifecycleEvent: Protokolliert das Hinzufügen und Entfernen von PowerShell-Anbietern. Der Standardwert ist $true (protokolliert). Informationen zu PowerShell-Anbietern finden Sie unter about_Providers.

Um ein Log*-Ereignis zu aktivieren, geben Sie die Variable mit dem Wert " $true, z. B.:

$LogCommandLifeCycleEvent = $true

Um einen Ereignistyp zu deaktivieren, geben Sie die Variable mit dem Wert " $false, z. B.:

$LogCommandLifeCycleEvent = $false

Die von Ihnen aktivierten Ereignisse sind nur für die aktuelle PowerShell-Konsole wirksam. Um die Konfiguration auf alle Konsolen anzuwenden, speichern Sie die Variableneinstellungen in Ihrem PowerShell-Profil. Weitere Informationen finden Sie unter about_Profiles.

$MaximumHistoryCount

Bestimmt, wie viele Befehle im Befehlsverlauf für die aktuelle Sitzung gespeichert werden.

Gültige Werte: 1 - 32768 (Int32)

Standard: 4096

Um die Anzahl der befehle zu bestimmen, die aktuell im Befehlsverlauf gespeichert sind, geben Sie Folgendes ein:

(Get-History).Count

Verwenden Sie das Get-History Cmdlet, um die befehle anzuzeigen, die im Sitzungsverlauf gespeichert wurden. Weitere Informationen finden Sie unter about_History.

$OFS

Das Ausgabefeldtrennzeichen (OUTPUT Field Separator, OFS) gibt das Zeichen an, das die Elemente eines Arrays trennt, das in eine Zeichenfolge konvertiert wird.

Gültige Werte: Eine beliebige Zeichenfolge.

Standard: Leerzeichen

Standardmäßig ist die $OFS Variable nicht vorhanden, und das Ausgabedateitrennzeichen ist leer, Sie können diese Variable jedoch hinzufügen und auf eine beliebige Zeichenfolge festlegen. Sie können den Wert $OFS in Ihrer Sitzung ändern, indem Sie sie eingeben $OFS="<value>".

Hinweis

Wenn Sie den Standardwert eines Leerzeichens (" ") in Ihrer Skript-, Modul- oder Konfigurationsausgabe erwarten, achten Sie darauf, dass der $OFS Standardwert nicht an anderer Stelle im Code geändert wurde.

Beispiele

In diesem Beispiel wird gezeigt, dass ein Leerzeichen verwendet wird, um die Werte zu trennen, wenn ein Array in eine Zeichenfolge konvertiert wird. In diesem Fall wird ein Array ganzzahliger Zahlen in einer Variablen gespeichert, und dann wird die Variable als Zeichenfolge umgewandelt.

$array = 1,2,3,4
[string]$array

1 2 3 4

Um das Trennzeichen zu ändern, fügen Sie die $OFS Variable hinzu, indem Sie ihm einen Wert zuweisen. Die Variable muss benannt $OFSwerden.

$OFS = "+"
[string]$array

1+2+3+4

Um das Standardverhalten wiederherzustellen, können Sie dem Wert der $OFS Variablen ein Leerzeichen (" ") zuweisen oder diese löschen. Die folgenden Befehle löschen die Variable, und stellen Sie dann sicher, dass das Trennzeichen ein Leerzeichen ist.

Remove-Variable OFS
[string]$array

1 2 3 4

$OutputEncoding

Bestimmt die Zeichencodierungsmethode, die PowerShell beim Anfügen von Daten in systemeigene Anwendungen verwendet.

Hinweis

In den meisten Szenarien sollte der Wert für $OutputEncoding den Wert von [Console]::InputEncoding.

Die gültigen Werte sind wie folgt: Objekte, die von einer Encoding-Klasse abgeleitet werden, z. B. ASCIIEncoding, UTF7Encoding, UTF8Encoding, UTF32Encoding und UnicodeEncoding.

Standard: UTF8Encoding-Objekt .

Beispiele

Der erste Befehl findet den Wert von $OutputEncoding. Da es sich bei dem Wert um ein Codierungsobjekt handelt, wird nur dessen EncodingName-Eigenschaft angezeigt.

$OutputEncoding.EncodingName

Die verbleibenden Beispiele verwenden das folgende PowerShell-Skript, das hexdump.ps1 gespeichert wurde, um das Verhalten von $OutputEncoding.

$inputStream = [Console]::OpenStandardInput()
try {
    $buffer = [byte[]]::new(1024)
    $read = $inputStream.Read($buffer, 0, $buffer.Length)
    Format-Hex -InputObject $buffer -Count $read
} finally {
    $inputStream.Dispose()
}

Im folgenden Beispiel wird gezeigt, wie der Zeichenfolgenwert café in Bytes codiert wird, wenn er oben erstellt wurde hexdump.ps1 . Es zeigt, dass der Zeichenfolgenwert mithilfe des UTF8Encoding-Schemas codiert wird.

'café' | pwsh -File ./hexdump.ps1

   Label: Byte[] (System.Byte[]) <28873E25>

          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 63 61 66 C3 A9 0D 0A                            caf�

Das folgende Beispiel zeigt, wie sich die Bytes ändern, wenn die Codierung in UnicodeEncoding geändert wird.

$OutputEncoding = [System.Text.Encoding]::Unicode
'café' | pwsh -File ./hexdump.ps1

   Label: Byte[] (System.Byte[]) <515A7DC3>

          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 FF FE 63 00 61 00 66 00 E9 00 0D 00 0A 00       ÿþc a f é � �

$ProgressPreference

Bestimmt, wie PowerShell auf Statusaktualisierungen reagiert, die von einem Skript, Cmdlet oder Anbieter generiert werden, z. B. auf die Statusanzeigen, die vom Cmdlet Write-Progress generiert werden. Das Write-Progress Cmdlet erstellt Statusanzeigen, die den Status eines Befehls anzeigen.

Die $ProgressPreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Die folgenden Werte sind gültig:

• Unterbrechung : Geben Sie den Debugger ein, wenn Sie in den Statusdatenstrom schreiben.
• Stopp: Zeigt die Statusanzeige nicht an. Stattdessen wird eine Fehlermeldung angezeigt und die Ausführung beendet.
• Inquire: Zeigt die Statusanzeige nicht an. Fordert zum Fortsetzen der Berechtigung auf. Wenn Sie mit Y oder Aantworten, wird die Statusleiste angezeigt.
• Weiter: (Standard) Zeigt die Statusleiste an und setzt die Ausführung fort.
• SilentlyContinue: Führt den Befehl aus, zeigt jedoch nicht die Statusleiste an.

$PSDefaultParameterValues

Gibt Standardwerte für die Parameter von Cmdlets und erweiterten Funktionen an. Der Wert von $PSDefaultParameterValues ist eine Hashtabelle, in der der Schlüssel aus dem Cmdlet-Namen und dem Parameternamen besteht, getrennt durch einen Doppelpunkt (:). Der Wert ist ein benutzerdefinierter Standardwert, den Sie angeben.

$PSDefaultParameterValues wurde in PowerShell 3.0 eingeführt.

Weitere Informationen zu dieser Einstellungsvariable finden Sie unter about_Parameters_Default_Values.

$PSEmailServer

Gibt den Standard-E-Mail-Server an, der zum Senden von E-Mail-Nachrichten verwendet wird. Diese Einstellungsvariable wird von Cmdlets verwendet, die E-Mails senden, z. B. das Cmdlet Send-MailMessage .

$PSModuleAutoloadingPreference

Aktiviert und deaktiviert den automatischen Import von Modulen in der Sitzung. Die $PSModuleAutoloadingPreference Variable ist standardmäßig nicht vorhanden. Das Standardverhalten, wenn die Variable nicht definiert ist, ist identisch mit $PSModuleAutoloadingPreference = 'All'.

Um ein Modul automatisch zu importieren, rufen Oder verwenden Sie einen Befehl, der im Modul enthalten ist.

Die $PSModuleAutoloadingPreference Variable verwendet einen der PSModuleAutoLoadingPreference Enumerationswerte:

• All: Module werden automatisch bei der Erstverwendung importiert.
• ModuleQualified: Module werden automatisch importiert, wenn ein Benutzer den modulqualifizierten Namen eines Befehls im Modul verwendet. Wenn der Benutzer beispielsweise eingibt MyModule\MyCommand, importiert PowerShell das MyModule-Modul .
• None: Deaktiviert den automatischen Import von Modulen. Verwenden Sie das Import-Module Cmdlet, um ein Modul zu importieren.

Weitere Informationen zum automatischen Importieren von Modulen finden Sie unter about_Modules.

$PSNativeCommandArgumentPassing

PowerShell 7.3 hat die Art und Weise geändert, wie sie die Befehlszeile für systemeigene Befehle analysiert. Die neue $PSNativeCommandArgumentPassing Einstellungsvariable steuert dieses Verhalten.

Achtung

Das neue Verhalten ist eine bahnbrechende Änderung des vorherigen Verhaltens. Dadurch kann es geschehen, dass Skripts und Automatisierungen zum Umgehen der verschiedenen Probleme beim Aufrufen nativer Anwendungen nicht mehr funktionieren.

Mit der automatischen Variablen $PSNativeCommandArgumentPassing können Sie das Verhalten zur Laufzeit auswählen. Die gültigen Werte sind Legacy, Standard und Windows. Legacy ist das historische Verhalten.

Die $PSNativeCommandArgumentPassing Variable ist standardmäßig definiert, aber der Wert ist plattformspezifisch.

• Unter Windows ist die Einstellung auf Windows.
• Auf Nicht-Windows-Plattformen ist die Einstellung auf .Standard
• Wenn Sie die $PSNativeCommandArgumentPassing Variable entfernt haben, verwendet PowerShell das Standard Verhalten.

Das Verhalten und Windows Standard der Modus sind identisch, außer im Windows Modus verwendet PowerShell das Legacy Verhalten des Arguments, das übergeben wird, wenn Sie die folgenden Dateien ausführen.

• cmd.exe
• cscript.exe
• find.exe
• sqlcmd.exe
• wscript.exe
• Dateien enden mit:
  • .bat
  • .cmd
  • .js
  • .vbs
  • .wsf

Wenn $PSNativeCommandArgumentPassing auf Legacy oder Standard festgelegt ist, überprüft der Parser keine diese Dateien. Beispiele für das neue Verhalten finden Sie unter about_Parsing.

In PowerShell 7.3 besteht nun auch die Möglichkeit zum Nachverfolgen der Parameterbindung für native Befehle. Weitere Informationen finden Sie unter Trace-Command.

$PSNativeCommandUseErrorActionPreference

Ist $PSNativeCommandUseErrorActionPreference dies $trueder Grund, geben systemeigene Befehle mit Nicht-Null-Beendigungscodes Fehler gemäß $ErrorActionPreference.

Einige systemeigene Befehle, z . B. Robocopy , verwenden Nicht-Null-Exitcodes, um andere Informationen als Fehler darzustellen. In diesen Fällen können Sie das Verhalten vorübergehend deaktivieren und verhindern, dass Nicht-Null-Exitcodes Fehler ausgeben.

& {
    # Disable $PSNativeCommandUseErrorActionPreference for this scriptblock
    $PSNativeCommandUseErrorActionPreference = $false
    robocopy.exe D:\reports\operational "\\reporting\ops" CY2022Q4.md
    if ($LASTEXITCODE -gt 8) {
        throw "robocopy failed with exit code $LASTEXITCODE"
    }
}

In diesem Beispiel wird die $PSNativeCommandUseErrorActionPreference Variable in einem Scriptblock geändert. Die Änderung ist lokal für den Scriptblock. Wenn der Scriptblock beendet wird, wird die Variable auf den vorherigen Wert zurückgesetzt.

$PSSessionApplicationName

Gibt den Standardanwendungsnamen für einen Remotebefehl an, der Webdienste für die Verwaltung (WS-Management)-Technologie verwendet. Weitere Informationen finden Sie unter "Informationen zur Windows-Remoteverwaltung".

Der Standardanwendungsname des Systems lautet WSMAN, Sie können diese Einstellungsvariable jedoch verwenden, um die Standardeinstellung zu ändern.

Der Anwendungsname ist der letzte Knoten in einem Verbindungs-URI. Der Anwendungsname im folgenden Beispiel-URI lautet WSMANz. B. .

http://Server01:8080/WSMAN

Der Standardanwendungsname wird verwendet, wenn der Remotebefehl keinen Verbindungs-URI oder einen Anwendungsnamen angibt.

Der WinRM-Dienst verwendet den Anwendungsnamen, um einen Listener zum Dienst der Verbindungsanforderung auszuwählen. Der Wert des Parameters sollte mit dem Wert der URLPrefix-Eigenschaft eines Listeners auf dem Remotecomputer übereinstimmen.

Um den Systemstandard und den Wert dieser Variablen außer Kraft zu setzen und einen anderen Anwendungsnamen für eine bestimmte Sitzung auszuwählen, verwenden Sie die Parameter "ConnectionURI " oder "ApplicationName " der Cmdlets "New-PSSession", "Enter-PSSession" oder "Invoke-Command ".

Die $PSSessionApplicationName Einstellungsvariable wird auf dem lokalen Computer festgelegt, gibt jedoch einen Listener auf dem Remotecomputer an. Wenn der von Ihnen angegebene Anwendungsname auf dem Remotecomputer nicht vorhanden ist, schlägt der Befehl zum Einrichten der Sitzung fehl.

$PSSessionConfigurationName

Gibt die Standardsitzungskonfiguration an, die zum Erstellen neuer Sitzungen in der aktuellen Sitzung verwendet wird.

Diese Einstellungsvariable wird auf dem lokalen Computer festgelegt, gibt jedoch eine Sitzungskonfiguration an, die sich auf dem Remotecomputer befindet.

Der Wert der $PSSessionConfigurationName Variablen ist ein vollqualifizierter Ressourcen-URI.

Der Standardwert http://schemas.microsoft.com/PowerShell/microsoft.PowerShell gibt die Microsoft.PowerShell-Sitzungskonfiguration auf dem Remotecomputer an.

Wenn Sie nur einen Konfigurationsnamen angeben, wird der folgende Schema-URI vorangestellt:

http://schemas.microsoft.com/PowerShell/

Sie können die Standardeinstellung außer Kraft setzen und eine andere Sitzungskonfiguration für eine bestimmte Sitzung auswählen, indem Sie den ConfigurationName-Parameter der New-PSSessionOder Enter-PSSessionInvoke-Command Cmdlets verwenden.

Sie können den Wert dieser Variablen jederzeit ändern. Denken Sie daran, dass die ausgewählte Sitzungskonfiguration auf dem Remotecomputer vorhanden sein muss. Ist dies nicht der Fehler, schlägt der Befehl zum Erstellen einer Sitzung, die die Sitzungskonfiguration verwendet, fehl.

Diese Einstellungsvariable bestimmt nicht, welche lokalen Sitzungskonfigurationen verwendet werden, wenn Remotebenutzer eine Sitzung erstellen, die eine Verbindung mit diesem Computer herstellt. Sie können jedoch die Berechtigungen für die lokalen Sitzungskonfigurationen verwenden, um zu bestimmen, welche Benutzer sie verwenden können.

$PSSessionOption

Legt die Standardwerte für erweiterte Benutzeroptionen in einer Remotesitzung fest. Diese Optionseinstellungen setzen die Systemstandardwerte für Sitzungsoptionen außer Kraft.

Die $PSSessionOption Variable enthält ein PSSessionOption -Objekt. Weitere Informationen finden Sie unter System.Management.Automation.Remoting.PSSessionOption. Jede Eigenschaft des Objekts stellt eine Sitzungsoption dar. Die NoCompression-Eigenschaft wandelt beispielsweise während der Sitzung die Datenkomprimierung um.

Standardmäßig enthält die $PSSessionOption Variable ein PSSessionOption -Objekt mit den Standardwerten für alle Optionen, wie unten dargestellt.

MaximumConnectionRedirectionCount : 5
NoCompression                     : False
NoMachineProfile                  : False
ProxyAccessType                   : None
ProxyAuthentication               : Negotiate
ProxyCredential                   :
SkipCACheck                       : False
SkipCNCheck                       : False
SkipRevocationCheck               : False
OperationTimeout                  : 00:03:00
NoEncryption                      : False
UseUTF16                          : False
IncludePortInSPN                  : False
OutputBufferingMode               : None
Culture                           :
UICulture                         :
MaximumReceivedDataSizePerCommand :
MaximumReceivedObjectSize         : 209715200
ApplicationArguments              :
OpenTimeout                       : 00:03:00
CancelTimeout                     : 00:01:00
IdleTimeout                       : -00:00:00.0010000

Beschreibungen dieser Optionen und weitere Informationen finden Sie unter New-PSSessionOption. Weitere Informationen zu Remotebefehlen und -sitzungen finden Sie unter about_Remote und about_PSSessions.

Verwenden Sie das New-PSSessionOption Cmdlet, um den Wert der $PSSessionOption Einstellungsvariablen zu ändern, um ein PSSessionOption-Objekt mit den gewünschten Optionswerten zu erstellen. Speichern Sie die Ausgabe in einer Variablen namens $PSSessionOption.

$PSSessionOption = New-PSSessionOption -NoCompression

Um die Einstellungsvariable $PSSessionOption in jeder PowerShell-Sitzung zu verwenden, fügen Sie einen New-PSSessionOption Befehl hinzu, der die $PSSessionOption Variable zu Ihrem PowerShell-Profil erstellt. Weitere Informationen finden Sie unter about_Profiles.

Sie können benutzerdefinierte Optionen für eine bestimmte Remotesitzung festlegen. Die von Ihnen festgelegten Optionen haben Vorrang vor den Systemstandardeinstellungen und dem Wert der $PSSessionOption Einstellungsvariablen.

Verwenden Sie das New-PSSessionOption Cmdlet zum Erstellen eines PSSessionOption-Objekts , um benutzerdefinierte Sitzungsoptionen festzulegen. Verwenden Sie dann das PSSessionOption-Objekt als Wert des SessionOption-Parameters in Cmdlets, die eine Sitzung erstellen, z New-PSSession. B. , Enter-PSSessionund Invoke-Command.

$PSStyle

Ab PowerShell 7.2 können Sie jetzt auf die $PSStyle automatische Variable zugreifen, um das Rendern der ANSI-Zeichenfolgenausgabe anzuzeigen und zu ändern. $PSStyle ist eine Instanz der PSStyle-Klasse . Die Member dieser Klasse definieren Zeichenfolgen, die ANSI-Escapesequenzen enthalten, die das Rendern von Text im Terminal steuern.

Die Basismember geben Zeichenfolgen von ANSI-Escapesequenzen zurück, die ihren Namen zugeordnet sind. Die Werte können beliebig angepasst werden. Die Eigenschaftennamen vereinfachen das Erstellen von verzierten Zeichenfolgen mithilfe des Tabstoppabschlusses. Zum Beispiel:

"$($PSStyle.Background.BrightCyan)Power$($PSStyle.Underline)$($PSStyle.Bold)Shell$($PSStyle.Reset)"

Die Elemente "Hintergrund" und "Vordergrund " verfügen außerdem über eine FromRgb() Methode zum Angeben der 24-Bit-Farbe.

Weitere Informationen zu $PSStyle finden Sie unter about_ANSI_Terminals.

$Transcript

Wird verwendet, Start-Transcript um den Namen und speicherort der Transkriptdatei anzugeben. Wenn Sie keinen Wert für den Path-Parameter angeben, Start-Transcript wird der Pfad im Wert der $Transcript globalen Variablen verwendet. Wenn Sie diese Variable nicht erstellt haben, Start-Transcript werden die Transkriptionen am folgenden Speicherort unter Verwendung des Standardnamens gespeichert:

• Windows: $HOME\Documents
• Unter Linux oder macOS: $HOME

Der Standarddateiname lautet: PowerShell_transcript.<computername>.<random>.<timestamp>.txt.

$VerbosePreference

Bestimmt, wie PowerShell auf ausführliche Nachrichten reagiert, die von einem Skript, Cmdlet oder Anbieter generiert werden, z. B. auf die vom Cmdlet Write-Verbose generierten Nachrichten. Ausführliche Nachrichten beschreiben die Aktionen, die zum Ausführen eines Befehls ausgeführt werden.

Ausführliche Nachrichten werden standardmäßig nicht angezeigt, aber Sie können dieses Verhalten ändern, indem Sie den Wert ändern $VerbosePreference.

Die $VerbosePreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Die folgenden Werte sind gültig:

• Break – Geben Sie den Debugger ein, wenn Sie in den ausführlichen Datenstrom schreiben.
• Stopp: Zeigt die ausführliche Meldung und eine Fehlermeldung an und beendet die Ausführung.
• Inquire: Zeigt die ausführliche Meldung an und zeigt dann eine Eingabeaufforderung an, die Sie fragt, ob Sie fortfahren möchten.
• Weiter: Zeigt die ausführliche Meldung an und setzt dann mit der Ausführung fort.
• SilentlyContinue: (Standard) Zeigt die ausführliche Meldung nicht an. Setzt die Ausführung fort.

Sie können den allgemeinen Parameter "Verbose " eines Cmdlets verwenden, um ausführliche Nachrichten für einen bestimmten Befehl anzuzeigen oder auszublenden. Weitere Informationen findest du unter about_CommonParameters.

Beispiele

Diese Beispiele zeigen den Effekt der verschiedenen Werte und des Verbose-Parameters$VerbosePreference, um den Einstellungswert außer Kraft zu setzen.

In diesem Beispiel wird der Effekt des SilentlyContinue-Werts dargestellt, d. h. der Standardwert. Der Befehl verwendet den Parameter Message , schreibt aber keine Nachricht in die PowerShell-Konsole.

Write-Verbose -Message "Verbose message test."

Wenn der Verbose-Parameter verwendet wird, wird die Nachricht geschrieben.

Write-Verbose -Message "Verbose message test." -Verbose

VERBOSE: Verbose message test.

In diesem Beispiel wird der Effekt des Continue-Werts veranschaulicht. Die $VerbosePreference Variable ist auf "Weiter" festgelegt, und die Meldung wird angezeigt.

$VerbosePreference = "Continue"
Write-Verbose -Message "Verbose message test."

VERBOSE: Verbose message test.

In diesem Beispiel wird der Verbose-Parameter mit einem Wert verwendet, der $false den Continue-Wert überschreibt. Die Nachricht wird nicht angezeigt.

Write-Verbose -Message "Verbose message test." -Verbose:$false

In diesem Beispiel wird der Effekt des Stop-Werts veranschaulicht. Die $VerbosePreference Variable ist auf "Stop" festgelegt, und die Meldung wird angezeigt. Der Befehl wird beendet.

$VerbosePreference = "Stop"
Write-Verbose -Message "Verbose message test."

VERBOSE: Verbose message test.
Write-Verbose : The running command stopped because the preference variable
  "VerbosePreference" or common parameter is set to Stop: Verbose message test.
At line:1 char:1
+ Write-Verbose -Message "Verbose message test."

In diesem Beispiel wird der Verbose-Parameter mit einem Wert verwendet, der $false den Stop-Wert überschreibt. Die Nachricht wird nicht angezeigt.

Write-Verbose -Message "Verbose message test." -Verbose:$false

In diesem Beispiel wird der Effekt des Inquire-Werts veranschaulicht. Die $VerbosePreference Variable ist auf Inquire festgelegt. Die Meldung wird angezeigt, und der Benutzer wird zur Bestätigung aufgefordert.

$VerbosePreference = "Inquire"
Write-Verbose -Message "Verbose message test."

VERBOSE: Verbose message test.

Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [?] Help (default is "Y"):

In diesem Beispiel wird der Verbose-Parameter mit einem Wert verwendet, der $false den Inquire-Wert überschreibt. Der Benutzer wird nicht aufgefordert, und die Nachricht wird nicht angezeigt.

Write-Verbose -Message "Verbose message test." -Verbose:$false

$WarningPreference

Bestimmt, wie PowerShell auf Warnmeldungen reagiert, die von einem Skript, Cmdlet oder Anbieter generiert wurden, z. B. auf die vom Cmdlet "Schreibwarnung " generierten Nachrichten.

Warnmeldungen werden standardmäßig angezeigt, und die Ausführung wird fortgesetzt, Sie können dieses Verhalten jedoch ändern, indem Sie den Wert ändern $WarningPreference.

Die $WarningPreference Variable verwendet einen der ActionPreference Enumerationswerte: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend oder Break.

Die folgenden Werte sind gültig:

• Break – Geben Sie den Debugger ein, wenn eine Warnmeldung geschrieben wird.
• Stopp: Zeigt die Warnmeldung und eine Fehlermeldung an und beendet die Ausführung.
• Inquire: Zeigt die Warnmeldung an und fordert dann die Berechtigung zum Fortsetzen auf.
• Continue: (Default) Displays the warning message and then continue executing.
• SilentlyContinue: Zeigt die Warnmeldung nicht an. Setzt die Ausführung fort.

Sie können den allgemeinen WarningAction-Parameter eines Cmdlets verwenden, um zu bestimmen, wie PowerShell auf Warnungen von einem bestimmten Befehl reagiert. Weitere Informationen findest du unter about_CommonParameters.

Beispiele

Diese Beispiele zeigen den Effekt der verschiedenen Werte von $WarningPreference. Der WarningAction-Parameter setzt den Einstellungswert außer Kraft.

In diesem Beispiel wird der Effekt des Standardwerts " Continue" gezeigt.

$m = "This action can delete data."
Write-Warning -Message $m

WARNING: This action can delete data.

In diesem Beispiel wird der WarningAction-Parameter mit dem Wert SilentlyContinue verwendet, um die Warnung zu unterdrücken. Die Nachricht wird nicht angezeigt.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue

In diesem Beispiel wird die $WarningPreference Variable in den Wert "SilentlyContinue " geändert. Die Nachricht wird nicht angezeigt.

$WarningPreference = "SilentlyContinue"
$m = "This action can delete data."
Write-Warning -Message $m

In diesem Beispiel wird der WarningAction-Parameter verwendet, um zu beenden, wenn eine Warnung generiert wird.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction Stop

WARNING: This action can delete data.
Write-Warning : The running command stopped because the preference variable
  "WarningPreference" or common parameter is set to Stop:
    This action can delete data.
At line:1 char:1
+ Write-Warning -Message $m -WarningAction Stop

In diesem Beispiel wird die $WarningPreference Variable in den Inquire-Wert geändert. Der Benutzer wird zur Bestätigung aufgefordert.

$WarningPreference = "Inquire"
$m = "This action can delete data."
Write-Warning -Message $m

WARNING: This action can delete data.

Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [?] Help (default is "Y"):

In diesem Beispiel wird der WarningAction-Parameter mit dem Wert SilentlyContinue verwendet. Der Befehl wird weiterhin ausgeführt, und es wird keine Meldung angezeigt.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue

In diesem Beispiel wird der $WarningPreference Wert in "Stop" geändert.

$WarningPreference = "Stop"
$m = "This action can delete data."
Write-Warning -Message $m

WARNING: This action can delete data.
Write-Warning : The running command stopped because the preference variable
  "WarningPreference" or common parameter is set to Stop:
    This action can delete data.
At line:1 char:1
+ Write-Warning -Message $m

In diesem Beispiel wird die WarningAction mit dem Inquire-Wert verwendet. Der Benutzer wird aufgefordert, wenn eine Warnung auftritt.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction Inquire

WARNING: This action can delete data.

Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [?] Help (default is "Y"):

$WhatIfPreference

Bestimmt, ob WhatIf automatisch für jeden Befehl aktiviert ist, der ihn unterstützt. Wenn WhatIf aktiviert ist, meldet das Cmdlet den erwarteten Effekt des Befehls, führt den Befehl aber nicht aus.

Die folgenden Werte sind gültig:

• False (0, nicht aktiviert): (Standard) WhatIf ist nicht automatisch aktiviert. Um es manuell zu aktivieren, verwenden Sie den WhatIf-Parameter des Cmdlets.
• True (1, aktiviert): WhatIf wird automatisch für jeden Befehl aktiviert, der ihn unterstützt. Benutzer können den Parameter WhatIf mit dem Wert "False" verwenden, um ihn manuell zu deaktivieren, z -WhatIf:$false. B. .

Beispiele

Diese Beispiele zeigen den Effekt der verschiedenen Werte von $WhatIfPreference. Sie zeigen, wie sie den WhatIf-Parameter verwenden, um den Einstellungswert für einen bestimmten Befehl außer Kraft zu setzen.

In diesem Beispiel wird der Effekt der $WhatIfPreference Variablen dargestellt, die auf den Standardwert "False" festgelegt ist. Wird verwendet Get-ChildItem , um zu überprüfen, ob die Datei vorhanden ist. Remove-Item löscht die Datei. Nachdem die Datei gelöscht wurde, können Sie den Löschvorgang mit Get-ChildItem.

Get-ChildItem -Path .\test.txt
Remove-Item -Path ./test.txt

    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           9/13/2019    10:53             10 test.txt

Get-ChildItem -Path .\test.txt

Get-ChildItem : Cannot find path 'C:\Test\test.txt' because it does not exist.
At line:1 char:1
+ Get-ChildItem -File test.txt

In diesem Beispiel wird der Effekt der Verwendung des WhatIf-Parameters gezeigt, wenn der Wert "$WhatIfPreferenceFalse" lautet.

Überprüfen Sie, ob die Datei vorhanden ist.

Get-ChildItem -Path .\test2.txt

    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

Verwenden Sie den WhatIf-Parameter , um das Ergebnis des Löschens der Datei zu ermitteln.

Remove-Item -Path .\test2.txt -WhatIf

What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".

Stellen Sie sicher, dass die Datei nicht gelöscht wurde.

Get-ChildItem -Path .\test2.txt

    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

In diesem Beispiel wird der Effekt der $WhatIfPreference Variablen dargestellt, die auf den Wert "True" festgelegt ist. Wenn Sie Remove-Item eine Datei löschen, wird der Pfad der Datei angezeigt, die Datei wird jedoch nicht gelöscht.

Versuchen Sie, eine Datei zu löschen. Eine Meldung wird angezeigt, was passiert, wenn Remove-Item sie ausgeführt wurde, aber die Datei wird nicht gelöscht.

$WhatIfPreference = "True"
Remove-Item -Path .\test2.txt

What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".

Überprüfen Sie Get-ChildItem , ob die Datei nicht gelöscht wurde.

Get-ChildItem -Path .\test2.txt

    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

In diesem Beispiel wird gezeigt, wie eine Datei gelöscht wird, wenn der Wert $WhatIfPreference "True" ist. Er verwendet den WhatIf-Parameter mit einem Wert von $false. Wird Get-ChildItem verwendet, um zu überprüfen, ob die Datei gelöscht wurde.

Remove-Item -Path .\test2.txt -WhatIf:$false
Get-ChildItem -Path .\test2.txt

Get-ChildItem : Cannot find path 'C:\Test\test2.txt' because it does not exist.
At line:1 char:1
+ Get-ChildItem -Path .\test2.txt

Im Folgenden finden Sie Beispiele für das Get-Process Cmdlet, das WhatIf nicht unterstützt und Stop-Process WhatIf unterstützt. Der Wert der $WhatIfPreference Variablen ist True.

Get-Process unterstützt WhatIf nicht. Wenn der Befehl ausgeführt wird, wird der Winword-Prozess angezeigt.

Get-Process -Name Winword

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
    130   119.84     173.38       8.39   15024   4 WINWORD

Stop-Process unterstützt WhatIf. Der Winword-Prozess wird nicht beendet.

Stop-Process -Name Winword

What if: Performing the operation "Stop-Process" on target "WINWORD (15024)".

Sie können das Stop-Process WhatIf-Verhalten überschreiben, indem Sie den WhatIf-Parameter mit einem Wert von $false. Der Winword-Prozess wird beendet.

Stop-Process -Name Winword -WhatIf:$false

Um zu überprüfen, ob der Winword-Prozess beendet wurde, verwenden Sie Get-Process.

Get-Process -Name Winword

Get-Process : Cannot find a process with the name "Winword".
  Verify the process name and call the cmdlet again.
At line:1 char:1
+ Get-Process -Name Winword

Siehe auch

• about_automatic_variables
• about_CommonParameters
• about_Environment_Variables
• about_Profiles
• about_Remote
• about_Scopes
• about_Variables