Windows PowerShell 5.1 frente a PowerShell 7 en servidores: bajo qué motor se ejecuta realmente un script

Qué es

Windows Server incluye Windows PowerShell 5.1 (powershell.exe) como parte del sistema operativo. PowerShell 7.x (pwsh.exe) es una instalación aparte, multiplataforma y con licencia MIT, que según la guía de migración de Microsoft se ejecuta en paralelo con la 5.1 en lugar de sustituirla, y que tiene su propia ruta de instalación, su propio $PSModulePath, perfiles por versión y registros de eventos propios. Llamar a uno desde un script esperando el comportamiento del otro es una causa frecuente de informes del tipo «funciona de forma interactiva, pero no en la tarea programada».

Por qué importa

Los dos motores se diferencian en algo más que el número de versión:

• Ejecutable y PATH: powershell.exe (en System32\WindowsPowerShell\v1.0) es siempre la 5.1 en un servidor sin modificar; pwsh.exe solo existe si se instaló la 7.x por separado. El MSI añade $Env:ProgramFiles\PowerShell\7 al PATH, pero los procesos iniciados antes de la instalación (servicios de larga duración) no ven el nuevo PATH, y las instalaciones mediante ZIP o desde la Store pueden no estar en absoluto en el PATH del equipo.
• Compatibilidad de módulos: la mayoría de los módulos, incluido el actual de Active Directory, funcionan en la 7.x, pero algunos módulos exclusivos de Windows PowerShell no se cargan de forma nativa. Import-Module -UseWindowsPowerShell lo resuelve, en palabras de Microsoft, «loading module using Windows PowerShell Compatibility functionality»: ejecuta el módulo dentro de un proceso 5.1 oculto y actúa como proxy de los comandos, que devuelven objetos deserializados; es más lento y no admite todas las funciones. PowerShell 7 aplica este mecanismo alternativo de forma implícita solo a los módulos de la carpeta de módulos del sistema de la 5.1 que no estén marcados como compatibles con Core (y que no figuren en su lista de denegación).
• Endpoints de remoting: con WinRM, Enter-PSSession/Invoke-Command sin un -ConfigurationName explícito se conectan al endpoint de Windows PowerShell 5.1 llamado Microsoft.PowerShell, incluso cuando el cliente ejecuta pwsh. PowerShell 7 dispone de sus propios endpoints (PowerShell.7, PowerShell.7.x.y) solo después de ejecutar Enable-PSRemoting con privilegios elevados bajo la 7.x; la guía de migración los menciona entre los «new remoting endpoints».
• Tareas programadas: la acción -Execute del módulo ScheduledTasks es simplemente la ruta de un ejecutable; una tarea creada con -Execute 'powershell.exe' se ejecuta siempre con la 5.1, sin importar desde qué shell se haya creado.

Cómo aplicarlo

• Haz que el script informe de $PSVersionTable.PSVersion y $PSVersionTable.PSEdition al inicio de cada ejecución, para que los registros muestren qué motor lo ejecutó realmente.
• En la automatización (tareas programadas, runners de CI, scripts de remoting), fija en el código la ruta completa del ejecutable deseado en lugar de depender del orden del PATH.
• Cuando un módulo solo funciona con la 5.1, usa -UseWindowsPowerShell de forma explícita en lugar de confiar en el mecanismo alternativo implícito, que no cubre los módulos situados fuera de la carpeta de módulos del sistema.
• Para el remoting, pasa -ConfigurationName PowerShell.7 (o el nombre que haya registrado Enable-PSRemoting ejecutado bajo pwsh) si el destino debe usar PowerShell 7, y verifica con Get-PSSessionConfiguration en el equipo de destino.

Trampas

• Suponer que instalar PowerShell 7 actualiza o elimina Windows PowerShell 5.1: ambos permanecen y powershell.exe sigue funcionando sin cambios.
• Probar un script de forma interactiva en una ventana de pwsh y desplegarlo en una tarea programada que sigue llamando a powershell.exe.
• Olvidar que -UseWindowsPowerShell inicia un proceso adicional en segundo plano por sesión, lo que cambia el rendimiento y la forma en que aparecen los errores en comparación con un módulo nativo de la 7.x.