Упрощаем обслуживание SCDPM-серверов

Если вы когда-нибудь пробовали регулярно обслуживать SCDPM-серверы (например, ежемесячно устанавливать обновления), то, наверняка, знаете, что просто так выключать SCDPM-сервер нельзя — предварительно надо отключить всех агентов и дождаться завершения всех заданий.

Но есть проблема — не существует быстрого способа получить в PowerShell список всех подключённых к серверу активных агентов. Вы, конечно, можете сказать, что я неправ и командлет Get-DPMProductionServer с фильтром «ServerProtectionState -eq ‘HasDatasourcesProtected'» решают задачу, но, на самом деле — нет: вы забыли про узлы кластеров. Если SCDPM-сервер защищает кластерный ресурс, но никак не защищает сами узлы кластера, вы не увидите их в выводе Get-DPMProductionServer (с применённым фильтром). Плюс ко всему, в выводе будут маячить совершенно ненужные кластерные ресурсы, агента на которых как раз никакого и нет.

Вот почему я предлагаю вам скрипт для быстрого и точного получения списка настоящих активных компьютеров, подключённых к вашему SCDPM-серверу. Просто передайте ему на вход список имён SCDPM-серверов (или ничего не передавайте для локального выполнения) и в ответ вы получите коллекцию объектов ProtectedServers для каждого из них. Дальше, вы можете передать эту коллекцию, напрямую через pipeline, командлетам Enable/Disable-DPMProductionServer.

Команда «setspn -x» теперь регистронезависимая

Как вы знаете, дублирующиеся SPN в домене AD DS приводят к сбоям при аутентификации с использованием Kerberos, заметить которые вы можете по появлению ошибок KRB_AP_ERR_MODIFIED и событиям №11 в журналах ваших систем. Для проактивного исправления проблемы, начиная с Windows Server 2008, встроенное средство setspn дополнено ключом «-x», который выводит список дублирующихся SPN в домене (либо в лесу, если использован ещё и ключ «-f»). Многие компании используют результат работы команды «setspn -x -f», как источник данных для системы мониторинга.

Оказывается, всё это время, практически никто из IT-администраторов (и я тоже) не обращал внимания, что ключ «-x» производил сравнение SPN с учётом регистра! Т.е. следующие SPN он считал разными и не выводил в результате своей работы:

  • HOST/SERVERNAME
  • HOST/ServerName

Начиная с Windows 10, Microsoft изменила поведение средства setspn на регистронезависимое и, теперь, в вывод setspn будут попадать все дублирующиеся SPN, независимо от их регистра.

Несмотря на то, что Microsoft утверждает, что в среде Windows SPN не-регистрозависимые, Shane Young обнаружил, что SharePoint так не считает.

Я советую всем администраторам AD DS проверить свою инфраструктуру при помощи setspn из поставки Windows 10, хотя бы один раз, чтобы найти ДЕЙСТВИТЕЛЬНО ВСЕ дублирующиеся SPN (я у себя нашёл ;).