sergey vasin

The IT blog

PowerShell Workflows: Используем параметры – Hey, Scripting Guy! Blog

leave a comment »

Резюме: Honorary Scripting Guy и Microsoft PowerShell MVP Richard Siddaway продолжает свою серию статей о рабочих процессах Windows PowerShell рассказом о параметрах.

Microsoft Scripting Guy, Ed Wilson на связи. Сегодня я публикую шестую часть в серии статей о рабочих процессах Windows PowerShell за авторством Windows PowerShell MVP и Honorary Scripting Guy Richard Siddaway.

Заметка: Первая статья, PowerShell Workflows: Основы рассказывает об основных концепциях рабочих процессов. Вторая, PowerShell Workflows: Ограничения, рассматривает ограничения, с которыми вы можете столкнуться при написании рабочих процессов. Третья статья, PowerShell Workflows: Вложения, рассказывает о вложении рабочих процессов. В четвертой статье, PowerShell Workflows – Механизм заданий, рассказывается о запуске рабочих процессов в качестве заданий Windows PowerShell. В пятой статье, PowerShell Workflows: Перезагрузка компьютера, затрагиваются вопросы перезагрузки компьютера при выполнении рабочего процесса. Перед тем как читать эту статью, вам стоит ознакомиться с предыдущими.

Richard Siddaway написал несколько гостевых постов, кроме этого он является автором двух книг по Windows PowerShell. Последняя его книга, PowerShell in Depth написана в соавторстве двумя другими MVP – Don Jones и Jeffrey Hicks.

Итак, Ричард.

В этой статье мы рассмотрим параметры, доступные для рабочих процессов и активностей, варианты подключения с удаленным компьютерам, а также командлеты для рабочих процессов. Давайте начнем с параметров.

Для рабочих процессов и активностей существует достаточное количество параметров. Они приведены в следующей таблице.

Parameter

Workflow

Activity

AppendOutput

Y

AsJob

Y

JobName

Y

Debug

Y

DisplayName

Y

ErrorAction

Y

Input

Y

MergeErrorToOutput

Y

PSActionRetryCount

Y

PSActionRetryIntervalSec

Y

PSActionRunningTimeoutSec

Y

PSAllowRedirection

Y

Y

PSApplicationName

Y

Y

PSAuthentication

Y

Y

PSAuthenticationLevel

Y

PSCertificateThumbprint

Y

Y

PSComputerName

Y

Y

PSConfigurationName

Y

Y

PSConnectionRetryCount   **

Y

Y

PSConnectionRetryIntervalSec   **

Y

Y

PSConnectionURI

Y

Y

PSCredential

Y

Y

PSDebug

Y

PSDisableSerialization

Y

PSElapsedTimeOutSec

Y

PSError

Y

PSParameterCollection

Y

PSPersist

Y

Y

PSPort

Y

Y

PSPrivateMetaData

Y

PSProgress

Y

PSProgressMessage

Y

PSRemotingBehavior

Y

PSRequiredModules

Y

PSRunningTimeOutSec

Y

PSSessionOption

Y

Y

PSUseSSL

Y

Y

PSVerbose

Y

PSWarning

Y

Result

Y

UseDefaultInput

Y

Verbose

Y

WarningAction

Y

**В документации сказано, что эти параметры могут применяться к активностям, однако тестирование показало, что активности их не поддерживают. Я полагаю, что это параметры рабочих процессов.

Я не буду здесь объяснять каждый из них, так как название большинства из них говорит само за себя. Также вы можете найти более подробную информацию по ним в двух следующих файлах справки:

about_WorkflowCommonParameters

about_ActivityCommonParameters

Некоторые параметры вы уже использовали в предыдущих статьях, например параметры для запуска рабочего процесса в качестве задания.

Рабочие процессы и удаленный доступ

Один из наиболее интересных параметров – это PSComputerName, который используется для подключения к удаленному компьютеру. Есть несколько вариантов. Первый – это указание компьютера на уровне рабочего процесса.

workflow test-remoteaccess {

Get-WmiObject -Class Win32_ComputerSystem

}

