System Center 2012 R2 Configuration Manager - перенос баз данных сервера Primary Site (с учётом SSRS и WSUS) между экземплярами SQL Server

В процессе выполнения задач по виртуализации экземпляров SQL Server обслуживающих продукты System Center 2012 R2 относительно просто был произведён перенос базы дынных Orchestrator (помогла прежняя заметка) и базы данных Virtual Machine Manager (помогла прежняя заметка). Когда дело дошло до баз данных Configuration Manager, стало понятно, что без написания отдельной шпаргалки по этому поводу обойтись не получится, так как есть целый ряд нюансов, которые запомнить моему “склерозу” будет не под силу.

Начнём с описания имеющейся на момент переноса конфигурации SCCM:

KOM-AD01-SCCM02 – Виртуальная машина – сервер первичного сайта (Primary Site Server) SCCM с набором ролей, в числе которых присутствует роль Точка обновления программного обеспечения (Software Update Point / SUP). Отдельно я обозначаю наличие этой роли по причине того, что в контексте нашей задачи потребуются дополнительные действия для обеспечения работоспособности компонент WSUS.
Имя первичного сайта SCCM - K10

KOM-AD01-SQLCL3\SCCM – Кластерный экземпляр SQL Server, функционирующий на двух физических серверах с именами KOM-AD01-SQL03 и KOM-AD01-SQL04

В указанном кластерном экземпляре SQL Server расположены базы данных первичного сайта (CM_K10), компонент WSUS, используемых ролью SUP (SUSDB), и служб SSRS экземпляра RSSCCM (ReportServer и ReportServerTempDB)

KOM-AD01-SQL05 – выделенный виртуальный сервер для служб SQL Server Reporting Services (SSRS). В конфигурации SSRS создан отдельный экземпляр (с именем RSSCCM) для роли SCCM – Точка служб отчётов (Reporting services point)

Что нужно сделать:

• Скопировать все базы данных SCCM из физического кластерного экземпляра SQL Server KOM-AD01-SQLCL3\SCCM на выделенный экземпляр SQL сервер KOM-AD01-DB50\SCCM, функционирующий на виртуальной машине KOM-AD01-DB50. Помимо самих баз данных необходимо скопировать также SQL-логины, разрешения на уровне экземпляра и отдельных БД, задания (Jobs) и др.объекты SQL Server. 
• Перенастроить зависимые от БД компоненты SCCM на серверах KOM-AD01-SCCM02 и KOM-AD01-SQL05 для использования баз данных в новом месторасположении.

План действий будет следующий:

1. Резервное копирование всего, что возможно.
2. Подготовка нового сервера БД.
3. Остановка служб SCCM/WSUS/IIS
4. Копирование объектов SQL Server в новое месторасположение
5. Дополнительная настройка объектов SQL Server после копирования
6. Остановка старого экземпляра SQL Server
7. Реконфигурация и запуск WSUS
8. Подключение сервера SCCM к новому экземпляру SQL Server
9. Первичная проверка работоспособности SCCM
10. Восстановление работоспособности отчётов SCCM
11. Заключительные мероприятия

Поехали…

1. Резервное копирование

Перед тем, как начать какие-либо манипуляции сделаем резервную копию всего, что только возможно и всеми доступными нам методами…
А) Резервная копия виртуальных машин KOM-AD01-SCCM02 и KOM-AD01-SQL05 средствами DPM
Б) Резервная копия всех баз данных экземпляра SQL Server KOM-AD01-SQLCL3\SCCM средствами DPM
В) Полная резервная копия первичного сайта средствами SCCM.

Чтобы выполнить последний пункт, в консоли SCCM должно быть настроено задание резервного копирования первичного сайта. Это настраивайся в разделе консоли \Администрирование\Обзор\Конфигурация сайта\Сайты > выбираем первичный сайт, открываем контекстное меню и выбираем пункт Обслуживание сайта

В списке задач обслуживания открываем пункт Резервное копирование сайта и настраиваем сетевой путь для сохранения резервной копии и время выполнения..

Расписание задания настраивается таким образом, что задается интервал начала и окончания запуска, который можно сузить максимум до 1 часа. Чтобы не ждать, мы можем запустить резервное копирование вручную. Для этого перейдём в раздел консоли SCCM \Мониторинг\Обзор\Состояние системы\Состояние компонента, найдём компонент с именем SMS_SITE_BACKUP относящийся к нашему первичному сайту, откроем на нём контекстное меню и выберем Запустить > Диспетчер служб Configuration Manager

