Удаленное управление компьютером из командной строки windows

Приветствую. Иногда возникают задачи когда нужно что-либо сделать на удаленном компьютере, при этом либо нет возможности подключиться по RDP, например, если вдруг сервер сильно загружен, и ему не хватит ресурсов для запуска терминальной сессии (да да, у меня такое встречалось, не сказать что часто, но бывало ). Либо из командной строки задачу сделать быстрее. Ну или еще как вариант, если нужно что то сделать скрытно, в том случае если пользователь в момент когда это нужно сделать работает за компьютером. Пользователям Linux с этим гораздо проще, у них есть ssh. Но и в Windows есть возможность подключаться, с позволения сказать, в командную строку.

В общем и целом на помощь к нам приходят утилиты SysInternals, а именно — pstools, а еще конкретнее — psexec из этого набора утилит. Скачать это добро можно здесь.

После того как скачали, нужно эти утилиты разархивировать куда-нибудь. Я обычно на диске C: создаю папку ps, что бы удобнее было добираться до утилит. Установки они не требуют. Для того что бы подключиться к удаленному компьютеру в командной строке набираем:

c:\ps\PsExec.exe \\192.168.1.114 -u domain\user -p password cmd

За место cmd можно например запустить какой-нибудь батник или другую команду.

Видео по теме:

11 8

Поделитесь статьей с друзьями в соц. сетях, возможно, она будет им полезна.

---

Если вам помогла статья, вы можете >>отблагодарить автора<<

---

В наше время даже для собак придумали удаленное управление.

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

В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать SMBv1 и загружать обновления. Да и провести инвентаризацию или установить срочный патч таким методом тоже можно.

Когда-то давно я устроился работать в организацию в период эпидемии Kido\Conficker. Наиболее простым способом выяснить, все ли хорошо в ИС компании, была славная утилита от Касперского под названием Kido Killer, которая проверяла наличие вируса и устраняла его. Запускать программу на доброй сотне машин руками было невесело, поэтому пришлось знакомиться с автоматизацией.

Если в операционных системах *nix для удаленного запуска, как правило, используется SSH, то у Windows способов запуска программ и скриптов воистину как песка в пустыне. Я разберу основные варианты, как общеизвестные, так и экзотические. Таких очевидных вещей как telnet-сервер касаться не буду, тем более Microsoft уже убрала его из современных ОС.

Способы старые, временем проверенные

Psexec

Пожалуй, это первое, что приходит на ум, когда идет речь об удаленном запуске программ. Утилита от Марка Руссиновича используется еще со времен Windows NT и до сих пор применяется. Помимо основной функции, можно использовать ее и как Runas, и для запуска программ в пользовательской сессии терминального сервера. Psexec также позволяет задавать ядра процессора, на которых будет запускаться программа, и ее приоритет в системе.

В качестве примера посмотрим, установлено ли обновление, закрывающее нашумевшую уязвимость SMB на списке компьютеров:

