На этот раз случай из разряда Worst Practice (сам создал проблему- сам решил), однако возможно это поможет кому-то.
Дело №8. Проблемы при переносе SQL базы SCCM 2012 на другой сервер.
В один прекрасный вечер я решил изменить конфигурацию моего 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 продолжает «есть» память, теперь уже абсолютно впустую. А ведь ради экономии памяти все и затевалось.
Я открыл оснастку «удаление программ» и начал удаля все подряд, что имело в своем имени 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 командой
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS /SQLSYSADMINACCOUNTS=домен\юзер /SAPWD=пароль
После выполнения этой команды все базы пропали, так что пришлось заново восстановить базы 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 и мои отчеты заработали!
Ну если честно, то не совсем заработали, потому как дополнительно пришлось изменить учетную запись для управления отчетами, т.к. для старой учетной записи почему-то не сохранялись настройки безопасности в SQL Repor Services. 
Вот здесь статья по решению проблем с SQL ReportServices сильно помогла в решении проблемы. И конечно же technet. А также Андрей Коршиков(который является большим специалистом в SQL из Украины, и кстати очень ищет единомышленников в РБ для создания сообщества).
На этом предлагаю закончить.
RDP dog 
[…] […]