about_Windows_Powershell_5.1

  • Artigo

Descrição breve

Descreve os novos recursos incluídos no Windows PowerShell 5.1.

Descrição longa

O Windows PowerShell 5.1 inclui novos recursos significativos que estendem seu uso, melhoram sua usabilidade e permitem que você controle e gerencie ambientes baseados no Windows de forma mais fácil e abrangente.

O Windows PowerShell 5.1 é compatível com versões anteriores. Cmdlets, provedores, módulos, snap-ins, scripts, funções e perfis projetados para Windows PowerShell 4.0, Windows PowerShell 3.0 e Windows PowerShell 2.0 geralmente funcionam no Windows PowerShell 5.1 sem alterações.

  • Novos cmdlets: usuários e grupos locais; Get-ComputerInfo
  • Os aprimoramentos do PowerShellGet incluem a imposição de módulos assinados e a instalação de módulos JEA
  • Suporte acrescentado para o PackageManagement para Contêineres, Configuração de CBS, configuração baseada em EXE, pacotes CAB
  • Melhorias de depuração para classes DSC e PowerShell
  • Aprimoramentos de segurança, incluindo a imposição de módulos de catálogo assinado provenientes do Servidor de Recepção e ao usar cmdlets do PowerShellGet
  • Respostas para diversos problemas e solicitações de usuários

O Windows PowerShell 5.1 é instalado por padrão no Windows Server versão 2016 e superior e no cliente Windows versão 10 e superior.

Para instalar o Windows PowerShell 5.1 em versões mais antigas do Windows, consulte Instalar e configurar o WMF 5.1. Certifique-se de ler os detalhes do download e atender a todos os requisitos do sistema antes de instalar o Windows Management Framework 5.1.

Você também pode ler sobre as alterações no Windows PowerShell 5.1 em Novidades no Windows PowerShell.

Edições do PowerShell

A partir da versão 5.1, o PowerShell está disponível em diferentes edições que denotam os vários conjuntos de recursos e compatibilidades de plataforma.

  • Desktop Edition: criado no .NET Framework; fornece compatibilidade com scripts e módulos destinados a versões do PowerShell em execução em edições de volume completo do Windows, como Server Core e Windows Desktop.
  • Core Edition: criada no .NET Core, oferece compatibilidade com scripts e módulos destinados a versões do PowerShell executadas em edições de volume reduzido do Windows, como o Nano Server e Windows IoT.

Saiba mais sobre como usar as edições do PowerShell

Cmdlets de Catálogo

Dois novos cmdlets foram adicionados no módulo Microsoft.PowerShell.Security . Esses cmdlets geram e validam arquivos de catálogo do Windows.

New-FileCatalog

New-FileCatalog cria um arquivo de catálogo do Windows para um conjunto de pastas e arquivos. Este arquivo de catálogo contém hashes para todos os arquivos nos caminhos especificados. Os usuários podem distribuir o conjunto de pastas juntamente com o arquivo de catálogo correspondente que representa essas pastas. Essas informações são úteis para validar se as alterações foram feitas nas pastas desde a hora de criação do catálogo.

New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
 [-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

Há suporte para as versões 1 e 2 do catálogo. A versão 1 usa o algoritmo de hash SHA1 para criar hashes de arquivo; a versão 2 usa SHA256. Você deve usar a versão 2 do catálogo.

Para verificar a integridade do arquivo de catálogo (Pester.cat, no exemplo acima), assine-o usando o cmdlet Set-AuthenticodeSignature.

Test-FileCatalog

Test-FileCatalog valida o catálogo que representa um conjunto de pastas.

Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
 [-CatalogFilePath] <String> [[-Path] <String[]>]
 [-WhatIf] [-Confirm] [<CommonParameters>]

Esse cmdlet compara todos os hashes de arquivo e seus caminhos relativos encontrados em um catálogo com arquivos em disco. Se ele detectar qualquer incompatibilidade entre hashes e caminhos de arquivo, ele retornará o status como ValidationFailed. Os usuários podem recuperar todas essas informações usando o parâmetro Detailed . Ele também exibe o status de assinatura do catálogo na propriedade Signature , que é equivalente a chamar o cmdlet Get-AuthenticodeSignature no arquivo de catálogo. Os usuários também podem ignorar qualquer arquivo durante a validação usando o parâmetro FilesToSkip .

Cache de análise do módulo

A partir do WMF 5.1, o PowerShell fornece controle sobre o arquivo usado para armazenar em cache dados sobre um módulo, como os comandos que ele exporta.

Por padrão, esse cache é armazenado no arquivo ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache. O cache normalmente é lido na inicialização ao procurar um comando e é gravado em um thread em segundo plano em algum momento após a importação de um módulo.

Para alterar o local padrão do cache, defina a variável de ambiente $env:PSModuleAnalysisCachePath antes de iniciar o PowerShell. As alterações nessa variável de ambiente afetam apenas os processos filho. O valor deve nomear um caminho completo (incluindo nome do arquivo) em que o PowerShell tenha permissão para criar e gravar arquivos. Para desabilitar o cache de arquivo, defina esse valor para um local inválido, por exemplo:

$env:PSModuleAnalysisCachePath = 'nul'

Isso define o caminho para um dispositivo inválido. Se o PowerShell não puder gravar no caminho, nenhum erro será retornado, mas você poderá ver o relatório de erros usando um rastreador:

Trace-Command -PSHost -Name Modules -Expression {
  Import-Module Microsoft.PowerShell.Management -Force
}

Ao gravar o cache, o PowerShell verifica se há módulos que não existem mais para evitar um cache desnecessariamente grande. Você pode desabilitar as verificações usando a seguinte configuração:

$env:PSDisableModuleAnalysisCacheCleanup = 1

A definição dessa variável de ambiente entra em vigor imediatamente no processo atual.

Especificando a versão do módulo

No WMF 5.1, o using module comporta-se da mesma maneira que outras construções relacionadas ao módulo no PowerShell. Anteriormente, você não tinha como especificar uma versão específica do módulo. Se houvesse várias versões presentes, isso resultaria em um erro.

No WMF 5.1:

  • Você pode usar o Construtor ModuleSpecification (tabela de hash). Essa tabela de hash tem o mesmo formato que Get-Module -FullyQualifiedName.

    Exemplo:using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

  • Se houver várias versões do módulo, o PowerShell usará a mesma lógicaImport-Module de resolução e não retornará um erro.

Melhorias no Pester

No WMF 5.1, a versão do Pester fornecida com o PowerShell foi atualizada de 3.3.5 para 3.4.0. Você pode revisar as alterações nas versões 3.3.5 a 3.4.0 inspecionando o CHANGELOG no repositório do GitHub.

KEYWORDS

O que há de novo no Windows PowerShell 5.1