psexec @computers.txt /u USER /p PASS cmd.exe /v /c ""systeminfo | find "KB4012212" || echo !computername! >> \\server\share\log.txt"""

В файле computers.txt находится список компьютеров. Для запуска по всему домену можно использовать \\*. В файле \\server\share\log.txt будут появляться имена рабочих станций или серверов без обновления. Если в домене существуют компьютеры с *nix на борту или нет доступа к административному сетевому ресурсу Admin$ ― команда на этой машине не выполнится, но обработка продолжится. Чтобы скрипт не зависал при каждой попытке подключения, можно задать тайм-аут с помощью ключа -n.

Если компьютер выключен ― мы об этом не узнаем. Поэтому лучше предварительно проверять доступность машин или собирать в файле информацию об успешном или неудачном выполнении.

К минусам Psexec можно отнести то, что она из-за своего удобства и популярности часто используется вирусописателями. Поэтому антивирусные системы могут обнаруживать утилиту как опасность вида remote admin.

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

WMIC

Для управления системами Windows с помощью разных графических утилит часто используется WMI (Windows Management Instrumentation) ― реализация объектно-ориентированного стандарта управления WBEM. В качестве утилиты с графическим интерфейсом для работы с WMI можно использовать wbemtest.exe.

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

wmic /node:"servername" qfe get hotfixid | find "KB4012212"

Использовать список компьютеров также можно командой /node:»@computers.txt».

Еще при помощи WMI можно запускать программы – синтаксис предельно прост:

wmic /node:"servername" process call create "cmd /c somecommands"

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

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

Групповые политики и скрипты

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

Скрипты, выполняющиеся при старте и завершении системы.

Скрипты, выполняющиеся при входе и выходе пользователя из системы.

Скрипты, настраиваемые в пользовательском разделе, выполняются от имени пользователя, а в разделе компьютера ― под аккаунтом SYSTEM.

Назначенные задания

Довольно интересный способ, заслуживающий право на жизнь. Назначенные задания можно создавать из командной строки при помощи утилиты schtasks.exe, выполнять их, затем удалять. Подробнее с синтаксисом можно ознакомиться в документации, я же разберу пример использования назначенных заданий в доменной среде. Предположим, нам нужно выполнить команду как можно быстрее вне зависимости от того, выключен компьютер или нет. Для этого используются так называемые предпочтения групповых политик (Group Policy Preference).

Искать установку назначенных заданий следует в конфигурации компьютера или пользователя ― «Настройка ― Параметры панели управления ― Назначенные задания».

Создание нового назначенного задания.

Для выполнения команды или скрипта ASAP понадобится создать «Немедленную задачу (Windows 7 и выше)». Если вдруг в инфраструктуре остались машины под управлением Windows XP, то подойдет «Очередное задание (Windows XP)».

Стоит сделать несколько политик с соответствующими WMI-фильтрами или создать два разных назначенных задания в одной политике с нацеливанием ― например, при помощи того же WMI-фильтра. Это поможет избежать конфликтов в разнородной среде со старыми и новыми Windows.

Пример WMI-фильтра для применения политики только на компьютерах с Windows XP:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.1%" AND ProductType = "1"

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

Запускаем немедленную задачу только один раз.

При использовании таких назначенных заданий программа запустится, как только компьютер получит обновление групповой политики. Это удобно: не нужно проверять доступность компьютеров в случае Psexec и wmic и заставлять пользователей перезагружать машины, как в случае скриптов групповых политик. При необходимости можно скопировать файл скрипта локально в разделе «Настройка ― Конфигурация Windows ― Файлы».

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

Через реестр

Модификация реестра на пользовательских машинах ― странный вариант, лишь на случай крайней необходимости. Можно использовать ветки Run или RunOnce. Подробнее о них ― в документации. Сама модификация реестра может проводиться через групповые политики или из командной строки ― например, такой командой:

reg add \\COMPUTER\HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce /v script /t Reg_SZ /d "script.cmd"

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

Есть и другие способы, такие как правка ярлыков в папке «Автозагрузка» или добавление в ярлык к популярной программе && script.cmd, но эти методы уже из серии «можно, но не нужно».

Теперь перейдем к новым инструментам.

Способы новые или куда же без PowerShell

PowerShell, оправдывая свое название, может подключаться к удаленным компьютерам при помощи WMI, RPC и WS-Management (WSMan). Использование последнего метода требует предварительной настройки.

Командлеты, не требующие предварительной настройки, как правило, имеют параметр ComputerName, но не имеют параметра Session. Посмотреть список таких командлетов можно командой:

Get-Command | where { $_.parameters.keys -contains "ComputerName" -and $_.parameters.keys -notcontains "Session"}

Для настройки WSMan в общем случае достаточно выполнить команду Enable-PSRemoting-Force. Она запустит службу удаленного управления WinRM и пропишет исключения в фаерволе ― в принципе, это можно сделать для всего домена при помощи групповых политик. Подробнее настройка описана в документации.

После того как все компьютеры будут готовы принимать запросы, мы сможем подключаться при помощи соответствующих командлетов PowerShell. Для проверки возможности подключения используется командлет Test-WSMan.

Проверка возможности подключения.

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

Invoke-Command -ComputerName COMPUTER -ScriptBlock { COMMAND } -credential USERNAME

Где COMPUTER ― имя компьютера, COMMAND ―– имя команды, а USERNAME ― имя пользователя, если оно нужно.

Смотрим содержимое диска С удаленного компьютера.

Если же нам нужно получить полноценную консоль ― не автоматизации ради, а ради управления конкретным компьютером, ― то можно использовать командлет Enter-PSSession.

Работаем в консоли удаленного компьютера.

Напомню, что с помощью JEA можно ограничить доступные подобной сессии командлеты или дать доступ нужным без прав администратора.

Конечно, кроме встроенных средств и небольших утилит, существует множество программ для управления структурой. Помимо взрослых решений, для управления конфигурациями вроде Chef, Ansible и MS SCCM можно использовать и средства мониторинга вроде Zabbix, и даже консоль управления антивирусом Касперского.

В период гетерогенных структур хорошо бы иметь возможность унифицированного управления Windows и Linux. Это можно сделать и с помощью PowerShell, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?

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

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

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

PsExec.exe

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

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

[code]psexec \\main ipconfig /flushdns[/code]

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

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

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

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

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

[code]psexec -i \\main winver.exe[/code]

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

[code]psexec @c:\comps.txt systeminfo.exe[/code]

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

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

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

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

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

[code]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)[/code]

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

[code]wmic /node:main process call create calc.exe[/code]

Разумеется, возможности 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) 

[code]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[/code]

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

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

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

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

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

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

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

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

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

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

WinRM (WS-Management)

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

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

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

[code]winrm quickconfig[/code]

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

[code]winrm help config[/code]

Если на управляемом компьютере работает веб-сервер, 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, а после него следует команда, которую нужно выполнить. Вот несколько примеров:

[code]winrs -r:Core ver.exe[/code]

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

[code]winrs -r:Core «dir c:\temp > c:\temp\list.txt»[/code]

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

[code]winrs -r:main cmd.exe[/code]

Эта функция аналогична 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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[code]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[/code]

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

[code]for /f «skip=4 tokens=1» %%a in (‘net files’) do net files %%a /close
exit[/code]

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

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

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

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

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

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

[code]echo test > \\server\commandShare\trigger.txt[/code]

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

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

Ссылки

Скачать PsTool в составе PsExec с этого сайта.

PsExec.exe скачать с сайта Microsoft

Windows SysInternals

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

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

http://xaegr.wordpress.com/

PsExec — это удобная утилита командной строки, с помощью нее можно запускать программы на удаленных Windows системах, перенаправляя данные, которые выводится приложением на экран на локальный ПК. Т.е. при работе с этой утилитой складывается ощущение, что приложение работает локально на вашем ПК. PsExec – бесплатная утилита и ее можно скачать по адресу https://download.sysinternals.com/files/PSTools.zip.

Какие требования к окружению при работе с утилитой PsExec? Для удаленного запуска команд и процессов необходимо, чтобы на удаленном и локальном ПК функционировали службы «Сервер» и «Рабочая станция» (Workstation и Server), а на удаленном компьютере должен быть доступен стандартный общий ресурс Admin$.

Удобство PsExec в том, что ее легко развернуть в сети благодаря возможности удаленной установки, без необходимости устанавливать или настраивать что-либо на каждом. На удаленном ПК PsExec работает в виде службы Windows с таким же именем.

PsExec очень удобна при выполнении множества задач по обслуживанию и администрированию удаленных рабочих станций и серверов. Устанавливать ее не нужно, можно просто скопировать ее в каталог, определенный в переменной %path% (например, C:WindowsSystem32). При запуске команд через PsExec на удаленном ПК запустится служба PsExec (исполняемый файл system32psexesvc.exe), соответственно для нормальной работы вам понадобятся права администратора домена на удаленной машине. Формат запуска и параметры командной строки у утилиты PsExec следующие:

Usage: psexec [computer[,computer2[,…] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,… ] cmd [arguments]

В том случае, если имя пользователя и пароль не указаны, используются права текущего пользователя:

psexec buh_pc1 cmd.exe

psexec buh_pc1 -u admin -p P@ssw0rd notepad.exe

В принципе эту утилиту можно рассматривать как альтернативу telnet. Внимание: при использовании PsExec будьте осторожны, так как в принципе соединение между сервером и клиентом PsExec не шифруется и данные можно перехватить сетевым сниффером.
Если вам понадобится запустить определенную команду на нескольких компьютерах одновременно (например, shutdown –f –r –t 0 ☺), то их имена или ip-адреса нужно перечислить через запятую, или же поместить в текстовый файл, который выбрать в качестве одного их параметров утилиты PsExec..

psexec buh_pc1, buh_pc2 shutdown –f –r –t 0

psexec @c:list_of_buh_pc.txt shutdown –f –r –t 0

При использовании ключа “-c” указанная программа сначала скопируется с вашего ПК на удаленный, а потом выполнится. Ключ “-i” заставляет указанную команду запустится в интерактивном режиме. Если вы хотите, чтобы после запуска определенной команды PsExec не ждал ее окончания, а вывернул вам управление (командную строку), нужно указать параметр “-d”:

psexec -d buh_pc1 chkdsk

Эта команда запустит на удаленной системе процесс проверки диска, а администратор сможет продолжить введение команд.

The Remote Desktop Connection (RDC) tool, also known as Microsoft Terminal Services Client (MSTSC), allows a user to connect to another computer remotely over the network using the Remote Desktop Protocol (RDP). Most users use this tool via its Graphical User Interface (GUI) which is convenient to use, but this article focuses on using the Remote Desktop via the command line.

Connecting to other computers using RDC through the command line allows you to control different settings and preferences of the connection. Windows allows a user to use certain switches to predefine the settings before the connection is made. For example, you can define the name or IP address of the remote computer, or adjust the RDC window size even before running the tool.

Learn how to enable RDC in Windows 11.

Let us help you become aware of the switch options and how you can use them to configure your RDC connections.

MSTSC commands and switches

The conventional way to open the RDC in Windows is by searching for “Remote Desktop Connection” or “RDC” in Run and open the tool.

This then opens the RDC tool where you can enter the name of IP address with port number (optional) of the remote computer that you want to connect to.

Most of you would already be aware of this method.

This section covers the possible commands and switches that you can use with RDC via the command line. We shall start with the most basic ones and then continue.

Launch RDC from Run

The very basic command to run Remote Desktop Connection from the command line is via Run. Simply type in the following in Run and hit Enter.

mstsc

Running this will open the RDC with a blank text field. However, with the addition of a few switches, you can change the settings and preferences of the RDC connection. Let us continue forward with a few examples.

Use RDC to connect via console

Although RDC fully supports GUI, you can also connect to remote machines through a console. This will help in case you wish to continue the session that you got disconnected from earlier. In contrast, a regular GUI-based RDC session creates a new session each time you connect to the same machine.

Use the following command to connect to a remote computer via console:

mstsc /console

Launch RDC with IP address

You can also launch RDC along with the IP address of the machine to connect it with. If the port on the machine is changed from the default value, you can also add the port number. Use the following commands to do so:

mstsc /v:IPAddress

mstsc /v:IPAddress:PortNumber

Replace IPAddress with the complete IP address of the remote computer that you want to connect with, and PortNumber with the port number if changed from its default value.

Launch RDC with computer name

You can also connect to the remote computer by its unique computer name. The switch used for this is the same one used with the IP address and port number in the steps above.

mstsc /v:ComputerName

Replace ComputerName with the unique name of the remote device that you can find in its settings or properties.

Launch RDC in full-screen mode

You can also launch the RDC connection in full-screen mode. Here is how:

mstsc /f

These switches can be combined into a single command to execute an RDC connection to your preferences. Here is an example:

mstsc /f /v:192.168.10.122:8002

MSTSC commands and switches

There are more commands and switches you can use with mstsc command-line to adjust your settings for the connection beforehand. Here is the complete list:

<connectionfile>	For a .rdp file required to make a connection (if applicable).
/v:	IP Address or computer name of the remote computer.
/g:	IP Address or device name of a Remote Gateway Server (if applicable).
/admin	To establish a connection with administrative privileges.
/f	View the Remote Desktop Window in full-screen mode.
/w:	To specify the width of the Remote Desktop Window.
/h:	To specify the height of the Remote Desktop Window.
/public	Run the Remote Desktop Connection publicly (less secure).
/span	To match the width and height of the Remote Desktop with the local desktop.
/edit <connectionfile>	To edit a .rdp file.
/multimonTo make the monitor layout of the Remote Desktop Services session identical to the client-side configuration.
/restrictedAdmin	Connect to the remote PC in Restricted Administration mode. The credentials are not sent to the remote PC in this mode, protecting you if you connect to a compromised PC.
/remoteGuard	Connect your device to a remote device using the Remote Guard, which prevents sending credentials to a remote PC.
/prompt	To prompt you to put in credentials to connect to the remote PC.
/shadow:	The ID of the session that you want to connect to.
/control	Give control of the session when shadowing.
/noConsentPrompt	To allow shadowing without user consent.
/migrate	Migrate legacy connection files created with Client Connection Manager to new .rdp connection files.
/?	To get help in the command prompt.

These switches can have the following syntax in either Run or the Command Prompt:

mstsc [<connection file>] [/v:<server[:port]>] [/g:<gateway>] 
[/admin] [/f] [/w:<width> /h:<height>] [/public] | 
[/span] [/multimon] [/edit "connection file"] [/restrictedAdmin] 
[/remoteGuard] [/prompt] [/shadow:<sessionID> [/control][/noConsentPrompt]]

The parameters in the alligator brackets (< and >) are variables that you can adjust according to your preferences.

Troubleshoot RDC via command line

You can also troubleshoot Remote Desktop services through the command line. For example, if you are unable to connect to a device using the GUI RDC but have access via console, you can check whether there are any configurations to be made that will connect you via GUI successfully.

Check if RDP is enabled from Command prompt

Learn how to enable RDP remotely.

You can run the following command to check the status of your device if RDP is enabled or disabled:

netstat /p tcp /a | findstr 3389

If the results come back as “Listening,” it means that RDP is enabled.

Check if RDP is enabled from PowerShell

Another method to check whether RDP is enabled is through Windows PowerShell. You can run the following commands in PowerShell and it will tell you whether the service is available or not.

if ((Get-ItemProperty "hklm:\System\CurrentControlSet\Control\Terminal Server").fDenyTSConnections -eq 0) { write-host "RDP is Enabled" } else { write-host "RDP is NOT enabled" }

If the script returns “RDP is enabled,” it means that it is.

Frequently Asked Questions