Почему Lync Server 2013 перестал запускаться?

by Опубликовано

Здравствуйте, сегодня расскажем о восстановлении Microsoft Lync Server 2013 в рамках свежей инфраструктуры. Случай из разряда: «вчера все хорошо работало». Данная статья будет полезна системным администраторам и интеграторам,- всем тем, кто планирует внедрять у себя новые продукты Microsoft, особенно тем, кто не владеет английским языком.

Автор: Худяев Илья. Системный инженер компании Рубикон.

 

Сначала опишу инфраструктуру и оговорюсь, что вначале несколько месяцев до этого все работало без нареканий.

  • Уровень леса и домена: 2008 R2
  • Операционная система: Windows Server 2012
  • Версия: Microsoft Lync Server 2013 (далее по тексту Lync)
  • Использование виртуализации в среде: Да

Однажды случилось экстренное отключение электропитания и после запуска Lync перестал работать. В логах следующие события:

  • В системном (System) логе все было забито событиями Schannel 36888:

Оповещение о неустранимой ошибке было создано и отправлено удаленной конечной точке. Это может привести к разрыву соединения. Определенный в протоколе TLS код оповещения о неустранимой ошибке: 10. Состояние ошибки Windows SChannel: 1203.

  • В логе Lync Server появились разнообразные ошибки и предупреждения:
    • Предупреждение: LS User Service 32174
    • Ошибки: LS User Service 32178, LS User Service 30988

Все свидетельствовали о том что Lync Server не может больше функционировать, и причина скорее всего в настройках безопасности.

Сначала проверил службы SQL Server — они все успешно работали, потом — службы Lync Server. И здесь обнаружилась следующая проблема: служба Lync Server Front-End была в состоянии «Запускается» (Starting) и ничего дальше с ней не происходило. Это уже больше было похоже на какой-либо баг в новой системе.

Поиск подобных проблем на просторах российского интернета результатов не дал. На иностранных форумах уже были подобные темы, и особенно полезной оказалась одна тема крупных размеров на social.technet [1] за декабрь прошлого года.

Основную причину такого поведения, там советовали искать в сертификатах. Суть сводилась к довольно простому решению: необходимо проверить хранилища сертификатов и удостовериться, что в «Доверенных корневых центрах сертификации» находятся только самоподписанные сертификаты. А сертификаты центров сертификации(ЦС), заверенные другим ЦС в «Промежуточные центры сертификации».

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

Сервер перезагрузился. Не работает. — «проблемный» сертификат снова был в хранилище «Доверенные корневые центры сертификации». Почему? — ответ групповые политики.

Для проверки запустил rsop.msc: Параметры компьютера – Политики — Конфигурация Windows — Параметры Windows — Параметры безопасности — Политики открытого ключа — Доверенные корневые центры сертификации.

Чтобы удалить его зашел на один из контроллеров домена и поправил групповые политики. Переместил проблемный сертификат в параметр: Параметры компьютера – Политики — Конфигурация Windows — Параметры Windows — Параметры безопасности — Политики открытого ключа — Промежуточные центры сертификации.

Запустил repadmin /syncall. И снова зашел на сервер Lync. На сервере Lync запустил обновление политик через gpupdate /force. Через rsop.msc проверил что политики теперь применяются верно и перезагрузил сервер.

Сервер перезагрузился не работает! Симптомы, как и прежде.

В хранилище сертификатов в «Доверенных корневых ЦС» снова видим «проблемный» сертификат. Мистика? Нет. Проверка групповых политик через rsop.msc показала, что политики, несмотря на изменения применяются прежние, хотя до перезагрузки все применялось как надо. Возникали две версии произошедшего.

  • Прежние политики вернул к прежнему виду другой администратор;
  • Изменения политики не реплицировались на другие контроллеры домена.

Первую версию сразу отмел как маловероятную. Вторая версия оказалась верной. На втором контроллере домена изменения в политике не отразились.

Для проверки на обоих КД запустил dcdiag ( все тесты пройдены ) и создал групповые политики (по одной на каждом КД). В итоге, сами групповые политики реплицируются, а шаблоны нет. Вывод: не работает DFS-R

Первым делом проверил логи Репликации DFS (DFS Replication) и обнаружил везде последнее предупреждение DFSR 2213 от даты отключения электропитания:

Служба репликации DFS остановила репликацию на томе C:. Это происходит, если рабата базы данных DFSR JET была завершена с ошибками, а автоматическое восстановление отключено. Чтобы устранить эту проблему, заархивируйте файлы в соответствующих реплицированных папках, а затем возобновите репликацию с помощью метода WMI ResumeReplication.

Такое поведение характерно только для Windows Server 2008 R2 и более старших версий. Такой механизм защиты позволяет заархивировать данные в реплицируемых папках на случай некорректного разрешения конфликтов. После аварийного отключения служба была остановлена, поэтому шаблоны групповых политики не реплицировались.

Чтобы запустить ее достаточно скопировать и ввести команду из этого сообщения в командной строке с административными привилегиями и ввести Y, когда попросят:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=»12345678-1234-ABCD-EGFD-123456789″ call ResumeReplication

, где «12345678-1234-ABCD-EGFD-123456789» GUID вашего раздела.
Примечание: на попытку просто скопировать и запустить у меня система выдала мне ошибку, поэтому я сначала запустил wmic а потом ввел оставшуюся часть команды.

Вывод из PowerShell:

.PS C:\Windows\system32> wmic
wmic:root\cli>/namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=»12345678-1234-ABCD-EGFD-123456789» call ResumeReplication
Выполнить (\\COMP1\root\microsoftdfs:DfsrVolumeConfig.VolumeGuid=»12345678-1234-ABCD-EGFD-123456789″)->ResumeReplication
Метод успешно вызван.
Параметры вывода:
instance of __PARAMETERS
{
ReturnValue = 0;
};

Подобную команду запустил на остальных КД. Проверил репликацию групповых политик.

Вот краткий план выполненных действий:

  1. Собрали информацию из логов Lync сервера
  2. Проверили Сертификаты
  3. Проверили групповые политики
  4. Возобновили репликацию DFSR после аварийного отключения электропитания.

Ссылки:

  1. http://social.technet.microsoft.com/Forums/en-US/lyncdeploy/thread/e1c7b… — обширная тема на форуме Microsoft посвященная Lync Server 2013 и проблеме с сертификатами на английском языке.
  2. http://support.microsoft.com/kb/2663685/en-us — hotfix с описание проблемного сценария, в в случае автоматического восстановления репликациии DFS.
  3. http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr… — о процессе восстановления репликации DFS после экстренного отключения.

 

Материал подготовил Худяев Илья
Системный инженер
ООО «Рубикон»
тел. +7 (8332) 760-746
ihud@rubicon-it.ru

Опубликовано Администратор