Windows PowerShell: Краткий обзор удаленного управления в версии 2.0

У вас уже была возможность поэкспериментировать с последней версией CTP Windows PowerShell 2.0? В последней версии, CTP2, удаленное управление еще больше переработано, и теперь пришло время приступить к ознакомлению с ее новыми возможностями. Прежде чем приступить к рассмотрению Windows PowerShell 2.0, необходимо загрузить программу с веб-узла go.microsoft.com/fwlink/?LinkID=119707.

Прежде всего, позвольте мне уточнить ряд важных моментов. CTP – это предоставляемая корпорацией Майкрософт предварительная бета-версия кода, позволяющая нетерпеливым пользователям наподобие меня получить представление о направлении, в котором движется Майкрософт, при помощи следующей версии приложения. Каждая веха или выпуск CTP (как это называется в промышленности) может полностью отличаться от предыдущих выпусков. Это происходит потому, что группы разработки собирают отзывы пользователей, внимательно изучают их, а затем на основе этих отзывов вносят в приложение изменения. Такая методика обуславливает важное преимущество и ограничение использования CTP.

Преимущество заключается в том, что при использовании CTP вы можете предоставить отзыв (через веб-узел connect.microsoft.com) о продукте во время разработки, когда группа разработчиков может отреагировать на него! Если вы подождете до бета-версии или, что еще хуже, до стадии подготовки к выпуску, отреагировать на ваш отзыв гораздо сложнее. При подготовке к выпуску может случиться все, что угодно, и группа разработки при необходимости может внести большие и значительные изменения.

Это представляет для меня ограничение. Версия CTP не готова к выпуску. Конечно, версия CTP2 Windows PowerShell™ 2.0 может быть одной из самых устойчивых частей предварительной версии кода, которую вы когда-либо видели, но необходимо помнить, что следующая версия CTP может полностью отличаться от нее. Поэтому пока не следует полагаться на версию CTP2, потому что после выпуска следующей версии может потребоваться начать все сначала.

Имейте в виду, что версия CTP не может быть установлена вместе с Windows PowerShell 1.0. В идеале в системе также должна быть установлена платформа Microsoft® .NET Framework 3.5, чтобы обеспечить поддержку всех доступных функций. В противном случае функции будут ограничены.

Кроме того, поскольку версия CTP является очень ранней, пока корпорация Майкрософт уделяла основное внимание последним операционным системам, т.е. Windows Vista® и Windows Server® 2008. Совместимость с ОС в данный момент никоим образом не означает совместимости с ОС, которую можно ожидать в итоговом выпущенном коде. Портированию в более ранние версии уделяется внимание на последующих этапах цикла разработки.

Два типа удаленной работы

В мире удаленного управления обычно присутствуют два типа удаленного управления: удаленная работа слияния и развертывания. При удаленной работе слияния несколько администраторов подключаются к одному серверу по протоколу SSH. Windows PowerShell поддерживает подобное подключение безопасным и разделенным образом, чтобы, например, компания, размещающая Exchange Server, могла предоставить своим клиентам административный доступ к отдельным частям сервера. Удаленная работа слияния обеспечивает надежный удаленный интерактивный доступ к копии Windows PowerShell (только версии 2.0!), установленной на удаленном сервере.

Удаленная работа развертывания заключается в выдаче набора команд для группы удаленных серверов одновременно. Команды параллельно «разветвляются» с рабочей станции на группу серверов. Команды выполняются на всех серверах, а результаты — в форме объектов Windows PowerShell — возвращаются на рабочую станцию для просмотра и работы с ними. Windows PowerShell поддерживает две основные технологии для удаленной работы разветвления — инструментарий управления Windows® (WMI) и удаленное управление Windows (WinRM), которые впервые появились в составе Windows Server 2008, а затем были обновлены в версии CTP Windows PowerShell 2.0.

Синхронная и асинхронная

В действительности, еще в Windows PowerShell 1.0 существовали определенные возможности разветвления, привязанные к инструментарию управления WMI. Например, можно просто создать массив имен компьютеров, а затем получить из каждого класс WMI:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem 
    –computer $names

Для выполнения методов, например, перезагрузки компьютера, необходимы некоторые дополнительные действия, поскольку версия 1.0 не предоставляет способ массового выполнения методов WMI. Однако это изменилось в версии 2.0 CTP благодаря командлету Invoke-WmiMethod:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot

Однако этот метод имеет одну проблему. Он синхронный, что означает, что одновременно осуществляется обращение только к одному компьютеру, и для выполнения других команд необходимо подождать завершения. Но в версии CTP представлена новая концепция – фоновые задания, позволяющая выполнение подобных команд в фоновом режиме. В самом простом варианте команда WMI может быть выполнена в фоновом режиме простым добавлением параметра –AsJob:

$names = @("server1","server2","server2")  
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob 

