Чем можно посмотреть список запущенных процессов на машине пользователя как это сделать удаленно
Как посмотреть список процессов в Windows на удаленном компьютере
Бывает так, что нам нужно посмотреть, запущена та или иная программа на удаленном компьютере. Просто и быстро. Без стороннего софта. Ну или по каким-то другим причинам посмотреть запущенные процессы.
Если говорить о локальном компьютере, то абсолютное большинство использует для мониторинга процессов Windows Диспетчер задач. Но вот в случае с удаленным компьютером он нам не помощник. Рассмотрим очень простой способ.
tasklist [/S имя_удаленного_компьютера [/U имя_пользователя [/P пароль]]] [/M модуль | /SVC | /V] [/FI фильтр] [/FO формат] [/NH]
/S — необходимо указать имя удаленного компьютера, если подключаемся к такому. Для локального компьютера не указывается;
/U — имя пользователя, от которого будут просматриваться процессы. Пользователь должен быть администратором;
/P — пароль от указанной учетной записи пользователя, если пароль не указан, будет выполнен запрос на ввод пароля;
/M — отображение всех процессов, которые используют указанное имя. Если не задано, будут отображаться все процессы;
/SVC — отображение служб для каждого процесса;
/V — ведение подробного протоколирования;
/FI — отображение процессов, которые соответствуют указанному фильтру;
Таким образом, если нам просто нужно посмотреть список запущенных процессов на локальном компьютере, то достаточно просто набрать
Пример вывода команды tasklist.
Если же мы хотим посмотреть процессы на удаленном компьютере (например, с именем Test-PC), то команда должна выглядеть следующим образом:
Использование фильтров в команде tasklist.
Начнем с того, что фильтр заключается в кавычки. Далее идёт очень простая схема:
[имя_фильтра] [оператор] [значение]
Есть ограниченное число имён фильтров, операторов и значений. Они в таблице ниже.
| Имя фильтра | Допустимые операторы | Допустимые значения | Описание |
| STATUS | eq, ne | RUNNING, SUSPENDED, NOT RESPONDING, UNKNOWN | Статус процесса |
| IMAGENAME | eq, ne | Имя (часть имени) процесса(-ов) | Подходящие по наименованию процессы |
| PID | eq, ne, gt, lt, ge, le | Значение PID | Идентификатор процесса |
| SESSION | eq, ne, gt, lt, ge, le | Номер сеанса | Номер сеанса в Windows |
| SESSIONNAME | eq, ne | Имя сеанса | Имя сеанса в Windows |
| CPUTIME | eq, ne, gt, lt, ge, le | Время ЦП в формате чч:мм:сс (часы:минуты:секунды) | Время обработки задачи |
| MEMUSAGE | eq, ne, gt, lt, ge, le | Используемая ОЗУ (в КБ) | Размер используемой задачей оперативной памяти |
| USERNAME | eq, ne | Имя пользователя | Пользователь, из-под которого запущен процесс |
| SERVICES | eq, ne | Имя службы | Используемые службы |
| WINDOWTITLE | eq, ne | Заголовок окна | Заголовок окна процесса |
| MODULES | eq, ne | Имя dll (динамически подключаемой библиотеки) | Используемые библиотеки |
Отметим, что для удаленных компьютеров не действуют фильтры «WINDOWTITLE» и «STATUS».
Используемые операторы сравнения означают следующее:
eq — равно;
ne — не равно;
gt — больше;
lt — меньше;
ge — больше или равно;
le — меньше или равно.
Синтаксис фильтров является, пожалуй, самой сложной частью. Все следующие примеры проще. Тот же просмотр служб, относящихся к задачам, вызывается следующей командой:
Просмотр используемых служб в команде tasklist.
Если мы хотим вывести информацию в файл, то нужно использовать параметр /FO. Конечно же, у вас должны быть права на запись в каталог, куда вы хотите поместить файл с выводимой информацией. Команда
Что, если нам надо посмотреть какие процессы используют определенную dll-библиотеку? Например, библиотеку cfgmgr32.dll. Это можно сделать командой
Управление процессами с помощью PowerShell
PowerShell предоставляет широкие возможности управления процессами на локальном или удаленном компьютере. С помощью PowerShell можно получить список запущенных процессов, приостановить зависший процесс, найти процесс по заголовку окна, запустить новый процесс в скрытом или интерактивном режиме.
Список доступных командлетов управления процессами в Windows 10 можно вывести так:
Get-Command –Noun Process
Get-Process – получение списка запущенных процессов
Командлет Get-Process позволяет вывести список запущенных процессов на локальном компьютере.
По-умолчанию выводятся следующие свойства запущенных процессов:
Чтобы получить все свойства нескольких процессов:
Get-Process winword, notep* | Format-List *
Можно вывести только определенный свойства процессов. Например, имя (ProcessName) время запуска (StartTime), заголовок окна процесса (MainWindowTitle), имя исполняемого файла (Path) и наименование разработчика (Company):
Get-Process winword, notep* | Select-Object ProcessName, StartTime, MainWindowTitle, Path, Company|ft
Вывести список запущенных процессов пользователя с графическими окнами (в список не попадут фоновые и системные процессы):
Get-Process | Where-Object <$_.mainWindowTitle>| Format-Table Id, Name, mainWindowtitle
С помощью параметра IncludeUserName можно вывести имя пользователя (владельца), который запустил процесс:
С помощью Where-Object можно выбрать процессы в соответствии с заданными критериями. Например, выведем все процессы, которые используются более 200 Мб оперативной памяти, отсортируем процессы в порядке убывания используемого объема RAM, размер памяти из Кб преобразуем в Мб:
Как мы уже говорили ранее командлет Get-Process в параметре CPU содержит время использования процессора конкретным процессом в секундах. Чтобы отобразить процент использования CPU процессами (по аналогии с Task Manager), используйте такую функцию:
Чтобы найти зависшие процессы (которые не отвечают), выполните команду:
Start-Process, Stop-Process: запуск и остановка процессов из PowerShell
Чтобы запустить новый процесс с помощью PowerShell используется команда:
Можно запустить программу и передать ей аргументы:
С помощью параметра WindowStyle вы можете задать режим запуска окна процесса (normal, minimized, maximized, hidden). Например, чтобы запустить программу в максимально развернуом окне и дождаться завершения процесса, выполните команду:
С помощью командлета Stop-Process можно завершить любой процесс. Например, чтобы закрыть все запущенные процессы notepad:
По-умолчанию не запрашивается подтверждение завершения процесса. Закрываются все процессы, которые соответствуют указанным критериям. Чтобы запросить подтверждение завершения для каждого процесса, добавьте –Confirm.
Из PowerShell можно принудительно завершить все приложения, которые не отвечают диспетчеру процессов Windows:
PowerShell: управление процессами на удаленном компьютере
С помощью аргумента ComputerName командлет Get-Process позволяет управлять процессами на удаленных компьютерах (должен быть включен и настроен WinRM).
Если вы хотите завершить процесс на удаленном компьютере, имейте в виду, что у командлета Stop-Process отсутствует параметр –ComputerName. Для завершения процесса на удаленном компьютере можно использовать такой PowerShell код:
1000++ способ запуска команд на удаленном компьютере
В наше время даже для собак придумали удаленное управление.
Возвращаясь к циклу «Конспект Админа», мне хотелось бы рассказать о вариантах запуска исполняемых программ на удаленных компьютерах. Эта статья будет интересна тем, у кого еще нет систем централизованного управления, но уже есть понимание утомительности ручного обхода рабочих станций и серверов. Либо тем, кому решения «под ключ» не интересны ввиду неспортивности.
В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать SMBv1 и загружать обновления. Да и провести инвентаризацию или установить срочный патч таким методом тоже можно.
Когда-то давно я устроился работать в организацию в период эпидемии Kido\Conficker. Наиболее простым способом выяснить, все ли хорошо в ИС компании, была славная утилита от Касперского под названием Kido Killer, которая проверяла наличие вируса и устраняла его. Запускать программу на доброй сотне машин руками было невесело, поэтому пришлось знакомиться с автоматизацией.
Если в операционных системах *nix для удаленного запуска, как правило, используется SSH, то у Windows способов запуска программ и скриптов воистину как песка в пустыне. Я разберу основные варианты, как общеизвестные, так и экзотические. Таких очевидных вещей как telnet-сервер касаться не буду, тем более Microsoft уже убрала его из современных ОС.
Способы старые, временем проверенные
Psexec
Пожалуй, это первое, что приходит на ум, когда идет речь об удаленном запуске программ. Утилита от Марка Руссиновича используется еще со времен Windows NT и до сих пор применяется. Помимо основной функции, можно использовать ее и как Runas, и для запуска программ в пользовательской сессии терминального сервера. Psexec также позволяет задавать ядра процессора, на которых будет запускаться программа, и ее приоритет в системе.
В качестве примера посмотрим, установлено ли обновление, закрывающее нашумевшую уязвимость SMB на списке компьютеров:
В файле computers.txt находится список компьютеров. Для запуска по всему домену можно использовать \\*. В файле \\server\share\log.txt будут появляться имена рабочих станций или серверов без обновления. Если в домене существуют компьютеры с *nix на борту или нет доступа к административному сетевому ресурсу Admin$ ― команда на этой машине не выполнится, но обработка продолжится. Чтобы скрипт не зависал при каждой попытке подключения, можно задать тайм-аут с помощью ключа -n.
Если компьютер выключен ― мы об этом не узнаем. Поэтому лучше предварительно проверять доступность машин или собирать в файле информацию об успешном или неудачном выполнении.
К минусам Psexec можно отнести то, что она из-за своего удобства и популярности часто используется вирусописателями. Поэтому антивирусные системы могут обнаруживать утилиту как опасность вида remote admin.
По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего Psexec. При необходимости логин и пароль можно задать явно или же использовать аккаунт SYSTEM.
Для управления системами Windows с помощью разных графических утилит часто используется WMI (Windows Management Instrumentation) ― реализация объектно-ориентированного стандарта управления WBEM. В качестве утилиты с графическим интерфейсом для работы с WMI можно использовать wbemtest.exe.
Для работы с WMI из консоли создана wmic.exe. Например, для проверки установленных обновлений вместо жутковатой конструкции из предыдущего примера можно использовать простую команду:
Использовать список компьютеров также можно командой /node:»@computers.txt».
Еще при помощи WMI можно запускать программы – синтаксис предельно прост:
К сожалению, в отличие от Psexec, получить вывод в консоли не получится ― придется выводить результаты команды в файл.
По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего wmic. При необходимости логин и пароль можно задать явно.
Групповые политики и скрипты
Если предыдущие варианты не требовали доменной среды, то в этом случае потребуется домен. Поддерживаются скрипты при входе и выходе пользователя из системы, а также при ее включении и выключении. Поскольку каждый администратор Windows сталкивался с ними, я не буду подробно расписывать как ими пользоваться ― лишь напомню, где их искать.
Скрипты, выполняющиеся при старте и завершении системы.
Скрипты, выполняющиеся при входе и выходе пользователя из системы.
Скрипты, настраиваемые в пользовательском разделе, выполняются от имени пользователя, а в разделе компьютера ― под аккаунтом SYSTEM.
Назначенные задания
Довольно интересный способ, заслуживающий право на жизнь. Назначенные задания можно создавать из командной строки при помощи утилиты schtasks.exe, выполнять их, затем удалять. Подробнее с синтаксисом можно ознакомиться в документации, я же разберу пример использования назначенных заданий в доменной среде. Предположим, нам нужно выполнить команду как можно быстрее вне зависимости от того, выключен компьютер или нет. Для этого используются так называемые предпочтения групповых политик (Group Policy Preference).
Искать установку назначенных заданий следует в конфигурации компьютера или пользователя ― «Настройка ― Параметры панели управления ― Назначенные задания».
Создание нового назначенного задания.
Для выполнения команды или скрипта ASAP понадобится создать «Немедленную задачу (Windows 7 и выше)». Если вдруг в инфраструктуре остались машины под управлением Windows XP, то подойдет «Очередное задание (Windows XP)».
Стоит сделать несколько политик с соответствующими WMI-фильтрами или создать два разных назначенных задания в одной политике с нацеливанием ― например, при помощи того же WMI-фильтра. Это поможет избежать конфликтов в разнородной среде со старыми и новыми Windows.
Пример WMI-фильтра для применения политики только на компьютерах с Windows XP:
В остальном процедура создания назначенного задания тривиальна. Единственное, не забывайте отметить пункт «Применить один раз и не применять повторно», если задача не требует повторного запуска.
Запускаем немедленную задачу только один раз.
При использовании таких назначенных заданий программа запустится, как только компьютер получит обновление групповой политики. Это удобно: не нужно проверять доступность компьютеров в случае Psexec и wmic и заставлять пользователей перезагружать машины, как в случае скриптов групповых политик. При необходимости можно скопировать файл скрипта локально в разделе «Настройка ― Конфигурация Windows ― Файлы».
Назначенные задания позволяют явно задать имя пользователя для запуска программы, в том числе и для SYSTEM.
Через реестр
Модификация реестра на пользовательских машинах ― странный вариант, лишь на случай крайней необходимости. Можно использовать ветки Run или RunOnce. Подробнее о них ― в документации. Сама модификация реестра может проводиться через групповые политики или из командной строки ― например, такой командой:
В зависимости от ветки реестра, процесс будет выполняться или под пользователем, выполнившим вход в систему, или под аккаунтом SYSTEM.
Есть и другие способы, такие как правка ярлыков в папке «Автозагрузка» или добавление в ярлык к популярной программе && script.cmd, но эти методы уже из серии «можно, но не нужно».
Теперь перейдем к новым инструментам.
Способы новые или куда же без PowerShell
PowerShell, оправдывая свое название, может подключаться к удаленным компьютерам при помощи WMI, RPC и WS-Management (WSMan). Использование последнего метода требует предварительной настройки.
Командлеты, не требующие предварительной настройки, как правило, имеют параметр ComputerName, но не имеют параметра Session. Посмотреть список таких командлетов можно командой:
Для настройки WSMan в общем случае достаточно выполнить команду Enable-PSRemoting-Force. Она запустит службу удаленного управления WinRM и пропишет исключения в фаерволе ― в принципе, это можно сделать для всего домена при помощи групповых политик. Подробнее настройка описана в документации.
После того как все компьютеры будут готовы принимать запросы, мы сможем подключаться при помощи соответствующих командлетов PowerShell. Для проверки возможности подключения используется командлет Test-WSMan.
Проверка возможности подключения.
Для того чтобы выполнить определенную команду или скрипт, используется командлет Invoke-Command со следующим синтаксисом:
Где COMPUTER ― имя компьютера, COMMAND ―– имя команды, а USERNAME ― имя пользователя, если оно нужно.
Смотрим содержимое диска С удаленного компьютера.
Если же нам нужно получить полноценную консоль ― не автоматизации ради, а ради управления конкретным компьютером, ― то можно использовать командлет Enter-PSSession.
Работаем в консоли удаленного компьютера.
Напомню, что с помощью JEA можно ограничить доступные подобной сессии командлеты или дать доступ нужным без прав администратора.
Конечно, кроме встроенных средств и небольших утилит, существует множество программ для управления структурой. Помимо взрослых решений, для управления конфигурациями вроде Chef, Ansible и MS SCCM можно использовать и средства мониторинга вроде Zabbix, и даже консоль управления антивирусом Касперского.
В период гетерогенных структур хорошо бы иметь возможность унифицированного управления Windows и Linux. Это можно сделать и с помощью PowerShell, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?
Кстати, поделитесь вашими способами скрытого и не очень запуска программ на удаленных компьютерах. Ну, за исключением эксплойтов.
Удаленное управление сеансом пользователя windows стандартными средствами
Однажды мне захотелось управлять одним из домашних компьютеров удаленно, но при этом взаимодействовать с текущим пользователем, но компьютер был довольно слабый и при запуске например TeamViewer’а нагрузка процессора поднималась до 98% и компьютер начинал заметно тормозить. Попробовал стандартный RDP, но тогда «выбивался» текущий пользователь и для входа локально приходилось набивать пароль. Но чуть позже мне случайно попалась команда shadow.
Наблюдать за другим сеансом служб удаленных рабочих столов.
SHADOW < | >[/SERVER: ] [/V]
Имя сеанса.
Идентификатор сеанса.
/SERVER: Сервер терминалов (по умолчанию текущий).
/V Отображение информации о выполненных действиях.
Тогда получается что запускается всего 2 процесса.
Для того что бы все это работало нам необходимо сначала включить RemoteRPC, например через реестр:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“AllowRemoteRPC”=dword:00000001
После этого можно будет через Диспетчер служб удаленных рабочих столов посмотреть какие пользователи залогинены на компьютере, какие у них id и какие процессы запущены (жаль только названия, нет информации о нагрузке).
По умолчанию пользователю будет задаваться вопрос с разрешением управления, можно отключить вопрос или сделать только удаленное наблюдение, меняется через реестр:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
«Shadow»=dword:0000000x
По умолчания этой строчки вообще нет и её нужно будет создавать.
Так же можно включить через групповые политики локальные или доменные. Для включения локально запускаем gpedit.msc — выбираем административные шаблоны — добавление и удаление шаблонов, добавляем System.adm из папки WINDOWS\inf
Теперь настраиваем: конфигурация компьютера — административные шаблоны — компоненты windows — службы терминалов — устанавливает правила для удаленного управления. Для windows xp.
И конфигурация компьютера — административные шаблоны — компоненты windows- службы удаленных рабочих столов – узел сеансов удаленных рабочих столов – подключения – устанавливает правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов. Для windows 7.
Все это работает и в домене, если у пользователя есть соответствующие права.
В доменных настройках профиля пользователя тоже есть настройка подобных прав (я встречал эти настройки даже в домене win 2000)
Если рассматривать терминальный сервер, то там через свойства RDP(через конфигурация узла сеансов удаленных рабочих столов) можно выставить любому пользователю права на удаленное управление,
и отдельно настроить взаимодействие или управление удаленным сеансом.
Для удобства можно подключаться через диспетчер задач
Как проверить список запущенных процессов в Windows?
В статье описывается несколько способов, которые помогут отобразить список запущенных процессов в Windows. Операции производятся в Windows 10, но что-то сработает и в более ранних версиях.
Согласитесь, задача отобразить список запущенных процессов далеко не самая сложная. Однако подходы к её решению не обязательно должны быть стандартными. Информацию по процессам можно представить и в более комфортном виде, чем, например, через…
Диспетчер задач
Чаще всего, кроме этого способа, пользователям больше ничего и не известно. Но, раз уж это так, значит, этого большинству из нас достаточно. Вызывается оный во всех последних версиях Windows просто — достаточно зажать три клавиши быстрого доступа:
Ctrl + Shift + Esc
Вкладка с процессами не изменилась со времён Windows XP:
Однако, если вы на К76, вам Диспетчера мало. Согласен, продолжаем.
Список запущенных процессов из командной строки
В Windows есть встроенная командная утилита tasklist, отображающая список запущенных процессов на указанном компьютере. Как и многие другие в папке System32, tasklist принадлежит к числу административных утилит, которые могут смотреть запущенные процессы на удалённых машинах по сети. Для локального компьютера команда в консоли, запущенной от имени администратора, может, например, принять такой вид:
После этого на Рабочем столе появится текстовый файл:
в котором запущенные на момент исполнения команды будут представлены в удобочитаемом виде. Текстовый вывод не понимает кириллицы, так что я обычно использую специальные текстовые редакторы типа Notepad ++. Но, думаю, что в файле написано, понятно и так:
Или процессы можно представить в табличном формате; если есть Excel, можете просматривать процессы оттуда:
Для удалённого компьютера команда примет вид:
На этом можно было бы и закончить, но я продолжу аналогичным вариантом, откуда вы узнаете…
Как узнать список запущенных процессов из Power Shell
Информация из файла, получаемого аналогичным путём, будет немного более информативнее. Этот вариант доступен владельцам копий Windows 7/10, и командлет на отображение списка на том же Рабочем столе будет таким:
для локальной копии Windows: