Как восстановить сервер Exchange в удаленном режиме.

Не так давно я отправился в поездку, не прихватив свой переносной компьютер. Проверяя с первой подходящей машины свой почтовый ящик, я обнаружил, что не могу его открыть. Как и многие другие администраторы Microsoft Exchange 2000, серверы Exchange я настроил на обслуживание клиентов не только своей организации, но и партнеров. И если я не смог получить свою почту, следовательно, ни наши партнеры, ни подрядчики — никто не получил почту, поскольку все они обслуживаются нашими почтовыми серверами. Расстояние до офиса составляло примерно 500 миль. Что делать?

Проверка параметров

При возникновении любой проблемы с сервером всегда есть несколько вариантов поведения. Во-первых, проблему можно попробовать проигнорировать, заняться другими делами и уже после возвращения домой поработать с сервером. Но поскольку наши партнеры рассчитывают на бесперебойную работу почтовой службы, такая возможность меня не устроила — и, скорее всего, это не выход для большинства администраторов Exchange. Во-вторых, можно все бросить и помчаться решать проблему. Если бы в это время я был дома, еще куда ни шло. Но в данном случае у меня не было большого желания упаковывать чемоданы, возвращаться домой и прерывать свой отпуск. Третьей и последней возможностью оставалось обратиться к серверу через Internet и решить возникшую проблему в удаленном режиме.

К счастью, перед тем как отправиться в отпуск, я достал несколько полезных программ для решения проблем в режиме удаленного доступа. Естественно, большинство этих программ свободно распространяются и могут быть полезны только в том случае, если администратор заранее установил и настроил их.

Наиболее важный инструмент для удаленного доступа и поиска неисправностей в системе позволяет работать в режиме удаленной консоли сервера. (Дополнительную информацию об утилитах для удаленного доступа можно найти в ст. Дона Джонса «Средства дистанционного администрирования», опубликованной в № 5 нашего журнала за прошлый год.)

Если используется почтовый сервер Exchange, установленный на Windows 2000, можно задействовать встроенную терминальную службу Windows 2000 Server Terminal Services. Служба терминалов устанавливается в одном из двух режимов: Remote Administration Mode или Application Server Mode. Режим Remote Administration Mode позволяет открыть две отдельные терминальные сессии для каждого обслуживаемого сервера без дополнительного лицензирования, а Application Server Mode требует использования дополнительных лицензий. Чтобы подключить Terminal Services, нужно сделать следующее:

  • открыть Control Panel Add/Remove Programs;
  • щелкнуть Add/Remove Windows Components;
  • отыскать в списке службы Terminal Services, установить флажок Terminal Services и щелкнуть Details;
  • убедиться, что в окне Terminal Services установлен флажок Enable Terminal Services. Щелкнуть ОК и затем Next;
  • программа установки спросит, в каком режиме нужно настроить Terminal Services - в Remote Administration Mode или Application Server Mode. Следует выбрать Remote administration mode и щелкнуть Next.

Конечно, необходимо убедиться, что с учетной записью, в контексте которой будут выполняться задачи удаленного администрирования, можно локально зарегистрироваться на всех обслуживаемых серверах. Следовательно, придется воспользоваться оснасткой Active Directory Users and Computers консоли Microsoft Management Console (MMC) для настройки соответствующих пользовательских разрешений.

Если почтовый сервер Exchange запущен на Windows NT 4.0, следует либо переустановить операционную систему и другое программное обеспечение и поставить NT Server 4.0, Terminal Server Edition (что само по себе «удовольствие» дорогое во всех отношениях — и по деньгам, и по трудозатратам), либо установить какое-либо программное обеспечение удаленного администрирования, например от Symantec (pcAnywhere), Altiris (Carbon Copy), AT&T Laboratories Cambridge (Virtual Network Computing, VNC). Мне нравится VNC, это бесплатный продукт, его можно найти по адресу: http://www.uk.research.att.com/vnc. Дополнительный плюс — VNC Viewer целиком умещается на дискете, его можно возить с собой и использовать на любой машине. Естественно, он не имеет ни таких возможностей, как продукты конкурентов, ни официальной поддержки. Все перечисленные выше программы работают под управлением Windows 2000. Не имеет значения, на какой платформе будет запускаться программа удаленного доступа, нужно только внимательно следить за соблюдением рекомендаций по безопасности при установке утилиты — наверное, никто не хочет, чтобы любой желающий смог по Internet работать с почтовым сервером через удаленную консоль.