В диспетчере служб найдём одноимённую службу SMS_SITE_BACKUP для нашего сервера первичного сайта, откроем контекстное меню и выполним Запрос текущего состояния службы. Запрос покажет, что служба на данный момент остановлена. Выбираем следующее действие Запустить, чтобы инициировать фактический запуск выполнения задания резервного копирования.

Чтобы проследить за статусом выполнения задачи в контекстном меню соответствующего компонента выберем пункт Показать сообщения > Все

Откроется диалоговая форма отображающая в реальном режиме времени записи в лог-файл:
C:\Program Files\Microsoft Configuration Manager\Logs\smsbkup.log
По записям лога дождёмся успешного завершения задания резервного копирования.

2. Подготовка нового сервера БД

Подразумевается, что новый экземпляр SQL Server KOM-AD01-DB50\SCCM, на который планируется перенос баз данных SCCM уже развёрнут. При его развёртывании мы должны убедиться во-первых в том, что используемая версия SQL Server поддерживается (по документу Supported Configurations for Configuration Manager), а во-вторых проверить, то что версии на исходном и целевом экземпляре SQL Server идентичны. Узнать версию SQL Server это можно простым SQL-запросом:  

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
SELECT @@VERSION

***

Убедимся в том, что порядок сортировки (Server Collation) для нового экземпляра SQL Server соответствует SQL_Latin1_General_CP1_CI_AS

***

Убедимся в том, что для нового экземпляра SQL Server включена поддержка CRL (Common Language Runtime). Значение run_value должно быть установлено в 1:

sp_configure 'clr enabled'

Если это не так, выполняем SQL-запрос для изменения этого параметра:

sp_configure 'clr enabled', 1 RECONFIGURE

Снова проверяем. Возвращаемое значение должно иметь следующий вид (по аналогии с исходным SQL сервером)

Так как далее для копирования объектов между экземплярами SQL Server мы будем использовать мощный скрипт, который будет копировать в том числе и значения sp_configure, -описанных манипуляций делать не потребуется, но для полноты описания я всё-таки решил сохранить эту информацию, так как во многих источниках она обозначается отдельно.

***

Ни в одном из встречающихся описаний по переносу баз данных SCCM я не встретил информации о том, что в новый экземпляр SQL Server нужно выполнять предварительное копирование MASTER-KEY. Однако, опять же для полноты я решил включить этот шаг в данное описание. Итак, задача скопировать мастер-ключ из старого экземпляра SQL Server в новый (разумеется при условии, что в новом экземпляре SQL Server нет никаких других баз данных, которые могут использовать текущий ключ) делается так…
А) Экспортируем мастер-ключ на исходном экземпляре SQL Server (KOM-AD01-SQLCL3\SCCM) SQL-запросом:

BACKUP SERVICE MASTER KEY TO FILE ='K:\MSSQL11.SCCM\MSSQL\Backup\MASTER_KEY_SCCM.BAK' ENCRYPTION BY PASSWORD = 'P@ssw0rd'

Б) Копируем полученный файл MASTER_KEY_SCCM.BAK во временную папку на сервер с экземпляром-получателем SQL Server (KOM-AD01-DB50\SCCM) и выполняем его импорт SQL-запросом:

RESTORE SERVICE MASTER KEY FROM FILE = 'C:\Temp\MASTER_KEY_SCCM.BAK' DECRYPTION BY PASSWORD = 'P@ssw0rd'

B) В целях безопасности не забываем удалить файл мастер-ключа с файловой системы исходного и целевого серверов.

***

Заключительным шагом подготовки будет включение доменной учетной записи компьютера принадлежащей серверу первичного сайта KOM-AD01-SCCM02 в локальную группу Administrators на новом сервере БД (KOM-AD01-DB50)

3. Остановка служб SCCM/WSUS/IIS

По возможности закрываем все используемые консоли SCCM.

На сервере первичного сайта KOM-AD01-SCCM02 с правами администратора запускаем утилиту Hierarchy Maintenance Tool ("C:\Program Files\Microsoft Configuration Manager\bin\X64\00000409\preinst.exe") для остановки всех служб SCCM командой:

