Partilhar via

about_Windows_PowerShell_5,1

Breve descrição

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
  • Melhorias do PowerShellGet com a imposição de módulos assinados e a instalação de módulos JEA
  • Adicionado suporte ao PackageManagement para Contentores, Configuração CBS, configuração com base em EXE, pacotes CAB
  • Melhorias na depuração para classes DSC e PowerShell
  • Melhorias de segurança, incluindo a imposição de módulos assinados de catálogo provenientes do Servidor de Solicitação e ao utilizar os cmdlets PowerShellGet
  • Respostas a vários pedidos e problemas de utilizadores

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.

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

Edições do PowerShell

Começando na versão 5.1, o PowerShell está disponível nas diferentes edições que denotam conjuntos de funcionalidade e compatibilidade de plataforma variados.

  • Desktop Edition: Construído no .NET Framework e fornece compatibilidade com scripts e módulos destinados a versões do PowerShell em execução em edições completas do Windows, como Server Core e Windows Desktop.
  • Core Edition: Construído no .NET Core e fornece compatibilidade com scripts e módulos destinados a versões do PowerShell em execução em edições de espaço reduzido do Windows, como Nano Server e Windows IoT.

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

Cmdlets do catálogo

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

Novo-CatálogoDeFicheiros

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 em caminhos especificados. Os usuários podem distribuir o conjunto de pastas junto com o arquivo de catálogo correspondente que representa essas pastas. Essas informações são úteis para validar se foram feitas alterações nas pastas desde o momento da criação do catálogo.

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

As versões de catálogo 1 e 2 são suportadas. A versão 1 usa o algoritmo de hash SHA1 para criar hashes de arquivo; 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 .

Catálogo de Arquivos de Teste

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

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

Este cmdlet compara todos os hashes de arquivo e seus caminhos relativos encontrados em um catálogo com arquivos no disco. Se detetar qualquer incompatibilidade entre hashes de arquivo e caminhos, 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 de 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 enquanto procura um comando e é escrito em um thread em segundo plano algum tempo depois que um módulo é importado.

Para alterar o local padrão do cache, defina a variável de ambiente antes de iniciar o $env:PSModuleAnalysisCachePath PowerShell. As alterações nessa variável de ambiente afetam apenas os processos filho. O valor deve nomear um caminho completo (incluindo nome de arquivo) que o PowerShell tenha permissão para criar e gravar arquivos. Para desativar o cache de arquivos, defina esse valor como 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 escrever o cache, o PowerShell verifica se há módulos que não existem mais para evitar um cache desnecessariamente grande. Você pode desativar 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, using module se comporta da mesma maneira que outras construções relacionadas a módulos 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 ModuleSpecification Construtor (Hashtable). Esta 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

WMF 5.1 vem com Pester v3.4.0. Para obter mais informações sobre esta versão, consulte o CHANGELOG no repositório GitHub.

  • Last updated on