В один прекрасный вечер я решил изменить конфигурацию моего SCCM 2012. Он находился на одном виртуальном сервере с SCSM и SQL Server 2008R2 SP1. Все это хозяйство “кушало” 6 Гб памяти, а работать с консолью менеджера было неудобно – тормоза и все прочее.

Обдумав ситуацию, я решил отселить SQL на отдельную виртуальную машину. Была найдена инструкция немного староватая, база 2012 SCCM например называется по-другому, но все еще действенная.

Всего-то делов, сохранить базу, перенести ее на новый сервер, восстановить базу, остановить службы сайта командой preinst /stopsite, запустить из программы настройки (Configuration manager setup) восстановление и указать новое расположение базы SQL. На новый сервер SQL установятся 3 роли SCCM (Component Server, Site Database Server, Site System). Перезагрузив сервер, я убедился, что SCCM работает.

С переносом базы SCSM действия такие же – сохранение и восстановление базы, только новое расположение надо указать вручную в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database (ключи DatabaseServerName и DatabaseName).

Перенос SQL базы SCCM 2012  на другой сервер

Казалось бы, все хорошо, все работает, но “старый” SQL продолжает “есть” память, теперь уже абсолютно впустую. А ведь ради экономии памяти все и затевалось.

Я открыл оснастку “удаление программ” и начал удалять все подряд, что имело в своем имени SQL. После перезагрузки от SQL не осталось и следа. И SCCM отказался работать также.

Размышления привели меня к догадке – не стоило удалять абсолютно весь SQL, поскольку для собственных “черных дел” SCCM устанавливает компоненты MS SQL 2008 Native client и Managed objects. Т.к. по случаю я имел на руках резервную копию базы, я просто решил переустановить SCCM.

После запуска установки, я выбрал вариант восстановления с использованием уже существующей базы. Однако проверка предварительных требований показала 2 ошибки. Учетная запись компьютера SCCM не имела прав локального администратора на машине с SQL. И, вот неожиданность – оказалось, что способ сортировки данных (Collation) СЕРВЕРА отличен от требуемого SCCM – SQL_Latin1_General_CP1_CI_AS ! Т.е. SQL при установке поглядел в локаль и решил установить Collation на кириллицу (ну не я же виноват!). Самое забавное, что базы после восстановления содержали правильный Collation. Пришлось перенастроить способ сортировки сервера, практически переустановить SQL командой

После выполнения этой команды все базы пропали, так что пришлось заново восстановить базы SCCM и SCSM. Зато теперь восстановление SCCM прошло успешно. Но радоваться я не спешил и не зря! Как оказалось я поспешил и удалил SQL сервер с базой WSUS поэтому Software Update Point перестал работать, а все мои Software Update Groups стали отображаться иконками с крестиками. В логах пестрили ошибки связи с WSUS. Служба Wsus была остановлена. Я нашел mdf-файл с базой SYSDB, однако все мои попытки оживить WSUS не увенчались успехом, так что я просто переустановил WSUS, указал путь к базе SQL, и переустановил роль Software Update Point. После чего началась синхронизация базы данных WSUS и SQL как и при первичной установки роли. А вот как надо перемещать базу WSUS “по-хорошему

Кстати, в SCCM Best Practice прямым текстом советуют при поднятии роли Software Update Point не указывать категории обновлений и категории программного обеспечения это можно сделать потом, а если вы сразу выберите все что нужно, первоначальная синхронизация займет довольно много времени, у меня она проходила около 4 часов.

Разобравшись с ролью Software Update Point, я решил установить роль Reporting services point. Однако при восстановлении SQL базы ReportService и ReportServiceTempDB были “отцеплены” и спокойно лежали в виде файлов. Поэтому установка роли Reporting services point не могла быть продолжена, мастер не видел инстанс MSSQLSERVER. Я добавил базы на SQL сервер, воспользовавшись утилитой Reporting Services Configuration Manager – запустил службу, удалил все зашифрованное содержимое, перезапустил службу Reporting Service и мои отчеты заработали!

2

Ну если честно, то не совсем заработали, потому как дополнительно пришлось изменить учетную запись для управления отчетами, т.к. для старой учетной записи почему-то не сохранялись настройки безопасности в SQL Repor Services.

3

Вот здесь статья по решению проблем с SQL ReportServices сильно помогла в решении проблемы. И, конечно же, technet. А также Андрей Коршиков (который является большим специалистом в SQL из Украины, и кстати очень ищет единомышленников в РБ для создания сообщества).

Статья опубликована в продолжение рубрики «Записки системного администратора» или «Случай из практики», материалами для которой любезно делится мой коллега из Белоруссии. Оригинал статьи он опубликовал в своём блоге RDP dog.