Windows PowerShell. Parametri comuni e variabili di runtime
Ogni mese dell'anno, Don Jones presenterà una puntata in un parte 12-tutorial su Windows PowerShell del flusso di lavoro. Ti invitiamo a leggere la serie nell'ordine, cominciando con il gennaio 2013 colonna.
Don Jones
Una delle cose pulite di un flusso di lavoro si è ottenere una tonnellata di funzionalità incorporate. Ad esempio, ogni flusso di lavoro che è scrivere in modo nativo sa come parlare a computer remoti tramite Windows PowerShell remoting (gestione remota Windows, conosciuto come WinRM).
Ciò significa che è possibile scrivere ogni flusso di lavoro per l'esecuzione sul computer locale, e si può remoto l'intera cosa. Le variabili e i parametri del flusso di lavoro comuni consentono di accedere a queste funzionalità nativa "scorciatoia".
Parametri del flusso di lavoro comuni
Questi sono tutti documentati nel file della guida di about_WorkflowCommonParameters, anche se è necessario importare manualmente il modulo PSWorkflow in Windows PowerShell 3.0 in ordine per quel file di aiuto per essere visibile. Qui è uno sguardo ad alcuni dei più comuni:
- -AsJob le forze del flusso di lavoro per l'esecuzione come un processo in background. Il parametro - JobName correlato consente di applicare un nome personalizzato per il lavoro.
- -PSAuthentication consente di specificare un meccanismo di autenticazione, come Kerberos o Credential Security Support Provider (CredSSP), per le connessioni remote. CredSSP è utile quando il flusso di lavoro ha bisogno di accedere a risorse locali non richiedono un'ulteriore rete "hop".
- -PSComputerName consente di specificare uno o più nomi di computer su cui si intende eseguire il flusso di lavoro. Ad esempio, - PSComputerName (Get-ADComputer-filtro * | Selezionare - espandere nome) vuoi eseguire il flusso di lavoro su tutti i computer del dominio. Si dovrebbe essere attenti con questo.
- PSConnectionRetryCount - specifica il numero di volte in cui che il flusso di lavoro tenta di connettersi a ogni computer remoto, e - PSConnectionRetryIntervalSec è il numero di secondi di attesa tra i tentativi.
- -PSCredential consente di specificare una credenziale alternativa per le connessioni remote.
- -PSParameterCollection consente di specificare un oggetto hashtable di parametri comuni del flusso di lavoro. Questo è difficile. È possibile specificare un elenco delimitato da virgole di tabelle hash, con ogni hashtable connessione a uno o più computer. Ad esempio, si specifica un numero di tentativi di connessione diversi per computer uno e due: -
PSParameterCollection, @{PSComputerName='ONE';PSConnectionRetryCount=10},@{PSComputerName='TWO';PSConnectionRetryCount=20}
- PSPort e - PSUseSSL consentono di specificare le porte alternative e facoltativamente abilitare SSL (supponendo che le macchine remote hanno un certificato SSL valido e WinRM listener configurati) per la connessione.
Ricordate, tutti i flussi di lavoro di ottenere queste opzioni. Non è necessario scrivere codice per farle funzionare. E sono liberi, che è impressionante.
Variabili del flusso di lavoro automatico
Tutti i normali Windows PowerShell variabili automatiche, ad esempio $Args, $Error, $MyInvocation, $PSBoundParameters e $PsCmdlet, sono disponibili all'interno di un flusso di lavoro. Flussi di lavoro molto più aggiungere in cima a che cosa Windows PowerShell fornisce:
- $PSParentActivityID fornisce un identificatore univoco per l'ambito corrente e per tutti gli ambiti del bambino. Questo consente di identificare in modo univoco ogni istanza di un flusso di lavoro, ad esempio quando si desidera registrare informazioni in un file centrale.
- $PSWorkflowRoot contiene il percorso della radice di un flusso di lavoro.
- $WorkflowInstanceID è l'identificatore univoco per l'istanza del flusso di lavoro.
Un intero set di variabili riflette il contenuto dei comuni parametri del flusso di lavoro descritti in precedenza. Ad esempio, $PSComputerName contiene il valore del parametro - PSComputerName. È inoltre possibile utilizzare $ParentJobName e $JobName per accedere alle informazioni di lavoro. Se - PSComputerName contiene valori multipli, quindi ogni computer che esegue il flusso di lavoro vedrà solo il proprio nome in $PSComputerName. Controllare questo elenco completo delle variabili per ulteriore riferimento.
Regole variabili
Ricordate che le variabili in un flusso di lavoro lavoro un po ' diverso. Ad esempio, è Impossibile assegnare i risultati di una sottoespressione a una variabile. anziché:
$x = $(Get-Service)
Basta eseguire:
$x = Get-Service
Inoltre, è non è possibile assegnare un valore variabile a un'altra variabile nella stessa istruzione:
$a = $b = 23
Si avrebbe a che fare come due operazioni distinte. Inoltre, non può mettere un oggetto in una variabile e modificare le proprietà di tale oggetto:
$obj = New-PSSessionOption $obj.SkipCACheck = $true
Proprio i parametri e le variabili
I flussi di lavoro naturalmente può definire i propri parametri di input in un blocco di Param. Queste sono esposte all'interno del flusso di lavoro come variabili. Ad esempio, definendo - MyParam ti dà una $MyParam variabile all'interno del flusso di lavoro. Basta non aggiungere i parametri del flusso di lavoro comuni. Quelli sono magicamente aggiunto da Windows PowerShell quando il flusso di lavoro viene eseguito.
Parametri comuni attività
Qui è un po ' di confusione — ogni comando si esegue in un flusso di lavoro, o ogni blocco di comandi si esegue in un blocco {} InlineScript, è considerato un'attività. Windows PowerShell aggiunge parametri comuni per tali attività, tra cui - PSComputerName. Perché queste attività sembrano cmdlet normale, questo può essere confusionario. Di seguito è riportato un esempio di utilizzo di questo attributo.
Get-Process –PSComputerName ONE,TWO,THREE
Il cmdlet Get-Process normale ha un parametro - ComputerName, ma non il parametro - PSComputerName. Quest'ultimo è valido solo all'interno di un flusso di lavoro, dove Get-Process non è tecnicamente un cmdlet, è un'attività flusso di lavoro. Un blocco {} InlineScript supporta questi parametri:
InlineScript { Get-Process } –PSComputerName ONE,TWO,THREE
I comandi all'interno del InlineScript {} sono soli i cmdlet. Non ottengono l'attività parametri comuni. Infine e solo per rendere le cose più confuse, qualsiasi comando che non ha un equivalente del flusso di lavoro attività verranno incapsulati in modo implicito in un {} InlineScript, ma non è possibile utilizzare i parametri di attività comuni. Di seguito è riportato un esempio di utilizzo di questo attributo.
Get-WindowsFeature
Che è un comando, non un'attività flusso di lavoro. C'è nessuna attività equivalente disponibili. Non si sa che, perché non non c'è nessun modo di dire. Ma non è possibile aggiungere - PSComputerName ad esso. Questo è dove il flusso di lavoro diventa fastidioso, perché non c'è alcun modo per facilmente dire che cosa è un'attività e cosa non lo è. Così non sempre saprete, ad eccezione di provarlo e farlo indipendentemente dall'esito.
Vedere come questo diventa difficile?
Questo è dove lavoro con i flussi di lavoro inizia a diventare difficile. Hai tutti questi bit extra accadendo sotto il cofano. Mentre la maggior parte sono utile, sei non costantemente implementati. Si finisce con un sacco di tentativi ed errori.
Basta ricordare, flusso di lavoro è un mondo diverso. Windows PowerShell fornisce solo un gateway ad esso. Non si può pretendere piena coerenza con l'ambiente di Windows PowerShell normale.
.jpg)
Don Jones è un Windows PowerShell MVP Award destinatario e un redattore di TechNet Magazine. Egli è coautore di quattro libri su Windows PowerShell versione 3.0, tra cui quelli gratuiti su Windows PowerShell remoting e creazione di report HTML in Windows PowerShell. Trovarli tutti a PowerShellBooks.com, o porre domande di Jones nei forum di discussione a PowerShell.org.