about_Windows_PowerShell_Compatibility

Kurze Beschreibung

Beschreibt die Windows PowerShell-Kompatibilitätsfunktionalität für PowerShell 7.

Lange Beschreibung

Sofern das Modulmanifest nicht angibt, dass das Modul mit PowerShell Core kompatibel ist, werden Module im %windir%\system32\WindowsPowerShell\v1.0\Modules Ordner in einen Windows PowerShell 5.1-Hintergrundprozess über das Windows PowerShell-Kompatibilitätsfeature geladen.

Verwenden des Kompatibilitätsfeatures

Wenn das erste Modul mithilfe des Windows PowerShell-Kompatibilitätsfeatures importiert wird, erstellt PowerShell eine Remotesitzung mit dem Namen WinPSCompatSession , die in einem Windows PowerShell 5.1-Hintergrundprozess ausgeführt wird. PowerShell erstellt diesen Prozess, wenn das Kompatibilitätsfeature das erste Modul importiert. Der Prozess wird geschlossen, wenn das letzte Modul entfernt wird (mit Remove-Module) oder wenn der PowerShell-Prozess beendet wird.

Die in der WinPSCompatSession Sitzung geladenen Module werden über implizites Remoting verwendet und in die aktuelle PowerShell-Sitzung widergespiegelt. Dies ist die gleiche Transportmethode, die für PowerShell-Aufträge verwendet wird.

Wenn ein Modul in die WinPSCompatSession Sitzung importiert wird, generiert implizites Remoting ein Proxymodul im Verzeichnis des $env:Temp Benutzers und importiert dieses Proxymodul in die aktuelle PowerShell-Sitzung. Mit dem Proxymodul kann PowerShell erkennen, dass das Modul mithilfe der Windows PowerShell-Kompatibilitätsfunktionalität geladen wurde.

Nachdem die Sitzung erstellt wurde, kann sie für Vorgänge verwendet werden, die nicht ordnungsgemäß für deserialisierte Objekte funktionieren. Die gesamte Pipeline wird in Windows PowerShell ausgeführt, und nur das endgültige Ergebnis wird zurückgegeben. Zum Beispiel:

$s = Get-PSSession -Name WinPSCompatSession
Invoke-Command -Session $s -ScriptBlock {
  "Running in Windows PowerShell version $($PSVersionTable.PSVersion)"
}

Das Kompatibilitätsfeature kann auf zwei Arten aufgerufen werden:

• Explizit durch Importieren eines Moduls mithilfe des UseWindowsPowerShell-Parameters

  Import-Module -Name ScheduledTasks -UseWindowsPowerShell
  

• Implizit durch Importieren eines Windows PowerShell-Moduls nach Modulname, Pfad oder automatisches Laden über die Befehlsermittlung.

  Import-Module -Name ServerManager
  Get-AppLockerPolicy -Local
  

  Wenn das AppLocker-Modul noch nicht geladen wurde, wird das AppLocker-Modul automatisch geladen, wenn Sie ausgeführt werden Get-AppLockerPolicy.

Die Windows PowerShell-Kompatibilität blockiert das Laden von Modulen, die in der Einstellung in der WindowsPowerShellCompatibilityModuleDenyList PowerShell-Konfigurationsdatei aufgeführt sind.

Der Standardwert dieser Einstellung lautet:

"WindowsPowerShellCompatibilityModuleDenyList":  [
   "PSScheduledJob","BestPractices","UpdateServices"
]

Verwalten des ladens impliziten Moduls

Verwenden Sie zum Deaktivieren des impliziten Importverhaltens des Windows PowerShell-Kompatibilitätsfeatures die DisableImplicitWinCompat Einstellung in einer PowerShell-Konfigurationsdatei. Diese Einstellung kann der powershell.config.json Datei hinzugefügt werden. Weitere Informationen finden Sie unter about_PowerShell_Config.

In diesem Beispiel wird gezeigt, wie Sie eine Konfigurationsdatei erstellen, die das implizite Modulladefeature der Windows PowerShell-Kompatibilität deaktiviert.

$ConfigPath = "$PSHOME\DisableWinCompat.powershell.config.json"
$ConfigJSON = ConvertTo-Json -InputObject @{
  "DisableImplicitWinCompat" = $true
  "Microsoft.PowerShell:ExecutionPolicy" = "RemoteSigned"
}
$ConfigJSON | Out-File -Force $ConfigPath
pwsh -settingsFile $ConfigPath

Weitere Informationen zur Modulkompatibilität finden Sie in der PowerShell 7-Modulkompatibilitätsliste .

Verwalten von Cmdlet-Clobbering

Das Windows PowerShell-Kompatibilitätsfeature verwendet implizites Remoting zum Laden von Modulen im Kompatibilitätsmodus. Das Ergebnis ist, dass von dem Modul exportierte Befehle Vorrang vor Befehlen mit demselben Namen in der aktuellen PowerShell 7-Sitzung haben. In der PowerShell 7.0.0-Version enthielt dies die Kernmodule, die mit PowerShell ausgeliefert werden.

In PowerShell 7.1 wurde das Verhalten geändert, sodass die folgenden PowerShell-Kernmodule nicht klobbert werden:

• Microsoft.PowerShell.ConsoleHost
• Microsoft.PowerShell.Diagnostics
• Microsoft.PowerShell.Host
• Microsoft.PowerShell.Management
• Microsoft.PowerShell.Security
• Microsoft.PowerShell.Utility
• Microsoft.WSMan.Management

PowerShell 7.1 hat außerdem die Möglichkeit hinzugefügt, weitere Module aus dem Klobbering durch den Kompatibilitätsmodus auszuschließen.

Sie können die WindowsPowerShellCompatibilityNoClobberModuleList Einstellung zur PowerShell-Konfigurationsdatei hinzufügen. Der Wert dieser Einstellung ist eine durch Trennzeichen getrennte Liste von Modulnamen. Der Standardwert dieser Einstellung lautet:

"WindowsPowerShellCompatibilityNoClobberModuleList": [ ]

Begrenzungen

Die Windows PowerShell-Kompatibilitätsfunktionalität:

1. Funktioniert nur lokal auf Windows-Computern
2. Erfordert Windows PowerShell 5.1
3. Verwendet serialisierte Cmdlet-Parameter und Rückgabewerte, nicht für Liveobjekte
4. Teilt einen einzelnen Runspace für alle Module, die in die Windows PowerShell-Remotingsitzung importiert wurden.

Temporäre Dateien

Das Windows PowerShell-Kompatibilitätsfeature verwendet implizites Remoting, um Windows PowerShell 5.1-Module in PowerShell 7 verfügbar zu machen. Implizites Remoting erstellt temporäre Dateien im $env:Temp Verzeichnis. Jedes proxiierte Modul wird in einem separaten Ordner mit der folgenden Benennungskonvention gespeichert:

• remoteIpMoProxy_<ModuleName>_<ModuleVersion>_localhost_<SessionGuid>.

PowerShell entfernt die temporären Dateien, wenn Sie das letzte proxiierte Modul aus der Sitzung entfernen oder die Sitzung schließen.

Siehe auch

• about_Modules
• Import-Module