Windows PowerShellДержитесь за кресло!

Дон Джонс (Don Jones)

Содержание

Решение
Посмотреть в действии
Удаленное управление «один ко многим»
Даже не задумывайтесь
Удаленное управление в новом стиле

Меня всегда раздражали двойственные сообщения от Майкрософт по поводу управления серверами. С одной стороны правильно, когда нам говорят установить средства управления на собственные клиентские компьютеры и использовать их для управления серверами. Не нужно обращаться в центр обработки данных, и даже использование удаленного рабочего стола — это, по сути, жульничество, потому что это то же самое, что обращение в центр обработки данных, избегая лишь пешей прогулки. С другой стороны, существует множество задач по управлению серверами, которые не так уж легко выполнить, используя существующие средства удаленного доступа, например изменение IP-адреса или любых других сетевых параметров.

Вопросы и ответы по Windows PowerShell

В Можно ли использовать сценарий Windows PowerShell в качестве сценария входа?

О Да, но возможно это будет бессмысленно. Нельзя просто перетащить сценарий в объект групповой политики (GPO) как это можно сделать с файлом в VBScript. Вместо этого, следует просто создать пакетный файл, использующий Powershell.exe, который при прохождении параметра командной строки, сообщает ему, какой сценарий следует использовать. А это неуклюже. Придется также установить Windows PowerShell на каждом компьютере, на котором сценарий входа будет использоваться. И наконец, не забывайте, что Windows PowerShell гораздо более автономна нежели оболочка VBScript или оболочка Cmd.exe. Например, сопоставление диска с помощью командлета New-PSDrive не скажется на Windows Explorer и придется снова вернуться к команде Net Use, чтобы сопоставить диск уже в Windows. А если так, то почему бы уж тогда не использовать обычный пакетный файл, который гораздо проще включить в объект групповой политики.

В Можно ли создать расписание для сценария Windows PowerShell?

О Безусловно. На самом деле расписание создается для PowerShell.exe (расположенного в папке %systemroot% в директории /WindowsPowerShell) и для него задается параметр командной строки, который указывает, какой сценарий ему следует использовать. Убедитесь, что запланированное задание настроено на использование учетной записи пользователя, у которой есть соответствующие разрешения для действий сценария. А также убедитесь, что политика выполнения оболочки настроена на разрешение выполнения сценария (лично я предпочитаю политику AllSigned, которая означает, что сценарий должен иметь цифровую подпись; дополнительные сведения читайте в разделе Справка «О подписании»).

В Существует ли простой способ работы с разрешениями для файлов и папок в Windows PowerShell?

О Безусловно. В вашем распоряжении команды Get-ACL и Set-ACL. Get-ACL прекрасно подходит, если все что вам нужно это отчеты о разрешениях. По правде говоря, использование этих команд для изменения разрешений практически не применимо. Разрешения в Windows — зверь сложный, и программирование необходимое для создания списков управления доступом (ACL) — тоже задача непростая. Но кто сказал, что нужно использовать командлеты? Оболочка хороша для использования более традиционных средств командной строки, и различные итерации Cacls.exe (включая такие как Dsacls для Active Directory) прекрасно срабатывают изнутри Windows PowerShell. Я постоянно пользуюсь ими, когда мне нужно изменить или задать разрешения для папок.

Еще один прекрасный пример — это настройка установки Server Core. Добавление ролей, конфигурация сети, даже активация Windows производится из местного окна консоли или с помощью удаленного компьютера с помощью средств командной строки. Существующие на данный момент средства — эта либо специально созданные точечные решения для решения разовых задач, либо решения, для которых требуется знание инструментария управления Windows (WMI). Я предпочитаю инструментарий WMI, но откровенно говоря, для большинства администраторов это слишком сложное средство, требующее массу времени для изучения, и в основном оно остается невостребованным.

Windows PowerShell обещает все упростить, слегка облегчив в использовании инструментарий WMI, а также, что куда более важно, включив все административные задачи в гораздо более простые в использовании командлеты, приблизительно соответствующие служебным программам командной строки, которыми все уже пользуются на протяжении многих лет. Проблема оболочки в том, что помимо инструментария WMI, это в сущности местная оболочка. Многие основные командлеты конфигурации операционной системы не поддерживают связь с удаленным компьютером. Оболочка также не решает и более вопиющих проблем инструментария WMI, например использования удаленных вызовов для уделенного подключения. Удаленные вызовы — это проблема в средах, использующих брандмауэры (а где их нет в наши дни?), зачастую делающих инструментарий WMI бесполезным для любого удаленного управления.

