Привет!? Устранение неполадок с отключением служб удаленных рабочих столов

Я написал книги об операционных системах Windows Server еще со времен темных веков Windows NT. Я также использовал эти операционные системы в бизнес-среде и помогал другим ИТ-специалистам научиться правильно их администрировать и устранять неполадки, когда что-то идет не так. Одной из функций Windows Server, с которой мне приходилось часто работать, являются службы удаленных рабочих столов (RDS), которые имеют богатую историю. Как я упомянул в одной из своих книг, еще в эпоху мэйнфреймов, когда были компьютеры, балом правили тупые терминалы. Пользователи вводили свои данные в терминал с «зеленым экраном», и они отправлялись по проводам на мейнфрейм. После того, как команды пользователя были обработаны, результаты затем передавались по проводам обратно на терминал, где они отображались ярко-зеленым цветом на черном фоне. Эту клиент-серверную архитектуру тупых терминалов и терминальных серверов все еще можно увидеть в действии, когда вы смотрите классические фильмы, такие как «Мозг на миллиард долларов» с Майклом Кейном.

Конечно, с тех пор терминальные серверы прошли долгий путь. Microsoft впервые представила свою собственную версию этой архитектуры еще в 1996 году с выпуском Windows NT 4.0 Terminal Server, и она предоставила пользователям сеансовые рабочие столы, к которым они могли получить удаленный доступ, как если бы они вошли в систему в интерактивном режиме. Затем, когда были выпущены последующие версии Windows Server, службы терминалов были усовершенствованы во многих отношениях и переименованы в службы удаленных рабочих столов. Сегодня RDS является основным продуктом для организаций, которые хотят развернуть широкий спектр решений для удаленной работы, включая виртуальные рабочие столы, программы RemoteApp и рабочие столы на основе сеансов. На самом деле RDS может даже позволить пользователям безопасно запускать бизнес-приложения через Интернет, как если бы они сидели за компьютером в локальной сети компании. Однако, естественно, особенно с таким гигантом, как Microsoft, ничто не стоит на месте и не остается неизменным в мире ИТ. Таким образом, при активном стремлении Microsoft к облаку под руководством Сатьи Наделлы вполне логично, что сама RDS должна продолжать развиваться с новыми сценариями, такими как развертывание фермы RDS в Microsoft Azure и аналогичными захватывающими вариантами. Однако на многих крупных предприятиях по-прежнему развернуты собственные RDS-фермы для доставки приложений и рабочих столов, и, как и многие расширяющие возможности технологии, эта часто может оставить измученного системного администратора чувством беспомощности, когда что-то пойдет не так. В этой статье предлагается несколько советов о том, как можно попытаться устранить один конкретный тип неприятных проблем, которые время от времени возникают в средах RDS, а именно связанных с отключением служб удаленных рабочих столов (преднамеренным или нет) пользовательских сеансов. Три истории, которыми я поделился ниже, основаны либо на моем собственном профессиональном опыте, либо на моих коллегах по ИТ-специальности. Как обычно, я немного приукрасил истории, чтобы сделать их более интересными и поучительными, с типичным ИТ-специалистом Бобом в роли злодея.

Службы удаленных рабочих столов отключаются: до свидания и скатертью дорога!

Консультант по RDS по имени Боб рассказал мне о клиенте, который сказал, что клиент, с которым он работал, столкнулся с проблемой, связанной с неожиданной загрузкой пользовательских сеансов на их устройстве RDS. Когда пользователь пытался восстановить сеанс, окно RDS запрашивало его учетные данные. Когда пользователь ввел учетные данные и нажал «Подключить», диалоговое окно подключения закрылось без установления соединения. Какого черта?

Боб начал с записи некоторых журналов с помощью средства диагностики служб удаленных рабочих столов, чтобы попытаться диагностировать, что может быть основной причиной отключения служб удаленных рабочих столов его клиента. Анализ журналов трассировки, захваченных этим инструментом, показал, что попытка входа в систему оказалась успешной, несмотря на то, что пользователь был немедленно удален с сервера RDS. Дальнейшее расследование выявило следующую серию записей в файле журнала:

[1] … [rdrpnpLib] rdrpnp_cpp655 CRdrPnpManager::OnRemoteDisconnect() – CRdrPnpManager::OnRemoteDisconnect: 2

