Windows PowerShell: Parâmetros comuns e variáveis de tempo de execução
Cada mês deste ano, Don Jones apresentará um novo artigo em um tutorial dividido em 12 partes sobre o fluxo de trabalho do Windows PowerShell. Nós encorajamos você a ler a série na ordem, começando com o de janeiro de 2013 coluna.
Don Jones
Dentre as coisas legais sobre um fluxo de trabalho é você obter uma tonelada de funcionalidade interna. Por exemplo, cada fluxo de trabalho que você escrever nativamente sabe como falar com computadores remotos através de Windows PowerShell remoting (Windows Remote Management, conhecido como WinRM).
Isso significa que você pode escrever cada fluxo de trabalho para correr contra o computador local, e você pode remoto a coisa toda. Variáveis e parâmetros de fluxo de trabalho comuns permitem acessar esses recursos nativos "atalho".
Parâmetros de fluxo de trabalho comuns
Estas são todas documentadas no arquivo de ajuda do about_WorkflowCommonParameters, embora você precise importar manualmente o módulo de PSWorkflow no Windows PowerShell 3.0 para que esse arquivo de ajuda ser visível. Aqui está uma olhada em alguns dos mais comuns:
- -AsJob força o fluxo de trabalho para ser executado como um trabalho em segundo plano. O parâmetro de - JobName relacionados permite aplicar um nome personalizado para o trabalho.
- PSAuthentication - permite especificar um mecanismo de autenticação, como Kerberos ou Credential Security Support Provider (CredSSP), para conexões remotas. CredSSP é útil quando o fluxo de trabalho precisa acessar recursos não-locais que exigem uma rede adicional "hop".
- PSComputerName - permite que você especificar um ou mais nomes de computador em que você pretende executar o fluxo de trabalho. Por exemplo, - PSComputerName (Get-ADComputer-filtro * | Selecione - expanda nome) iria correr o fluxo de trabalho em todos os computadores do domínio. Você deve ter cuidado com este.
- PSConnectionRetryCount - especifica o número de vezes que o fluxo de trabalho tenta conectar-se a cada computador remoto, e - PSConnectionRetryIntervalSec é o número de segundos de espera entre tentativas.
- -PSCredential permite que você especificar uma credencial alternativa para conexões remotas.
- PSParameterCollection - permite que você especificar uma tabela de hash de parâmetros comuns de fluxo de trabalho. Este é complicado. Você pode especificar uma lista separada por vírgulas de tabelas de hash, com cada tabela de hash ligar a um ou mais computadores. Por exemplo, especifica uma conexão diferente contagem de repetição para computadores de um e dois: -
PSParameterCollection, @{PSComputerName='ONE';PSConnectionRetryCount=10},@{PSComputerName='TWO';PSConnectionRetryCount=20}
- PSPort e - PSUseSSL que você especificar portas alternativas e, opcionalmente, habilitar o SSL (supondo que as máquinas remotas tem um certificado SSL válido e ouvinte de WinRM configurado) para a conexão.
Lembre-se, todos os fluxos de trabalho obter essas opções. Você não tem que escrever nenhum código para fazê-los funcionar. E eles estão livres, o que é impressionante.
Variáveis de fluxo de trabalho automático
Todos os normais do Windows PowerShell variáveis automáticas, tais como $Args, $Error, $MyInvocation, $PSBoundParameters e $PsCmdlet, estão disponíveis dentro de um fluxo de trabalho. Fluxos de trabalho adicionam muito mais sobre o que o Windows PowerShell fornece:
- $PSParentActivityID fornece um identificador exclusivo para o escopo atual e todos os escopos filho. Isso permite que você identificar exclusivamente cada instância de um fluxo de trabalho, como quando você quiser informações de log para um arquivo central.
- $PSWorkflowRoot contém o caminho de raiz de um fluxo de trabalho.
- $WorkflowInstanceID é o identificador exclusivo para a instância de fluxo de trabalho.
Todo um conjunto de variáveis reflete o conteúdo dos parâmetros de fluxo de trabalho comum, descritos anteriormente. Por exemplo, o $PSComputerName contém o valor do parâmetro - PSComputerName. Você também pode usar o $ParentJobName e $JobName para acessar informações sobre o trabalho. Se - PSComputerName contém vários valores, cada computador que executa o fluxo de trabalho verá apenas seu próprio nome em $PSComputerName. Verificar isso lista completa das variáveis para referência adicional.
Regras de variáveis
Lembre-se que variáveis em um fluxo de trabalho de trabalho um pouco diferente. Por exemplo, você não pode atribuir os resultados de uma subexpressão para uma variável. Em vez de:
$x = $(Get-Service)
Você acabou de executar:
$x = Get-Service
Além disso, você não pode atribuir um valor da variável para outra variável na mesma instrução:
$a = $b = 23
Você teria que fazer duas operações separadas. Além disso, você não pode colocar um objeto em uma variável e alterar as propriedades do objeto:
$obj = New-PSSessionOption $obj.SkipCACheck = $true
Seus próprios parâmetros e variáveis
Seus fluxos de trabalho naturalmente podem definir seus próprios parâmetros de entrada em um bloco de Param. Estes são expostos dentro do fluxo de trabalho como variáveis. Por exemplo, definir - MyParam dá-lhe uma variável $MyParam dentro do fluxo de trabalho. Apenas não adicione os parâmetros de fluxo de trabalho comum. Aqueles são magicamente adicionados pelo Windows PowerShell quando o fluxo de trabalho é executado.
Parâmetros comuns de atividade
Aqui está um pouco confuso — cada comando que você executa em um fluxo de trabalho, ou cada bloco de comandos que você executa em um bloco de {} InlineScript, é considerado uma atividade. Windows PowerShell adiciona parâmetros comuns para essas atividades, incluindo - PSComputerName. Porque estas atividades parecem com cmdlets normal, isso pode ser confuso. Por exemplo:
Get-Process –PSComputerName ONE,TWO,THREE
O cmdlet Get-Process normal tem um parâmetro - ComputerName, mas não um parâmetro - PSComputerName. O último é válido somente dentro de um fluxo de trabalho, onde Get-Process, tecnicamente, não é um cmdlet — é uma atividade de fluxo de trabalho. Um bloco de {} InlineScript suporta estes parâmetros:
InlineScript { Get-Process } –PSComputerName ONE,TWO,THREE
Os comandos dentro de {} InlineScript para o produto são apenas cmdlets. Eles não ficam a atividade parâmetros comuns. Finalmente e apenas para tornar as coisas mais confusas, qualquer comando que não tem um fluxo de trabalho equivalente a atividade irá ser empacotada implicitamente {} InlineScript para um produto, mas não pode usar os parâmetros de atividade comum. Por exemplo:
Get-WindowsFeature
Que é um comando, não é uma atividade de fluxo de trabalho. Não há nenhuma atividade equivalente disponível. Não é que você sabe que, porque não há nenhuma maneira de saber. Mas você não pode adicionar - PSComputerName-lo. Este é onde o fluxo de trabalho fica chato, porque não há nenhuma maneira para facilmente dizer o que é uma atividade e o que não é. Assim você não vai sempre saber, exceto para experimentá-lo e tê-lo a ter sucesso ou falhar.
Veja como isto fica complicado?
Isto é onde começa a trabalhar com fluxos de trabalho para se tornar difícil. Você tem todos esses bits extras acontecendo sob o capô. Enquanto a maioria são úteis, eles são não consistentemente aplicado. Você acaba com um monte de tentativa e erro.
Basta lembre que o fluxo de trabalho é um mundo diferente. Windows PowerShell é apenas fornecer uma porta de entrada para ele. Você não pode esperar a plena coerência com o ambiente normal do Windows PowerShell.
.jpg)
Don Jones é um receptor do prêmio de MVP do Windows PowerShell e um editor colaborador da TechNet Magazine. Ele é co-autor de quatro livros sobre o Windows PowerShell versão 3.0, incluindo os gratuitos sobre o Windows PowerShell remoting e criação de relatórios HTML no Windows PowerShell. Encontrá-los todos no PowerShellBooks.com, ou fazer perguntas de Jones nos fóruns de discussão em PowerShell.org.