Заметьте, что в коде рабочего процесса не указывается имя компьютера. Однако, вы можете запустить этот рабочий процесс следующим образом:

PS> test-remoteaccess -PSComputerName server02, win732 | select Name, Manufacturer, Model

Name Manufacturer Model

—- ———— ——

SERVER02 LENOVO 4318CTO

WIN732 Microsoft Corporation Virtual Machine

Использование параметра рабочего процесса –PSComputerName приводит к тому, что имя компьютера передается всем активностям этот рабочего процесса. Этот способ удобен, если вы запускаете достаточно простой рабочий процесс и хотите, чтобы все его активности были выполнены на удаленном компьютере, однако, если вы получаете данные с нескольких компьютеров, вывод может быть довольно запутанным. Давайте рассмотрим следующий пример.

workflow test-remoteaccess {

Get-WmiObject -Class Win32_ComputerSystem |

Select-Object -Property Name, Manufacturer, Model

Get-Process

Get-Service

}

test-remoteaccess -PSComputerName server02, win732

Я получил данные в следующем порядке:

Data item First Second
WMI Server02 Win732
Process Server02 Win732
Service Server02 и Win732 вперемешку

Данные могут возвращаться в любом порядке, так как активности выполняются параллельно на нескольких компьютерах.

Таким образом, использование параметра рабочего процесса –PSComputerName отлично подходит для случаев, когда вам не так важен порядок вывода данных, или когда данные не выводятся вообще.

Когда вы используете параметр –PSComputerName, он фактически заменяет собой параметр командлета –ComputerName. Т.е. использование этого параметра не предоставляет вам еще один способ подключения. Кроме того, подключение происходит посредством механизма, используемого командлетом. Если удаленный компьютер не поддерживает этот механизм, рабочий процесс не сможет выполниться на этом компьютере. Давайте взглянем на пример, где вместо командлета Get-WmiObject мы будем использовать Get-CimInstance. Также не забудьте изменить имя параметра –Class на –ClassName.

workflow test-remoteaccess {

Get-CimInstance -ClassName Win32_ComputerSystem

}

Давайте запустим его на тех же самых компьютерах.

PS> test-remoteaccess -PSComputerName server02, win732

Name PrimaryOwnerName Domain TotalPhysicalMemory Model Manufacture PSComputerName

—- ———— —— ———— —— ———— ————

SERVER02 Windows … Manticor… 17108062208 4318CTO LENOVO server02

The WS-Management service cannot process the request. A DMTF resource URI was used to

access a non-DMTF class. Try again using a non-DMTF resource URI.

+ CategoryInfo : NotSpecified: (root\cimv2:Win32_ComputerSystem:String) []

, CimException

+ FullyQualifiedErrorId : HRESULT 0x80338139,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

+ PSComputerName : [localhost]

Рабочий процесс отработал на компьютере Server02, однако попытка его запуска на Win732 привела к появлению ошибки, сообщающей о проблеме с подключением по протоколу WSMan (WinRM). Командлеты WMI для подключения к удаленным компьютерам используют DCOM, однако командлеты CIM используют WSMan, и если быть более точным, WSMan весии 3.0, который входит в состав Windows PowerShell 3.0. Win732 – это компьютер под управлением Windows 7, с установленным Windows PowerShell 2.0. Варианты решения этой проблемы – установить на компьютер Windows PowerShell 3.0, использовать командлеты WMI или создать сессию CIM с использованием DCOM (эту тему мы сейчас рассматривать не будем).

Вернемся к вариантам запуска рабочего процесса на удаленных компьютерах. Вы также можете указать параметр –PSComputerName для активности.

workflow test-remoteaccess {

param(

[string[]]$computername

)

foreach -parallel ($computer in $computername) {

Get-WmiObject -Class Win32_ComputerSystem -PSComputerName $computer

}

}

Этот рабочий процесс содержит параметр, принимающий список имен компьютеров. Конструкция foreach –parallel используется для выполнения активностей на каждом из этих компьютеров. Как вы помните из первой статьи, выполнение на компьютерах из списка происходит параллельно, однако команды из блока foreach –parallel выполняются последовательно на каждом отдельном компьютере. В этом примере мы снова используем DCOM.

