Удаленное управление windows http входящий трафик

В небольших офисах далеко не всегда используются сетевые принтеры и МФУ, поэтому получить статистику использования печатающих устройств получить достаточно сложно. Тем более, если это требуется произвести с минимальными затратами. Такие данные смогут помочь определить наиболее активно используемые устройства, оценить нагрузку на них и принять своевременные решения по закупке расходных материалов, техническом обслуживании или даже замене на более экономичные и производительные. Данную задачу возможно решить без дополнительного ПО используя встроенные средства управления журналами Windows и скриптом на Powershell.

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

• www.papercut.com/products/free_software/print_logger
• www.printaudit.com/print-audit-6.asp

Такие системы далеко не всегда подходят, так как они требуют покупки, бесплатные версии имеют ограниченную функциональность, необходима установка как центрального ПО на сервер, так и агентов на клиентские компьютеры, некоторые программы работают только с принт-сервером и так далее. Предлагаю использовать для решения задачи встроенные средства операционной системы Windows 7/2008R2 и скрипты на Powershell.

Итак, примем за исходные данные следующую информацию:

• В организации есть домен Active Directory
• В организации используются компьютеры c операционной системой не ниже Windows 7, сервера – с ОС не ниже Windows Server 2008R2
• Есть как сетевые, так и локальные принтеры и МФУ.
• Существует необходимость централизовано обрабатывать журналы печати с принтеров и иметь статистику использования и нагрузки на печатающие устройства.

Подготовка инфраструктуры

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

