Как включить удаленную оболочку Windows

В этой статье вы можете включить Windows Remote Shell.

Оригинальная версия продукта: Windows Server 2003
Исходный номер КБ: 555966

Эта статья была написана Yuval Sinay, MVP Майкрософт.

Советы

Чтобы включить windows Remote Shell, необходимо развернуть параметры на стороне сервера и клиента:

Сторона сервера

Определение сервера в статье описывает хост Windows, который попадает в оболочку удаленного управления.

Войдите в консоль Windows.

Необязательный (для Windows Vista служит удаленным сервером): запустите службу «Windows Remote Management» и установите ее для автоматического запуска после перезагрузки.

Напишите командную подсказку WinRM quickconfig и нажмите кнопку Ввод.

Должен появиться следующий вывод:

После нажатия кнопки y должен появиться следующий вывод:

Мы рекомендуем изменить параметры по умолчанию с помощью команды winrm.cmd (Например, включить поддержку HTTPS и т.д.).

Windows Remote Shell с помощью SOAP. Некоторые брандмауэры могут блокировать трафик SOAP. Дополнительные сведения см. в документации поставщика.

Сторона клиента

На хосте Windows Vista/Windows 2008 используйте команду и нажмите winrs -r:%servername% remote command кнопку Ввод.

Пример. Чтобы просмотреть удаленную файловую систему, напишите следующую команду:

В среде Windows Workgroup необходимо добавить доверие к серверу, который клиент инициирует подключение к ней с помощью команды winrm set winrm/config/client @ .

Проверка новых параметров с помощью команды winrm enumerate winrm/config/listener .

Заявление об отказе от контента решений сообщества

КОРПОРАЦИЯ МАЙКРОСОФТ И/ИЛИ ЕЕ ПОСТАВЩИКИ НЕ СОДЕРЖАТ НИКАКИХ ПРЕДСТАВЛЕНИЙ О ПРИГОДНОСТИ, НАДЕЖНОСТИ ИЛИ ТОЧНОСТИ ИНФОРМАЦИИ И СВЯЗАННОЙ С НЕЙ ГРАФИКИ. ВСЯ ТАКАЯ ИНФОРМАЦИЯ И СВЯЗАННАЯ С НЕЙ ГРАФИКА ПРЕДОСТАВЛЯЮТСЯ БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. КОРПОРАЦИЯ МАЙКРОСОФТ И/ИЛИ ЕЕ ПОСТАВЩИКИ НАСТОЯЩИМ СНИМАТЬИ ВСЕ ГАРАНТИИ И УСЛОВИЯ, ОТНОСЯЩИЕСЯ К ЭТОЙ ИНФОРМАЦИИ И СВЯЗАННЫМ ГРАФИЧЕСКИМ ГРАФИКАМ, ВКЛЮЧАЯ ВСЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ И УСЛОВИЯ ДЛЯ ОБЕСПЕЧЕНИЯ СООТВЕТСТВИЯ ТРЕБОВАНИЯМ, ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ, ВОРКМАНЛИКЕ УСИЛИЯ, ДОЛЖНОСТИ И НЕНАРУШЕНИЯ ПРАВ. ВЫ ЯВНО СОГЛАСНЫ, ЧТО В СЛУЧАЕ ОТСУТСТВИЯ У КОРПОРАЦИИ МАЙКРОСОФТ И/ИЛИ ЕЕ ПОСТАВЩИКОВ НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ПРЯМЫЕ, КОСВЕННЫЕ, ПУНИТИВЕ, СЛУЧАЙНЫЕ, СПЕЦИАЛЬНЫЕ УБЫТКИ, А ТАКЖЕ ЛЮБЫЕ УЩЕРБА БЕЗ ОГРАНИЧЕНИЙ, УЩЕРБА ДЛЯ ПОТЕРИ ИСПОЛЬЗОВАНИЯ, ДАННЫХ ИЛИ ПРИБЫЛИ, КОТОРЫЕ СВЯЗАНЫ С ИСПОЛЬЗОВАНИЕМ ИЛИ НЕВОЗМОЖНОСТЬЮ ИСПОЛЬЗОВАТЬ ИНФОРМАЦИЮ И СВЯЗАННУЮ С НИМИ ГРАФИКУ, В ЗАВИСИМОСТИ ОТ ДОГОВОРА, НАРУШЕНИЯМ, НЕБРЕЖНОСТЬЮ, ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТИ ИЛИ ИНЫМ СПОСОБОМ, ДАЖЕ ЕСЛИ КОРПОРАЦИИ МАЙКРОСОФТ ИЛИ ЕЕ ПОСТАВЩИКАМ РЕКОМЕНДУЕТСЯ ВОЗДЕРЖАТЬ УЩЕРБ.