PS> test-remoteaccess -computername server02, win732 | select Name, Manufacturer, Model

Name Manufacturer Model

—- ———— ——

SERVER02 LENOVO 4318CTO

WIN732 Microsoft Corporation Virtual Machine

Теперь давайте рассмотрим сценарий, где командлеты, выполнение которых должно происходить на удаленных компьютерах, расположены в блоке InlineScript. Нужно понимать, что в этом случае вы работаете с командлетами, а не активностями, поэтому вы будете использовать присущий командлетам параметр –ComputerName.

workflow test-remoteaccess {

param(

[string[]]$computername

)

inlinescript {

foreach ($computer in $using:computername) {

Get-WmiObject -Class Win32_ComputerSystem -ComputerName $computer

}

}

}

Рабочий процесс обладает параметром computername, в качестве значения для которого указывается список имен компьютеров. Внутри блока InlineScript, конструкция foreach обрабатывает каждый компьютер из списка. Вам потребуется задать foreach следующим образом:

foreach ($computer in $using:computername)

Модификатор $using позволяет конструкции получить доступ к переменной, которая была определена в области действия (scope) выше по иерархии (информацию по переменным и их областям действия в рабочих процессах вы можете найти во второй статье). Рабочий процесс вызывается таким же образом, как и в предыдущем примере.

PS> test-remoteaccess -computername server02, win732 | select Name, Manufacturer, Model

Name Manufacturer Model

—- ———— ——

SERVER02 LENOVO 4318CTO

WIN732 Microsoft Corporation Virtual Machine

Как вы видите, существует несколько способов работы с именами компьютерами в рабочих процессах. Есть еще один способ, не перед тем перейти к его рассмотрению, вам нужно познакомиться с командлетами рабочих процессов.

Командлеты рабочих процессов

Модуль PSWorkflow нами уже упоминался. Его импорт, помимо файлов справки и возможности запуска рабочих процессов, также делает доступными два командлета. Существует еще один модуль – PSWorkflowUtility, в котором содержится один командлет – Invoke-AsWorkfow. Командлеты и модули приведены в следующей таблице.

Module Cmdlet/Function
PSWorkflow New-PSWorkflowExecutionOption New-PSWorkflowSession
PSWorkflowUtility Invoke-AsWorkflow

Командлеты, входящие в модуль PSWorkflow предназначены для работы с сессиями рабочих процессов. Вы можете считать сессии рабочих процессов неким аналогом удаленным сессиям, известным вам с Windows PowerShell 2.0. Если вы собираетесь запустить одну или две команды на удаленном компьютере, то, возможно, будет эффективнее создавать подключения по мере необходимости и разрывать их по завершении работы команды. Если же вам нужно запустить множество команд, каждой из которых потребуется создать подключение к удаленному компьютеру, то в этом случае более правильным будет создать удаленную сессию.

В файле справки к командлету New-PSWorkflowSession говорится: «Командлет New-PSWorkflowSession создает пользовательскую сессию («PSSession»), которая специальным образом предназначена для запуска рабочих процессов Windows PowerShell. Она использует конфигурацию сессий Microsoft.PowerShell.Workflow, включающую в себя скрипты, файлы типов и форматирования, а также опции, необходимые для рабочих процессов. Если возникнет такая необходимость, командлет New-PSWorkflowExecutionOption позволит вам определить дополнительные параметры конфигурации сессии рабочих процессов.

Если вы когда-либо создавали удаленную сессию в Windows PowerShell, вы не найдете ничего необычного в создании сессии рабочих процессов.

$wkfsess1 = New-PSWorkflowSession -ComputerName server02, win732

$wkfsess1

$sb ={

Import-Module PSWorkflow

workflow test-remoteaccess {

Get-WmiObject -Class Win32_ComputerSystem |

select -Property Name, Manufacturer, Model

}

test-remoteaccess

}

Invoke-Command -Session $wkfsess1 -ScriptBlock $sb

Команды, которые вы собираетесь запустить в рамках сессии помещаются в скриптблок. Для запуска команд в рамках сессии используется командлет Invoke-Command.

