SRQ: Сбой подключения на терминальный сервер Windows 2003: восстановление настроек по-умолчанию.
SRQ – это три буквы с которых начинаются практически все наши кейсы в системе Service Desk. Этот пост первый в серии решения конкретных проблем. В такие посты я буду отбирать проблемы, которые с виду выглядят очень просто, но решаются не так тривиально как это кажется в самом начале. Итак, дело о терминальном сервере, который отказался принимать подключения.
В эту субботу мне позвонил знакомый и поведал историю, что в их офисе Windows Server 2003 SP2 не обрабатывает подключения по RDP, хотя к другим серверам и даже к рабочим станцяим подключние работает нормально. Кратко обговорив детали, выяснили, что сервер не в домене, RDP использует режим удаленного администрирования, а ошибка выглядит так: черный экран вместе приглашения ввести пароль, а по истечение нескольких секунд ошибка “сервер закрыл подключение, проверьте конфигурацию сети”.
Частенько такие ошибки связаны c двуями вещами: лицензирование терминалов, сетевые проблемы на маршрутизаторах или брандмаурэрах. Но в этой конкретной ситуации все находится в локальной сети без каких-либо фаерволов, а сервер работает в режиме удаленного администрирования, т.е. никаких лицензионных проблем быть не должно. Проблема стала выглядеть достаточно интересной для того, чтобы посетить место лично.
Придя на место, первым делом я проверил что сервер настроен правильно, затем отключил все антивирусы и прочее антишпионское ПО. Попробовали подключиться c удаленной машины – черный экран и затем якобы сетевая проблема. Пробуем подключиться локально – такая же ситуация. Ок.
Проверяем, что сервер действительно работает на порту 3389, делаем это с помощью команды
netstat –n -a
Действительно, сервер работает и принимает подключиения, что нам подтвердил сетевой трейс. Весёлая статья про черный экран Windows 2003 к нам не подходит, т.к. во-первых, мы не можем завершить вход на станцию; во вторых, локально это не проявляется, а реестр в указаных в статье ветках выглядит нормальным.
Всегда, всегда, всегда устанваливайте Support Tools и Resource Kit на любой из своих серверов.
Идем дальше – нам нужны утилиты для дигностики терминального сервера. А именно tsctst.exe и tstst.exe. Как это обычно бывает, на сервере не был установлен ни пакет Support Tools, ни пакет Resource Kit. Скачиваем необходимые утилиты с сайта Microsoft, плюс, помним, что tstst.exe легче всего всзять из пакета MPS Report - Directory Services, установив который, мы обнаружим нужную нам утилиту в каталоге %windir%\mps report.
Хорошо когда есть спокойное время и интернет для того, чтобы выкачать данные утилиты и установить их на нужном сервере. А что делать если, как это не редко бывает, сервер стоит далеко, канал до него плохой, а проблему надо решить прямо сейчас. Задержки для пересылки утилит крайне портят нервы, да и серьезно замедляют процесс диагностики и решения проблем.
Проверка показала, что сервер когда-то работал в домене, плюс имеет достаточно нестандартные настройки RDP подключения. Утилита tstst.exe показала, что часть драйверов RDP сервера зарегистрированы с ошибками. Что-же план решения получился такой:
через средства администрирования(TSCC.msc) удаляем RDP подключение и создаем его занаво с настройками по-умолчанию.
используя утилиту DevCon, перерегистрируем необходимые компоненты терминального сервера
devcon -r install %windir%\inf\machine.inf root\rdpdr
перегружаем сервер
Вот таким нехитрым образом мы сбросили все основные настройки RDP в состояние по-умолчанию, а так же перерегистрировали все необходимые драйверы и библиотеки. После перезагрузки сервер радостно стал принимать подключения как с удаленных машин, так и с самого себя.
P.S. AdminPack для Windows 2008 теперь называется Windows Server 2008 Remote Administration tools и ставится только и только на Vista. (В комплекте любого сервера Windows 2008 всегда присутствует)