Windows PowerShell 5.1 e PowerShell 7 em servidores: sob qual deles um script realmente executa

O que é

O Windows Server inclui o Windows PowerShell 5.1 (powershell.exe) como parte do sistema operacional. O PowerShell 7.x (pwsh.exe) é uma instalação separada, multiplataforma e sob licença MIT, que, segundo o guia de migração da Microsoft, roda lado a lado com o 5.1, sem substituí-lo, com caminho de instalação, $PSModulePath, perfis por versão e logs de eventos próprios. Chamar um dos dois em um script esperando o comportamento do outro é uma fonte comum de relatos do tipo "funciona no modo interativo, mas não na tarefa agendada".

Por que importa

Os dois motores diferem em mais do que o número da versão:

• Executável e PATH: powershell.exe (em System32\WindowsPowerShell\v1.0) é sempre o 5.1 em um servidor padrão; pwsh.exe só existe se o 7.x tiver sido instalado separadamente. O MSI adiciona $Env:ProgramFiles\PowerShell\7 ao PATH, mas processos iniciados antes da instalação (serviços de longa duração) não enxergam o novo PATH, e instalações por ZIP ou pela Store podem nem estar no PATH da máquina.
• Compatibilidade de módulos: a maioria dos módulos, inclusive o atual Active Directory, funciona no 7.x, mas alguns módulos exclusivos do Windows PowerShell não carregam de forma nativa. O Import-Module -UseWindowsPowerShell resolve isso, nas palavras da própria Microsoft, "loading module using Windows PowerShell Compatibility functionality": o módulo roda dentro de um processo 5.1 oculto, e os comandos são repassados por proxy, retornando objetos desserializados. Isso é mais lento e não suporta todos os recursos. O PowerShell 7 aplica esse fallback de forma implícita apenas a módulos da pasta de módulos do sistema do 5.1 que não estejam marcados como compatíveis com Core (e que não estejam na sua lista de bloqueio).
• Endpoints de remoting: via WinRM, Enter-PSSession/Invoke-Command sem um -ConfigurationName explícito chegam ao endpoint do Windows PowerShell 5.1 chamado Microsoft.PowerShell, mesmo quando o cliente executa pwsh. O PowerShell 7 só ganha endpoints próprios (PowerShell.7, PowerShell.7.x.y) depois de executar Enable-PSRemoting com privilégios elevados no 7.x; o guia de migração os lista entre os "new remoting endpoints".
• Tarefas agendadas: a ação -Execute do módulo ScheduledTasks é apenas o caminho de um executável. Uma tarefa criada com -Execute 'powershell.exe' sempre roda sob o 5.1, independentemente do shell que a criou.

Como aplicar

• Faça o script informar $PSVersionTable.PSVersion e $PSVersionTable.PSEdition no início da execução, para que os logs mostrem qual motor de fato o executou.
• Em automações (tarefas agendadas, runners de CI, scripts de remoting), fixe no código o caminho completo do executável desejado em vez de depender da ordem do PATH.
• Quando um módulo só funciona no 5.1, use -UseWindowsPowerShell de forma explícita, em vez de confiar no fallback implícito, que não cobre módulos fora da pasta de módulos do sistema.
• No remoting, passe -ConfigurationName PowerShell.7 (ou o nome que o Enable-PSRemoting executado sob pwsh tiver registrado) se o destino precisar ser o PowerShell 7, e confirme com Get-PSSessionConfiguration no destino.

Armadilhas

• Supor que instalar o PowerShell 7 atualiza ou remove o Windows PowerShell 5.1; ambos permanecem, e o powershell.exe continua funcionando sem alterações.
• Testar um script de forma interativa em uma janela pwsh e implantá-lo em uma tarefa agendada que ainda chama powershell.exe.
• Esquecer que -UseWindowsPowerShell inicia um processo adicional em segundo plano por sessão, o que altera o desempenho e as superfícies de erro em comparação com um módulo nativo do 7.x.