"C:\Program Files\Microsoft Configuration Manager\bin\X64\00000409\preinst.exe" /stopsite

Затем останавливаем службы WSUS  и IIS Admin:

net stop WsusService & net stop IISADMIN

4. Копирование объектов SQL Server в новое месторасположение

Для копирования всех баз данных используемых SCCM из одного экземпляра SQL Server в другой можно использовать разные инструменты. После некоторых мытарств по этому поводу, я нашёл один довольно мощный PowerShell-скрипт от Chrissy LeMaire (всех благ автору!) - Start-SQLMigration.ps1. Его мы и будем использовать для решения нашей задачи.

На SQL сервере-получателе KOM-AD01-DB50 разместим скрипт в удобном для нас месте, например в каталоге C:\Tools\Start-SQLMigration, с правами Администратора откроем консоль PowerShell, сменим текущий каталог и запустим скрипт на выполнение, передав ему необходимые параметры:

cd C:\Tools\Start-SQLMigration
.\Start-SQLMigration.ps1 -Source KOM-AD01-SQLCL3\SCCM -Destination KOM-AD01-DB50\SCCM -BackupRestore -Everything -NetworkShare \\KOM-AD01-FSCL02\SQL-TEMP$

Сначала скрипт начнёт процедуру создания резервной копии первой базы данных на SQL сервере-источнике

Затем последует восстановление получившейся резервной копии первой БД на SQL сервере-получателе

По завершению будет выведена статусная информация о результате проделанных операций с первой БД, где кстати говоря, мы увидим, что вместе с переносом БД в новом месторасположении были восстановлены некоторые важные для нас параметры базы.

Далее по аналогии методом Backup/Restore будут скопированы все прочие базы данных, обнаруженные скриптов в исходном экземпляре SQL Server

Затем будет выведен свод по операциям с базами данных и начнётся процедура копирования SQL-логинов…

Снова свод, теперь уже по SQL-логинам и начало копирования SQL-джобам…

Свод по джобам и копирование пользовательских объектов в системных  базах master, model, msdb, а также конфигурации sp_configure…

В конечном итоге, в результате работы скрипта в новый экземпляр SQL Server скопируются SQL-логины, права на уровне экземпляра, базы данных, джобы, и т.д. Дополнительно лог выполняемых заданий можно будет просмотреть в файлах, появившихся в каталоге, из которого был запущен скрипт.

В моём случае всё копирование прошло в целом гладко, за исключением одной ошибки копирования SQL-логина ConfigMgr_DViewAccess, который были создан с привязкой к локальной группе безопасности на сервере-источнике. Позже этот SQL-логин будет автоматически воссоздан в процессе работы мастера реконфигурации SCCM - Configuration Manager Setup Wizard 

5. Дополнительная настройка объектов SQL Server после копирования

Согласно документа Choose the Database Used for WSUS 3.0, есть пару требований для корректной работы БД WSUS. Несмотря на то, что речь идёт о старой версии WSUS, есть мнение, что нужно придерживаться этих требований. В частности, в свойствах Fasets экземпляра SQL Server должна быть включена опция NestedTriggersEnabled

А в свойствах самой базы данных SUSDB должна быть включена опция Recursive Triggers Enabled

***

Также после копирования на новом SQL сервере необходимо проверить текущие настройки БД важные для работы первичного сайта SCCM, сопоставив их с настройками на старом SQL сервере. Для этого выполним один и тот же SQL-запрос на старом и новом SQL сервере:

SELECT name, collation_name, is_trustworthy_on, is_broker_enabled, is_honor_broker_priority_on FROM sys.databases

В нашем случае старый SQL сервер имеет следующие настройки…

Важно, чтобы значения параметров is_trustworthy_on, is_broker_enabled, is_honor_broker_priority_on для БД первичного сайта были такими же и на новом SQL сервере. Если же всё таки они отличаются, то устанавливаем их SQL-скриптом:

USE master
GO
ALTER DATABASE CM_K10 SET ENABLE_BROKER
GO
ALTER DATABASE CM_K10 SET TRUSTWORTHY ON
GO
ALTER DATABASE CM_K10 SET HONOR_BROKER_PRIORITY ON
GO

