В один прекрасный вечер я решил изменить конфигурацию моего 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 командой
|
1 |
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.