Проблема CMDBs для CAS и Primary Site, возникающая при размещении на одном SQL кластере.

В рамках развёртывания сложной иерархии ConfigMgr 2012 R2 столкнулись с проблемой, описанной ниже. Удалось её разрешить совместно с инженерами Premier Support Microsoft, за что им большое спасибо.

Описание архитектуры
Существует 2-х узловый SQL (failover) кластер на базе Windows Server 2012 R2 Datacenter. На нём размещаются 2 именованных экземпляра SQL для CAS и Primary Site. Все сертификаты  самоподписанные.


Симптомы

Периодически возникает проблема с невозможностью перевода ресурсов SQL между узлами кластера (при попытке перевода возникают ошибки SQL службы не запускаются).

На серверах SQL, обслуживающих базы данных SCCM с периодичностью каждые 24 часа появляются папки вида SMS_<Site Server FQDN>_SMS_SQL_SERVER<Integer>.

Причина возникновения

Зарегистрированный баг, связанный с одновременным размещением баз данных SCCM разных сайтов на одних и тех же узлах кластера SQL (в разных экземплярах).

Технические подробности ошибки

Ошибка возникает в связи со следующей последовательностью действий:

1)      При установке роли сервера базы данных SQL для SCCM создается специальный сертификат в хранилище MY (HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates) (KEY1). SCCM конфигурирует SQL сервер использовать данный сертификат. В кластеризованном окружении отпечаток его также хранится в ключе 'Certificate' в <HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL<Instance>\MSSQLServer\SuperSocketNetLib> (KEY2).

При установке SQL для другой базы SCCM, работающей в другом экземпляре – у нас появляется второй сертификат в общем хранилище KEY1 и также сертификат в ветке реестра вида KEY2.

2)      Компонент CertMgr сервера SCCM каждые 30 минут проверяет правильность сертификата сервера SQL, именно здесь кроется ошибка в коде – алгоритм выбирает первый попавшийся сертификат из хранилища (KEY1), подпадающий под ряд критериев, и затем сравнивает отпечаток с отпечатком из KEY2 соответствующего экземпляра. Очевидно, для одного из серверов мы получаем совпадение, для другого – всегда несоответствие.

3)      Данное несоответствие вызывает процедуру переустановки компонента на SQL-сервере, которая после первой неудачи повторяется каждые 24 часа. Попытка переустановки завершается неудачей, так как сертификат уже существует. Именно в этот момент появляется новая папка с файлами.

ПРИМЕЧАНИЕ! К сожалению, данный код игнорирует наличие файла no_sms_on_drive.sms, который обычно используется для защиты диска от записи компонентов SCCM (по-умолчанию, всегда выбирается диск с наибольшим объемом свободного места).

Соответственно мы оказываемся в тупиковой ситуации:

1)      Мы не можем ничего сделать с количеством и наличием сертификатов на серверах SQL, так как они необходимы для правильного функционирования компонентов.

2)      Мы не можем повлиять на код, делающий неверный выбор сертификата – в этом и заключается баг. Он проявляется только в данной конфигурации (2 базы в разных экземплярах одного кластера), и так как таких инсталляций немного и, кроме создания лишних папок, к другим ошибкам не приводит – продуктовая группа System Center отложила исправление до следующей версии продукта.

3)      И, наконец, мы не можем отключить переустановку компонента, так как ее инициирует SITE_COMPONENT_MANAGER, необходимый для функционирования массы другого функционала.

Рекомендации

Данное поведение дополнительных угроз, кроме самого факта создания новых папок, не несет.

Объем каждой папки около 1 Мб, соответственно о быстром уменьшении свободного места на диске беспокоиться не стоит (напомню, выбирается диск с наибольшим объемом свободного места). Microsoft рекомендует периодически удалять папки вида SMS_<Site Server FQDN>_SMS_SQL_SERVER<Integer>, оставляя последнюю из созданных по дате. Это можно производить периодически вручную, либо же автоматизировав процесс скриптом/заданием в планировщике.

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

Возможные обходные пути:

• Заскриптовать ручное исправление проблемы – заново давать права учетной записи, под которой работает SQL-сервер;
• Периодически обнаруживать и удалять CMN-файлы из инбокса certmgr;
• использовать PKI-сертификат из выдающего УЦ Microsoft (ADCS), для шифрования соединения БД сайта с сайт-сервером;

Пункт 3 - очень интересен. Судя по лабораторным тестированиям, поведение ConfigMgr, после смены self-signed сертификатов на принадлежащие корпоративному ЦС, меняется: SCCM перестает проверять согласованность Thumbprint’ов для PKI-сертификата и просто работает дальше.

Мы пошли по пути упрощения иерархии. Надеюсь, данная информация поможет кому-либо.