Решение

Корпорация Майкрософт была в курсе этих недостатков достаточно давно, но не торопилась с выпуском всех необходимых исправлений в виде единого продукта. Таким продуктом является Windows PowerShell v2, включающий в себя удаленное управление Windows (WRM). Оба они впервые выдут в свет в Windows 7 и Windows Server 2008 R2, и оба будут по умолчанию установлены в обеих операционных системах.

Данные технологии также будут доступны для предыдущих версий, возможно до Windows XP. Но на момент написания данного материала официальных заявления о том, какие предыдущие версии операционных систем будут поддерживаться не было (чем старше ОС, тем сложнее задача для Майкрософт, поскольку более старые версии могут не иметь необходимых технологий).

WinRM — это основная технология, с помощью которой все это стало возможно. Применение корпорацией Майкрософт WS-MAN или веб-служб для управления, как подразумевается в самом названии, использующих для связи протоколы HTTP и HTTPS, означает более легкое прохождение трафика через брандмауэр. В отличие от RPC, которые начинают с некоей единой хорошо известной точки, а затем связь переходит в некий выбираемый в случайном порядке порт, протоколы HTTP и HTTPS используют один единственный порт. По умолчанию это порты 80 и 443, которые впоследствии можно изменить, если они вам не нравятся. WinRM дает возможность многим приложениям «прослушивать» входящие подключения, а Windows PowerShell v2 это то самое приложение, которое способно все это делать. (Лично мне кажется, что инструментарий WMI в конечном итоге может быть переведен на использование WinRM).

Фактически вы сидите за компьютером клиента и просите его связаться по протоколу SSH с удаленным компьютером. Это активирует WinRM на удаленном компьютере, что, в свою очередь, запускает экземпляр Windows PowerShell v2 на удаленном компьютере. Этот экземпляр оболочки может исполнять ваши команды и доставлять результаты обратно на ваш компьютер.

Посмотреть в действии

Официальные бета-выпуски Windows 7 стали первым случаем, когда весь мир мог ознакомиться с ними: Открыть сеанс Windows PowerShell на одном или на нескольких серверах и запустить Enable-PSRemoting, чтобы настроить WinRM и запустить службу WinRM. Затем, перейти на клиентский компьютер, на котором запущена Windows PowerShell v2 и запустить $session = New-PSSession computername, указав имя сервера, который был только что настроен для удаленного управления. Командлет New-PSSession может также принимать альтернативные учетные данные, если это требуется, а также может использовать нестандартные порты, если вы произвели соответствующую настройку.

Если вы видите длинное сообщение о программной ошибке, подобное приведенному на рис. 1, причина в способе проверки подлинности WinRM. По умолчанию он использует Kerberos, но в недоменной среде, такой, как на лабораторном компьютере на иллюстрации, Kerberos использовать нельзя. Когда Kerberos недоступен, WinRM требует использовать HTTPS-транспорт, что требует установки SSL-сертификата на сервере. Это делается для того, чтобы предоставить взаимную проверку подлинности между вами и сервером, и, таким образом, вы будете знать, что вы подсоединились к требуемому компьютеру. Даже определение уровня проверки подлинности как Basic или Digest в параметре проверки подлинности не окажет должного эффекта, поскольку WinRM хочет использовать HTTPS для шифрования этого трафика. Какое же самое простое решение? Будьте в домене Active Directory!

Рис. 1 Подобное длинное сообщение об ошибке может выводиться из-за способа проверки подлинности WinRM.

После активирования сеанса, вы можете начать использовать его. Сценарий Enter-PSSession $session подсоединит вас в режиме реального времени к удаленному серверу. Чудесным образом вы печатаете в его экземпляре Windows PowerShell. Команды выполняются интерактивно и вы немедленно видите результаты, в отличие от SSH или схожих технологий, часто используемых на UNIX-компьютерах.

Windows PowerShell даже производит некоторое шифрование по умолчанию, поэтому если не используется HTTPS, вы хорошо защищены от «подслушивания». Запустите Exit-PSSession чтобы отсоединиться от удаленной консоли и вернуться в свою локальную консоль. Командная строка оболочки даже меняется, когда вы подсоединены к удаленному компьютеру, в качестве индикации того, где вы находитесь.