Можно просмотреть состояние итогового задания, выполнив Get-PSJob, а окончательные результаты задания можно просмотреть, выполнив Receive-PSJob. (Управление заданиями будет рассмотрено более подробно в следующей статье.) Однако командлет Invoke-Command предоставляет лучшие способы выполнения команд в фоновом режиме, например следующий:

$command = { Get-WmiObject     Win32_OperatingSystem }  
$names = @("server1","server2","server2")  
Invoke-Command –command $command     –computer $names –asjob 

Таким образом, команда Get-WmiObject передается всем указанным компьютерам, затем выполняется локально. Обычное выполнение происходит гораздо быстрее без необходимости использования подключений RPC инструментария WMI. Вместо этого Invoke-Command использует WinRM, который по умолчанию использует порт 80 или 443. Эти порты упрощают перемещение брандмауэров и являются полностью настраиваемыми. Invoke-Command также поддерживает дополнительные параметры для альтернативных учетных данных и регулирования, позволяя работать с сотнями компьютеров при параллельной работе всего некоторых из них. Это позволяет избежать перегрузки и излишних издержек.

Повторно используемые пространства выполнения

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

$names = @("server1","server2","server2")  
New-RunSpace –computer $names 

Поскольку пространства выполнения также используют WinRM, они также по умолчанию используют порт 80 (или 443, если указан параметр –UseSSL). Они также должны принимать альтернативные учетные данные и т. д. При получении итоговых объектов пространства выполнения их можно передать командлету Invoke-Command, и Windows PowerShell передаст команду компьютерам, на которых существуют пространства выполнения:

$command = { Get-WmiObject     Win32_OperatingSystem }  
$rs = Get-Runspace  
Invoke-Command –command $command     –runspace $rs –asjob 

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

Удаленная работа слияния

Пространства выполнения также являются ключевыми объектами для удаленной работы слияния. Например, на рис. 1 показано созданное мною пространство выполнения на удаленном компьютере, полученная ссылка на это пространство выполнения и последующее использование командлета Push-Runspace для активации пространства выполнения. После этого я выполняю команды на удаленном компьютере аналогично тому, как позволяет SSH или средства удаленного интерпретатора команд. Выполнение Pop-Runspace возвращает исходное пространство выполнения «local», а командная строка оболочки помогает отслеживать местонахождение.

Рис. 1. Использование пространства имен для выполнения команд на удаленном компьютере (щелкните изображение, чтобы увеличить его)

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

PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"  
PS C:\>$server2 = get-runspace -sessionid 2  
PS C:\>push-runspace $server2  [win-yfzxqmhxawm]: 
PS C:\Windows\System32>    pop-runspace  
PS C:\>

Этот прием называется слиянием, поскольку одновременно удаленные интерактивные пространства выполнения на одном сервере могут быть открыты несколькими администраторами — происходит их «слияние» с отдельных рабочих станций на сервер. Новая модель безопасности в Windows PowerShell 2.0 позволяет создавать ограниченные интерпретаторы команд и командлеты, поэтому может быть запрещено внесение каждым администратором глобальных изменений. Каждый администратор ограничивается собственной областью в интерпретаторе команд. (Для этих новых методов обеспечения безопасности требуется установка определенного специального программного обеспечения на языке, предназначенном для платформы .NET Framework. Это выходит за рамки статьи о Windows PowerShell, но приятно знать, что такие возможности существуют.)

«Убойное» приложение в 2.0

В версию CTP Windows PowerShell 2.0 входит потрясающий список новых возможностей. По моему мнение, удаленная работа – это «убойное» приложение. Она выгода для всех администраторов практически во всех средах.

Вам следует ознакомиться с этими новыми функциями, чтобы вы могли предоставить свои предложения группе разработки. Вам необходимо управления портами WinRM по умолчанию через групповую политику? Должны ли командлеты работать по-другому? Присутствуют ли проблемы производительности? Достаточно ли просто осуществляется настройка WinRM? Вы можете внести свой вклад, отправив предложения на веб-узле connect.microsoft.com, или поделиться мнением с обладателями звания MVP, включая меня (чтобы связаться со мной, оставьте отзыв на форумах ScriptingAnswers.com). Поэтому примите участие и помогите в создании «убойного» приложения для Windows PowerShell следующего поколения!

Командлет месяца: Select-Object

Попробуйте выполнить следующую команду: Get-Service | ConvertTo-HTML | Out-File Services.htm. Теперь просмотрите полученный файл HTML в веб-обозревателе. Довольно много информации, не так ли? Если бы только существовал способ немного ограничить ее, выбрав только нужную информацию. Именно это выполняет командлет Select-Object. Например, предположим, необходим список имен служб и их текущего состояния. Можно использовать следующее: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.

Однако необходимо помнить только одно: командлет Select-Object сбрасывает исходный объект, в этом случае службы, и создает пользовательский объект (тип объекта PSCustom), содержащий только указанные свойства. Все функции исходного объекта более недоступны, поэтому, наверное, вам потребуется разместить Select-Object в конце конвейера, обеспечивая максимально долгую работу с объектом.