[0] … [rdrpnpLib] rdrpnp_cpp567 CRdrPnpManager::OnRemoteConnect() – CRdrPnpManager::OnRemoteConnect: 2

[0] … [rdrpnpLib] rdrpnp_cpp580 CRdrPnpManager::OnRemoteConnect() — «GetSession FAILED». ЧСС = 0x8007053d (ОШИБКА_СЕРВЕРА_ОТКЛЮЧЕНА)

Эти строки, по-видимому, указывают на то, что после успешного входа в систему сеанс завершается, поскольку на сервере произошел сбой перенаправления Plug and Play (PnP). Однако на самом деле это означает, что перенаправление диска не удалось при попытке подключения. Перенаправление диска позволяет указать, какие локальные устройства и ресурсы должны быть доступны для удаленных сеансов, которые пользователи устанавливают с сервером RDS. Перенаправлением дисков можно управлять на стороне сервера с помощью групповой политики, используя параметр политики Конфигурация компьютераПолитикиАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПеренаправление устройств и ресурсов. Перенаправление диска также можно включить или отключить на стороне клиента на вкладке «Локальные ресурсы» утилиты «Подключение к удаленному рабочему столу» (mstsc.exe).

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

Хорошо, вы можете немного подождать

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

К сожалению, параметр групповой политики «Установить ограничение времени для активных сеансов служб терминалов», расположенный в разделе «Конфигурация пользователяПолитикиАдминистративные шаблоныКомпоненты WindowsСлужбы терминаловСервер терминаловОграничения времени сеанса» в дереве политик, может быть установлен только на максимальное значение пять дней для версии Windows Server, используемой заказчиком. Не беспокойтесь, у Боба была идея: что, если он вытолкнет ключ реестра с большим значением для этого параметра с помощью предпочтений групповой политики (GPP)? Небольшой поиск в TechNet и MSDN показал, что значением реестра, соответствующим этому параметру политики, было значение DWORD с именем MaxDisconnectionTime, которое находилось в ключе HKCUSOFTWAREPoliciesMicrosoftWindows NTTerminal Services в реестре. Боб рассудил, что, возможно, ограничение до пяти дней было артефактом того, как параметр политики был представлен в редакторе групповой политики, поэтому он создал предпочтение, которое присвоило значение 1814400000 (21 день в миллисекундах) значению реестра MaxDisconnectionTime, и передал его. выход на целевых клиентов.

Ну, что вы знаете, это сработало! Клиент был счастлив, и Боб тоже. Единственным недостатком этой истории является то, что Боб, вероятно, сделал что-то, что служба поддержки Microsoft может счесть «неподдерживаемой», если клиент когда-либо вызовет их для обращения в службу поддержки. Но ключевой вывод из этой истории заключается в том, что групповая политика может быть изменена неожиданным образом, если вы достаточно постараетесь. Просто будь осторожен.

Скажи мне что-нибудь шестнадцатеричным

Последняя история Боба была подсказкой, которую он узнал от инженера службы поддержки Microsoft. Когда службы удаленных рабочих столов по какой-либо причине отключаются, они создают код ошибки, который можно найти в захваченных журналах. К сожалению, код является числовым, что не очень помогает, когда вы пытаетесь устранить проблему. Это похоже на то, как вселенная генерирует код ошибки «42», когда что-то идет не так (конечно, это взлет Дугласа Адамса).

В любом случае, было бы неплохо, если бы вы могли быстро преобразовать код ошибки в понятное имя при устранении неполадок, связанных с отключением служб удаленных рабочих столов. Что ж, видимо есть способ с помощью PowerShell, хотя сам я его не пробовал. Вот сценарий, который он получил от парня из Microsoft:

Парам(
[parameter(Position=0,Mandatory=$true,HelpMessage=”Введите десятичный код причины отключения от трассировки rds на стороне клиента”)]
[строка] $disconnectReason
)
#если это выглядит как шестнадцатеричный, попробуйте преобразовать в dec
if([regex]::IsMatch($disconnectReason, "[a-fA-FxX]"))
{
$disconnectReason = [Преобразовать]::ToInt32($disconnectReason, 16)
}
Write-Host «проверка кода ошибки: $disconnectReason»
$mstsc = новый объект -ComObject MSTscAx.MsTscAx
write-host «описание: $($mstsc.GetErrorDescription($disconnectReason,0))»

Надеюсь, это может быть полезно для некоторых из наших читателей!