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 всегда присутствует)
Comments
- Anonymous
January 01, 2003
2Funtik. Внутри компании существует не одна система учета заявок. В данный момент та, которую использует Microsoft Premier Support - Clarify. Оное используется очень с давних времен, при этом конечно регулярно обновляется и дорабатывается. http://www.microsoft.com/presspass/press/1996/mar96/clarfypr.mspx Что мне нравится в организации работ так это две вещи
- Практически все можно сделать через E-mail
- Есть отдельная очень мощная поискова система по разнородным инцидентам. Это позволяет существенно повысить эффективность своей работы. Как видишь от самой системы получается что это "почти" не зависит - каналы работы с ней e-mail и web форма поиска, такие каналы можно прикрутить к любой системе, главное грамотно спланировать процесс. 2Den. Понимашь, далеко не всегда по "останкам" сервера можно догадаться как он до такой жизни дошел. Учитвая то, что обычно объяснения "все работало, а тут вдруг сломалось". В данном конкретном случае никто уже и не помнит когда и откуда этот сервер взялся - так что это суровое наследие прошлого, а чтобы такого не возникало надо документировать изменения... Если уж не ITIL процесс внедрить, то хотя бы просто записывать на листочке кто откуда сервера приносит. :)
Anonymous
November 24, 2008
а service desk у вас чей, если не секрет?Anonymous
November 25, 2008
И все же, откуда проблема выскочила (из-за чего)? Ведь нормально работал или как? Что могло попортить библиотеки? Т.е. есть жедание узнать причину, чтобы заранее ее исключить))Anonymous
March 24, 2009
похожая проблема. но рецепт не помог. вот тут подробнее о проблеме: http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/8216383f-dcd8-40ed-8344-876b3eee0668/