1. Наличие пользователя в группе Читатели журнала событий (Event Log Readers), от имени которого будет читаться журнал
2. Доступ по удаленному управлению (Windows Remote Management с сервера-коллектора
3. Настроенное разрешение на пересылку событий на сервер-коллектор логов.
4. Включенный журнал событий печати (выключен по умолчанию)

Создаем в оснастке Пользователи и Компьютеры нового пользователя, в качестве полного имени и логина указываем EventCollectorUser. Назначаем сложный пароль и ставим галочки «Запретить смену пароля пользователем» и «Срок действия пароля неограничен».

Далее создаем на контроллер домена новую групповую политику и называем ее, например, GPO-EventCollector.
В политике задаем следующие параметры:

1. В разделе «Конфигурация компьютера — Настройка — Параметры панели управления — Службы» создаем запись службы «Автозагрузка: Автоматически (отложенный запуск)», «Имя службы — Служба удаленного управления Windows (MS-Management) (WinRM)», «Действие службы: Запуск службы»
2. В разделе «Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Удаленное управление Windows — Служба удаленного управления Windows» задать параметр «Разрешить автоматическую настройку прослушивателей: Включить» и разделе параметра «Фильтр IPv4″ поставить значение «*».
3. В разделе «Конфигурация компьютера – Политики – Конфигурация Windows – Параметры безопасности – Брандмауэр Windows в режиме повышенной безопасности – Брандмауэр Windows в режиме повышенной безопасности – Правила для входящих подключений» создаем новое правило. Выбираем пункт «Предопределенные правила» и в списке выбираем «Удаленное управление Windows (HTTP — входящий трафик)»
4. В разделе «Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Пересылка событий» задать параметр «Настроить конечный диспетчер подписки» и в разделе параметра «SubscriptionManagers» вписать полный FQDN путь до сервера–коллектора.
5. В разделе «Конфигурация компьютера – Политики – Конфигурация Windows – Параметры безопасности – Группы с ограниченным доступом» добавляем новую группу «Читатели журнала событий». В члены группы добавляем созданного нами пользователя EventCollectorUser.

После создания групповой политики необходимо перезагрузить целевые компьютеры или выполнить на них команду gpupdate /force.

Включить журнал печати на целевом компьютере можно через оснастку MMC «Просмотр событий» по пути «Журналы приложений и служб – Microsoft – Windows – PrintService – Работает» (кликнуть правой кнопкой мыши на журнале и выбрать «включить»). Этот вариант подходит, если компьютеров не так много.
В случае, если требуется включить журнал на большой группе ПК, то можно воспользоваться следующим способом:

1. Подготовить текстовый файл со списком имен компьютеров. Например, d:\temp\computers.txt
2. Запустить следующую команду от имени пользователя с правами администратора домена:
   For /F %i in (d:\temp\computers.txt) do wevtutil sl Microsoft-Windows-PrintService/Operational /e:true /r:%i

Update: Также, как верно заметил NeSvist, можно установить ключ реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PrintService/Operational — Enabled равным 1.
Данный параметр можно раздать в групповой политике, которую мы создали выше.
Для справки: О работе с реестром в GPO

Создание подписки на события

После подготовки инфраструктуры можно переходить непосредственно к настройке подписки на события на сервере-коллекторе.

1. Идем в оснастку «Просмотр событий – Подписки».
2. Выбираем справа в меню «Создать подписку…»
3. Вводим имя подписки, например, «Test Subscription». Добавляем понятное описание.
4. Далее выбираем журнал, в который будут попадать принимаемые события. Рекомендую оставить все по умолчанию – «Перенаправленные события». Тут стоит заметить, что найти способ помещать события в журнал, созданный вручную, мне не удалось. Так что вариант по-умолчанию остается почти единственным.
5. Далее щелкаем на кнопке «Выбрать компьютеры…». В открывшемся окне кнопкой «Добавить» добавляем необходимые компьютеры-источники. Кнопкой «Проверить» можно проверить доступность целевых машин по протоколу удаленного управления, результат покажут в информационном окне.
6. Выбираем события, которые будем собирать с источников. Нас интересует уровень событий «Сведения» из журнала «Microsoft-Windows-PrintService/Работает» с кодом событий 307. Все остальные настройки оставляем по умолчанию.
7. Щелкаем по кнопке «Дополнительно», в открывшемся окне выбираем пункт «определенный пользователь» и указываем созданного нами пользователя и его пароль. Настройки оптимизации доставки событий оставляем в положение «Обычная».
8. Щелкаем «ОК» и подписка создана. При появлении событий в логе компьютеров-источников, они в течение 15 минут будут загружены на сервер-коллектор в журнал «Перенаправленные события».

Скрипт обработки собранных событий

Собранные события можно выгрузить в формате CSV средствами оснастки «Просмотр событий», но полученные данные будут не очень информативны и не позволят на их основе получить интересную статистику, которую можно показать руководству. Поэтому я предлагаю вариант обработки полученных событий средствами Powershell для удобства их дальнейшего использования.
Поиском на просторах Интернета был найден скрипт анализа журналов печати для Windows Server 2003. (http://trevorsullivan.net/2009/11/06/windows-2003-print-log-parsing-script-powershell/) Так как есть определенные различия в командлетах Powershell новых версий, и способ получения событий отличается от предложенного в статье, то скрипт был мной переработан.
Общую структуру скрипта я менять не стал, он разбит по функциям, которые легко модифицировать (в случае локализации, например). Логика работы скрипта следующая:

1. Получаем список событий из журнала
2. Парсим свойство Message каждого события и записываем поля в объект PrintJob
3. Сохраняем полученный список объектов в формате CSV

Получаем список событий из журнала «Перенаправленные события» по коду 307 (на случай, если в указанный журнал пересылаются еще какие-либо события).

Function GetPrintEntriesFromLog()
{
	$PrintEntries = get-winevent -FilterHashTable @{LogName='ForwardedEvents'; ID=307;}
	return $PrintEntries
}

Создаем новый объект PrintJob. Добавляем в него требуемые поля.

Function CreatePrintJob()
{
	$PrintJob = New-Object PsObject
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name PageCount -Value $null
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name UserName -Value $null
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name DocumentName -Value $null
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Size -Value $null
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Printer -Value $null
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Time -Value $null
	return $PrintJob
}

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

#Парсим параметры объекта
Function ParsePrintEntry($PrintEntry)
{
	$NewPrintJob = CreatePrintJob

	$NewPrintJob.PageCount = GetPageCount $PrintEntry.Message
	$NewPrintJob.UserName = GetUserName $PrintEntry.Message
	$NewPrintJob.DocumentName = GetDocumentName $PrintEntry.Message
	$NewPrintJob.Size = GetPrintSize $PrintEntry.Message
	$NewPrintJob.Printer = GetPrinterName $PrintEntry.Message
	$NewPrintJob.Time = $PrintEntry.TimeCreated.ToString()

	return $NewPrintJob
}

#Получаем имя пользователя
Function GetUserName($PrintEntry)
{
	If ($PrintEntry -eq "" -or $PrintEntry -eq $null) { return $null }
	$rxUserName = [regex]"которым владеет ([0-9a-zA-Z.]{1,})"
	$rxMatches = $rxUserName.Match($PrintEntry)
	return $rxMatches.Groups[1].Value
}

#Получаем имя принтера
Function GetPrinterName($PrintEntry)
{
	If ($PrintEntry -eq "" -or $PrintEntry -eq $null) { return $null }
	$rxPrinterName = [regex]"распечатан на (.{1,}) через"
	$rxMatches = $rxPrinterName.Match($PrintEntry)
	return $rxMatches.Groups[1].Value
}

#Получаем размер распечатки в байтах
Function GetPrintSize($PrintEntry)
{
	If ($PrintEntry -eq "" -or $PrintEntry -eq $null) { return $null }
	$rxPrintSize = [regex]"Размер в байтах: ([0-9]+)."
	$rxMatches = $rxPrintSize.Match($PrintEntry)
	return $rxMatches.Groups[1].Value
}

#Получаем количество страниц (самый важный параметр)
Function GetPageCount($PrintEntry)
{
	If ($PrintEntry -eq "" -or $PrintEntry -eq $null) { return $null }
	$rxPageCount = [regex]"Страниц напечатано: ([0-9]+)"
	$rxMatches = $rxPageCount.Match($PrintEntry)
	return $rxMatches.Groups[1].Value
}

#Получаем имя документа
Function GetDocumentName($PrintEntry)
{
	If ($PrintEntry -eq "" -or $PrintEntry -eq $null) { return $null }
	$rxDocumentName = [regex]", (.{1,}) которым владеет"
	$rxMatches = $rxDocumentName.Match($PrintEntry)
	return $rxMatches.Groups[1].Value
}

Основная функция. Получаем список событий и в цикле превращаем его в объект PrintJob. Потом делаем экспорт полученного списка объектов в указанный файл. Ставим кодировку UTF8 для корректного отображения кириллицы и разделитель «;» для читаемого открытия файла в Excel. Каждые 100 событий пишем лог, это удобно при отладке.

Function Main()
{
	$PrintEntries = GetPrintEntriesFromLog
	$Global:ParsedEntries = @{}; $i = 0

	ForEach ($PrintEntry in $PrintEntries)
	{	
        $ParsedEntries.Add($i, $(ParsePrintEntry $PrintEntry))
		$i++
		if ($i % 100 -eq 0)
		{ Write-Host "Processed $i records" }
	}
    $ParsedEntries.Values | Export-Csv "D:\PrintReports\PrintUsageReport.csv" -NoTypeInformation -Encoding UTF8 -Delimiter ';'
}

#Запускаем главную функцию.
Main 

При подготовке регулярных выражений для скрипта использовался сайт Regex101.com. Сайт понятный, с краткой документацией, подсветкой результата поиска в исходной строке, расшифровкой смысла регулярного выражения на лету. Очень информативно и удобно, рекомендуется к употреблению.
Полученный скрипт можно применять по требованию, запуская в командной оболочке PowerShell, а можно назначить в качестве задания в Планировщике заданий.
Для этого необходимо:

1. Открыть Планировщик заданий (Пуск – Администрирование – Планировщик заданий)
2. Выбрать пункт «Создать простую задачу…»
3. Ввести имя задачи, описание, выбрать интервал выполнения
4. Выбрать действие «запустить программу». В качестве программы выбрать «C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe», а в качестве аргумента – путь к скрипту.
5. Открыть свойства задачи и выставить переключатель «Выполнять вне зависимости от регистрации пользователя», выбрать пользователя, от имени которого должна выполняться задача и ввести пароль от него.

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

Решение проблем

1. Если при запуске скрипта возникает ошибка вида:
   

   Невозможно загрузить файл D:\PrintReports\PrintInfo.ps1, так как выполнение сценариев отключено в этой системе. Для получения дополнительных
   сведений см. about_Execution_Policies по адресу go.microsoft.com/fwlink/?LinkID=135170.
   + CategoryInfo: Ошибка безопасности: (:) [], ParentContainsErrorRecordException
   + FullyQualifiedErrorId: UnauthorizedAccess

   это означает, что политика безопасности для исполняемых скриптов Powershell не позволяет запустить программу. Для запуска созданного скрипта необходимо понизить уровень безопасности до «Remote Signed», то есть будет разрешено выполнение любых сценариев, созданных локально, а сценарии, созданные на удаленных системах, выполняются только в том случае, если подписаны доверенным издателем. Для этого в консоли Powershell, запущенной от имени администратора, необходимо выполнить команду Set-ExecutionPolicy RemoteSigned.

2. Для тестирования пересылки и сбора событий можно использовать инструмент командной строки eventcreate.exe. Эта утилита позволяет создавать события вручную в определенном журнале. К примеру, можно создать событие с ID 100 в логе Приложение при помощи следующей команды: eventcreate /t error /id 100 /l application /d «Custom event». Если все настроено правильно и есть сбор событий из указанного журнала, то событие окажется на сервере-коллекторе в течение минуты.
   Если событие не попало на сервер-коллектор, необходимо проверить следующее:
   • Если параметры задавались групповой политикой, то проверить, что политика применяется. При необходимости, можно принудительно применить групповую политику командой gpupdate /force
   • Статус службы Windows Remote Management (WinRM) (Служба удаленного управления Windows). Служба должна быть запущена и настроена на автоматический запуск. При необходимости на клиентском компьютере можно сконфигурировать данную службу командой winrm quickconfig. Эта команда конфигурирует службу WinRM, создает прослушиватель winrm и создает правило исключения брандмауэра.
     Для проверки, что сервер-коллектор может соединиться с компьютером-источником с помощью WinRM можно воспользоваться следующей командой: winrm id -remote:<Имя целевого компьютера> -u:<Имя пользователя> -p:<Пароль>. Указываются учетная запись и пароль пользователя, имеющего возможность подключения по winrm.
   • Пользователь EventCollectorUser входит в состав группы Читатели журнала событий. Только члены этой группы могут читать события на конкретном компьютере.

Что можно улучшить

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

• Выборка событий по времени (за день, неделю, месяц) и запись их в соответствующие отдельные листы электронной таблицы или выходные CSV-файлы. Можно предусмотреть задание диапазона дат при помощи входных параметров скрипта.
• Добавление графического представления данных с использованием сводных таблиц по пользователям и печатающим устройствам и графиков. Такой отчет можно сразу класть на стол руководителю.
• Настроить архивирование и ротацию журнала «Перенаправленные события», добавить функцию анализа соответствующих архивных файлов. Это будет разумно при работе с достаточно большим числом компьютеров (более 50).

Итак, в этой статье я постарался показать принцип централизованного сбора событий с журналов Windows и их дальнейшей обработки средствами Powershell. Данный способ подходит для решения задачи в небольших организациях. Разумеется, специализированное программное обеспечение справляется с поставленными целями более эффективно, но оно дорого, более громоздко, его установка приносит IT-специалисту меньше новых знаний и навыков, понимания работы обслуживаемого им программного обеспечения.

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

1. mcp.su/windows-server-2008/event-collector-in-windows-server-2008
2. windowsnotes.ru/powershell-2/nastrojka-udalennogo-vzaimodejstviya-v-powershell-chast-1
3. social.technet.microsoft.com/Forums/en-US/8e7399f6-ffdc-48d6-927b-f0beebd4c7f0/enabling-print-history-through-group-policy?forum=winserverprint
4. mywinsysadm.wordpress.com/2012/07/16/powershell-audit-printer-event-logs
5. www.winblog.ru/admin/1147767392-29031101.html
6. windowsitpro.com/security/q-what-are-some-simple-tips-testing-and-troubleshooting-windows-event-forwarding-and-collec

Update: Как заметили NeSvist и selenite, привязка к конкретной локализации и разбор ее регулярными выражениями — не самое эффективное решение. В связи с этим, привожу вариант обработки собранных событий с использованием их представления в XML. Решение получилось более аккуратным и понятным.

# Получаем события из лога      
$Events = Get-Winevent -FilterHashTable @{LogName='ForwardedEvents'; ID=307;}      

# Массив заданий печати
$Jobs = @()
ForEach ($Event in $Events) {            
    # Конвертируем событие XML            
    $eventXML = [xml]$Event.ToXml()
    # Создаем новый объект задания печати и заполняем поля из XML-представления события            
    $PrintJob = New-Object PsObject
    Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name PageCount -Value $eventXML.Event.UserData.DocumentPrinted.Param8
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name UserName -Value $eventXML.Event.UserData.DocumentPrinted.Param3
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name DocumentName -Value $eventXML.Event.UserData.DocumentPrinted.Param2
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Size -Value $eventXML.Event.UserData.DocumentPrinted.Param7
	Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Printer -Value $eventXML.Event.UserData.DocumentPrinted.Param5
    # Приводим дату из формата SystemTime к обычному представлению.
    $date = Get-Date $eventXML.Event.System.TimeCreated.SystemTime
    Add-Member -Force -InputObject $PrintJob -MemberType NoteProperty -Name Time -Value $date
    # Добавляем задание печати к массиву
    $Jobs += $PrintJob
}            

# Выводим список полученных заданий печати в CSV          
$Jobs | Export-Csv D:\PrintReports\events.csv -NoTypeInformation -Encoding UTF8 -Delimiter ';'  

Эффективное управление ИТ начинается с наличия правильных инструментов для контроля за системами и устройствами, независимо от их местонахождения. Windows Remote Management (WinRM) — это инструмент, который помогает ИТ-администраторам выполнять важные задачи, такие как устранение неполадок, настройка и автоматизация, без физического присутствия.

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

Картинка с сайта: blog.scalefusion.com

В этом блоге объясняются ключевые аспекты WinRM: от его функций и настройки до возникающих проблем. 

Что такое удаленное управление Windows (WinRM)?

Windows Remote Management (WinRM) — это протокол на базе Windows, разработанный для упрощения удаленного управления и автоматизации. Он построен на протоколе WS-Management — общедоступном стандарте для удаленного обмена данными управления с любым компьютерным устройством, реализующим этот протокол. 

Протокол WS-Management обеспечивает совместимость между устройствами и системами. Он полезен в сочетании с удаленным управлением PowerShell, что позволяет администраторам управлять несколькими устройствами с помощью скриптов и команд.

Цель WinRM

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

Совместимость 

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

Почему важен протокол WinRM?

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

Использование WinRM для подключения к удаленному компьютеру в сценарии удаленного управления Windows очень похоже на создание локального подключения. WinRM предназначен для улучшения управления оборудованием в различных сетевых средах. 

WinRM — это инструмент командной строки, встроенный в операционные системы Windows, который использует .NET и PowerShell. Это позволяет выполнять удаленные команды и скрипты PowerShell как на отдельных машинах Windows, так и на больших наборах удаленных систем без необходимости использования RDP или прямого входа.

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

• Удаленный мониторинг, управление и настройка серверов, операционных систем и клиентских машин.
• Общайтесь и взаимодействуйте с хостами по всей сети, включая рабочие станции, серверы и любые операционные системы, поддерживающие WinRM.
• Выполнять команды в системах, доступных через сеть, без физического присутствия.

Основные компоненты удаленного управления Windows (WinRM)

Картинка с сайта: blog.scalefusion.com

Основа WinRM основана на следующих основных компонентах. Эти компоненты работают вместе, чтобы обеспечить удаленное управление системами Windows, облегчить задачи автоматизации и обеспечить безопасное удаленное выполнение команд. 

1. Служба WinRM (winrm.exe)

Это основная служба, которая работает на устройствах Windows, позволяя им принимать и отвечать на запросы удаленного управления. Она прослушивает входящие запросы на определенных портах (по умолчанию 5985 для HTTP и 5986 для HTTPS).

2. Прослушиватель WinRM

Прослушиватель отвечает за прием и обработку входящих запросов на удаленное управление. Он прослушивает указанный сетевой порт (5985 для HTTP или 5986 для HTTPS). Каждый прослушиватель привязан к определенному сетевому интерфейсу и протоколу.

3. Инструмент командной строки WinRM (winrm.exe)

Это утилита командной строки, используемая для настройки и управления службой WinRM. Она позволяет администраторам запускать, останавливать или настраивать прослушиватели WinRM, устанавливать политики аутентификации и устранять неполадки в настройках WinRM.

4. Протокол WS-Man (веб-сервисы для управления)

Windows Remote Management основан на протоколе WS-Man, который является стандартом для веб-служб, используемых для управления устройствами. Он позволяет обмениваться данными управления независимо от платформы, обеспечивая связь между компьютерами, устройствами и приложениями независимо от операционных систем.

5. Удаленное взаимодействие PowerShell

PowerShell Remoting построен на WinRM и позволяет администраторам выполнять команды PowerShell на удаленных системах. Он обеспечивает безопасный канал для удаленного выполнения скриптов и команд как на Windows, так и на не-Windows системах (с помощью сторонних инструментов).

6. Аутентификация и шифрование

WinRM поддерживает несколько механизмов аутентификации, включая базовую аутентификацию, Kerberos и NTLM. Он также поддерживает шифрование для безопасного обмена данными между клиентом и сервером, гарантируя защиту конфиденциальных данных во время процесса удаленного управления.

7. Правила брандмауэра

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

Как работает WinRM?

Картинка с сайта: blog.scalefusion.com

Процесс взаимодействия между клиентом и сервером через удаленное управление Windows обычно состоит из следующих этапов:

Этап 1 — Клиент инициирует запрос: процесс начинается, когда клиент WinRM (например, скрипт PowerShell) отправляет запрос на сервер WinRM. Этот запрос может включать выполнение команды или получение системной информации.

Этап 2 — Аутентификация и авторизация: Сервер должен аутентифицировать клиента перед выполнением любого действия. WinRM поддерживает несколько механизмов аутентификации, включая:

• Согласование аутентификации (Kerberos или NTLM)
• Базовая аутентификация (учетные данные отправляются в виде обычного текста)
• Аутентификация на основе сертификатов (с использованием SSL-сертификатов)

После аутентификации сервер проверяет, есть ли у клиента соответствующие разрешения для выполнения запрошенного действия.

Этап 3 — Обмен данными: Клиент отправляет фактическую команду или запрос после успешной аутентификации. Сервер WinRM обрабатывает этот запрос и возвращает результаты. Данные передаются в формате XML, который понимают как клиент, так и сервер.

Этап 4 — Выполнение команд: Если запрос включает выполнение команды, сервер выполнит команду на удаленной машине. Это может включать вызов скрипта, сбор системной информации или изменение конфигураций.

Этап 5 — Response Sent Back: После завершения задачи сервер отправляет ответ обратно клиенту с результатом операции. Это может включать стандартный вывод выполненных команд, коды ошибок или подтверждение внесенных изменений.

Варианты использования WinRM

1. Удаленное выполнение команд: Системные администраторы могут запускать команды на нескольких удаленных машинах одновременно, что снижает необходимость в физическом доступе.

2. Автоматизированное написание сценариев: WinRM обычно используется в скриптах для автоматизации задач на нескольких компьютерах, таких как установка программного обеспечения, обновления или настройка системы.

3. Управление серверными фермами: WinRM необходим для управления большим количеством серверов в центрах обработки данных, делая управление серверами более эффективным.

4. Аудит безопасности: WinRM можно использовать для сбора данных в целях аудита, например, для проверки системных журналов или просмотра параметров конфигурации.

Преимущества удаленного управления Windows (WinRM)

Удаленное управление Windows (WinRM) обеспечивает ряд существенных преимуществ для ИТ-операций, повышая эффективность, диагностику, экономичность и масштабируемость, особенно в корпоративных средах.

1. Повышенная эффективность

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

2. Лучшая диагностика

Благодаря подробным возможностям регистрации и мониторинга WinRM помогает быстрее выявлять и решать проблемы. Диагностика в реальном времени минимизирует время простоя, предоставляя ИТ-отделам информацию, необходимую для эффективного устранения неполадок из любого места.

3. Экономически эффективным

WinRM является экономически эффективным решением, сокращая расходы на поездки и оборудование. Удаленная диагностика неисправностей позволяет ИТ-персоналу обрабатывать больше систем с меньшими ресурсами, что сокращает эксплуатационные расходы.

4. Масштабируемость для предприятий

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

Проблемы использования удаленного управления Windows (WinRM)

1. Сложная конфигурация

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

2. Вопросы безопасности

WinRM представляет потенциальные риски безопасности, если не настроен должным образом. Слабые настройки шифрования, неправильная аутентификация или открытые порты могут подвергнуть систему киберугрозам. В ноябре 2024 года Microsoft устранила критические уязвимости в системах Windows, включая те, которые связаны с NTLM и планировщиком заданий. Хотя не все они были напрямую связаны с WinRM, они подчеркивают проблему небезопасных служб удаленного управления.

3. Ограниченная совместимость

WinRM оптимизирован для управления средами Windows, что означает, что он менее эффективен в гетерогенных ИТ-экосистемах, где используются macOS, Linux или мобильные устройства. Хотя существуют обходные пути, такие как использование удаленного PowerShell, они часто добавляют сложности и по-прежнему не полностью решают кросс-платформенное управление, что ограничивает область применения утилиты WinRM.

4. Расходы на устранение неполадок

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

5. Проблемы масштабируемости

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

Scalefusion UEM как лучшая альтернатива — почему?

Хотя Windows Remote Management (WinRM) служит надежным инструментом для управления средами на базе Windows, современные ИТ-технологии требуют более универсальных, масштабируемых и кроссплатформенных решений. 

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

1. Кроссплатформенная совместимость

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

Scalefusion UEM, с другой стороны, предназначен для управления всеми конечными точками, включая Windows, macOS iOS, Android, Linux и ChromeOS с одной платформы. Это делает его гораздо более универсальным решением, особенно в организациях с гетерогенной ИТ-экосистемой.

2. Упрощенная настройка и управление

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

Scalefusion UEM упрощает настройку и предоставляет централизованный и логически организованный интерфейс для управления устройствами, пользователями и политиками. Администраторы могут настраивать политики в одном профиле устройства и применять их к устройствам оптом, что делает управление более эффективным и безошибочным.

3. Повышенная безопасность

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

В отличие от этого, Scalefusion UEM предоставляет расширенные функции безопасности, такие как управление приложениями, настройка шифрования BitLocker, Управление обновлениями и исправлениями ОС, управление браузером, отслеживание местоположения и Geofencing. Он также обеспечивает интеграцию с решениями IAM, такими как OneIdP, и решениями безопасности конечных точек, такими как Veltar. Эти функции гарантируют, что конфиденциальные корпоративные данные и устройства остаются в безопасности на всех устройствах, снижая риск несанкционированного доступа и утечки данных. 

4. Масштабируемость для современных предприятий

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

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

5. Эффективное устранение неполадок и удаленная поддержка

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

Scalefusion UEM, с другой стороны, предлагает мощные удаленное устранение неполадок Возможности, такие как удаленная трансляция и управление, вызовы VoIP, передача файлов и подробная информация об устройстве, все в удобном интерфейсе. ИТ-отделы могут быстро выявлять и устранять проблемы с устройством, минимизируя время простоя и повышая общую производительность.

6. Перспективное управление ИТ

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

Вам нужна защищенная и полностью управляемая экосистема Windows? 

По умолчанию трафик в сессии PowerShell Remoting шифруется независимо от того, используется ли для передачи протокол HTTP (порт TCP/5985) или HTTPS (порт TCP/5986). Весть трафик в любом случае шифруется с помощью ключа AES-256. Однако, если вы подключаетесь к удаленному компьютеру не вашем лесу AD, или в рабочей группе, с которой Kerberos не может обеспечить доверительные отношения, вы рискуете стать жертвой man-in-the middle атак. Microsoft рекомендует всегда исопльзовать HTTPS транспорт для PowerShell Remoting, когда вы подключаетесь к сторонним компьютерам.

В этой статье мы рассмотрим, как настроить PowerShell Remoting через HTTPS с помощью SSL сертификата, который обеспечивает более высокий уровень защиты ваших сессий к компьютерам не в домене Active Directory.

Следующие шаги описывают настройку удаленного Windows устройства, к которому вы хотите подключаться через PowerShell Remoting по HTTPS.

Убедитесь, что тип вашей сети (сетевого подключения) определяется как Private или Domain:

Get-NetConnectionProfile

Включите WinRM и PSRemoting с помощью команды:

Enable-PSRemoting -Force

Чтобы настроить HTTPS для WinRM, сначала вам нужно создать SSL сертификат на компьютере, к которому вы хотите подключиться. Этот сертификат будет использоваться для шифрования WinRM трафика. Проще всего создать самоподписанный сертификат с помощью PowerShell (в доменной среде вы можете автоматизировать выпуск сертификатов для WinRM через Auto Enrollment).

В качестве DNS имени сертификата будет указаны имя компьютера и его IP адрес (удобно, если вашей сети не DNS сервера). Оба значения для Subject Alternative Name сертфиката можно получить через PowerShell:

$hostName = $env:COMPUTERNAME
$hostIP=(Get-NetAdapter| Get-NetIPAddress).IPv4Address|Out-String
$srvCert = New-SelfSignedCertificate -DnsName $hostName,$hostIP -CertStoreLocation Cert:\LocalMachine\My
$srvCert

Новый SSL сертификат появится в персональном хранилище сертификатов компьютера.

Картинка с сайта: winitpro.ru

По умолчанию для Powershell Remoting в Windows созданы два листенера на разных портах: HTTP на порту 5985 и HTTPS на 5986. Список активных листенеров можно получить так:

Get-ChildItem wsman:\localhost\Listener

Удалите стандартные HTTP и HTTPS листенеры:

Get-ChildItem wsman:\localhost\Listener\ | Where-Object -Property Keys -like 'Transport=HTTP*' | Remove-Item -Recurse

Создайте новый HTTPS листенер и привяжите к нему ваш сертификат:

New-Item -Path WSMan:\localhost\Listener\ -Transport HTTPS -Address * -CertificateThumbPrint $srvCert.Thumbprint -Force

Картинка с сайта: winitpro.ru

Создайте правило для Windows Firewall, которое разрешает WinRM HTTPS трафик, или проверьте что она активно:

New-NetFirewallRule -Displayname 'WinRM - Powershell remoting HTTPS-In' -Name 'WinRM - Powershell remoting HTTPS-In' -Profile Any -LocalPort 5986 -Protocol TCP

Перезапустите службу WinRM:

Restart-Service WinRM

Вы можете проверить к какому отпечатку сертификата привязан HTTPS листенер WinRM с помощью команды:

WinRM e winrm/config/listener

Удаленный хост настроен. Теперь вам нужно экспортировать SSL сертификат в cer файл:

Export-Certificate -Cert $srvCert -FilePath c:\PS\PsRemoting-Cert.cer

Не забудьте, проверить что конфигурации WinRM сервера и клиента запрещают нешифрованное подключение (по-умолчанию это так):

dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted
dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted

Картинка с сайта: winitpro.ru

Если нужно, запретите использовать нешифрованные подключения:

winrm set winrm/config/service '@{AllowUnencrypted="false"}'
winrm set winrm/config/client '@{AllowUnencrypted="false"}'

Скопируйте cer файл на ваш компьютер и импортируйте его командой (или распространите сертфикат на компьтеры через GPO):

Import-Certificate -FilePath c:\PS\PsRemoting-Cert.cer -CertStoreLocation Cert:\LocalMachine\root\

Теперь для подключения к удаленному серверу через WinRM HTTPS нужно использовать аргумент -UseSSL в командах Enter-PSSession и Invoke-Command. В следующем примере мы подключимся к удаленному хосту из консоли PowerShell по IP адресу (обратите внимание, что мы не добавляли этот IP адрес в TrustedHosts):

$SessionOption = New-PSSessionOption -SkipCNCheck
Enter-PSSession -Computername 192.168.13.4 -UseSSL -Credential kbuldogov -SessionOption $SessionOption

Картинка с сайта: winitpro.ru

При подключении по IP адресу если не использовать опцию SkipCNCheck появляется ошибка T
he SSL certificate contains a common name (CN) that does not match the hostname
.

WinRM and PowerShell Remoting is a crucial feature to have when managing remote Windows computers. Just like other services, WinRM listens on specific ports under specific circumstances. In this tutorial, learn those WinRM ports and even how to change them, if needed.

Related: PowerShell Remoting: The Ultimate Guide

The WinRM Listener

One of the most important parts of WInRM (and the ports it runs on) is the WinRM listener.

The WinRM listener is a web server at its core. It communicates with HTTP and HTTPS and back in the pre-Windows 7 days it even used to default to the same port 80 and port 443 that most web servers use.

The listener runs as a service on your computer that is waiting for connections to attempt to be established, just like a normal web server.

A WinRm listener can listen two different ways; HTTP or HTTPS. The WinRM port for HTTP is 5985 while the WinRm port for HTTPS is 5986, by default.

• HTTP – Port 5985
• HTTPS – Port 5986

Related: PowerShell Remoting: The Ultimate Guide

Errors Connecting to Wrong Ports

And if you do not add the firewall rule when you change the port you will get the same message even when providing the port like this.

Changing WinRM Ports

While Microsoft recommends staying with the default listening ports for compatibility and ease of use, you can change them. This can be helpful in cases when this is a conflict with the default ports or a firewall restriction blocking the use of those ports.

Maybe you have a system set up that’s configured to connect to WinRM over custom ports. When you try to connect like normal, you receive the following error message:

Картинка с сайта: adamtheautomator.com

If so, it’s time to change the WinRM port on the server side!

To change the WinRm ports, you’ll first need to figure out if you already have a service listening on those ports.

Tracking Down Existing Connections

The easiest way to discover what ports are in use on a Windows machine is to use the netstat tool. Netstat checks for all active ports on your system and, if active, returns the source and destination IP and port used.

To track down listening ports prior to changing WinRm posts, run netstat -aon. The -aon switches:

• show all active connections (a)
• show the process ID for the process that opened the connection (o)
• do no attempt to resolve any DNS names of destination IPs (n)

Картинка с сайта: adamtheautomator.com

If a web server is listening on port 80, for example, you’ll see a line where the local address ended in :80 under the Local Address column. This row is where you’ll see the PID or process ID the connection is using.

Once you know the PID, you can then reference the PID to find the process name using something like the Get-Process PowerShell cmdlet.

Картинка с сайта: adamtheautomator.com

Although in this case, you can see above that the process name is just System. This means that the process is highly integrated within the OS and is probably built into Windows.

Setting WinRM Compatibility Ports

WinRM has a feature called compatibility ports. Compatibility ports exist to be backward-compatible with some legacy systems that only work on ports 80 for HTTP and 443 for HTTPS. If you need to change WinRm to listen on these ports, enable the compatibility listeners.

Once you know that you do not have anything else running on ports 80 and 443 set the WSMan listeners to use the compatibility ports (80 for HTTP and 443 for HTTPS).

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener -Value $true
 Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value $true

Setting WinRM to Listen on Any Port

If, for some reason, you need to configure WinRM to listen on a non-standard port, you can do that too. To do so:

1. Find the listener name. You can do this by enumerating all of the WinRM listeners with the Get-Item cmdlet. The command below is listing all (*) of the listeners currently installed.

Get-Item WSMan:\localhost\Listener*

Картинка с сайта: adamtheautomator.com

2. Next, using the listener name shown above, configure each listener using Set-Item providing the path of the listener and the port number to change it to.

Set-Item WSMan:\localhost\Listener\\Port -Value 

3. At this point, the WinRM listeners are listening on the correct ports, the Windows Firewall is probably rejecting any remote connections to those ports. You need to open those ports. To do so, run the following command. The New-NetFirewallRule below is creating a Windows Firewall rule to allow all inbound TCP connections to a custom port.

$FirewallParam = @{
     DisplayName = 'Custom WinRM Port Rule'
     Direction = 'Inbound'
     LocalPort = 
     Protocol = 'TCP'
     Action = 'Allow'
     Program = 'System'
 }
 New-NetFirewallRule @FirewallParam

Related: Disable Windows Firewall: Discover the Many Ways

If you would have not opened the appropriate Windows Firewall port, you would get a message like this when trying to connect:

Картинка с сайта: adamtheautomator.com

Connecting to a Custom Port with PSRemoting

Now that you’ve set up and configured WinRM successfully on the WinRM server, you need to test connecting with the WinRM client. To do that requires just one additional parameter; Port.

Using any of the PSRemoting commands like Invoke-Command or Enter-PSSession, specify the Port parameter and the port set up to successfully make a connection.

Enter-PSSession -ComputerName <hostname> -Port 1111

Картинка с сайта: adamtheautomator.com

Related: Invoke-Command: The Best Way to Run Remote Code

Reading Time: 6 minutes

I’ve already shown you how to remotely manage your Server Core installations of Windows Server Core using the Remote Desktop Protocol, but using Windows Remote Management (WinRM, Microsoft implementation of WS-Management) in combination with WinRS might prove to be even more useful for day to day administration.

About WS-Management

WS-Management is a specification of a SOAP-based protocol for the management of servers, devices, applications and more. The specification is based on DMTF open standards and Internet standards for Web Services and was published in March, 2005 by a group of companies, including AMD, Dell, Intel, Microsoft, Sun Microsystems and others.

WS-Management provides a common way for systems to access and exchange management information across the IT infrastructure. The specification is quite rich, supporting much more than get/set of simple variables, and in that it is closer to WBEM or Netconf than to SNMP. A mapping of the DMTF-originated Common Information Model into WS-Management was also defined.

Remote Shell

One of the most common uses for Windows Remote Management is the Remote Shell, (WinRS) that can be used to execute a program on a remote host.

Other uses

Windows Remote Management is not a stranger to this blog. I wrote a blogpost 6 months ago on event forwarding and already looked into WinRM. You might find your Windows Remote Management is already enabled after following those directions.

This blog post will be focusing on using WinRM, combined with WinRS.

Windows Remote Management is the server part answering the Remote Shell. In Windows Server 2008 it is not enabled by default, which is good from a security point of view.

Determining whether WinRM is configured or not

Windows Remote Management is installed by default on Windows Server 2008 and the WinRM service is set to start (delayed) automatically. The only way to determine whether Windows Remote Management is installed is by examining the output of the following command:

WinRM enumerate winrm/config/listener

or (shorter, but with the same effect)

WinRM e winrm/config/listener

When this command has no output, it means no listeners are configured and Windows Remote Management is not configured.

Enabling Windows Remote Management

Using the command line

To enable Windows Remote Shell on a server running a Server Core installation, type the following command at the command prompt of the Server Core box:

WinRM quickconfig

or (shorter, but with the same effect)

WinRM qc

The command questions whether you really want to enable Windows Remote Management:

WinRM is not set up to allow remote access to this machine for management.
The following changes must be made: Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine
Make these changes [y/n]?

Press y to continue or n to cancel.

This command will perform a couple of actions. First of all it will check whether the Windows Remote Management service is started and set to start automatically. After that it creates listeners for all the network connections to accept Windows Remote Shell connections with default settings. It will also open up port 80 in the Windows Firewall.

If configuration is successful, the following output is displayed:

WinRM has been updated for remote management. WinRM service type changed to delayed auto start. WinRM service started. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.

Using Group Policies

When you place Server Core boxes in a separate Organizational Unit in your Active Directory environment you can manage Windows Remote Management centrally.

Look for the Windows Remote Management and Windows Remote Shell Group Policy Objects (GPOs) under Administrative Templates and Windows Components.
Do not forget to also open up TCP 80 on the firewall.

Default settings

The default settings of Windows Remote Management might not suit your needs. You can change on which network interfaces Windows Remote Management listens, change the URI’s and change whether WinRM will use HTTP (TCP 80) or HTTPS (TCP 443)

While WinRM listens on port 80 by default, it doesn’t mean traffic is unencrypted. Traffic by default is only accepted by WinRM when it is encrypted using the Negotiate or Kerberos SSP. Enabling HTTPS is not a security measure persé. It is needed when you want to use the Windows Remote Shell (WinRS) from a host that is not in the same domain as the Server Core box. (unless you use the trick below)

Windows Remote Shell is enabled by default within Windows Remote Management. For Windows Remote Shell the default settings are:

• Maximum of 5 concurrent users
• Maximum of 2 shells per user
• Maximum of 80MB memory usage per shell
• Maximum of 5 processes per shell

Disabling Windows Remote Management

To disable Windows Remote Management you need to remove the listener. The following command can be used:

WinRM delete winrm/config/listener?IPAdress=*+Transport=HTTP

WinRS

On another computer, at a command prompt, use WinRS.exe to run commands on a server running a Server Core installation. For example, type:

winrs -r:ServerName cmd.exe

Where ServerName is the name of the server running a Server Core installation with Windows Remote Management. This will result in a remote prompt where you can happily type away your commands.

Tips and tricks

Workaround for non-domain situations

When the Server Core box and the remote host are not members of the same domain you can’t connect to the Server Core box using WinRS, because of the built-in security measures. Run the following commands to lower security:

Note:
You seriously cripple the built-in security of Windows Server 2008 after running the following commands. Only apply these commands to test situations.

On the Windows server Core box

Run the following commands on the console of the Server Core box to lower security:

WinRM set winrm/config/service/auth @{Basic=»true»}
WinRM set winrm/config/client @{TrustedHosts=»<local>«}
WinRM set winrm/config/client @{TrustedHosts=»RemoteHost«}

Where RemoteHost is the host you want to be able to connect to the server.

On the remote host

Start the Command Prompt with elevated privileges. On machines with User Account Control enabled this is easily achieved by pressing the Start button, typing cmd and press CTRL and SHIFT together with Enter to run the command.  Run the following commands on the remote host to lower security:

WinRM set winrm/config/service/auth @{Basic=»true»}
WinRM set winrm/config/client @{TrustedHosts=»<local>«}
WinRM set winrm/config/client @{TrustedHosts=»ServerName«}

Where ServerName is the name of the server running a Server Core installation with Windows Remote Management.

To open the Remote Shell use the following command:

winrs -r:»ServerName«: –u:Domain\Username –p:Password cmd.exe

Where Domain\Username is the name of an account with administrative rights on the server running a Server Core installation with Windows Remote Management and Password is the password for the account.

Trick to get the hostname displayed

Using the Windows Remote Shell might get confusing pretty fast, since the prompt doesn’t show where you’re connected to or whether you’re connected at all. There are some giveaways though:

• When you type exit your command window doesn’t close
• The WinRS command is displayed in the title of your command prompt window

This can become very painful when you decide to shutdown a server and turn off the wrong server accidentally…

Arlindo Alves, the Belgian IT Pro Evangelist, has a good trick to display some extra information on the command prompt, which also works when using the Windows Remote Shell. I suggest you read his blog post on it. It entails adding an Extended String value named prompt to the following registry key:

HKLM\System\CurrentControlSet\Control\Session Manager\Environment

He fills his prompt with all kinds of stuff (which doesn’t seem to get passed through completely using WinRS) but I simply add the following data to the value:

[IdentificationString]$s$p$g

Where IdentificationString is an identification string that accurately describes what the server is all about. (which in my case differs from the hostname)

Concluding

Windows Remote Management and the Windows Remote Shell are really good tools and can make your life as a systems administrators much easier. In the light of Server Core this combination of tools will not generate as much traffic as RDP’ing into a Windows Server 2008 box and can be scheduled. This might make it the ideal solution for day to day system management.

Unfortunately security is a real pain in the behind if both machines aren’t in the same Active Directory domain. You’ll need to type away some commands to make it work.

Arlindo Alves’ tip to show the hostname of the server on both the console of the Server Core box and the remote shell might prove to be a real lifesaver.

Further reading

Installation and Configuration for Windows Remote Management
Windows Remote Management (WinRM) for Powershell and CMD on Windows 2008
Windows Server 2008 – Server Core – Change Default Prompt
Will the real Core please stand up?
WinRS: Microsoft’s Disappointing Answer to SSH for Remote Administration
WS-Management: Windows Vista and Windows Server 2008
RedmondMag October 2007 – First Look: WinRM & WinRS
Configuring Windows Server 2008 Server Core Basic Networking Settings
Connecting to WinRM with Windows Vista
How can I remotely run commands on a Windows Vista or Windows Server 2008 box?