Концепция альтернативной оболочки Windows. Часть 1.

Предположим, Вы приобрели новый компьютер с предустановленной ОС Windows. После загрузки системы и входа в профиль пользователя Вас приветствует Рабочий стол с несколькими иконками и полоска Панели Задач в нижней части экрана — там тоже несколько иконок. После настройки Интернета Вы начинаете скачивать программки — большие и маленькие. После запуска инсталляторов для каждой из них на Рабочем столе (а иногда и на Панели Быстрого запуска) появляются новые ярлычки. Вы начинаете работать с программами, и, возможно, часть созданных документов сохраняете на Рабочий стол.

реклама

На Рабочем столе становится всё больше и больше иконок, и уже глаза начинают разбегаться.

При сильной захламленности Рабочего стола Вас подстерегает ещё одна неприятность. Для создания нового документа нужно активировать ярлык приложения, а для изменения документа нужно дважды кликнуть по иконке документа. Но ярлыки приложений и иконки документов на Рабочем столе перемешаны, и поиск нужного объекта требует некоторого напряжения. Можно, конечно, перетащить все ярлыки приложений в левую (правую, верхнюю или нижнюю) часть Рабочего стола, но не факт, что при очередной перезагрузке этот порядок сохранится.

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

Рассмотрим типовые решения проблемы нехватки места на Рабочем столе.

реклама

Можно всегда сохранять документы в библиотеку «Документы», раскладывая их по папкам, или периодически перемещать туда документы с Рабочего стола.

Можно поступить более радикально — удалить часть объектов в корзину.

Можно так же добавлять ярлыки приложений на Панель Быстрого запуска (в Windows 10 она срослась в единое целое с Панелью Задач). Постепенно там тоже накапливается приличное количество иконок. Иконки начинают занимать несколько рядов, и рабочее пространство для окон приложений сокращается.

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

реклама

Ещё можно купить монитор большего размера или расширить Рабочий стол на несколько мониторов . .

Это, пожалуй, все варианты, которые предлагает ОС.

Что могло бы облегчить работу на компьютере в данной ситуации?

Если бы на Рабочем столе была полоса прокрутки, то часть иконок можно было бы поместить в невидимую область экрана.

реклама

Или, скажем, если бы ОС предоставляла возможность иметь в своём распоряжении несколько полноценных Рабочих столов, то можно было бы перераспределить иконки между ними.

Кнопочки на Панели Быстрого Запуска надо тоже как-то поделить. Скажем, иметь несколько Панелей Быстрого Запуска — по одной на каждый Рабочий стол.

Итак, обозначим список наших пожеланий.

1. Мы хотим, чтобы было много Рабочих столов.
2. Мы хотим, чтобы на каждом Рабочем столе при необходимости была прокрутка.
3. Мы хотим, чтобы ярлыки приложений располагались отдельно от иконок документов и папок с документами.
4. Мы хотим, чтобы для каждого Рабочего стола была своя Панель Быстрого Запуска.
5. Мы хотим, чтобы текст подписи под значками не усекался, а отображался полностью, в удобоваримом виде.

Как эти требования выполняются в Программном комплексе «Пользовательская оболочка» (в дальнейшем — ПКПО)?

В ПКПО есть аналог Рабочего стола, называемый Составным проектом. Пользователь может создать практически неограниченное количество Составных проектов. Все Составные проекты образуют древовидную структуру и, естественно, у каждого Составного проекта есть имя. Кроме того, Вы можете сразу переходить из одного Составного проекта в другой сразу, вне зависимости от места в Дереве Проектов, если создадите объект «Родственный проект».

Составной проект, с которым в данное время работает пользователь, отображается в специальной панели — Окне Просмотра. Слева от Окна просмотра располагается Панель Кэша Приложений, куда пользователь помещает ярлыки приложений, которые могут понадобиться в текущем Составном проекте. Если в любой из панелей содержится много объектов, автоматически появляется прокрутка. Граница между панелью Кэша Приложений и Окном просмотра изменяемая. Объекты в Окне Просмотра сортируются по одному из выбранных критериев, но сначала отображаются папки, т. е. вложенные Составные проекты (см. Рисунок 1).

