PowerShell в Orchestrator – Запуск x64, v4 PowerShell скриптов

Думаю, для тех, кто уже использовал System Center Orchestrator, не является секретом то что очень часто в процедурах приходится использовать скрипты PowerShell (или код C#, смотря что ближе, но сейчас не об этом). Однако, возможности Orchestrator в плане исполнения скриптов PowerShell местами ограничены. Так, например, Orchestrator использует только x86 версию PowerShell, да еще и версии 2, даже если установлен на Windows Server 2012 R2 где доступен PowerShell v4.

Удостовериться в этом можно выполнив такой код, и выведя результаты:

Разумеется, это вызывает проблемы если хочется воспользоваться возможностями новых версий PowerShell или использовать модули которые есть только в x64 версии. К счастью, для этой проблемы доступно несколько обходных решений.

Самый простой метод, это запустить PowerShell.exe, и выполнить скрипт в нём. Я модифицировал вышеприведённый код для использования этой возможности:

Тут можно видеть что хоть и есть некоторые проблемы в форматировании вывода (лишние переносы строк), но зато теперь доступна версия 4.0.

Другое решение, позволяющее добиться такого результата (и при этом сохранив вывод в должном качестве) – это воспользоваться PowerShell Remoting. При этом вовсе необязательно подключаться к другому компьютеру, можно подключиться и к localhost. Но сам Remoting конечно должен быть включен (например, командлетом Enable-PSRemoting). Вот что получается:

Обратите внимание, что нужно обязательно указать параметр –ComputerName, иначе профита не будет.

А что делать если необходимо выполнить достаточно большой скрипт, и при этом вернуть еще несколько переменных? Тут можно воспользоваться, например, встроенным типом данных PowerShell – Hashtable. Hashtable представляет из себя простой набор ключей и соответствующих значений.

На сегодня всё. Дальше будет больше

Teched 2012: Облака без бла-бла-бла v2012

Вот и пришло время очередного TechEd Russia — 2012. На этот раз я опять буду участвовать в докладе «Облака без бла-бла-бла», но теперь в названии уже есть «v2012» (код доклада — INF330). Помогать мне будет моя коллега из Microsoft Consulting Services — Елена Козылькова. Как и на предыдущем TechEd, доклад будет содержать минимум абстрактных и маркетинговых слайдов, зато в нём будет немало демонстраций и действительно интересного о том, почему SC Orchestrator является необходимым элементом «облаков» и других современных автоматизированных систем.

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

Разумеется, как и всегда, я буду очень рад услышать ваши вопросы. Задать их мне можно будет либо на сессии вопросов и ответов про System Center (INF 220RT), либо в любое другое время когда вы сможете меня поймать. Например я точно буду готов отвечать на ваши вопросы после своего доклада «Облака без бла-бла-бла«.

Политики System Center Orchestrator с TechEd Russia 2011

На прошедшем TechEd Russia 2011, мы с Артуром Гаффановым в процессе нашего доклада «Интеграция продуктов System Center: облака без бла-бла-бла» показали много интересных демонстраций возможностей System Center Orchestrator.
В частности были следующие демки:

Автоматическое добавление процессоров на виртуальные серверы по сигналу от System Center Operations Manager.

Автоматическая очистка временных файлов на диске виртуального сервера если там заканчивается место, а если временных файлов было не много — увеличение виртуального диска и расширение раздела.
Политика создающая Change Request в System Center Service Manager для тех компьютеров где требуется перезагрузка для установки обновлений и политика перезагружающая эти компьютеры после одобрения Change Request.
Бонусная политика, уничтожающая виртуальные машины в ЦОД по команде из твиттера 😉

Посмотреть запись доклада можно здесь.
А если вы захотите что-то из этих политик применить у себя (разумеется адаптировав под свои задачи) или просто посмотреть на них более подробно, то можете загрузить файл экспорта отсюда. Обратите внимание, политики в формате Orchestrator RC, c Orchestrator Beta или Opalis они работать не будут. Зато скорее всего их можно будет импортировать в финальную релизную версию Orchestrator, когда она выйдет.

Многопоточный сканер сети

Натолкнулся в форумах на просьбу написать сканер сети работающий в несколько потоков, но на скриптах Задачка показалась мне интересной и даже полезной, поэтому родился вот такой скриптик:

ThreadPing.ps1

Param (            
[string[]]$Address = $(1..20 | %{"192.168.1.$_"}),            
[int]$Threads = 5            
)            
            
write-host "Distributing addresses around jobs"            
$JobAddresses = @{}            
$CurJob = 0            
$CurAddress = 0            
while ($CurAddress -lt $Address.count)            
{            
    $JobAddresses[$CurJob] += @($Address[$CurAddress])            
    $CurAddress++            
    if ($CurJob -eq $Threads -1)            
    {            
        $CurJob = 0            
    }            
    else            
    {            
        $CurJob++            
    }            
}            
            
$Jobs = @()            
foreach ($n in 0 .. ($Threads-1))            
{            
    Write-host "Starting job $n, for addresses $($JobAddresses[$n])"            
    $Jobs += Start-Job -ArgumentList $JobAddresses[$n] -ScriptBlock {            
        $ping = new-object System.Net.NetworkInformation.Ping            
        Foreach ($Ip in $Args)            
        {            
            trap {            
                new-object psobject -Property {            
                    Status = "Error: $_"            
                    Address = $Ip            
                    RoundtripTime = 0            
                }            
                Continue            
            }            
            $ping.send($Ip,100) | select `
                @{name="Status"; expression={$_.Status.ToString()}},             
                @{name = "Address"; expression={$Ip}}, RoundtripTime            
        }            
    }            
}            
            
write-host "Waiting for jobs"            
$ReceivedJobs = 0            
while ($ReceivedJobs -le $Jobs.Count)            
{            
    foreach ($CompletedJob in ($Jobs | where {$_.State -eq "Completed"}))            
    {            
        Receive-Job $CompletedJob | select status, address, roundtriptime            
        $ReceivedJobs ++            
        sleep 1            
    }            
}            
            
Remove-Job $Jobs            
write-host "Done."

 

У скрипта два аргумента:

• Threads – число потоков
• Address – диапазон ip-адресов в виде массива строк. Например чтобы просканировать адреса с 192.168.1.1 по 192.168.1.254 можно использовать следующую конструкцию: 1..254 | ${"192.168.1.$_"}

Пример использования:

PS > .\ThreadPing.ps1 -Address (1..20|%{"192.168.1.$_"}) -threads 5
Distributing addresses around jobs
Starting job 0, for addresses 192.168.1.1 192.168.1.6 192.168.1.11 192.168.1.16
Starting job 1, for addresses 192.168.1.2 192.168.1.7 192.168.1.12 192.168.1.17
Starting job 2, for addresses 192.168.1.3 192.168.1.8 192.168.1.13 192.168.1.18
Starting job 3, for addresses 192.168.1.4 192.168.1.9 192.168.1.14 192.168.1.19
Starting job 4, for addresses 192.168.1.5 192.168.1.10 192.168.1.15 192.168.1.20
Waiting for jobs

Done.
Status   Address      RoundtripTime
------   -------      -------------
TimedOut 192.168.1.2              0
TimedOut 192.168.1.7              0
Success  192.168.1.12             1
TimedOut 192.168.1.17             0
Success  192.168.1.1              0
Success  192.168.1.6              1
TimedOut 192.168.1.11             0
TimedOut 192.168.1.16             0
Success  192.168.1.3             10
TimedOut 192.168.1.8              0
TimedOut 192.168.1.13             0
TimedOut 192.168.1.18             0
TimedOut 192.168.1.4              0
TimedOut 192.168.1.9              0
TimedOut 192.168.1.14             0
TimedOut 192.168.1.19             0
TimedOut 192.168.1.5              0
TimedOut 192.168.1.10             0
TimedOut 192.168.1.15             0
TimedOut 192.168.1.20             0

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

.\ThreadPing.ps1 -Address (1..254|%{"192.168.1.$_"}) -threads 20 | 
	where {$_.status -eq "success"}

A что бы выбрать лишь адреса, достаточно добавить Select –ExpandProperty

$IPs = 1..3 | %{$s=$_; 1..254 | %{"192.168.$s.$_"}}
.\ThreadPing.ps1 -Address $Ips -threads 20 | 
	where {$_.status -eq "success"} | 
		Select -expandproperty Address

 

Да, кстати, сценарий использует фоновые работы, поэтому будет работать только в PowerShell 2.0, но я надеюсь все мои читатели уже до него обновились

Запуск политик Opalis

В нашем Opalis’е уже завелась первая простенькая политика и в этом посте я расскажу каким образом её можно запустить и заставить работать

Запускать политику можно в нескольких режимах. Сначала мы рассмотрим первый и основной – режим выполнения на Action Server’е.

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

Чтобы запустить нашу политику в этом режиме, надо лишь подтвердить все изменения в ней нажав кнопку Check In, а затем кнопку Start на панели инструментов. Теперь политика будет выполняться на сервере, каждый час, как мы и задали в настройках её первого элемента.

Клиент Opalis в выполнении политики не учавствует, его можно спокойно закрывать – политика выполняется на Action Server.

Отслеживать результаты её выполнения можно с помощью закладок в нижней части клиента Opalis. Каждый запуск отображается на вкладке Log History как отдельная запись.

Дважды щелкнув на этой записи, можно просмотреть этапы выполнения политики:

Правда, не слишком подробно. В этом журнале отображается достаточно мало информации об элементах. Это разумное решение – незачем засорять базу данных подробностями выполнения элементов. Обычно достататочно лишь статуса и сообщения об ошибке если она произошла.

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

При тестировании политика выполняется не на Action Server, а на компьютере на котором установлен клиент Opalis (в случае если это разные компьютеры). Кроме того, при тестировании испольуется учетная запись текущего пользователя.

Для запуска политики в таком режиме, надо выбрать в панели инструментов клиента Opalis пункт Test. Откроется Policy Testing Console, специальный отладочный интерпретатор политик.

Давайте кратко рассмотрим его элементы. Во-первых это панель инструментов, позволяющая запустить политику на выполнение с автоматическим переходом с элемента на элемент или в пошаговом режиме. Кроме того можно создавать точки останова (breakpoint) на тех элементах на которых вы хотите приостановить выполнение.

На верхней правой части экрана останавливаться не будем, там всё достаточно очевидно – отображается политика и текущий выполняемый элемент.

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

В правой нижней части экрана есть возможность изучить группы компьютеров, переменные, счетчики и т.д. Они нам пока не нужны, о них я расскажу в другой раз.

Самое же интересное расположено в центре нижней части экрана. Это список выполнившихся шагов политики и текущего шага. Эти элементы можно развернуть, и просмотреть все свойства элемента политики (и настройки, и входные данные и выходные) и их значения.

На этом пока всё В следующем посте расскажу о других методов старта политики кроме запуска каждые n дней/часов/минут.