Всё о о Microsoft Exchange Server и электронной почте.

Капризы MsExchangeSA в Exchange 2007

В один прекрасный день на почтовом сервере Exchange 2007 небольшой компании перестала запускаться служба MsExchangeSA. Мониторинг за сервером не был установлен, поэтому проблему обнаружили только на третий день, когда не смогли создать список рассылки. Меня пригласили помочь с ней разобраться.

В Application log было всего лишь две ошибки:

Event ID 2060 MSExchangeSA
The DsProxy failed to start, error ‘%1’.

Event ID 1005 MSExchangeSA
Unexpected error An unknown error has occurred. ID no: fffffffd
Microsoft Exchange System Attendant occurred.

Поиск решения привел к статье XADM: System Attendant Does Not Start with Event ID 2060. Смысл состоит в перезагрузке DC после установки галочки GC. Перегружай, не перегружай, а в моем случае это не помогло, да и статья была написана для Win2000.

Следующая статья была Не удалось запустить службу DsProxy, в которой сказано:

Это событие означает, что, возможно, данному серверу Microsoft Exchange не удается связаться с контроллером домена. Возможно также, что время на данном сервере Exchange не синхронизовано с временем на контроллере домена.

В качетве решения предлагалось проверить соединение сервера с DC, выполнить синхронизацию времени и запустить MsExchangeSA заново.

Соединение с DC конечно же было,но как может время не синхронизироваться в домене? Я даже мысли такой не допускал. Потом все же решил проверить время на сервере, DC и … время было разным. Мало того, что оно было разным, оно отличалось от времени на моей машине примерно на 5 сек. Не думаю, что это супер критично, но проблемы с синхронизацией времени в домене существуют и нужно их решать. Написал админу, чтобы поправил синхронизацию времени. Дело в том, что он получил сеть в наследство и еще не успел все проверить.

Дальше хуже. Запускаю dcdiag /v на DC и получаю:

Starting test: FsmoCheck
GC Name: \\server.mydomain.local Locator Flags: 0xe00001bc
PDC Name: \\server.mydomain.local Locator Flags: 0xe00001bd
Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
A Time Server could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call
failed,error 1355
A Good Time Server could not be located.
KDC Name: \\server.mydomain.local Locator Flags: 0xe00001bс server.mydomain.localfailed test FsmoCheck

Здрасьте, все вроде работает, а The server holding the PDC role is down.
Пока админ чинил синхронизацию времени в домене по этим статьям:

How Windows Time Service Works
Configuring Windows Time Service
Configure the Windows Time Service
How to configure the PDC FSMO in the forest root domain to sync time?

Я продолжал «рыть» форумы в Интернете. Админ сказал, что наладил синхронизацию, dcdiag перестал выдавать ошибки и думаете все заработало? Нет! 🙂

Силы начали меня покидать и я стал задумываться о обращении в Microsoft PSS, как вдруг наткнулся на еще одну статью The System Attendant Service May Fail to Start on Exchange Server 2007 With NWLink Protocol Installed.
«Ну и при чем тут NWLink?» спросите Вы. В моем случае он на Exchange сервере не использовался, но я знал, что в компании использовались Маки. Я посмотрел в сетевые настройки и увидел там протокол — AppleTalk! (Админ потом признался, что пытался его настроить, но вроде бы удалял 🙂)

Что было дальше рассказывать не нужно. MSExchangeSA запустился и жизнь опять стала радужной.

Мораль сей басни такова:

  1. Обязательно использовать систему мониторинга чтобы узнавать о проблемах заранее и быть в курсе, что происходит с вашим сервисом, в моем случае — Exchange.
  2. dcdiag и netdiag должны проходить без ошибок
  3. Админы должны вести лог изменений о настройках на сервере (А нет ли систем, которые следят за этим автоматически?)

p.s.
— Самый страшный звук в серверной — тишина…
— Хрена с два. Самый страшный звук в серверной — весёлый детский смех!

 

 

Похожие посты:

  • Xaegr

    > Админы должны вести лог изменений о настройках на сервере (А нет ли систем, которые следят за этим автоматически?)

    У нас в компании любые изменения на серверах заносятся в спецжурнал на sharepoint. К сожалению всё автоматически не получится, но помоему вполне реально сделать MP для SCOM который будет сигналить если появился новый сервис/изменились настройки ip/в dcdiag появились ошибки и т.п…

  • Pavel Nagaev

    У нас кстати тоже самое. Мы с коллегой ведем свой сайтик на SharePoint, где кроме всего прочего есть библиотека Проблемы. И все что делаем — туда пишем, можно отследить изменения и то, какие проблемы мы решаем в данный момент.

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

  • Nimdan

    Я бы еще один пунк в мораль добавил — вот сколько всего можно наладить в сети, когда у вас перестал работать Exchange :).

  • orangeudav

    Ну и почему же все таки Exchange не может работать с включенным Apple Talk? Причины ведь так и не были озвучены? Очередно глюк из миллионов других непонятных глюков (( Мораль сей басни — мы не имеем никаких гарантий работоспособности чего бы то ни было.

  • http://www.exchangerus.ru Pavel Nagaev

    Так и статья для другого протокола написана.  У той статье объяснение дается очень простое:

    Cause

    This problem occurs because the NWLink protocol is enabled on your network interface card (NIC), which is an unsupported scenario.
    Это не глюк, я уверен, что у Микрософта есть техническое объяснение этому, но они не сочли нужным это писать в статье и объявили это неподдерживаемой конфигурацией.  Конечно так проще, но смысл писать детальное объяснение. Важно знать, что делать.
  • Joker

    В серьезных компаниях есть такая вещь, как Change Management policy. Сводит админов с ума, но иногда полезно. Суть в том, что если вы собрались даже просто пукнуть на сервер, надо оформить заявку, подробно описать, что именно планируется сделать (например, перезапустить сервис), почему это необходимо делать, какие последствия это вызовет или может вызвать, и привести оценку рисков, финансовую оценку возможных последствий, перечислить тех, кто будет за это отвечать, ну и еще с десяток пунктов. Страниц на 5-6 работы. Потом Вашу заявку рассмотрит специальный Change Management комитет (который собирается на заседания раз в неделю в лучшем случае), и может еще и отказать, если пиво в тот день оказалось неудачным.
    Вот такие дела. Отшибает охоту по любому поводу перестартовать сервисы и привычку жать кнопку ОК, не подумав как следует, ну просто напрочь. Но и жить после этого не хочется. Я в свое время решил, что с такими правилами это мой последний опыт в IT, больше админом быть не хочу 🙂

  • http://www.exchangerus.ru Pavel Nagaev

    Да я знаю про такое. Это действительно палка о двух концах.

  • http://komatozo.blogspot.com Alexander Trofimov

    Ну на самом деле все далеко не так страшно: есть куча изменений, которые считаются "auto approved". И их на самом деле очень большая часть, на сколько я себе могу представить =)