Главная Windows, Без рубрики, Новое Active Directory, PowerShell, Windows 2008 R2
  • Типовые задачи администрирования AD с использованием PowerShell

    monolisa-ascii_thumbВсем администраторам Active Directory периодически приходится сталкиваться с рутинными задачами, которые хотелось бы так или иначе автоматизировать. Как правило, это делается с использованием скриптов на наиболее известных языках программирования: VBScript, Jscript, PowerShell. Последний я считаю наиболее удобным. Благодаря некоторым из его особенностей те же процедуры, которые занимают в VBScript десяток строк и требуют понимания работы WMI, LDAP и еще многих китайских слов – в PowerShell занимает всего пять строк и требуют всего лишь знания программирования на уровне школьных уроков информатики. В настоящей статье мы рассмотрим типовые задачи администрирования Active Directory, и их автоматизацию с помощью PowerShell.

    P.S. Статья рассчитана на полных, или почти полных «чайников», пару раз видевших или где-то слышавших о PowerShell. На звание Терминатора не претендую, по сему просьба ногами не пинать.

     

    Общие положения

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

    В первую очередь, необходимо заметить, что для того, чтобы все нормально работало – необходимо иметь хотя бы один контроллер домена Windows Server 2008 R2 с установленной компонентой ActiveDirectory Web Services. Увы и ах, Windows Server 2003 уходит на свалку истории. Для работы с модулем ad_powershell необходимо установить Remote Server Administration Tools, его так же можно установить на рабочем компьютере и запускать скрипты оттуда. Разумеется, ОС на компьютере должна быть не ниже Windows 7. На контроллерах домена Windows Server 2008 R2 необходимые компоненты уже установлены.
    Перед тем, как выполнять скрипты – необходимо установить политику выполнения скриптов. По умолчанию, в целях безопасности включена политика Restricted, что означает, что на данном компьютере вообще запрещен запуск любых PowerShell-скриптов. О том, какие еще бывают политики выполнения – можно почитать в мануале:

    Get-Help Set-ExecutionPolicy –Detailed

    В нашем случае я рекомендую установить политику RemoteSigned, что позволит запускать любые собственноручно написанные скрипты, при этом запуск скриптов, скачанных из Интернета будет возможен только при наличии цифровой подписи с доверенным сертификатом. Запустите оболочку PowerShell с правами администратора (Run as Administrator) и выполните команду

    Set-ExecutionPolicy RemoteSigned

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

    Теперь можно проверить работу скриптов – написать простейший скрипт «Hello World!». Я предпочитаю пользоваться PowerShell ISE, хотя можно писать и в простейшем Notepad’е. PowerShell ISE – удобная среда програмирования для PowerShell с возможностью отладки. Входит в состав ОС Wondows 7 и 2008 R2. Вобщем, рекомендую.

    image

    Теперь переходим непосредственно к автоматизации. Для того, чтобы создать объекты в Active Directory, или изменить какие-либо свойства, нам необходим список объектов со всеми необходимыми параметрами. Например, список пользователей может содержать следующие парамеры: Имя, Фамилия, Логин, Пароль. Проще всего для этого использовать CSV-файл. CSV – это текстовый файл, содержащий список объектов (например – пользователей), с разделением параметров каким-либо символом (как правило, это запятая «,», хотя может быть и точка с запятой, знак табуляции и т.д.). Каждый объект обозначается одной строчкой. Так же, первая строчка может содержать список параметров.

     

    Пример:

     

    Name;Surname;Login;Password

    Ivan,Ivanov;i.ivanov;p@ssw0rd1

    Petr,Petrov;p.petrov;p@ssw0rd2

    Sidor;Sidorov;s.sidorov;p@ssw0rd3

     

    Чтобы получить список объектов из CSV-файла, используется командлет Import-CSV:

    $Users = Import-CSV “c:\temp\users.csv”

    Такой файл можно создать и в блокноте, но проще всего будет использовать Microsoft Excel. В Excel необходимо при сохранении файла выбрать формат CSV. Интересно, что Excel при сохранении в формат CSV в качестве разделителя использует знак “;”, хотя вроде бы написано «CSV (разделители – запятые)». PowerShell же по умолчанию считает, что в качестве разделителя используется запятая («,»). Чтобы наш скрипт работал корректно – необходимо либо заменить в CSV-файле все точки с запятой на запятые (используя автозамену в блокноте) либо же, что на мой взгляд правильнее – указать в скрипте использовать точку с запятой в качестве разделителя:

    $Users = Import-CSV “c:\temp\users.csv” –Delimiter “;”

    Чтобы проверить, как прошел импорт – можно посмотреть, что хранится в переменной $Users.

    image

    Как видим, в переменной $Users теперь хранится массив объектов с параметрами Name, Surname, Login, Password. Эти параметры можно использовать для создания учетных записей пользователей в AD.

    Прежде чем приступить к работе с Active Directory, необходимо произвести импорт соответствующего модуля в PowerShell. Только после этого появятся команды для работы с AD:

    Import-Module ActiveDirectory

    Эту строку можно (и даже нужно) вставлять в начало всех скриптов – чтобы не вводить эту команду вручную.

     

    Создание учетных записей пользователей

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

    Для нашего примера, в качестве списка пользователей будем брать CSV-файл со следующими полями:

     

    • Name – имя пользователя
    • Surname – фамилия пользователя
    • Password – пароль
    • OU – организационное подразделение, где будет находиться пользователь (вида Contoso_Users/Fin/Accounting)

     

    Вначале нам нужно импортировать пользователей из списка:

    $Users = Import-CSV $1 –Delimiter “;”

    Параметр $1 означает, что в качестве пути к CSV-файлу будет использоваться первый по счету параметр командной строки. Запускаться скрипт будет следующим образом:

    PS C:\Users\admin > Add_Users.ps1 c:\temp\users.csv

    Далее нам нужно пройтись по всему массиву пользователей из списка:

    Foreach($CurrentUser in $Users) {

    Знак открытой фигурной скобки означает начало цикла. Этот цикл проходит по всем объектам списка, и прискаивает текущий объект переменной $CurrentUser.

    Затем, для упрощения – присвоим значения соответствующих полей отдельным переменным:

     

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Password = $CurrentUser.Password

    $OU = $CurrentUser.OU

     

    Для того, чтобы задать пароль пользователю – необходимо перевести его в шифрованный формат SecureString:

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    Так же, OU нам нужно перевести в формат, соответствующий стандарту LDAP (для примера выше: “OU=Accounting,OU= Fin,OU= Contoso_Users,DC=contoso,DC=com”).

     

    Для этого вначале разделим строку $OU на отдельные составляющие:

    $OUTmp = $OU –Split “/”

     

    В результате переменная $OUTmp будет содержать массив из всех элементов пути:

    PS C:\Users\admin> $OUTmp

    Contoso_Users

    Fin

    Accounting

     

    Далее, используя командлет Foreach-Object, получим из нашего массива первую часть LDAP-пути:

     

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

     

    В переменной $Path появляется первая часть LDAP-пути:

     

    PS C:\Users\admin> $Path

    OU=Accounting,OU=Fin,OU=Contoso_Users,

     

    Теперь нам нужно получить полный путь, добавив к пути домен:

     

    $Path += “DC=contoso,DC=com”

    Получили полный LDAP-путь:

    PS C:\Users\admin> $Path

    OU=Accounting,OU=Fin,OU=Contoso_Users,DC=contoso,DC=com

     

    Теперь сформируем дисплейное имя пользователя, его логин, User Principal Name.

     

    $Login = $Name[0] + “.” + $Surname #логин формируется из первой буквы имени и фамилии, например: i.ivanov

    $Displayname = $Name + “ “ + $Surname #Дисплейное имя: Ivan Ivanov

    $UserPrincipalName = $Login + “@contoso.com

     

    Наконец, можно перейти к самой главной процедуре: созданию учетной записи пользователя.

     

    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

    Здесь, в принципе, все параметры понятны. Параметр -ChangePasswordAtLogon 1 означает, что пользователю будет предложено сменить пароль сразу после логина.

    По умолчанию в PowerShell, в отличие от стандартного визарда в оснастке ActiveDirectory Users And Computers учетные записи только что созданных пользователей будут отключены (Disabled). Поэтому сразу после создания учетные записи нужно включить:

    Enable-ADAccount $Login

    Теперь нужно закрыть цикл знаком «}». Можно сохранять скрипт и пробовать.

    Готовый скрипт будет выглядеть следующим образом:

     

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Password = $CurrentUser.Password

    $OU = $CurrentUser.OU

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    $OUTmp = $OU –Split “/”

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

    $Path += “DC=contoso,DC=com”

    $Login = $Name[0] + “.” + $Surname

    $Displayname = $Name + “ “ + $Surname #в кавычках – пробел!

    $UserPrincipalName = $Login + “@contoso.com”

    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

    Enable-ADAccount $Login

    }

     

    Создание учетных записей компьютеров

    Как известно, для работы с Active Directory перво-наперво необходимо вводить компьютеры в домен. Сделать это можно двумя способами:

    · Мышкой – самый известный способ, через «Свойства» «Моего компьютера». Легко и просто.

    · Командой netdom join. Тоже несложно, и можно использовать в скриптах.

    У первого способа есть существенный недостаток: учетные записи компьютеров создаются в дефолтном OU Computers. В организациях же, как правило имеются разные OU для разных типов компьютеров (сервер, десктоп, ноутбук), а так же отдельные OU для разных отделов/департаментов/и т.д., с различными групповыми политиками, действующими для разных OU. Поэтому после ввода компьютеров в домен необходимо переносить учетные записи компьютеров вручную в соответствующий OU, а затем перезагружать компьютер еще раз, чтобы на нем применились все необходимые политики. При использовании команды netdom можно указать нужное OU, но набирать все это с клавиатуры – та еще задачка, особенно – когда компьютеров много, и особенно, что часто бывают – задачку эту поручают простым эникейщикам. Где-то в какой-то букве обязательно ошибется.

    Самый лучший выход из этой ситуации – создать учетные записи компьютеров заранее, в соответствующих OU. Тогда компьютер сразу после ввода в домен и перезагрузки применит все соответствующие политики.

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

    Для учетных записей, как и для компьютеров, используем CSV-файл

    ComputerName;OU

    Server1;Cnotoso_Computers/Servers

    Server2;Cnotoso_Computers/Servers

    Desktop1;Cnotoso_Computers/Desktops

    Desktop2;Cnotoso_Computers/Desktops

    Desktop3;Cnotoso_Computers/Desktops

    Laptop1;Cnotoso_Computers/Laptops

     

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

     

    Import-Module ActiveDirectory

    $Computers = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentComputer in $Computers) {

    $ComputerName = $CurrentComputer.ComputerName

    $OU = $CurrentComputer.OU

    $OUTmp = $OU –Split “/”

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

    $Path += “DC=contoso,DC=com”

    New-ADComputer –Name $ComputerName –Path $Path

    }

     

    Массовый сброс паролей

    Иногда бывает необходимо массово сбросить пароли у множества пользователей.

    Структура CSV-файла:

    • Login – логин пользователя
    • NewPassword – новый пароль

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Login = $CurrentUser.Login

    $NewPassword = $CurrentUser.NewPassword

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    Set-ADAccountPassword –Identity $Login –Reset –NewPassword $SecurePwd

    }

     

    Массовое изменение параметров

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

     

    • Имя
    • Фамилия
    • E-Mail
    • Телефон
    • Организация (у компании несколько юр.лиц)
    • Должность

     

    Из нее мы создаем CSV-файл с полями:

     

    • Name
    • Surname
    • E-Mail
    • Phone
    • Organization
    • JobTitle

     

    Скрипт будет следующего вида:

     

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Email = $CurrentUser.E-Mail

    $Phone = $CurrentUser.Phone

    $Organization = $CurrentUser.Organization

    $JobTitle = $CurrentUser.JobTitle

    $Login = (Get-ADuser –Filter {GivenName –eq $Name –and Surname –eq $Surname}).SamAccountName #ищем юзера с заданным именем и фамилией и возвращаем его логин

    Set-ADUser $Login –EmailAddress $Email –MobilePhone $Phone –Company $Organization –Title $JobTitle

    }

     

    Заключение

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

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

    Например:

     

    • Добавить обработку ошибок (например, если пользователь с таким именем уже существует, или наоборот – не существует) – конструкции типа try… catch…
    • Автоматическую генерацию паролей заданной длины и сложности
    • Вывод логинов с автоматически сгенерированными праолями для только что созданных учетных записей в CSV-файл – командлет Export-CSV

     

    Ресурсы

    Эти ресурсы очень сильно помогут в изучении PowerShell. Во всяком случае мне они помогли.

    Надеюсь, эта статья была вам полезна, и кто-то, кто раньше боялся консоли – перестанет ее бояться. Улыбка

    Александр Косивченко

    • Ресурсы по Poweshell

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

    • Главная Windows, Без рубрики, Новое PowerShell, Windows 2008 R2
      • Эволюция ntbackup в wbadmin

        backupgСтарая истина – “бэкапы не нужны до того времени пока они не понадобятся” актуальна всегда и постоянно. Со времен Windows NT для архивации и восстановления использовалась утилита NTBackup. Проблем с ней не возникало и она верой и правдой служила долгие годы. Настройки были просты и производились как в графическом интерфейсе так и в командной строке. Синтаксис был простой, наприме для того что бы выполнить бэкап System State (состояния системы) достаточно было воспользоваться командой: NTBACKUP backup systemstate /f “D:\Backup\SystemState-backup.bkf”

        • Регулярные выражения в Windows PowerShell

          Введение

          regexp-0 Мне достаточно часто задают вопросы связанные не столько с самим PowerShell, сколько с применением в нем регулярных выражений. Это и понятно – регулярные выражения (или если сокращенно “регэкспы” (regexp, regular expressions)) обладают огромной мощью, и способны сильно упростить жизнь системного администратора или программиста. Однако в мире системного администрирования Windows они мало известны и непопулярны – в cmd.exe практически единственная возможность их применения это утилита findstr.exe, которая обладает очень маленьким функционалом и использует жутко урезанный диалект регулярных выражений. В VBScript функционал регулярных выражений тоже хорошо запрятан, и практически не используется. А вот в PowerShell, авторы языка позаботились о том чтобы регулярные выражения были легко доступны, удобны в использовании и максимально функциональны. Тем более что с последним пунктом всё оказалось достаточно просто – PowerShell использует реализацию регулярных выражений .NET, а она является одной из самых функциональных и производительных, и даже способна потягаться даже с признанным лидером в этой области – perl’ом 🙂

        • Главная Windows, Без рубрики, Новое PowerShell, remote execution
          • 7 способов выполнить команду на удалённом компьютере

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

            Так как задача эта популярная, то и способов её решения существует множество. Начиная от групповых политик (в которых можно применять для этой цели сценарии входа в систему или автозагрузки), и заканчивая мощными системами управления, вроде System Center Essentials или System Center Configuration Manager. Но я в этой статье хочу рассмотреть методы, которые доступны сразу из командной строки или файлов сценариев, а так же не требуют предварительной установки агентов и прочей суматохи. Впрочем, какие-то предварительные требования конечно есть. Например, у вас должны быть административные полномочия на том компьютере, на котором вы хотите выполнить команду (за исключением сценария с «проксированием», но об этом позже).

            PsExec.exe

            Один из моих любимых способов для решения этой задачи это утилита командной строки PsExec.exe написанная Марком Руссиновичем, которую вы можете свободно скачать с сайта Windows SysInternals. Ссылку на неё вы можете найти в конце статьи. Она не требует установки в систему, вы можете просто скопировать её в одну из папок, содержащихся в переменной окружения %path% и вызывать из любой оболочки командной строки: Cmd или PowerShell.

            Использовать PsExec очень просто. Например, чтобы выполнить ipconfig /flushdns на компьютере main, достаточно запустить следующую команду:

            psexec \\main ipconfig /flushdns

            Команда ipconfig будет запущена на компьютере main под вашими учетными данными. После завершения работы ipconfig весь текстовый вывод будет передан на ваш компьютер, а кроме того будет возвращён код выхода команды (error code). В случае если команда выполнилась успешно, он будет равен 0.

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

            Ключ -d говорит PsExec что ненужно дожидаться выполнения команды, а достаточно лишь запустить её, и забыть. В этом случае мы не получим выходных данных от консольной утилиты, но зато сможем не дожидаясь завершения предыдущей команды запускать другие. Это очень полезно, если вам необходимо запустить, например установщик программы на нескольких компьютерах.

            По умолчанию PsExec выполняет команды в скрытом режиме, то есть на системе где выполняется команда, не будут выводиться никакие окна или диалоги. Однако есть возможность изменить это поведение, с помощью ключа -i . После него можно указать номер сессии, в которой выводить окна, а можно и не указывать, тогда интерфейс будет отображен в консольной сессии.

            Таким образом, чтобы вывести окно с информацией о версии операционной системы на компьютере main, следует запустить PsExec таким образом:

            psexec -i \\main winver.exe

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

            psexec @c:\comps.txt systeminfo.exe

            Ну и одной из самых полезных способностей PsExec является возможность интерактивного перенаправления ввода/вывода между компьютерами, что позволяет нам запустить, например cmd.exe на удалённом сервере, а давать ему команды и получать результаты на локальном компьютере.

            Каким образом работает PsExec?

            Всё гениальное просто. В ресурсах исполняемого файла PsExec.exe находится другой исполняемый файл – PSEXESVC, который является службой Windows. Перед выполнением команды, PsExec распаковывает этот ресурс на скрытую административную общую папку удалённого компьютера, в файл: \\ИмяКомпьютера\Admin$\system32\psexesvc.exe. Если вы с помощью ключа -c указали что необходимо скопировать исполняемые файлы на эту систему, они тоже скопируются в эту папку.

            По завершению подготовительных действий, PsExec устанавливает и запускает службу, используя API функции Windows для управления службами. После того как PSEXESVC запустится, между ним и PsExec создаётся несколько каналов для передачи данных (вводимых команд, результатов, и т.д.). Завершив работу, PsExec останавливает службу, и удаляет её с целевого компьютера.

            Windows Management Instrumentation (WMI)

            Следующий способ реализации этой популярной задачи, о котором я хочу поведать – использование Windows Management Instrumentation. WMI присутствует во всех операционных системах Microsoft, начиная с Windows 2000, и даже на Windows 9x его можно установить из отдельного пакета. WMI включён по умолчанию, и не требует дополнительной настройки. Для его использования достаточно административных прав, и разрешенного на брандмауэре протокола DCOM. WMI предоставляет огромные возможности для управления системами, но нас сейчас интересует лишь одна из них.

            Для запуска процессов нам потребуется метод Create класса Win32_Process. Использовать его достаточно несложно. В PowerShell это делается следующим образом:

            $Computer = "main"
            $Command = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
            ([wmiclass]"\\$Computer\root\cimv2:Win32_Process").create($Command)

            Здесь в качестве запускаемого процесса я указал cmd.exe, а уже ему, в качестве аргументов передал нужную команду. Это необходимо в случае если вам нужно использовать переменные окружения удалённого компьютера или встроенные операторы cmd.exe, такие как «>» для перенаправления вывода в файл. Метод Create не дожидается завершения процесса, и не возвращает результатов, но зато сообщает нам его идентификатор – ProcessID.

            Если вы используете компьютер, на котором пока не установлен PowerShell, вы можете вызвать этот метод WMI и из сценария на VBScript. Например вот так:

            Листинг №1 – Запуск процесса используя WMI (VBScript)

            Computer = "PC3"
            Command = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
            Set objWMIService = GetObject("winmgmts:\\" & Computer & "\root\cimv2:Win32_Process")
            Result = objWMIService.Create("calc.exe", Null, Null, intProcessID)

            Но гораздо проще воспользоваться утилитой командной строки wmic.exe которая предоставляет достаточно удобный интерфейс для работы с WMI и входит в состав операционных систем, начиная с Windows XP. В ней чтобы запустить, например калькулятор на компьютере main достаточно выполнить следующую команду:

            wmic /node:main process call create calc.exe

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

            WSH Remote Scripting

            Да, как ни странно у Windows Script Host тоже есть возможность запуска сценариев на других компьютерах. Правда эта функция не получила большой популярности, и скорее всего из-за того что требует слишком много подготовительных мероприятий, а взамен предоставляет совсем немного возможностей. Но я все равно расскажу об этом методе, так как и он может пригодиться.

            Итак, для запуска сценария на другом компьютере с помощью WSH нам понадобится сделать следующее:

            1. Права администратора на удалённом компьютере. Это само собой разумеется, и требуется почти для всех остальных методов запуска перечисленных в этой статье.
            2. Разрешить WSH Remote Scripting создав в системном реестре строковой параметр Remote равный "1" в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
            3. Из за ошибки описанной в статье базы знаний Microsoft с номером 311269, на системах с Windows XP может понадобиться выполнить команду wscript –regserver
            4. Если на компьютерах используется брандмауэр, то в нём необходимо разрешить обращения к DCOM. Причем сделать это надо не только на управляемом компьютере, но и на том с которого вы хотите запускать сценарий.
            5. В системах Windows XP с пакетом обновлений 2 и выше, необходимо изменить параметры безопасности DCOM. Это можно сделать с помощью групповой политики. В узле Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options следует установить разрешения следующим образом:
              1. DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
                Выдать группам Anonymous Logon и Everyone разрешения Allow Local и Allow Remote Access
              2. DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
                Выдать группе Administrators разрешения Allow Local Launch, Allow Remote Launch, Allow Local Activation, Allow Remote Activation
                Группе Everyone – Allow Local Launch, Allow Local Activation

            Ну и после всех этих процедур, можно попробовать запустить свой сценарий на другом компьютере.

            Пример сценария, который использует эту технологию:

            Листинг №2 – WSH remote scripting (VBScript)

            Set objController = CreateObject("WshController")
            Set objRemoteScript = objController.CreateScript("C:\test.vbs", "PC5")WScript.ConnectObject objRemoteScript, "remote_"
            objRemoteScript.Execute
            Do While objRemoteScript.Status <> 1
            WScript.Sleep 1000
            Loop
            MsgBox "Script complete"
            Sub remote_Error
            Dim objError
            Set objError = objRemoteScript.Error
            WScript.Echo "Error – Line: " & objError.Line & _
            ", Char: " & objError.Character & vbCrLf & _
            "Description: " & objError.Description
            WScript.Quit –1
            End Sub

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

            Более подробную статью об этой технологии можно прочитать в статье Advanced VBScript for Microsoft Windows Administrators – Chapter 6: Remote Scripting (см. Ссылки).

            Планировщик заданий (Task Scheduler)

            Планировщиком заданий можно управлять из командной строки используя две утилиты – at.exe и schtasks.exe. Обе эти утилиты позволяют указать имя удалённого компьютера для создания задания, и, следовательно, позволяют решить нашу задачу. Но подробно мы рассмотрим лишь schtasks.exe, так как она предоставляет гораздо больше возможностей.

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

            schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system

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

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

            Листинг №3 – Установка программы с последующим удалением задания (Windows Batch)

            msiexec /qn /package \\server\share\subinacl.msi
            if exist "c:\program files\Windows Resource Kits\Tools\subinacl.exe" (
            subinacl /tn Install_Subinacl /f
            )

            WinRM (WS-Management)

            WinRM – это реализация открытого стандарта DMTF (Distributed Management Task Force) от Microsoft, которая позволяет управлять системами с помощью веб-служб. Углубляться в устройство технологии я не буду, а лишь кратко опишу, что необходимо для её использования.

            Версия WinRM 1 и выше входит в состав операционных систем, начиная с Windows Vista и Windows Server 2008. Для Windows XP и Windows Server 2003 можно установить WinRM в виде отдельного пакета (см. ссылки).

            Для того чтобы быстро настроить компьютер для подключений к нему используя стандартные порты и разрешив подключения административным учетным записям, достаточно выполнить команду:

            winrm quickconfig

            Чтобы winrm не спрашивал подтверждения, можно добавить к вызову ключ -quiet. Узнать информацию о более тонкой настройке можно посмотреть встроенную справку winrm:

            winrm help config

            Если на управляемом компьютере работает веб-сервер, WinRM никак ему не помешает, хоть и использует по умолчанию стандартные порты HTTP. Он будет перехватывать лишь подключения предназначенные специально для него.

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

            1. Настроить службу WinRM (Windows Remote Management)на автоматический запуск
            2. Настроить элемент групповой политики Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management (WinRM) \ WinRM Service \ Allow automatic configuration of listeners. Тут нужно указать диапазоны IP-адресов с которых разрешаются подключения.
            3. Разумеется, еще вам будет необходимо разрешить подключения на соответствующие порты (по умолчанию 80) в брандмауэре Windows.

            Независимо от того используется ли порт HTTP (80) или HTTPS (443) трафик передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.

            Но хватит о настройках, лучше перейдем непосредственно к использованию. Хоть утилита winrm позволяет настраивать службу WinRM, а так же выполнять например WMI запросы, нам более интересна другая – winrs. Буквы RS тут означают Remote Shell. WinRS работает очень похоже на PsExec хотя и использует технологию WinRM. Имя компьютера задаётся ключом -r, а после него следует команда которую нужно выполнить. Вот несколько примеров:

            winrs -r:Core ver.exe

            Так как winrs и так использует cmd.exe в качестве удалённой оболчки, в командах можно легко обращаться к удалённым переменным окружения, или использовать другие встроенные команды cmd.exe:

            winrs -r:Core "dir c:\temp > c:\temp\list.txt"

            Как и PsExec, утилита winrs позволяет открыть интерактивный сеанс на удалённом компьютере:

            winrs -r:main cmd.exe

            Эта функция аналогична telnet сессии, но использование winrs однозначно лучше telnet и даже PsExec, с точки зрения безопасности. Независимо от того используется ли порт HTTP (80) или HTTPS (443), трафик передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.

            Windows PowerShell 2.0 Remoting

            Хотя вторая версия Windows PowerShell на момент написания статьи находится еще в состоянии бета тестирования, о её возможностях в области удалённого выполнения команд определённо стоит рассказать уже сейчас. Попробовать его своими руками вы можете либо загрузив предварительную версию (см. ссылки) либо в составе бета-версии Windows 7 или Windows Server 2008 R2.

            Инфраструктура PowerShell Remoting основана на WinRM версии 2.0, и поэтому наследует все преимущества этой технологии, такие как шифрование передаваемых данных, и возможность работать по стандартным портам HTTP/HTTPS. Но благодаря богатым возможностям языка Windows PowerShell, и его способностям работы с объектами, мы получаем еще большие возможности. На данный момент пакет WinRM2.0 тоже находится в состоянии бета-тестирования, и доступен для загрузки только для систем Windows Vista и Windows 2008. В системы Windows 7 и Windows Server 2008R2 он будет встроен изначально, как и PowerShell 2.0.

            Обновление: К моменту публикации статьи на ItBand.ru, финальные версии PowerShell 2.0 и WinRM 2.0 доступны уже для всех поддерживаемых платформ. В состав Windows Server 2008R2 и Windows 7 они уже включены как неотъемлемые компоненты системы, а для Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 все необходимые компоненты можно получить в виде пакета называемого Windows Management Framework.

            Перед тем как воспользоваться всеми этими преимуществами, PowerShell Remoting необходимо активизировать, на управляющем, и управляемых компьютерах. Сделать это просто, запустив командлет (команду Windows PowerShell) Enable-PSRemoting. Причем если добавить ключ -Force то никаких подтверждений запрошено не будет. Этот командлет при необходимости вызовет winrs quickconfig, и создаст исключения в брандмауэре Windows, так что никаких дополнительных действий выполнять не нужно.

            После этого вы сможете легко выполнять команды на других компьютерах используя командлет Invoke-Command (или его псевдоним icm):

            Invoke-Command -ComputerName Main -ScriptBlock {netsh interface dump > c:\ipconfig.txt}

            Разумеется команду можно заранее поместить в переменную, а для параметра -ComputerName указать имена не одного, а сразу нескольких компьютеров. Следующая последовательность позволяет вывести версию файла Explorer.exe сразу с трех компьютеров.

            $Command = {(get-item c:\Windows\explorer.exe).VersionInfo.FileVersion}
            Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command

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

            Впрочем возможности PowerShell Remoting на этом только начинаются. С помощью командлета Enter-PSSession вы можете войти в интерактивную сессию Windows PowerShell на удалённом компьютере. Выйти из такого сеанса можно использовав командлет Exit-PSSession, или просто exit.

            Командлет New-PSSession создает сессии на удалённых компьютерах, указатели на которые можно поместить в переменную, а затем передавая её как аргумент для Invoke-Command выполнять команды сразу на нескольких компьютерах, в постоянном окружении. Пример вы можете увидеть на скриншоте, где я выполняю последовательность команд сразу на нескольких компьютерах из списка c:\computers.txt.

            Проксирование

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

            Чаще всего такие проблемы люди решают с помощью утилит вроде cpau.exe (см. ссылки) которые создают файл с зашифрованным паролем административной учетной записи, позволяющий запускать определённую программу. Проблема, однако, в том, что хоть пароль и зашифрован, перед запуском программы утилите придётся его расшифровать. А соответственно пользователь может использовать утилиту повторяющую алгоритм расшифровки пароля, и узнать его, чтобы затем использовать для запуска других программ или получения дополнительных привилегий. Практически это конечно достаточно сложно для обычных пользователей, не обладающих специальными знаниями, но, тем не менее, вполне возможно. Еще раз уточню, это не беда конкретной утилиты, а проблема такого подхода вообще.

            Еще может показаться, что для решения задачи подойдет параметр /savecred утилиты runas. Но тут есть даже две проблемы. Во-первых, как и вышеописанном случае, пароль сохраняется на компьютере пользователя, а, следовательно, может быть расшифрован, хотя в случае с runas для этого и понадобятся права локального администратора. Во-вторых, runas сохраняет учетные данные, не связывая их с конкретной командой, а, следовательно, пользователь сможет запустить с завышенными правами не только ту команду, доступ к которой вы хотели ему предоставить, но и любую другую.

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

            Работает она следующим образом. На компьютере постоянно работает сценарий с высокими привилегиями. Например, в нашем случае он будет запущен из-под учетной записи, обладающей правами администратора на файловом сервере. По сигналу пользователя он будет выполнять одну, заранее определённую команду. В этом примере – закрывать все файлы, открытые по сети.

            Для организации этой системы мы поместим на сервере, например в папке c:\scripts\ командные файлы Server.cmd и Action.cmd .

            Листинг №4 – Server.cmd (Windows Batch)

            set trigger=c:\commandShare\trigger.txt
            set action=c:\scripts\action.cmd
            set log=c:\scripts\log.txt
            :start
            if exist %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
            sleep.exe 5
            goto start

            Листинг №5 – Action.cmd (Windows Batch)

            for /f "skip=4 tokens=1" %%a in (‘net files’) do net files %%a /close
            exit

            Server.cmd будет ждать знака от пользователя (создание файла в определенном месте), и получив его, запускать файл с командами – Action.cmd. Разумеется, в эту папку пользователи не должны иметь никакого доступа. Автоматический запуск Server.cmd при запуске компьютера можно организовать, просто создав соответствующую задачу в планировщике:

            schtasks /create /ru domain\administrator /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd

            После параметра /ru указывается учетная запись, под которой будет выполняться сценарий (в нашем случае она обладает правами администратора на сервере), так как после параметра /rp пароль не указан – он будет запрошен при создании задачи. Параметр /sc позволяет указать момент запуска сценария, в нашем случае – при включении компьютера. Ну а /tn и /tr позволяют указать имя задачи, и исполняемый файл.

            Теперь, для того чтобы пользователь мог подать сценарию сигнал, мы создадим папку c:\commandShare и сделаем её доступной по сети. Доступ на запись в эту папку должен быть только у тех пользователей, которые будут запускать команду.

            После этого достаточно будет поместить пользователю на рабочий стол файл Run.cmd.

            Листинг №6 – Run.cmd (Windows Batch)

            echo test > \\server\commandShare\trigger.txt

            При его выполнении, от имени пользователя, будет создаваться файл \\server\commandShare\trigger.txt. Сценарий Server.cmd, заметив его, запустит на выполнение со своими привилегиями файл Action.cmd, добавит запись в файл c:\scripts\log.txt о текущем времени, а затем удалит trigger.txt чтобы не выполнять команду снова до следующего сигнала пользователя.

            В сценарии Server.cmd используется утилита Sleep.exe, позволяющая сделать паузу в выполнении сценария на заданный в секундах промежуток времени. Она не входит в состав операционной системы, но её можно взять из набора Resource Kit Tools (см. ссылки) и просто скопировать на любой компьютер.

            Ссылки

            PsExec.exe

            Windows SysInternals

            http://www.script-coding.info/WMI_Processes.html

            BUG: You receive an "ActiveX component can’t create object" error message when you Use Windows Script Host to execute remote script

            Advanced VBScript for Microsoft Windows Administrators – Chapter 6: Remote Scripting

            Вы всё ещё не используете WMI? Часть 1

            Вы всё еще не используете WMI? Часть 2

            Узнай секреты WMI: события и провайдеры

            Узнай секреты WMI: события и провайдеры

            WS-Management v1.1 для Windows XP и Windows Server 2003

            CPAU.exe

            Windows PowerShell 1.0

            Windows PowerShell 2.0 Community Technology Preview 3 –

            WinRM 2.0 Community Technology Preview 3

            Windows Server 2003 Resource Kit Tools

            Ранее статья была опубликована в журнале Windows IT Pro RE в №4 за 2009 год.

            Василий Гусев

            http://xaegr.wordpress.com/

          • Главная Windows, Новое Microsoft.next, PowerShell
            • Обзор нововведений Windows PowerShell 2.0

              • Рубрика: Windows,Новое
              • Автор: Василий Гусев
              • Дата: Thursday 01 Oct 2009

              powershell С одной стороны, синтаксис языка практически не претерпел изменений, переучиваться не придётся – сценарии написанные для PowerShell 1.0 будут прекрасно работать и в PowerShell 2.0. С другой стороны, приятных нововведений так много, что я сразу предупреждаю – рассказать обо всех них, в одной статье просто нереально. Так что я сделаю лишь краткий обзор нового функционала, и в конце расскажу об источниках более подробной информации.