В каждой из панелей «Пользовательской оболочки» есть несколько вариантов отображения иконок и подписей к ним, в том числе, без усечения текста.

Рисунок 1. Окно Просмотра и Кэш Приложений

А как насчёт Панели Быстрого Запуска?

Этот элемент интерфейса формируется с помощью другого приложения ПКПО — Пользовательской панели, аналога Панели Задач Windows (см. Рисунок 2). Панель Кэша Приложений (см. Рисунок 2) — это и есть аналог Панели Быстрого Запуска Windows.

Рисунок 2: Пользовательская панель

Таким образом, во время работы над текущим Составным проектом мы можем запустить нужное приложение, нажав кнопку на Панели Кэша Приложений.

Если с помощью средств навигации Окна Просмотра мы переходим в другой Составной проект, содержимое панелей Кэша Приложений обоих приложений полностью обновляется.

Поскольку Кэш Приложений отображается сразу в двух приложениях, Вы можете скрыть панель Кэша Приложений в «Пользовательской оболочке», тем самым увеличивая размер Окна Просмотра (см. Рисунок 1).

У некоторых пользователей может возникнуть возражение — некоторые приложения нужны в нескольких, или даже во всех Составных проектах, например, веб-браузер или пакет офисных программ. Что делать?

Эта проблема так же легко решается с помощью ПКПО.

Для ярлыков приложений, которые нужны во всех Составных проектах, выделяется специальная папка — Список Приложений, формируемая пользователем вручную, по собственному усмотрению. Ярлыки можно группировать в папки. В приложении «Пользовательская оболочка» Список Приложений при необходимости отображается в Правой панели (см. Рисунок 3).

Рисунок 3. Список Приложений в Правой панели

В приложении «Пользовательская панель» Список Приложений отображается в виде панели с кнопками — по одной кнопке на каждый ярлык приложения и каждую папку в корне Списка Приложений. Вложенные в папки Списка Приложений объекты отображаются в виде меню (см. Рисунок 2).

1. Если иконки не помещаются на какой-либо панели приложения «Пользовательская панель», появляются кнопки для прокрутки (см. кнопку прокрутки Списка Приложений на Рисунке 2).
2. Панель Кэша Приложений «Пользовательской оболочки» может работать и в режиме отображения Дерева папок (режим по умолчанию), подобно окну Проводника:

Рисунок 4: Панель Кэша Приложений в виде дерева

Дополнительную информацию по ПКПО можно найти на странице программы.

Выполнить команду на удалённом компьютере

Как выполнить команду на удалённом компьютере? Самый распространенный вопрос у системных администраторов. К этому можно отнести запуск какой либо команды на удалённом компьютере, не вставая со своего места. Можно конечно использовать DameWare Mini Remote Control но это не то. И это и то может быть необходимо для установки программы или утилиты, изменения каких либо настроек, или для чего угодно ещё. И конечно, редко речь идёт лишь об одном компьютере, чаще команду нужно выполнить на множестве рабочих станций или серверов.

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

Выполнить команду на удалённом компьютере через PsExec.exe

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

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

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

Выполнить команду на удалённом компьютере

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

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

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

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

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

Ну и одной из самых полезных способностей 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 нам понадобится сделать следующее:

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

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

Листинг №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 не спрашивал подтверждения, можно добавить к вызову ключ -quiet. Узнать информацию о более тонкой настройке можно посмотреть встроенную справку winrm:

Если на управляемом компьютере работает веб-сервер, 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 и так использует cmd.exe в качестве удалённой оболчки, в командах можно легко обращаться к удалённым переменным окружения, или использовать другие встроенные команды cmd.exe:

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

Эта функция аналогична 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 c:\ipconfig.txt>

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

Выполнить команду на удалённом компьютере

Как видно на, можно передавать сразу несколько команд в одном блоке, помещать их результаты выполнения на нескольких компьютерах в переменную, а затем обрабатывать на рабочей станции используя возможности 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 и сделаем её доступной по сети. Доступ на запись в эту папку должен быть только у тех пользователей, которые будут запускать команду.