Проверьте, работает ли сервер

Чтобы, находясь далеко от своего сервера, убедиться, что с ним все в порядке, для начала предстоит определить, включен ли он вообще. Если сервер включен, можно приступать к выяснению специфики проблемы (что именно не работает — не поступает входящая корреспонденция, не работает Microsoft Outlook Web Access, OWA). В моем случае утилита ping отработала успешно, IP-адрес сервера оказался действительным, поэтому я был уверен, что сервер включен и находится в сети. Но при этом стало очевидно, что POP3, IMAP4 и OWA не работают. Сервер отвечал на подключения по POP3 и IMAP4, но регистрацию по этим протоколам отвергал. Соединение Messaging API (MAPI) установить не удавалось, фиксировалась ошибка, попытка загрузить OWA-страницу любого пользователя приводила к появлению обычного диалогового окна аутентификации, а затем система выдавала сообщение об ошибке 503.

В зависимости от настроек брандмауэра, не всегда есть возможность использовать ping для проверки брандмауэра или почтового сервера внутри демилитаризованной зоны DMZ. Поэтому, прежде чем задействовать ping для поиска своего сервера извне, необходимо понять, а чего, собственно, следует ожидать. Любой тест, с помощью которого выясняется, включен сервер или нет, должен поддерживать выполнение следующих задач: запуск виртуального терминала (telnet) и подключение к хорошо известному порту или к заведомо активной системе; применение утилит Windows, например Server Manager или Computer Management в MMC, чтобы попытаться подключиться к проблемному серверу.

Если же сервер не функционирует, скажем, потому, что отсутствует электропитание или произошла остановка системы, и на мониторе возник «голубой экран смерти», тут уж ничего не поделаешь. Хотя если на сервере установлена одна из специальных плат удаленного обслуживания, значит, еще не все потеряно. Hewlett-Packard (HP), Compaq, Dell и большинство ведущих производителей оборудования выпускают подобные платы. В этом случае с помощью, например, виртуального терминала можно проверить состояние оборудования. Некоторые подобные карты даже позволяют увидеть текущую картинку на экране сервера, отличное дополнение для анализа ситуации на расстоянии. Платы удаленного обслуживания дают возможность запустить остановленную машину (за счет соединения с платой, а не с хостом). Трудно переоценить функцию, позволяющую «оживить» систему, до которой в данный момент просто невозможно добраться.

Обнаружение неисправности

Если компьютер работает и к нему можно обратиться, следующий шаг — задействовать приложение удаленной консоли. Я запустил Terminal Services Client, который заранее установил на подходящую для этих целей станцию. Если нельзя работать с выделенным клиентом Terminal Services — предположим, у заказчика нет такой возможности, — следует воспользоваться специальным элементом управления ActiveX, который может быть установлен на сервере. Его можно задействовать для установления сессии Terminal Services с любой машины Windows, на которой имеется Internet Explorer (IE). Упомянутый модуль ActiveX находится по адресу: http://www.microsoft.com/windows2000/ downloads/recommended/tsac/default.asp.

После установления консольной сессии в распоряжении администратора оказывается весь набор привычных инструментов, необходимых для выявления неисправности, как если бы он сидел за консолью сервера. Обычно я начинаю с просмотра Event Viewer и проверяю предупреждения и информационные события — они могут помочь отыскать причину неполадок. Exchange регистрирует большинство таких событий, включая всевозможные ошибки и сбои, в журнале Application. Для просмотра всех предупреждений стоит использовать фильтр (View, Filter). Фильтрация сообщений ускорит процесс поиска неисправности. После небольшой практики по одному взгляду на Event ID можно идентифицировать проблему. Рекомендую взять себе за правило обращаться за помощью в Microsoft Knowledge Base, если вдруг ID сообщения оказалось неизвестным. Многие события в документации Exchange освещены очень скупо, в отличие от Knowledge Base.

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

  • Команды Net Start и Net Stop позволяют запускать и останавливать любые службы. Поскольку Windows 2000 и NT учитывают взаимозависимость служб, можно просто остановить System Attendant (MSExchangeSA), прекратив работу сразу всех служб Exchange. Чтобы запустить Net Stop без необходимости отвечать на соответствующие запросы, следует набрать:

net stop msexchangesa /y

  • Команда Nltest из состава Microsoft Windows 2000 Server Resource Kit (ее описание можно прочитать в ст. Даррен Мар-Элиа «10 программ дистанционного управления из Resource Kit» в № 4 нашего журнала за 2001 г. — прим. ред.) имеет функцию выключения сервера (shutdown) «вручную» с командной строки удаленного компьютера, что бывает полезно при непонятных сбоях в работе сервера. Иногда сервер, который не удается штатно остановить с консоли, «поддается» остановке с помощью Nltest. Для принудительной остановки сервера следует использовать два переключателя:

nltest /server: /shutdown:
<»server hung»>

Переключатель /server сообщает команде, о каком сервере идет речь, /shutdown — событие, которое появится в журнале Event Log (server hung).

Мой почтовый сервер не зафиксировал в журнале ничего достойного внимания, поэтому сразу определить причину неисправности не удалось. Тот факт, что POP- и IMAP-пользователи не могли зарегистрироваться, послужил ключом к пониманию проблемы. Службы работали, но, поскольку Exchange 2000 использует библиотеки DLL, подгружаемые сервером IIS для обработки трафика POP3 и IMAP4, я не мог поручиться за нормальную работу хранилища Store. Возникло подозрение, что сервер ведет себя некорректно из-за проблемы с доступом к серверу глобального каталога Global Catalog (GC), так как запросы POP и IMAP моментально завершались с ошибкой. У нас имеется только один домен, так что сервер GC и контроллер домена DC — это одна и та же станция. Утилита Dsadiag из Windows 2000 Support Tools помогла частично решить проблему: сервер Exchange нуждался в обмене информацией с GC, который оказался неисправным, и его пришлось остановить в ожидании нового адаптера Fibre Channel. Самый быстрый способ исправить положение обычно состоит в перезапуске Store и поиске нового сервера GC. Во время рабочего дня предпринимать такие действия не следует, но в моем случае это было как раз удобное время суток. Однако, когда я попытался остановить и снова запустить Store, служба «зависла» — как всегда, некстати.

Поскольку остановить службу Store не удалось, не оставалось ничего иного, кроме как кардинально разрешить ситуацию — перезагрузить сервер целиком. Я нажал Ctrl+Alt+End для переключения в окно Windows Security из клиентской программы и выбрал Restart. Безрезультатно. Тогда с помощью Terminal Services я подключился к другому серверу, открыл окно командной строки и набрал:

nltest /server:cyclone /shutdown:wedged

Эта команда отработала как полагается, и, когда сервер снова загрузился, все было в порядке. Пользователи OWA, IMAP, POP и MAPI вновь могли работать со своими почтовыми ящиками, и Exchange установил соединение с нужным GC.

Буду ли я опять придерживаться изложенной методики, если потребуется? Вероятно. В данном случае параметры готовности сервера оказались существенно занижены, и непосредственно перед самым отпуском я позаботился о создании заведомо исправной резервной копии почтового сервера. Я полагал, что риск возможных потерь данных сведен к минимуму, и вероятность успешного восстановления высока. Конечно, может потребоваться более тщательно спланированный порядок действий при выявлении неисправностей, особенно если кто-то из коллег сможет подойти непосредственно к серверу и попробует помочь в решении проблемы, в частности, если для этого понадобится останавливать Store, запускать Eseutil или Isinteg. Вот какие рекомендации я мог бы дать на основании своего опыта.

  • Устанавливайте поддержку консоли удаленного доступа на каждый сервер, для которого может потребоваться удаленное вмешательство; установите соответствующий клиент (или подготовьте все для его развертывания) на станции поддержки, к которым всегда можно будет обратиться в удаленном режиме.
  • Убедитесь, что на критичных серверах установлены программы поддержки из Windows 2000 и Exchange 2000 Support Tools (расположены в соответствующем каталоге на компакт-диске). Также неплохо установить на эти серверы Windows 2000 Server Resource Kit и Exchange 2000 Resource Kit.
  • Eсли в работе системы возникают нарушения, исследуйте возможность использования программ оповещения. В состав Exchange 2000 и Exchange Server 5.5 входят программы мониторинга, которые с помощью почтовых отправлений извещают администратора о возникающих проблемах. Вероятно, есть смысл рассмотреть комбинацию встроенных возможностей и использования программ независимых разработчиков с функцией рассылки на пейджер (когда почтовый сервер не работает, встроенные службы рассылки почтовых уведомлений о неисправности не помогут).
  • Если кто-то из доверенных лиц будет рядом с сервером в отсутствие администратора, следует заранее обеспечить его необходимыми инструкциями по восстановлению работоспособности сервера Exchange.

ПОЛЬ РОБИШО — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: getting-started@robichaux.net.