Удаленное управление «один ко многим»

Возможность выполнять команды на одном компьютере замечательна, но как часто вам приходится делать что-то одно на одном сервере? Гораздо чаще мне приходится выполнять команду или набор команд на многих компьютерах. То что мы использовали до сих пор в Windows PowerShell v1 называется удаленное управление "один к одному" (1:1), то есть, один администратор управляет отдельным удаленным компьютером. Но оболочка shell также предлагает удаленное управление «один ко многим» (1:n), когда один администратор может управлять несколькими компьютерами. Фокус заключается в использовании параметра –computerName сеанса New-PSSession.

Я повторю свою прошлую команду, но на этот раз я распишу параметр, а не дам оболочке решать самой: Компьютер New-PSSession –computerName. Поскольку –computerName является позиционным параметром, мне не нужно было определять сам параметр ранее, но, сделав это сейчас, мы облегчим понимание этого приема: $sessions = New-PSSession –computerName (Get-Content c:\names.txt). Предположив, что файл C:\names.txt содержит список имен компьютеров, по имени компьютеру на каждую строку, оболочка создаст удаленный сеанс с каждым из них, сохраняя полный список сеансов в переменной $sessions.

По умолчанию сеансы создаются с использованием учетных данных, с которыми запускается Windows PowerShell то есть, либо учетной записи для входа или учетной записи, использованной мной с RunAs при запуске оболочки. Предупреждение: Если включен контроль учетных записей пользователей (UAC), обязательно запустите оболочку "как администратор" щелкнув правой кнопкой мыши на ее значок. Либо вы можете определить другое имя пользователя для сеансов, используя параметр команды –credential.

Как только у вас появился этот набор команд, вы можете продолжать работать с ними в режиме 1:1: Например, Enter-PSSession $sessions[0] свяжет вас с экземпляром оболочки первого компьютера. Но основные преимущества заключаются в выполнении команды на всех них сразу: Invoke-Command –scriptblock { ipconfig } 0 –session $sessions. Это запускает команду Ipconfig на всех компьютерах, к которым вы подключили сеанс и возвращает результаты на ваш компьютер. Это параллельно соединит ваши компьютеры, до 32 одновременно. Вы сможете изменить ограничение параллельного выполнения, использовав параметр –throttlelimit.

Даже не задумывайтесь

Разумеется, иногда вы будете запускать команды, которые выполняются не сразу, и, возможно, вам не захочется ожидать их завершения. В таких случаях, почему бы не включить оболочку в фоновом режиме? Всего лишь добавьте параметр –AsJob к Invoke-Command, и оболочка создаст фоновое задание.

Помните, что копия оболочки не выполняет особенно много работы; определенные вами команды выполняются на удаленных экземплярах Windows PowerShell. Ваша оболочка всего лишь ожидает, когда они завершат работу и собирает результаты, отправляемые ими. Эти результаты сохраняются в качестве задания. Запустите Get-Job, чтобы увидеть все текущие задания и их состояние (например, выполняются ли они все еще). Используйте Receive-Job, чтобы захватить результаты завершенного задания. Все может выглядеть следующим образом:

$sessions = New-PSSession –computerName (Get-Content c:\names.txt)
$job = Invoke-Command –scriptblock { your command(s) } –AsJob
Get-Job (to check the status)
$results = Receive-Job $job

Далее вы можете вывести $results, отфильтровать их, отсортировать и т. д. Каждый результат будет обладать прикрепленной информацией, чтобы вы смогли определить, с какого компьютера он поступил. Я рассмотрю фоновые задания (которые могут иметь и подзадания, с которыми вам придется иметь дело) в своей будущей статье.

Удаленное управление в новом стиле

Забудьте о старомодном удаленном управлении, заключавшимся в обращениях в центр данных или с использованием обходного пути с удаленным рабочим столом. Функции удаленного управления в Windows PowerShell v2 стали мощным и простым способом запуска любых команд на удаленных компьютерах. Не смотря на то, что я сосредоточил внимание на управлении сервером, те же методы также отлично подходят для задач управления рабочими столами, и это одна из причин, по которым Windows PowerShell v2 установлена в Windows 7, а также в Windows Server 2008 R2.

(Дон Джонс) Don Jones соучредитель Concentrated Technology пишет еженедельный блог о Windows PowerShell, SQL Server, App-V и на другие темы. Свяжитесь с ним через его веб-сайт.