Архив рубрики: Exchange 2010

Ошибка STOP 0x0000009E на узле кластера Exchange

Exchange 2010, ,

Жил-был обычный кластер Exchange 2010 и, после некоторого роста количества баз в Database Availability Group, один из двух DB-серверов внезапно начал падать с синим экраном и ошибкой 0x0000009E по ночам аккурат во время бэкапа. Но не всегда. Конечно же, он сразу перезагружался и к утру был в строю, но бэкап-то прерывался…

Поиск возможных причин падения показал, что все не так просто. За время существования ОС Windows обязательных и необязательных апдейтов, которые фиксят эту ошибку вышло достаточно, но дальнейшее изучение показало, что все эти апдейты уже установлены. А сервер продолжает падать с завидной регулярностью.

Проверили версии драйверов, статус рэйда, наличие каких-нибудь системных ошибок — все чисто. Сервера по железу одинаковые, но один падает, а другой продолжает работать. Выбрали в качестве «активного» сервера для баз второй — и падать начал он, а второй тем временем прекрасно работал!

Начали тщательно изучать все графики заббикса и увидели, что в момент начала бэкапа среднее время ответа дисковой подсистемы резко вырастает до 6000 мс (я не ошибся с нулями), затем данные от заббикс-агента отсутствуют, а затем, спустя минут 20-30 происходит ребут. В общем, было видно, что после роста количества (но не размера) баз дисковая подсистема перестала справляться с нагрузкой. Но причем тут синий экран?

Ответ кроется в логике работы Cluster Service: если на определенном этапе сервис перестает отвечать на время, превышающее 60 секунд (по умолчанию), то система выпадает в синий экран и перезагружается, предполагая, что с кластером что-то не то и эта нода не живая. За таймаут и действие по умолчанию отвечают два параметра: ClusSvcHangTimeout и HangRecoveryAction. Просмотреть текущие значения этих параметров можно при помощи команды:

cluster /cluster:clustername /prop

Установить таймаут можно командой:

cluster /cluster:clustername /prop ClusSvcHangTimeout=x

где x — время в секундах.

Но мы решили временно, до апгрейда серверов, установить другое действие по умолчанию, а именно «Запись в лог». Делается это так:

cluster /cluster:clustername /prop HangRecoveryAction=x

В данном случае x может быть от 0 до 3: 0 — отключить мониторинг и не делать вообще ничего, 1 — записать в лог, 2 — остановить Cluster Service, 3 — вызвать «синий экран смерти» с ошибкой 0x0000009E

После изменения действия на «запись в лог», ребуты прекратились.

Не работает смена истекшего пароля в OWA Exchange 2010

Exchange 2010,

Функционал по смене пароля в Outlook Web App бывает полезным во многих случаях. Например: у вас истек срок действия пароля от рабочей учетной записи, а в офис вы попасть в ближайшее время не сможете, но почту читать и отправлять надо. В нормальных условиях, если это было разрешено, OWA предлагает сменить пароль для учетной записи при авторизации. Однако, установка Rollup 25 на Exchange 2010 sp3 ломает эту возможность. Вместо диалога по смене пароля вы получаете ответ «неправильное имя пользователя или пароль». Можно, конечно, откатить апдейт, но обычно это не самый удобный вариант.

Для исправления этого косяка надо:
1. Открыть IIS на сервере, который обслуживает OWA.
2. Перейти в Default Web Site.
3. В правой панели кликнуть дважды на Modules.
4. В панели действий (Actions) нажать Configure native modules.
5. Выбрать exppw и нажать OK.
6. После этого сделать iisreset и проверить. Возможность смены пароля должна появиться.

Перезапуск процесса восстановления Exchange 2010 в случае ошибки

Exchange 2010, ,

При переносе сервера MS Exchange 2010 в конфигурации отличной от единственного сервера, могут возникать непредвиденные проблемы. Даже несмотря на то, что установщик выполняет большое количество проверок, бывают непредвиденные обстоятельства, из-за которых процесс установки прерывается. Казалось бы, нет ничего проще, чем запустить восстановление заново. Но если бы все пошло хорошо — это был бы не тот майкрософт :)

Если при установке все проверки пройдены и начался собственно этап установки, то после сбоя и повторного запуска, вы увидите примерно такую ошибку: «Setup previously failed while performing the action DisasterRecovery. You can’t resume setup by performing the action install». При этом, запустить Uninstall тоже нельзя. Да и вообще ничего нельзя сделать при помощи этого инсталлятора.

И, что характерно для майкрософта, решение проблемы находится в реестре. Для возобновления работы установщика, необходимо перейти в ветку:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14

Найти там разделы с именами ролей сервера (HubTransportRole, MailboxRole и др.) и удалить из них все ключи с именами «Watermark» и «Action». После этого установка перезапустится без проблем.

Перенос Exchange 2010 CAS+Hub на другой сервер при наличии Edge

Exchange 2010, Windows, , ,

Иногда возникает необходимость переноса Exchange-сервера на другое железо. В теории, в этом нет ничего сложного:

— Останавливаем существующий сервер;
— Устанавливаем ОС на новый, выдаем ему то же имя;
— Включаем новый сервер в домен;
— Устанавливаем весь необходимый софт (Microsoft Filter Pack, .NET 3.5) и необходимые роли/фичи сервера (можно подсмотреть здесь);
— Запускаем setup /m:RecoverServer и отдыхаем.

Но если ваша конфигурация Exchange содержит Edge-сервера, то на этапе проверки перед установкой вы получите следующую ошибку:

[ERROR] The internal transport certificate for the local server was damaged or missing in Active Directory. The problem has been fixed. However, if you have existing Edge Subscriptions, you must subscribe all Edge Transport servers again by using the New-EdgeSubscription cmdlet in the Shell.

И ведь, вроде как, в ошибке написано, что «problem has been fixed». Но как бы не так. Перезапуск установки с тем же ключом выдает такую же ошибку.

Для решение этой проблемы, необходимо сходить на контроллер домена, запустить там adsiedit и зайти в Configuration partition –> Services -> Microsoft Exchange –> _ВАША_ОРГАНИЗАЦИЯ –> Administrative Groups –> Exchange Administrative Group (FYDIBOHF23SPDLT) –> Servers –> _ИМЯ_ВАШЕГО_СЕРВЕРА_. По имени сервера необходимо кликнуть правой кнопкой и зайти в Properties. В списке свойств необходимо найти «msExchEdgeSyncCredential» и удалить все, что там есть.

Перезапускаем установку с помощью setup /m:recoverserver и не забываем перезагрузить сервер по окончании установки.

После перезагрузки, необходимо снова «связать» Hub Transport и Edge. Для этого необходимо запустить на Edge-сервере powershell и выполнить команду:

New-EdgeSubscription -FileName "c:\EdgeServerSubscription.xml"

Копируем файл EdgeServerSubscription.xml на наш hub transport, заходим в консоль управления Exchange->Organiztion Configuration->Hub Transport->Edge Subscriptions. Нажимаем New edge subscription, выбираем AD site, subscription file и нажимаем кнопку New.

Если серверов несколько — повторяем эту процедуру для каждого Edge и для каждого Hub.