Windows PowerShell 5.1 ou PowerShell 7 sur un serveur : quel moteur exécute réellement un script

Ce que c'est

Windows Server fournit Windows PowerShell 5.1 (powershell.exe) avec le système d'exploitation. PowerShell 7.x (pwsh.exe) est une installation distincte, multiplateforme et sous licence MIT. Selon le guide de migration de Microsoft, il s'exécute côte à côte avec la version 5.1 sans la remplacer, avec son propre chemin d'installation, son propre $PSModulePath, ses profils par version et ses journaux d'événements. Appeler l'un depuis un script en attendant le comportement de l'autre est une source fréquente de signalements du type « ça fonctionne en interactif, mais pas dans la tâche planifiée ».

Pourquoi c'est important

Les deux moteurs diffèrent par bien plus que le numéro de version :

• Exécutable et PATH : powershell.exe (situé dans System32\WindowsPowerShell\v1.0) correspond toujours à la version 5.1 sur un serveur standard ; pwsh.exe n'est présent que si la version 7.x a été installée séparément. Le MSI ajoute $Env:ProgramFiles\PowerShell\7 au PATH, mais les processus démarrés avant l'installation (services de longue durée) ne voient pas le nouveau PATH, et les installations par ZIP ou via le Store peuvent ne pas figurer du tout dans le PATH de la machine.
• Compatibilité des modules : la plupart des modules, y compris l'actuel module Active Directory, fonctionnent en 7.x, mais certains modules propres à Windows PowerShell ne se chargent pas nativement. Import-Module -UseWindowsPowerShell y remédie, pour reprendre les termes de Microsoft, en « loading module using Windows PowerShell Compatibility functionality » (chargement du module via la fonctionnalité de compatibilité de Windows PowerShell) : le module s'exécute dans un processus 5.1 masqué et les commandes sont relayées par un proxy, qui renvoie des objets désérialisés ; c'est plus lent et toutes les fonctionnalités ne sont pas prises en charge. PowerShell 7 n'applique ce repli de façon implicite qu'aux modules du dossier de modules système de la version 5.1 qui ne sont pas marqués comme compatibles Core (et qui ne figurent pas sur sa liste d'exclusion).
• Points de terminaison de remoting : via WinRM, Enter-PSSession et Invoke-Command sans -ConfigurationName explicite aboutissent au point de terminaison Windows PowerShell 5.1 nommé Microsoft.PowerShell, même si le client exécute pwsh. PowerShell 7 n'obtient ses propres points de terminaison (PowerShell.7, PowerShell.7.x.y) qu'après l'exécution de Enable-PSRemoting avec élévation de privilèges sous 7.x ; le guide de migration les range parmi les « new remoting endpoints » (nouveaux points de terminaison de remoting).
• Tâches planifiées : l'action -Execute du module ScheduledTasks est un simple chemin vers un exécutable ; une tâche créée avec -Execute 'powershell.exe' s'exécute toujours sous 5.1, quel que soit l'interpréteur de commandes qui a créé la tâche.

Comment l'appliquer

• Faire en sorte que le script affiche $PSVersionTable.PSVersion et $PSVersionTable.PSEdition au début de l'exécution, afin que les journaux indiquent quel moteur l'a réellement exécuté.
• Dans l'automatisation (tâches planifiées, runners CI, scripts de remoting), coder en dur le chemin complet de l'exécutable voulu plutôt que de s'en remettre à l'ordre du PATH.
• Lorsqu'un module ne fonctionne que sous 5.1, utiliser explicitement -UseWindowsPowerShell plutôt que de compter sur le repli implicite, qui ne couvre pas les modules situés hors du dossier de modules système.
• Pour le remoting, passer -ConfigurationName PowerShell.7 (ou le nom enregistré par Enable-PSRemoting exécuté sous pwsh) si la cible doit être PowerShell 7, et vérifier avec Get-PSSessionConfiguration sur la cible.

Pièges

• Supposer que l'installation de PowerShell 7 met à niveau ou supprime Windows PowerShell 5.1 : les deux coexistent et powershell.exe continue de fonctionner sans changement.
• Tester un script en interactif dans une fenêtre pwsh, puis le déployer dans une tâche planifiée qui appelle toujours powershell.exe.
• Oublier que -UseWindowsPowerShell démarre un processus d'arrière-plan supplémentaire par session, ce qui modifie les performances et les surfaces d'erreur par rapport à un module 7.x natif.