Одна из приятных вещей, касающаяся рабочего процесса, в том, что вы получаете массу встроенной функциональности. Например, каждый процесс, который вы пишете, на внутреннем уровне знает, как взаимодействовать с удаленными компьютерами посредством Windows PowerShell Remoting (удаленное управление Windows, известное как WinRM (Windows Remote Management)).
Это означает, что вы можете писать каждый рабочий процесс, предназначая его для выполнения на локальном компьютере, и то же самое делать удаленно. Общие параметры и переменные рабочего процесса позволяют получить доступ к этим встроенным «быстродоступным» средствам.
Общие параметры рабочего процесса
Все они описаны в справочном файле about_WorkflowCommonParameters, хотя вам нужно вручную импортировать модуль PSWorkflow в Windows PowerShell 3.0, чтобы сделать этот файл видимым. Вот несколько из часто используемых параметров:
- -AsJob заставляет рабочий процесс выполняться в качестве фонового задания. Связанный с ним параметр -JobName позволяет применять пользовательское имя задания.
- -PSAuthentication позволяет задавать для удаленного соединения механизм аутентификации, например, Kerberos или Credential Security Support Provider (CredSSP). CredSSP полезен, когда рабочему процессу необходимо получить доступ к нелокальным ресурсам, которые требуют дополнительного сетевого «перехода».
- -PsComputerName позволяет задать одно или несколько имен компьютеров, на которых вы планируете запускать рабочий процесс. Например, -PSComputerName (Get-ADComputer -filter * | Select -Expand Name) запустит рабочий процесс для всех компьютерах домена. Вы должны осторожно пользоваться этим параметром.
- -PSConnectionRetryCount задает число попыток рабочего процесса подключиться к каждому удаленному компьютеру, а -PSConnectionRetryIntervalSec — количество секунд ожидания между попытками.
- -PSCredential позволяет задать альтернативные учетные данные для удаленных соединений.
- -PSParameterCollection позволяет задать хеш-таблицу общих параметров рабочего процесса. Вы можете задать список хеш-таблиц с запятыми-разделителями, где каждая хеш-таблица соответствует подключению к одному или нескольким компьютерам. Например, ниже задается разное число попыток подключения для компьютеров ONE и TWO:
-PSParameterCollection, @{PSComputerName='ONE';
PSConnectionRetryCount=10}, @{PSComputerName='TWO';
PSConnectionRetryCount=20}- -PSPort и -PSUseSSL позволяют задать альтернативные порты и опционально включить SSL (в предположении, что удаленные компьютеры имеют действительный сертификат SSL и прослушиватель WinRM настроен) для соединения.
Помните, что все рабочие процессы получают эти параметры. Вам не нужно писать ни строки кода, чтобы они работали. И они бесплатны, что удивительно.
Автоматические переменные рабочего процесса
Все обычные автоматические переменные Windows PowerShell, такие как $Args, $Error, $MyInvocation, $PSBoundParameters и $PsCmdlet, доступны в рабочем процессе. Рабочие процессы добавляют еще немало переменных к тому, что предлагает Windows PowerShell:
- $PSParentActivityID предоставляет уникальный идентификатор для текущей области и для всех дочерних областей. Это позволяет однозначно идентифицировать каждый экземпляр рабочего процесса, например, когда вы хотите сохранять журнальную информацию в центральном файле.
- $PSWorkflowRoot содержит корневой путь рабочего процесса.
- $WorkflowInstanceID содержит уникальный идентификатор для экземпляра рабочего процесса.
Весь набор переменных отражает содержимое описанных выше общих параметров рабочего процесса. Например, $PSComputerName содержит значение параметра -PSComputerName. Вы также можете использовать $ParentJobName и $JobName для доступа к информации задания. Если -PSComputerName содержит несколько значений, то каждый компьютер, где выполняется рабочий процесс, увидит только свое имя в $PSComputerName. Подробнее см. полный список переменных.
Правила переменных
Помните, что переменные в рабочем процессе работают немного по-другому. Например, нельзя присвоить переменной результат подвыражения. Вместо:
$x = $(Get-Service)
вы просто выполняете:
$x = Get-Service
Кроме того, нельзя присвоить значение переменной другой переменной в том же выражении:
$a = $b = 23
Вы должны сделать это двумя операциями. Кроме того, нельзя поместить объект в переменную и изменять свойства этого объекта:
$obj = New-PSSessionOption $obj.SkipCACheck = $true
Ваши собственные параметры и переменные
В ваших рабочих процессах, конечно, можно вводить определения собственных входных параметров в блоке Param. В рабочем процессе они представляются в виде переменных. Например, определение -MyParam дает внутри рабочего процесса переменную $MyParam. Только не добавляйте общие параметры рабочего процесса. Их по волшебству добавляет Windows PowerShell при выполнении рабочего процесса.
Общие параметры действия
Тут можно слегка запутаться — каждая команда, которую вы выполняете в рабочем процессе, или каждый блок команд, выполняемых в блоке InlineScript{}, считается действием. Windows PowerShell также добавляет к этим действиям общие параметры, включая -PSComputerName. Поскольку эти действия выглядят как обычные командлеты, это может привести к путанице. Например:
Get-Process –PSComputerName ONE,TWO,THREE
Обычный командлет Get-Process имеет параметр -ComputerName, а не параметр -PSComputerName. Последний действителен только в рабочем процессе, где Get-Process технически не является командлетом — это действие рабочего процесса. Блок InlineScript{} поддерживает эти параметры:
InlineScript { Get-Process } –PSComputerName ONE,TWO,THREEКоманды внутри InlineScript{} являются просто командлетами. Они не получают общие параметры действия. Наконец, и просто чтобы еще больше запутать вас, любая команда, которая не имеет эквивалентного действия рабочего процесса, будет неявно обернута в InlineScript{}, но не может использовать общие параметры действия. Например:
Get-WindowsFeature
Это команда, а не действие рабочего процесса. Эквивалентное действие не доступно. И вы не узнаете об этом, потому что это невозможно узнать. Но вы не можете добавить к нему -PSComputerName. Вот где рабочий процесс досаждает, потому что нет простого способа выяснить, действие это или нет. Поэтому вы не узнаете это, пока не испытаете и не получите успех или неудачу.
Видите, как все усложняется?
Вот где становится труднее работать с рабочими процессами. Все эти дополнительные средства скрыты от вас под капотом. Несмотря на пользу большинства из них, они реализованы не последовательно. В итоге вам зачастую приходится работать методом проб и ошибок.
Просто помните, что рабочий процесс — это другой мир. Windows PowerShell лишь обеспечивает шлюз к нему. Не стоит ожидать полной согласованности с обычной средой Windows PowerShell.