[breakfruit]

Kazun, в общем скрипт отрабатывает без ошибок НО

Код:

$script:vmgroup=Get-VMgroups | where {$_.name -like "ad*"} | select -ExpandProperty ID

        Get-Rules -VMId $groupID | Export-Clixml -path c:\rules10.xml

$script:vmgroup2=Get-VMGroups | where {$_.name -like "web*"} | select -ExpandProperty ID
        Add-IPRule | Import-Clixml -path C:\rules10.xml

На этапе добавления правил - запрашвиает параметры для ввода. Практически все поля, указанные в экспортированном файле - обязательны для ввода, но командой командлетом фаервола - Import не воспринимается... Т.е. после выполнения Add-IPRule начинается запрос ввода данных.

Полагаю, что еще и парсинг XML придется почитать...

[Kazun]

Get-Help Add-IPRule -Full - смотрим какие параметры требуется передать командлету.

Код:

Import-Clixml -path C:\rules10.xml | Foreach {Add-IPRule -Name $_.Name -Action $_.Action}

[breakfruit]

Kazun, наводка отличная. Ман прочитал, но... Команда данная ровным четом не выполняет нужной функции, так как ADD-IPrule продалжает запрашивать необходимые параметры, но такой код

Код:

$script:vmgroup=Get-VMgroups | where {$_.name -like "ad.*"} | select -ExpandProperty ID

        Get-Rules -VMId $vmgroup | Export-Clixml -path c:\rules10.xml

$script:vmgroup2=Get-VMGroups | where {$_.name -like "web*"} | select -ExpandProperty ID

$script:inputdata=Import-Clixml -path C:\rules10.xml 



foreach ($VMid in $InputData)
         
         
         {
         Add-IPRule -VMId $vmid.vmid -Name $vmid.name -Action $vmid.action -Description $vmid.description -Protocol $vmid.protocol
         }

Делает то, что нужно, с оговоркой: правила дублируются в ту же группу, а не в другую. Я ужде в конец запутался. Вроде все корректно в коде. И поле нужное (VMId в данном случае указывает на ID группы) выцепил (проверил четырежды).

[breakfruit]

Нашел свою ошибку. Дальше пошли танцы со сторонним командлетом. Помечаю тему, как решенную. Всем спасибо за участие!

[greg zakharov]

...продалжает запрашивать необходимые параметры...

Если командлету передается довольно много параметров, то избежать головной боли - а главное спагетти-кода - можно, да и нужно, использовать тип Hashtable, например

Код:

PS> $par = @{
>> Path = 'E:\*'
>> Force = $true
>> }
>>
PS> gci @par

Особенно удобно использовать данный подход, как было сказано, при передаче большого количества параметров и дальнейшей отладке, не говоря уже о простоте "изъятия" одного из них.

[breakfruit]

greg zakharov, сейчас очень интересно, но я мало чего понял...

Т.е. я понимаю, о каких спагетти речь (они фактически и получились) - но все остальное....

[greg zakharov]

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

Код:

Invoke-Cmdlet -Param1 one -Param2 two ... -ParamN N

Иными словами, чем больше параметров, тем длиннее спагетти, а следовательно сложнее в отладке код. Чтобы сделать код более удобочитаемым параметры командлету можно передать в виде хэш-литерала, т.е. код выше можно переписать как:

Код:

$par = @{
  Param1 = 'one'
  Param2 = 'two'
  ...
  ParamN = N
}

Invoke-Cmdlet @par

Если по каким-то причинам какой-то из параметров оказался не нужел, достаточно его либо удалить из хэша, либо закомментировать.

[breakfruit]

greg zakharov, во. Я попоутно читаю, конечно же, литературу и блоги на тему PoSH. Т.е. мы создаем переменную и задаем значением оной - массив параметров? Или я путаюсь в определениях? Суть кода я понял, но (так как я ОЧЕНЬ далек от кодинга в принципе, и по образованию воообще никому не нужный гуманитарий :D ) в определениях, видимо, путаюсь.

[Iska]

breakfruit, верно. Только не «массив», а «хэш-таблица» (набор пар «имя-значение»).

[breakfruit]

Iska, и любой командлет (даже стороннего разработчика) будет его нормально воспринимать? Т.е. это приемущество непосредственно PoSH, которое не зависит от командлетов?