PowerShell 7.6 LTS: o que mudou e como migrar do 5.1

A maioria dos ambientes Windows corporativos ainda roda Windows PowerShell 5.1 — o que vem instalado por padrão no sistema, nunca recebeu grandes atualizações e está congelado no .NET Framework. Em 18 de março de 2026, a Microsoft lançou o PowerShell 7.6 LTS, construído sobre .NET 10 (também LTS), e a pergunta que muitos sysadmins estão se fazendo agora é: vale mesmo a pena migrar? A resposta curta é sim.
Por que "LTS" importa nesse contexto
PowerShell 7.6 é a quarta versão LTS do PowerShell moderno — as anteriores foram 7.0, 7.2 e 7.4. LTS significa três anos de suporte garantido com backport de correções de segurança, sem precisar acompanhar cada ponto release intermediário. Para ambientes com Change Control rigoroso, essa estabilidade de longo prazo é frequentemente o único argumento que o time de infra precisa ouvir.
O .NET 10 subjacente também é LTS, então as cadências ficam alinhadas: atualiza uma vez, qualifica, e o suporte vai até 2029. Nada de ter que renegociar janela de manutenção a cada seis meses por conta de uma nova versão non-LTS.
O que mudou de verdade no 7.6
O 7.6 não é uma reescrita — é uma versão de consolidação, com melhorias cirúrgicas que acumulam bastante no dia a dia. Os destaques confirmados pela Microsoft:
- Tab completion mais inteligente: ao atribuir um array e tentar completar com Tab, o PowerShell agora sugere métodos como
CounteLength. Navegação no registro do Windows também melhorou — ao usarGet-ChildItemem caminhos do Registry, o autocomplete sugere subchaves corretamente em vez de travar. - PSReadLine 2.4.5: atualização do módulo de edição interativa da linha de comando, com melhorias na previsão de sintaxe e no comportamento do histórico de comandos.
- PSResourceGet 1.2.0: o sucessor do antigo
PowerShellGetganhou tratamento de dependências mais robusto e downloads paralelos mais confiáveis. Quem usa a PSGallery com frequência vai notar a diferença. - PSWhere() e PSForEach() como aliases explícitos: os métodos intrínsecos
.Where()e.ForEach()ganharam aliases nomeados, tornando o código mais legível e os métodos mais fáceis de descobrir via Tab. - Out-GridView funciona de novo: o BinaryFormatter legado foi substituído por uma implementação própria e segura. Quem dependia de
Out-GridViewem automações e enfrentava falhas a partir do .NET 5+ vai notar a correção imediatamente.
Como instalar ou atualizar
A forma mais rápida no Windows 10/11 ou Windows Server 2022/2025 é via winget. Abra um terminal com privilégios de administrador e rode:
# Instalar pela primeira vez
winget install --id Microsoft.PowerShell --source winget
# Atualizar de uma versão anterior do PowerShell 7.x
winget upgrade Microsoft.PowerShellSe o ambiente não tiver winget disponível (Windows Server 2019, por exemplo), o MSI oficial está na página de releases do projeto no GitHub — baixe o .msi correspondente à arquitetura (x64 na maioria dos casos) e execute normalmente.
Após a instalação, confirme a versão:
pwsh -Command '$PSVersionTable'Você deve ver PSVersion 7.6.x e PSEdition Core. Se ainda aparecer 5.1, você está rodando o powershell.exe antigo, não o pwsh.exe novo.
Coexistência com o Windows PowerShell 5.1
O PowerShell 7.x instala em diretório separado e usa o executável pwsh.exe — diferente do powershell.exe do 5.1. As duas versões coexistem sem conflito, o que permite uma migração gradual em vez de uma virada de chave abrupta.
O ponto de atenção são módulos legados que dependem de assemblies do .NET Framework e não carregam no PowerShell 7. O mecanismo de compatibilidade Windows PowerShell Compatibility (importação implícita via sessão remota para o 5.1) cobre bastante coisa, mas não é infalível. O caminho mais seguro é:
- Listar os módulos que seus scripts usam:
Get-Module -ListAvailable. - Verificar compatibilidade na documentação oficial de migração da Microsoft.
- Testar scripts críticos em ambiente isolado com
pwsh.exeantes de promover para produção.
Se você ainda está construindo familiaridade com os fundamentos, o guia de cmdlets básicos do PowerShell cobre o essencial antes de pensar em migração de versão.
Por que sair do 5.1 agora
O Windows PowerShell 5.1 não recebe novas funcionalidades desde 2017. Manter ele em produção em 2026 significa abrir mão de recursos que já são padrão no ecossistema moderno:
- Foreach-Object -Parallel: paralelismo nativo sem runspaces manuais — disponível desde o 7.0.
- Operadores de pipeline encadeado:
&&e||ao estilo bash, para encadear comandos com condição de sucesso/falha. - Ternário e atribuição nula:
$x = $y ?? 'padrão'e$x ??= 'padrão'— economizam linhas inteiras deif/else. - SSH Remoting nativo: remoting via SSH sem depender de WinRM, o que é especialmente relevante em ambientes mistos Linux/Windows. O assunto conecta diretamente com o que abordamos sobre hardening de SSH em servidores Linux.
- Performance do .NET 10: ganhos de throughput em pipelines longos que somam bastante em automações intensivas rodando dezenas de vezes ao dia.
E se o objetivo principal for segurança operacional, o post sobre usar PowerShell para auditar logs de segurança no Windows traz scripts práticos que se beneficiam da maturidade do Get-WinEvent no 7.6.
Vale atualizar agora?
Para workstations e servidores de desenvolvimento, sim — hoje mesmo. Para produção, o LTS justifica a janela de mudança: planeje um sprint de validação, rode os scripts existentes em homologação com pwsh.exe, documente os módulos que precisam do modo de compatibilidade e então promova. Não há razão técnica para segurar o 5.1 depois que a avaliação estiver feita.
Se você gerencia muitas máquinas, o winget via Intune ou um script de deployment com o PSResourceGet 1.2.0 tornam a migração em escala bem mais direta. Se tiver dúvidas sobre o processo ou encontrou algum módulo legado problemático que não listei aqui, conta nos comentários.




Comentários