Invoke-Command -Session $wkfsess1 -ScriptBlock $sb

New-PSSession : [win732] Connecting to remote server win732 failed with the following error

message : The WS-Management service cannot process the request. Cannot find the

Microsoft.PowerShell.Workflow session configuration in the WSMan: drive on the win732 computer.

For more information, see the about_Remote_Troubleshooting Help topic.

At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSWorkflow\PSWorkflow.psm1:58 char:9

+ New-PSSession -ConfigurationName Microsoft.PowerShell.Workflow @PSBoundP …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-

PSSession], PSRemotingTransportException

+ FullyQualifiedErrorId : InvalidResourceUri,PSSessionOpenFailed

Id Name ComputerName State ConfigurationName Availability

— —- ———— —— —————— ————

5 Session5 server02 Opened Microsoft.PowerSh… Available

WARNING: [localhost]:This workflow job cannot be suspended because there are no persistence points

in the workflow. To make the workflow job suspendable, add persistence points to the workflow.

For more information, see the Help topics for Windows PowerShell Workflows.

Name : SERVER02

Manufacturer : LENOVO

Model : 4318CTO

PSSourceJobInstanceId : 78ab3c45-a8f6-428d-a4a4-92aff9df257d

PSComputerName : server02

RunspaceId : 6595de20-5cc3-41fa-9cb7-da0f40f1f0e0

Ой. Это один их недостатков сессий рабочих процессов – вы можете их использовать только если на удаленном компьютере установлен Windows PowerShell 3.0. Если мы посмотрим на точки подключения на компьютере с Windows Server 2012, на котором по умолчанию установлен Windows PowerShell 3.0 (WSMan 3.0), то мы увидим:

PS> ls WSMan:\localhost\Plugin | select name

Name

—-

Event Forwarding Plugin

microsoft.powershell

microsoft.powershell.workflow

microsoft.powershell32

microsoft.windows.servermanagerworkflows

SEL Plugin

WMI Provider

На компьютере с Windows 7 и Windows PowerShell 2.0 (WSMan 2.0) мы получим следующее:

PS> ls WSMan:\localhost\Plugin | select name

Name

—-

Event Forwarding Plugin

microsoft.powershell

WMI Provider

К сожалению, обойти это ограничение не получится и вам придется использовать параметры ComputerName и PSComputerName, рассмотренные в предыдущих примерах.

Теперь давайте рассмотрим командлет Invoke-AsWorkflow. Он отлично подходит для тестирования кода посредством рабочих процессов. Возьмем простой скрипт.

$exp = «Get-WmiObject -Class Win32_ComputerSystem |

select -Property Name, Manufacturer, Model»

Вы можете запустить его в виде рабочего процесса следующим образом:

Invoke-AsWorkflow -Expression $exp -PSComputerName server02, win732

До того, как вы подумали, что командлет Invoke-AsWorkflow – это способ превращения любого кода в рабочий процесс, хочу сказать, что этот командлет не предлагает всей функциональности рабочих процессов, потому как запускает переданные команды внутри блока InlineScript. То есть, вы не сможете использовать такие возможности, как, например, параллельное выполнение команд – одно из самых значительных преимуществ рабочих процессов.

Резюме

В этой статье был приведен ряд параметров рабочих процессов, и то, как они могут быть использованы для запуска рабочих процессов или активностей. Вы увидели, как имена компьютеров могут быть указаны для рабочего процесса, активности или сессии рабочих процессов. Также был рассмотрен командлет Invoke-AsWorkflow, позволяющий тестировать код, используя рабочие процессы.

В следующей статье мы рассмотрим некоторые рекомендации по использованию рабочих процессов, а также ряд вопросов, касающихся их построения.

~Richard.

Автор:

Ed Wilson, Microsoft Scripting Guy

Оригинал:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/30/powershell-workflows-using-parameters.aspx


Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell


Реклама

Written by Сергей Васин

Март 21, 2013 в 11:58

Опубликовано в HeyScriptingGuyBlog, PowerShell

Tagged with ,

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s