Снова проверяем результат, только теперь смотрим свойства только той базы, параметры которой меняли:

SELECT name, collation_name, is_trustworthy_on, is_broker_enabled, is_honor_broker_priority_on FROM sys.databases WHERE name = 'CM_K10'

***

Автор заметки Moving, Changing, Migrating, Restoring of your SCCM 2012 SQL Database?, во избежание некоторого рода ошибок в работе SCCM, предлагает дополнительно обратить внимание на то, что в свойствах базы данных первичного сайта должны быть включены параметры - Allow Snapshot Isolation, Is read Commited Snapshot On. Проверим их состояние с помощью SQL-запроса:

SELECT snapshot_isolation_state,snapshot_isolation_state_desc,is_read_committed_snapshot_on FROM sys.databases WHERE name = 'CM_K10'

Если по какой-то причине эти значения отличаются от показанных на скриншоте, то поменять из можно SQL-запросом:

ALTER DATABASE СM_K10 SET ALLOW_SNAPSHOT_ISOLATION ON 
ALTER DATABASE СM_K10 SET READ_COMMITTED_SNAPSHOT ON

В этой же заметке дана рекомендация обратить внимание на владельца базы данных сайта. Владельцем должна быть встроенная учетная запись SQL Server - sa.

И опять же, если это не так, то можно изменить владельца SQL-запросом:

EXEC sp_changedbowner 'sa';

6. Остановка старого экземпляра SQL Server

После того как все проверки скопированных в новый экземпляр SQL Server объектов выполнены, произведём остановку старого экземпляра SQL Server, чтобы быть уверенными в том, что в дальнейшем сервисы SCCM не смогут к нему подключиться. Так, как в нашем случае исходный экземпляр SQL Server является кластеризованным, то производить остановку такого экземпляра лучше через оснастку SQL Server Configuration Manager 

7. Реконфигурация и запуск WSUS

Не забывая про то, что наш SCCM сервер использует компоненты WSUS, перед его реконфигурацией поменяем настройки расположения базы данных SUSDB в системном реестре этого самого сервера первичного сайта (KOM-AD01-SCCM02). Для определения нужных параметров реестра нам пригодится старая заметка. 

В ключе реестра HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup поменяем значение параметра SqlServerName.

Обратите внимание на то, что если используется экземпляр SQL Server по умолчанию, то есть MSSQLSERVER, то его имя в значении параметра не указывается, а указывается только имя сервера, в противном случае WSUS не сможет подключиться к базе.

После сделанной правки реестра запускаем службы IIS Admin и WSUS

net start IISADMIN & net start WsusService

При старте службы WSUS убеждаемся в том, что в логе нет ошибок доступа к базе данных…

8. Подключение сервера SCCM к новому экземпляру SQL Server

На сервере первичного сайта KOM-AD01-SCCM02 с правами администратора запускаем ярлык “Configuration Manager Setup” из каталога C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft System Center 2012 R2\Configuration Manager

В открывшемся мастере Configuration Manager Setup Wizard на первой странице жмём Next а затем выбираем пункт Perform site maintenance or reset this site

На следующем шаге мастера выбираем Modify SQL Server configuration

Затем указываем FQDN имя нового сервера и экземпляра SQL Server, куда уже скопирована база данных первичного сайта SCCM (KOM-AD01-DB50\SCCM)

Дожидаемся завершения процедуры реконфигурации компонент SCCM (в моём случае процесс длился 40 минут)…

По окончанию процесса перезагружаем сервер первичного сайта KOM-AD01-SCCM02.

9. Первичная проверка работоспособности SCCM

После того как сервер первичного сайта переконфигурирован и перезагружен, запускаем консоль SCCM, чтобы убедиться в том, что мы можем подключиться консолью к первичному сайту. В процессе подключения мы можем получить сообщение о том, что консоль работает в режиме “только для чтения”

Это типичная ситуация, так как нашему серверу первичного сайта потребуется некоторое дополнительное время на то, чтобы произвести синхронизацию конфигурационных данных с сайтом верхнего уровня в иерархии SCCM (CAS). И пока эта синхронизация не будет полностью завершена, консоль будет работать в режиме “только для чтения”. Отследить текущее состояние процесса синхронизации можно в разделе консоли \Мониторинг\Обзор\Репликация базы данных

