about_Windows_PowerShell_Compatibility
Description courte
Décrit la fonctionnalité de compatibilité Windows PowerShell pour PowerShell 7.
Description longue
Sauf si le manifeste du module indique que le module est compatible avec PowerShell Core, les modules du %windir%\system32\WindowsPowerShell\v1.0\Modules
dossier sont chargés dans un processus Windows PowerShell 5.1 en arrière-plan par la fonctionnalité de compatibilité Windows PowerShell.
Utilisation de la fonctionnalité de compatibilité
Lorsque le premier module est importé à l’aide de la fonctionnalité de compatibilité Windows PowerShell, PowerShell crée une session distante nommée WinPSCompatSession
qui s’exécute dans un processus Windows PowerShell 5.1 en arrière-plan. PowerShell crée ce processus lorsque la fonctionnalité de compatibilité importe le premier module. Le processus est fermé lorsque le dernier module est supprimé (à l’aide Remove-Module
) ou lorsque le processus PowerShell se ferme.
Les modules chargés dans la WinPSCompatSession
session sont utilisés via la communication à distance implicite et reflétés dans la session PowerShell actuelle. Il s’agit de la même méthode de transport que celle utilisée pour les travaux PowerShell.
Lorsqu’un module est importé dans la WinPSCompatSession
session, la communication à distance implicite génère un module proxy dans le répertoire de $env:Temp
l’utilisateur et importe ce module proxy dans la session PowerShell actuelle. Le module proxy permet à PowerShell de détecter que le module a été chargé à l’aide de la fonctionnalité de compatibilité Windows PowerShell.
Une fois la session créée, elle peut être utilisée pour les opérations qui ne fonctionnent pas correctement sur les objets désérialisés. Le pipeline entier est exécuté dans Windows PowerShell et seul le résultat final est retourné. Par exemple :
$s = Get-PSSession -Name WinPSCompatSession
Invoke-Command -Session $s -ScriptBlock {
"Running in Windows PowerShell version $($PSVersionTable.PSVersion)"
}
La fonctionnalité de compatibilité peut être appelée de deux façons :
Importer explicitement un module à l’aide du paramètre UseWindowsPowerShell
Import-Module -Name ScheduledTasks -UseWindowsPowerShell
Implicitement en important un module Windows PowerShell par nom, chemin d’accès ou chargement automatique via la découverte de commandes.
Import-Module -Name ServerManager Get-AppLockerPolicy -Local
S’il n’est pas déjà chargé, le module AppLocker est chargé automatiquement lors de l’exécution
Get-AppLockerPolicy
.
La compatibilité Windows PowerShell bloque le chargement des modules répertoriés dans le paramètre dans le WindowsPowerShellCompatibilityModuleDenyList
fichier de configuration PowerShell.
La valeur par défaut de ce paramètre est la suivante :
"WindowsPowerShellCompatibilityModuleDenyList": [
"PSScheduledJob","BestPractices","UpdateServices"
]
Gestion du chargement implicite du module
Pour désactiver le comportement d’importation implicite de la fonctionnalité de compatibilité Windows PowerShell, utilisez le DisableImplicitWinCompat
paramètre dans un fichier de configuration PowerShell. Ce paramètre peut être ajouté au powershell.config.json
fichier. Pour plus d’informations, consultez about_PowerShell_Config.
Cet exemple montre comment créer un fichier de configuration qui désactive la fonctionnalité de chargement implicite de module de compatibilité Windows PowerShell.
$ConfigPath = "$PSHOME\DisableWinCompat.powershell.config.json"
$ConfigJSON = ConvertTo-Json -InputObject @{
"DisableImplicitWinCompat" = $true
"Microsoft.PowerShell:ExecutionPolicy" = "RemoteSigned"
}
$ConfigJSON | Out-File -Force $ConfigPath
pwsh -settingsFile $ConfigPath
Pour plus d’informations sur la compatibilité des modules, consultez la liste de compatibilité des modules PowerShell 7.
Gestion du clobbering des applets de commande
La fonctionnalité de compatibilité Windows PowerShell utilise la communication à distance implicite pour charger des modules en mode de compatibilité. Le résultat est que les commandes exportées par le module sont prioritaires sur les commandes du même nom dans la session PowerShell 7 actuelle. Dans la version de PowerShell 7.0.0, cela inclut les modules principaux fournis avec PowerShell.
Dans PowerShell 7.1, le comportement a été modifié afin que les modules PowerShell principaux suivants ne soient pas clobés :
- Microsoft.PowerShell.ConsoleHost
- Microsoft.PowerShell.Diagnostics
- Microsoft.PowerShell.Host
- Microsoft.PowerShell.Management
- Microsoft.PowerShell.Security
- Microsoft.PowerShell.Utility
- Microsoft.WSMan.Management
PowerShell 7.1 a également ajouté la possibilité d’exclure d’autres modules de clobbering par mode de compatibilité.
Vous pouvez ajouter le WindowsPowerShellCompatibilityNoClobberModuleList
paramètre au fichier de configuration PowerShell. La valeur de ce paramètre est une liste séparée par des virgules de noms de modules. La valeur par défaut de ce paramètre est la suivante :
"WindowsPowerShellCompatibilityNoClobberModuleList": [ ]
Limites
Fonctionnalités de compatibilité Windows PowerShell :
- Fonctionne uniquement localement sur les ordinateurs Windows
- Nécessite Windows PowerShell 5.1
- Fonctionne sur les paramètres d’applet de commande sérialisés et les valeurs de retour, et non sur les objets en direct
- Partage un seul runspace pour tous les modules importés dans la session de communication à distance Windows PowerShell
Fichiers temporaires
La fonctionnalité de compatibilité Windows PowerShell utilise la communication à distance implicite pour rendre les modules Windows PowerShell 5.1 disponibles dans PowerShell 7. La communication à distance implicite crée des fichiers temporaires dans le $env:Temp
répertoire. Chaque module proxié est stocké dans un dossier distinct avec la convention d’affectation de noms suivante :
remoteIpMoProxy_<ModuleName>_<ModuleVersion>_localhost_<SessionGuid>
.
PowerShell supprime les fichiers temporaires lorsque vous supprimez le dernier module proxié de la session ou fermez la session.