Подключиться к консоли windows по сети

Бывает такие случаи, когда при использовании RDP (Remote Desktop Protocol — протокол удалённого рабочего стола), не видно программ, которые установленные в системном трее, или ошибки и уведомления просто не отображаются. Для того, чтобы решить данную проблему, к терминальному северу можно подключиться в консольном режиме через тот же RDP.

Удаленный рабочий стол (Remote Desktop Protocol) или RDP — это технология дистанционного подключения к компьютеру (серверу), для непосредственного управлению им через локальную сеть или интернет. Я уже рассказывал о данной технологии в видеоуроке «Подключение к компьютеру через удаленный рабочий стол».

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

При использовании клиента удаленного рабочего стола (RDP) Windows, в качестве средства подключения к компьютеру с Windows Server 2003/2008/2012 с запущенной службой сервера терминалов, у вас есть возможность подключения на консоль сервера. Используя эту опцию, вы можете войти на сервер, так, как если бы вы сидели прямо перед ним, а не создавать новые сессии через сетевое подключение. Дело в том, что при удаленной установке некоторых программ, могут возникнуть проблемы, которые не позволят вам сделать это из терминальной сессии, поэтому вам понадобиться войти на сервер через консоль.

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

Для того, чтобы настроить удаленный доступ на целевом компьютере, владелец или администратор должен выполнить следующие действия (Мой компьютер \ Свойства \ Настройка удаленного доступа \ Удаленный доступ \ Разрешить подключение от компьютеров с любой версией удаленного рабочего стола).

Если хотите пускать в свой компьютер только определённых пользователей или группы пользователей вашей сети, то необходимо поставить галочку «Разрешить подключение с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети (рекомендуется)».

Как же подключиться к удаленному рабочему столу?

Это конечно же стандартными средствами Windows (Пуск \ Все программы \ Стандартные \ Подключение к удалённому рабочему столу)

Или через команду Выполнить (Win+R) и вводим команду mstsc. Это более быстрый способ и его используют в основном админы и разработчики программ, т.к. часто приходится подключаться к удаленным рабочим столам серверов.

Как же подключиться к консоли удаленного рабочего стола?

Для этого в появившемся окне вбиваем команду:

— Windows Server 2003 и Windows XP: mstsc /console

— Windows Server 2008/2012 и Windows 7/8/8.1: mstsc /admin

Вводим имя терминального севера или компьютера.

И вводим учетные данные пользователя имеющего права для удаленного подключения.

Так как RDP по умолчанию создаёт виртуальную консоль, то подключение происходит не к самой сессии, а непосредственно к консоли (основная консоль-мышь/клавиатура).

Какая разница между простым подключением к удаленному рабочему столу и подключением к консоли?

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

— В первом случае создается новая сессия (mstsc), параллельная с существующей. Во втором случае подключение осуществляется к своему рабочему столу (в рамках лицензий на терминал).

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

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

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

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

• Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:
  psexec @group.txt gpupdate /force
• Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:
  psexec \\computer -s wuauclt /detectnow
• Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:
  psexec \\computer -c -s klist.exe purge

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

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

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

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts="servername"}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser="X"}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns

Remote Desktop Protocol is a proprietary protocol developed by Microsoft which provides a user with a graphical interface to connect to another computer over a network connection. Most of us are administrators and we use this technology on a daily basis. Therefore, it isn’t new to us. Here is a link discussing all you need to know about the Kerberos delegation. Microsoft Terminal Services Client (MSTSC) is the command line interface to run the Microsoft Remote Desktop (RDP) client. It enables you to establish a remote connection to your Remote Desktop Server or Session Host (RDSH) as if you were directly connected. The mstsc command is used from within the Windows command line. In this article, you will learn about how to connect to the Remote Desktop console session from the command line.

You can type MSTSC directly into the search box on Windows 10 or from the Run dialogue box. You can also use the MSTSC command directly from the command line as well.  images below show what is obtainable and how to connect via the command line. There are a few different switches that you can use. I have described this topic extensively in this guide “how to protect Remote Desktop credentials with Windows Defender Remote Credential Guard or Restricted Admin Mode“. We will discuss all the various options available. 

Connect to Remote Desktop Console Session via the MSTSC Commands

The MSTSC command arguments used by an average user are /v and /f. You can use the command to set up the connection in seconds if the remote computer is in the same network or if you know the Internet Protocol (IP) address of the remote computer. The syntax of MSTSC is.

mstsc /?

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

Available MSTSC Command Line Arguments

The following are the available command line arguments:

Switches	Description
<connectionfile>	The name of the .rdp file required for establishing the connection.
/v:<server[:port]>	The remote computer or server where you want to connect.
/g:<gateway>	The RD Gateway Server to be used for the connection. Required only if the endpoint remote PC is specified with /v.
/admin	To establish the connection as an admin.
/f	To view the Remote Desktop Window in full screen.
/w:<width>	To specify the width of the Remote Desktop Window.
/h:<height>	To specify the height of the Remote Desktop Window.
/public	To run the Remote Desktop Connection publicly.
/span	To match the width and height of the Remote Desktop with the local desktop.
/edit <connectionfile>	To edit the specified .rdp file.
/multimon	To make the monitor layout of the Remote Desktop Services session identical to the client-side configuration.
/restrictedAdmin	To connect to the remote PC in the 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	To 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:<sessionID>	The ID of the session to be shadowed.
/control	To allow the control of the session when shadowing.
/noConsentPrompt	To allow shadowing without user consent.
/migrate	To migrate legacy connection files created with Client Connection Manager to new .rdp connection files.
/?	To display help in the command prompt.

This command will connect you to the console session on a server rather than starting a new session. Please see the following guides: How to remove saved RDP credentials entries in Windows 10, how to remove entries histories from the Remote Desktop Connection, and how to prevent the saving of Remote Desktop Credentials in Windows. In place of an RDP client, you can also use AnyDesk!

mstsc / console

Command to open Remote Desktop in full-screen mode

Starts Remote Desktop Connection in full-screen mode. Add /f switch to the command. Input mstsc/f and then press the Enter key. After that, input the IP address, and click on Connect. Finally, type in the credentials of the remote PC and then you can connect successfully.

mstsc /f

mstsc /v:computername

To connect to the console session of the remote machine. The “address” field should be replaced with the address of the remote machine. The program launched is also known as Microsoft Terminal Server Connection. Once you launch the mstsc program with the correct address and switches as indicated above, you will be able to login with the desired account. This will be the account’s console session.

mstsc /console /V:address

Note: You can use RDP to remotely connect to the console session of the device with the /admin switch as shown below. A console session is either when you’re at the computer’s physical console or a remote connection that’s the same as if you’re at the computer’s physical console. I have described a useful use case in this guide “MBAM Frequent Report Errors: Understanding Microsoft BitLocker Administration and Monitoring compliance state and error status“

mstsc.exe /admin /v:<IP address of device>

I hope you found this blog post helpful. Now, you have learned all the available options on how to connect to the Remote Desktop console session from the Command Line. If you have any questions, please let me know in the comment session.

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

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

В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать 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, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?

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