Дожидаемся когда канал репликации между нашим первичным сайтом SCCM и сайтом верхнего уровня перейдёт в состояние “Канал активен”…

После этого можно перезапустить консоль SCCM и она должна начать работать в штатном режиме.

***

Теперь можно перейти в раздел консоли \Администрирование\Обзор\Конфигурация сайта\Серверы и роли системы сайта и удалить запись о старом SQL сервере. В нашем случае потребуется удалить 2 записи серверов входящих в кластер – KOM-AD01-SQL03 и KOM-AD01-SQL04

10. Восстановление работоспособности отчётов SCCM

Для восстановления работоспособности функционала отчётов SCCM первым делом изменим конфигурацию служб SSRS на соответствующем сервере KOM-AD01-SQL05. Для этого запустим на этом сервере оснастку Reporting Services Configuration Manager и подключимся к экземпляру служб SSRS обслуживающему роль точки отчетности SCCM (как упоминалось ранее, в нашем примере имя экземпляра SSRS – RSSCCM)

В открывшейся диалоговой форме перейдём на закладку Database (здесь мы увидим ссылку на старый экземпляр SQL Server, который нами на текущий момент остановлен) и нажмём кнопку Change Database

В открывшемся мастере выберем пункт выбора существующего экземпляра базы данных SSRS – Choose an existing report server database

На следующем шаге мастера Database укажем имя нового экземпляра SQL Server – KOM-AD01-DB50\SCCM и нажмём кнопку Test Connection чтобы проверить возможность успешного подключения к указанному экземпляру

На шаге Database выберем уже существующую базу данных ReportServer в новом экземпляре SQL Server

На шаге Credentials нам необходимо указать учетные данные, используемые SSRS в дальнейшем для подключения к указанной базе данных. В моём случае выбрано использование учетной записи от имени которой запущен сам экземпляра SSRS, то есть выбран вариант Service Credentials

Дожидаемся успешного окончания процесса реконфигурации экземпляра SSRS…

По завершению закрываем оснастку Reporting Services Configuration Manager и проверяем доступность служебных URL нашего экземпляра SSRS по соответствующим ссылкам:

http://SSRS-SERVER/Reports_<Имя экземпляра SSRS>
http://SSRS-SERVER/ReportServer__<Имя экземпляра SSRS>

***

Переходим в консоль SCCM и правим свойства роли точки отчетов. В разделе консоли
\Администрирование\Обзор\Конфигурация сайта\Серверы и роли системы сайта находим наш сервер со службами SSRS (KOM-AD01-SQL05) выбираем установленную на нём роль Точка служб отчетов и открываем её Свойства

Изменяем имя сервера и экземпляра SQL Server, на то где теперь расположена база данных первичного сайта в формате KOM-AD01-DB50\SCCM и нажимаем кнопку Проверить, чтобы проверить возможность подключения к БД.

Ниже, в качестве Reporting Service Account указываем учетную запись от имени которой у нас работает экземпляр SSRS для SCCM

Сохраняем настройки и проверяем возможность отображения и успешного формирования отчётов SCCM в разделе консоли \Мониторинг\Обзор\Отчеты

11. Заключительные мероприятия

Что ещё можно дополнительно проверить в консоли SCCM поле завершения всех работ:

• Состояние синхронизации метаданных WSUS в разделе консоли
  \Мониторинг\Обзор\Состояние синхронизации точки обновления программного обеспечения
• Состояние всех ключевых компонент сайта в разделе консоли
  \Мониторинг\Обзор\Состояние системы\Состояние сайта

***

Не забываем отредактировать права доступа на сетевой каталог используемый в задаче резервного копирования нашего первичного сайта, чтобы новый сервер SQL смог сохранять туда резервную копию БД в процессе выполнения задания по резервному копированию.

***

В конце концов если всё это хозяйство “взлетело”, можно подумать и об удалении старого экземпляра SQL Server используемого ранее под SCCМ.

---

Дополнительные источники информации:

• TechNet Library - Maintaining Configuration Manager 2007 - How to Move the Site Database
• Steve Thompson [MVP] - Moving ConfigMgr 2012 databases between servers
• My System Center Experience  - Moving, Changing, Migrating, Restoring of your SCCM 2012 SQL Database?
• ctrl-alt-geek - Migrating SQL Server Databases that use Database Master Keys