[recovery mode] Миграция SCCM 2007 до SCCM 2012
Давно «мечтал» написать на эту тему, все лень было… Запаситесь печеньками, это надолго. Тут может быть какое-то количество ошибок — сообщите мне если обнаружите их, пожалуйста. Трудно вычитать ~35000 знаков. Я намеренно не хочу разделять пост на несколько частей, таким образом вся информация собранная мной будет в одном месте.
1. Архитектура
Иерархия SCCM 2012 состоит из трех типов серверов: Central Administration Site, Primary Site и Secondary Site. Создание четырехуровневой иерархии подобной существующей иерархии SCCM 2007 с использованием SCCM 2012 невозможно, так как иерархия SCCM 2012 трехуровневая. Отношения между серверами в иерархии Parent-Child, во главе иерархии стоит CAS сервер, ему подчиняются Primary Site сервера, а им подчиняются Secondary Site сервера. Начиная с версии 2012 SP1 возможна «конвертация» stand alone Primary в иерархию SCCM, таким образом в случае если у Вас менее 90000-95000 клиентов в иерархии — нет смысла в иерархии SCCM 2012 с CAS сервером.
Исходная и конечная иерархии SCCM не могут содержать одинаковые коды сайтов, таким образом, все коды сайтов должны быть изменены при миграции.
В миграции могут участвовать только сервера SCCM 2007 с установленным SP2 или более поздней версией.
Расширение схемы службы каталогов Active Directory для установки иерархии SCCM 2012 параллельно с SCCM 2007 не нужно (в случае если расширение схемы было произведено для установки SCCM 2007).
1.1. Central Administration Site
CAS сервер является главным сервером иерархии SCCM. Иерархия SCCM 2012 не может содержать более одного CAS сервера, кроме того он должен быть установлен первым в иерархии (не актуально после 2012 SP1). CAS сервер поддерживает не все роли, так как он не используется для взаимодействия с клиентами.
CAS сервер используется для управления всей инфраструктурой SCCM и является единственным сервером на котором доступна информация обо всей инфраструктуре, к примеру назначать способы обнаружения для Primary Site серверов или управлять ролями доступа администраторов к иерархии SCCM.
CAS сервер поддерживает до 100000 клиентов в инфраструктуре SCCM в случае если SQL сервер имеет редакцию «enterprise» или «datacenter» и до 50000 клиентов если SQL сервер имеет редакцию «standard».
1.2. Primary Site
К CAS серверу не может быть подключено более 25 Primary Site серверов. Primary Site сервер отвечает за взаимодействие с клиентами и с Secondary Site серверами, консолидирует полученные данные и отправляет их на CAS сервер.
Primary Site сервер поддерживает до 10 точек управления клиентами каждая из которых поддерживает до 25000 клиентов.
Primary Site сервер может управлять только клиентами подключенными напрямую к этому серверу или клиентами подключенными к его дочерним серверам.
Primary Site сервер поддерживает до 250 Secondary Site серверов и 250 Distribution point’ов. Primary site сервер может передавать данные на Secondary Site сервера и на Distribution point’ы по расписанию и\или может ограничивать используемую им пропускную способность канала.
Primary Site сервер поддерживает до 50000 клиентов в случае если он сосуществует с SQL сервером и до 100000 клиентов если SQL сервер существует отдельно от Primary Site сервера. Редакция SQL сервера не важна, в отличие от CAS сервера. Кроме того, Secondary Site серверы не увеличивают лимит подключенных к Primary Site серверу клиентов. В случае если CAS сервер имеет базу данных установленную на SQL сервер редакции “standard” лимит подключенных к Primary Site серверу и его дочерним серверам клиентов равен 50000.
Primary Site сервер не может содержать дочерних Primary Site серверов.
1.3. Secondary Site и Distribution Point
Миграция Secondary Site серверов происходит следующим образом – удаление исходного Secondary Site сервера, ожидание следующего цикла сбора информации, если успешное удаление Secondary Site сервера подтверждается после сбора информации происходит установка Distribution Point’а и импорт в него всех данных которые находились на исходном Secondary Site сервере.
Для миграции Distribution Point’а необходимо чтобы на сервере была установлена поддерживаемая SCCM 2012 операционная система и наличие свободного места в два раза превышающее размер всех пакетов на Distribution Point’е.
С помощью Distribution Point’а и Secondary Site сервера нельзя управлять инфраструктурой SCCM, все административные действия должны проводиться на CAS и Primary Site серверах. Основная задача Distribution Point’ов и Secondary Site серверов – уменьшение файлового трафика в сети и консолидация данных от клиентов для передачи родительскому Primary Site серверу.
Secondary Site сервер не может использоваться для назначения кода сайта SCCM клиентам. В случае если boundary группы используются для назначения сайтов клиентам и клиенту назначен код Secondary Site’а – клиенту присваивается код родительского сайта данного Secondary Site сервера.
Secondary Site сервер поддерживает до 250 Distribution point’ов. Distribution point поддерживает до 4000 клиентов.
Secondary Site сервер поддерживает до 5000 клиентов.
2. Возможность миграции различных типов объектов
К сожалению, я не понял как вставлять табличку, поэтому картинка.
Миграция коллекций – при выполнении миграции коллекций автоматически мигрируют все объекты (эту функцию можно отключить при создании «работы миграции»), которые связанны с этой коллекцией (кроме тех которые не могут быть мигрированы). Повторная миграция коллекций осуществляется идентично первоначальной.
Миграция объектов – при выполнении миграции объектов необходимо выбрать все объекты, которые должны участвовать в миграции.
Однако существуют некоторые ограничения. Коллекции должны содержать только пользователей или только компьютеры. Пустые коллекции не могут быть мигрированы, и вместо них будет создана папка. В случае наличия разворачиваний, включающих все подколлекции, нацеленных на пустую коллекцию при миграции будет создана новая коллекция содержащая все подколлекции и разворачивания будут нацелены на неё. Коллекции содержащие объект «unknown computer» будут мигрированы, но этот элемент будет удален из коллекции. Миграция связанных коллекций не поддерживается (связанные коллекции – коллекции содержащие пользователей и компьютеры).
Следующие объекты и данные не могут быть мигрированы: запросы, отчеты, данные инвентаризации клиентов, данные Intel AMT, измененные образы загрузки, данные в кэше агентов SCCM 2007, клиентская история, настройки безопасности, mof файлы.
Миграция отчетов невозможна средствами SCCM. Однако, для миграции отчетов можно воспользоваться утилитой SQL Server Reporting Services Report Builder. Для этого необходимо конвертировать все отчеты в исходной инфраструктуре таким образом, чтобы они использовали механизмы SQL. Для этого необходимо установить на базах данных роль SQL Server Reporting Services, после чего настроить доступ исходной иерархии SCCM к данному сервису (через консоль SCCM, управление серверами, управление ролями), конвертировать все отчеты в SQL отчеты (через консоль SCCM, выбрать необходимые отчеты и нажать “Copy Reports to Reporting Services”). Далее миграция отчетов производится средствами SQL Server Reporting Services Report Builder или утилитой ReportSync.
Миграция запросов невозможна средствами SCCM. Необходимо пересоздавать запросы или экспортировать запросы в виде «mof» файлов из иерархии SCCM 2007и импортировать их в SCCM 2012, это осуществляется средствами консоли SCCM исходной и целевой иерархий.
Миграция mof файлов невозможна средствами SCCM. Необходимо заново настраивать их в новой иерархии. Механизм взаимодействия с mof файлами не изменился, однако могут потребоваться изменения в существующих mof файлах для полной cовместимости с SCCM 2012.
3. Требования к SQL серверу
Для всех ролей серверов должны использоваться 64 битные редакции SQL сервера и аутентификация windows для доступа к базе данных.
Компонент «SQL Server Replication» не используется для репликации данных между серверами SCCM. Этот процесс происходит силами SMS Provider’а. В случае если необходимо генерировать и просматривать отчеты нужно установить на SQL сервер компонент «SQL Server Reporting Services».
Для каждого сервера SCCM должен использоваться отдельный экземпляр SQL сервера и параметр «Collation» SQL сервера должен быть одинаков на всех серверах в иерархии SCCM. Единственный поддерживаемый «Collation» — SQL_Latin1_general_CP1_CI_AS.
Для корректной работы сайт серверов иерархии SCCM 2012 необходимо чтобы SQL сервер поддерживал windows аутентификацию. Так как mixed режим поддерживает аутентификацию windows его использование на SQL серверах иерархии SCCM возможно. Таким образом, возможно использование mixed или windows аутентификации, «Best practice» — Windows режим.
Необходимо использовать следующие настройки потребления памяти SQL сервера:
— в случае сосуществования установки SQL и сервера SCCM ограничить потребление памяти SQL сервера до 50-80% оперативной памяти сервера.
— в случае раздельной установки SQL и сервера SCCM ограничить потребления памяти SQL сервера до 80-90% оперативной памяти сервера.
— Primary Site сервер и CAS сервер требуют резервирования 8гб оперативной памяти на SQL сервере, а Secondary Site сервер требует резервирования 4гб оперативной памяти SQL сервера.
4. Требования к сетевой инфраструктуре
gallery.technet.microsoft.com/SCCM-2012-R2-Network-scheme-b01fd985
Эта схема без CAS роли, другой схемы не нашел. Но я думаю 99% читающих это она подойдет.
5. Подготовка к миграции
Ввиду того что иерархия SCCM 2012 отличается от иерархии SCCM 2007 необходимо реорганизовать существующую структуру SCCM 2007 и сделать более плоской. Для осуществления миграции необходим аккаунт с доступом «Read» на все объекты иерархии SCCM 2007 и аккаунт с правами «Read» и «Write» к базе данных, кроме того необходимо открыть следующие порты: 135, 445, 1433 (все TCP).
Для миграции SCCM 2007 в SCCM 2012 необходимо выбрать исходный сервер в инфраструктуре 2007, это должен быть «высший» сервер существующей иерархии, поскольку после выбора исходного сервера нельзя будет мигрировать все объекты, сервера и клиентов которые находятся «выше» выбранного сервера.
Поскольку SCCM 2012 не поддерживает создание дочерних Primary Site серверов у Primary Site серверов мигрировать такую иерархию невозможно, необходимо консолидировать всех клиентов всех дочерних Primary Site серверов в существующей иерархии в соответствующие им родительские Primary Site сервера в новой иерархии. Консолидация клиентов происходит при «миграции» клиента. До непосредственной миграции клиенты находятся под управлением иерархии SCCM 2007. При миграции клиента он должен получить код родительского ему сайта SCCM 2012 при установке клиента (через ключ командной строки). Присвоение клиентам соответствующих им кодов сайтов родительских им Primary Site серверов и является консолидацией.
Все сервера в иерархии которые будут участвовать в миграции должны быть обновлены до версии SCCM 2007 SP2 или выше.
Secondary сервера не могут быть мигрированы, необходимо удаление сервера и установка на него Secondary сервера от инфраструктуры SCCM 2012 (возможно вместе с сохранением данных на Distribution point’е).
Для бесперебойного оказания услуг инфраструктуры SCCM могут совместно использовать существующие Distribution point’ы. Настройка совместного использования существующих Distribution point’ов производится на начальных этапах миграции для этого необходим аккаунт с правами «Modify» на объект SCCM.
Для миграции объектов SCCM необходимо подготовить общие папки к миграции, те дать доступ к общим папкам аккаунтам которые будут отвечать в новой иерархии за доступ к общим папкам. Кроме того, необходимо реконфигурировать объекты SCCM таким образом, чтобы они использовали UNC путь к общей папке, это позволит не перенастраивать объекты после миграции.
Коллекции не могут быть смешанными, те не могут содержать одновременно компьютеры и пользователей. Все смешанные коллекции нужно реорганизовать на коллекции, которые содержат только пользователей и только устройства. Кроме того, не могут быть мигрированы коллекции, которые содержат в себе смешанные коллекции и коллекции содержащие неизвестные компьютеры. Пустые коллекции будут мигрированы как папки.
Для миграции отчетов необходимо установить роль SQL Server Reporting Services (SRS) и конвертировать все отчеты в формат SRS. Миграция отчетов средствами SCCM невозможна, однако возможна средствами SQL.
Миграция клиентов позволяет избежать повторного распространения пакетов, это происходит потому что при миграции пакетов SCCM 2012 хранит в базе информацию о номере пакета SCCM 2007, а клиент, в свою очередь, при миграции сохраняет данные об установленных пакетах.
Для миграции клиентов необходимо создать и распространить пакеты для установки клиентов SCCM 2012 в иерархии SCCM 2007. Кроме того, возможно распространение клиентов SCCM 2012 любым доступным способом, так как миграция клиентов невозможна фактически необходим in place upgrade.
6. Подготовка целевой системы к миграции
Целевая иерархия должна быть развернута сверху вниз: первым должен быть развернут центральный сайт, после него развернуты его дочерние сайты и после этого должны быть развернуты сервера и точки распространения нижнего уровня. В случае если на каких-то площадках невозможно развернуть сервер из новой иерархии необходимо воспользоваться возможность создания точки распространения контента на клиентской системе.
Передачу контента возможно осуществить по настроенному графику, то есть, не загружая канал в рабочее время, или с помощью “Prestage Content File” и передать его на площадку офлайн способом. “Prestage Content File” создается на центральном сайте иерархии и содержит в себе все необходимые пакеты.
После разворачивания иерархии необходимо произвести тестирование. Проверить репликацию данных между сайтами в иерархии, проверить здоровье точек управления клиентами и точек распространения контентом. Проверить возможность подключения клиентов к каждой точке управления клиентами в иерархии, возможность отправления и приема данных клиентов. Проверить работоспособность разворачиваний и всех точек распространения данных в иерархии.
Следующим шагом подготовки целевой инфраструктуры должна стать настройка “Default Client Settings”, “Boundary”, “Boundary Group”, “Security Scope” и Административные учетные записи. Кроме того, необходимо создать 2 учетные записи для доступа к старой иерархии и для доступа к базе данных старой иерархии (возможно необходимо создание большего количества учетных записей если для доступа на разные сайты иерархии и разные сервера баз данных невозможно подключаться с одинаковыми учетными данными). “Security Scope” и “Boundary Group” необходимы для переназначения прав на управления контентом и указания местоположения контента в новой иерархии.
В начале процесса, в новой системе указываются адреса серверов SCCM 2007 и учетные данные для доступа к ним, начиная от высшего к низшему серверу в иерархии указываются все сервера которые будут участвовать в миграции. Затем производится выбор того какие данные необходимо перенести из старой системы в новую.
Фактически миграция представляет из себя копирование объектов из исходной иерархии в целевую. Миграция объектов происходит при помощи «работ миграции». Каждая «работа миграции» может мигрировать любое количество объектов SCCM. Возможна повторная миграция объектов SCCM в случае если это необходимо (например объект был изменен). Порядок миграции объектов не важен. Миграция ролей или Primary Site серверов SCCM невозможна (точки распространения контента и Secondary Site сервера – могут быть мигрированы).
Для копирования объектов из исходной иерархии в целевую необходимо осуществить сбор данных об исходной иерархии. В процессе сбора данных устанавливается связь между иерархиями. Сбор данных происходит путем считывания информации об объектах и их зависимостях, коллекциях, сайтах и клиентах из базы данных целевой иерархии.
Для миграции клиентов необходимо использовать консоль исходной иерархии или другие средства, так как миграция клиентов происходит путем “in place” обновления клиента. Механизмы установки агента на клиентский компьютер не изменились в SCCM 2012. Обновление может быть инициировано startup скриптом, групповой политикой или установлено как пакет с сервера исходной иерархии. До того как клиент будет мигрирован он находится под управлением исходной иерархии.
Клиент SCCM 2007 не может управляться иерархией SCCM 2012 и наоборот, клиент SCCM 2012 не может управляться иерархией SCCM 2007. В случае не правильно настроенных границ сайтов в иерархиях SCCM клиенты получившие неправильный код сайта (те код сайта из «другой» иерархии) будут не управляемы до тех пор пока им не будет назначен правильный код сайта. До начала миграции все клиенты управляются иерархией SCCM 2007, по мере миграции клиентов они переходят под управление SCCM 2012.
По завершении миграции клиентов и объектов можно приступать к миграции точек распространения контента. Она происходит при помощи консоли CAS сервера целевой иерархии (задание “Migrate Distribution Point”). При миграции точки распространения контента происходит обновление бинарных файлов и миграция файлового хранилища. Для миграции хранилища необходимо чтобы сервер имел свободное место в 2-2.5 раза превышающее место занятое всеми пакетами SCCM 2007 на этом сервере, так как происходит перестройка хранилища пакетов SCCM.
Миграция Secondary Site серверов невозможна. Вместо этого происходит “in place” апгрейд Secondary Site сервера только до точки распространения контента целевой иерархии (это техническое ограничение системы введенное компанией “Microsoft” в связи с изменениями в механизмах репликации пакетов в иерархии и усовершенствованиями в механизмах управления трафиком репликации пакетов) с сохранением всех пакетов. Для миграции хранилища необходимо чтобы сервер имел свободное место в 2-2.5 раза превышающее место занятое всеми пакетами SCCM 2007 на этом сервере, так как происходит перестройка хранилища пакетов SCCM.
Миграция Primary Site серверов невозможна, вместо миграции Primary Site серверов происходит миграция объектов из Primary Site сервера старой иерархии в CAS (или соответствующий ему Primary Site сервер) новой иерархии. Таким образом, для «миграции» Primary Site сервера необходимо наличие целевой инфраструктуры SCCM 2012 и место для хранения пакетов эквивалентное месту потраченному на исходном сервере. Не смотря на то что, CAS сервер не может обслуживать клиентов и не может быть точкой распространения контента необходимо наличие на нем свободного места для хранения всех пакетов иерархии.
Полезные утилиты:
ReportSync – утилита для миграции отчетов из иерархии SCCM 2007 в иерархию SCCM 2012. Доступна для скачивания в интернете.
RegKeytoMof – утилита для создания mof файлов для инвентаризации не стандартных параметров реестра. Доступна для скачивания в интернете.
ExtractContent – утилита для распаковки содержимого «Prestage Content» файла. Идет в комплекте с SCCM 2012, находится в папке «BIN» дистрибутива SCCM
CMTrace – утилита для просмотра логов. Идет в комплекте с SCCM 2012, находится в папке «Tools» дистрибутива SCCM.
Notepad – утилита для просмотра логов.
7. Приблизительный процесс миграции
Миграция происходит поэтапно. Переходить к следующему этапу миграции можно только после полного завершения предыдущего этапа. В случае отказа целевой иерархии возможен безболезненный возврат ИТ инфраструктуры на исходную иерархию, так как миграция не предполагает внесения каких-либо изменений препятствующих функционированию исходной иерархии (до этапа миграции клиентов).
На первом этапе миграции необходимо создать целевую иерархию SCCM параллельно с существующей иерархией.
Второй этап заключается в подготовка иерархий и сборе информации об исходной иерархии.
На третьем этапе происходит миграция объектов SCCM.
На четвертом этапе происходит миграция клиентов SCCM.
Пятым этапом является тестирование целевой иерархии и выведение из эксплуатации исходной иерархии.
7.1. Развертывание иерархии SCCM 2012
1. Подготовка аппаратной платформы для установки серверов иерархии.
2. Установка или разворачивание операционной системы и обновлений.
3. Установка сервера баз данных.
4. Установка ПО необходимого для полноценного функционирования CAS сервера.
5. Установка CAS сервера.
В процессе установки необходимо будет указать языки, которые должны быть поддерживаемы иерархией SCCM, сервер баз данных (аккаунт от имени которого происходит установка CAS сервера должен обладать соответствующими правами для доступа к серверу баз данных, кроме того, на сервере баз данных должен быть включен доступ по TCI\IP), необходимо указать код сайта CAS сервера. Можно использовать любой дистрибутив, так как возможность ввода лицензии после установки сервера – предусмотрена.
6. Проверка работоспособности CAS сервера: проверить здоровье компонентов CAS сервера (панель Monitoring, закладка «Site Status» и «Component Status»), проверка работоспособности консоли.
7. Подготовка второго сервера для установки первого Primary Site сервера (повторение шагов 2-4).
8. Установка Primary Site сервера.
В процессе установки необходимо указать сервер баз данных (аккаунт от имени которого происходит установка сервера должен обладать соответствующими правами для доступа к серверу баз данных, кроме того, на сервере баз данных должен быть включен доступ по TCI\IP), код сайта и указать сервер, который будет родительским данному Primary Site серверу, то есть CAS сервер новой иерархии. Для установки Primary Site сервера используется тот же дистрибутив что и для установки CAS сервера.
9. Проверка работоспособности Primary Site сервера: проверить здоровье компонентов Primary Site сервера (панель Monitoring, закладка «Site Status» и «Component Status»), проверка работоспособности консоли, проверить репликацию данных между данным сервером и CAS сервером (replmgr.log, rcmctrl.log или панель Monitoring, закладка «Site Status» и «Component Status»), проверить здоровье точки управления клиентами и точки распространения контентом (mpmsi.log, mpsetup.log, smsdpmon.log панель Monitoring, закладка «Site Status» и «Component Status»), проверить возможность подключения клиентов к каждой точке управления клиентами в иерархии, возможность отправления и приема данных клиентов.
10. Установка всех остальных Primary site серверов в иерархии (повторение шагов 8 и 9).
11. Проверка работоспособности иерархии SCCM 2012: проверить здоровье компонентов всех серверов иерархии (панель Monitoring, закладка «Site Status» и «Component Status»), проверить репликацию данных в иерархии (панель Monitoring, закладка «Site Hierarchy»), кроме того возможно осуществить проверку с помощью просмотра лог файлов на каждом конкретном сервере.
12. Установка необходимых дополнительных ролей на сервера иерархии и настроек (способы обнаружения клиентов, клиентские политики, «push» установка клиентов и так далее).
13. Настройка прав доступа пользователей к иерархии и настройка «security scopes».
7.2. Подготовка иерархий и сбор данных
1. Подготовка исходной иерархии к миграции. Подготовка коллекций и объектов к миграции, производится с помощью консоли SCCM 2007. Принадлежность объектов к сайтам исходной иерархии не имеет значения, так как при миграции объектов им можно указать любой сайт в целевой иерархии как родительский. Вследствие чего, миграция объектов может производится с любого сайта на любой, однако необходимо подключать все сайты имеющие уникальный контент.
2. Для миграции данных из исходной иерархии в целевую необходимо настроить связь между иерархиями. Начинать нужно с верхнего сайта иерархии.
3. После этого необходимо подключить Primary Site имеющие уникальный контент к иерархии SCCM 2012. Оба действия производятся с помощью консоли SCCM 2012 (вкладка Migration, закладки Administration). Для этого необходимо выбрать пункт «Specify Source Hierarchy» и ввести необходимые для подключения данные. Подключение сайтов иерархии SCCM 2007 происходит к центральному сайту.
4. Включение совместного использования точек распространения контента производится с помощью пункта «Share Distribution Points» (вкладка Migration, закладки Administration). Совместное использование точек распространения контента возможно только после сбора информации о них. Данный режим необходим для непрерывного обслуживания клиентов сайтов, в которых невозможно установить Secondary Site сервер или точку распространения клиентов целевой иерархии. До разворачивания указанных ролей клиенты старой и новой иерархии будут использовать точки распространения контента старой иерархии (в том числе точки распространения контента на Primary Site серверах).
7.3. Миграция объектов SCCM
1. После завершения первоначального сбора данных можно приступать к миграции данных из исходной иерархии в целевую. Для этого необходимо выбрать пункт «Create Migration Job» (вкладка Migration, закладки Administration). Далее необходимо выбрать одну из двух возможных типов работ: «Collection Migration» или «Object Migration». После этого выбрать необходимые объекты, выбрать время, назначить «Security Scope», выбрать сайт, на который будет мигрирован контент. Возможна повторная миграция объектов SCCM. В случае если во время проведения миграции объект был изменен его можно повторно мигрировать. Повторная миграция коллекций осуществляется с помощью пункта «Collection Migration».
Работы «Collection Migration» предназначены для миграции коллекций (вместе со всеми объектами от которых они зависят), в то время как работы «Object Migration» мигрируют объекты (вместе со всеми объектами от которых они зависят). Миграция ролей или Primary Site серверов SCCM невозможна (точки распространения контента и Secondary Site сервера – могут быть мигрированы). Таким образом, выбор объектов для миграции и готовность целевой иерархии к обслуживанию клиентов определяется потребностями организации.
2. Для миграции всех объектов необходимо последовательно создавать работы миграции (пункт 1) по мере завершения предыдущих работ миграции. Проверку успешности работ миграции можно проверить разными способами: создание отчетов миграции в закладке Reporting панели Monitoring, закладка Migration jobs в панели Administration, просмотр мигрировавших объектов в соответствующей закладке консоли SCCM и просмотр лог файла – migmctrl.log расположенного в папке logs.
Для миграции отчетов можно воспользоваться средствами SQL Server Reporting Services. Для этого необходимо конвертировать все отчеты в исходной инфраструктуре таким образом, чтобы они использовали механизмы SQL. Для этого необходимо установить на базах данных роль SQL Server Reporting Services, после чего настроить доступ исходной иерархии SCCM к данному сервису (через консоль SCCM, управление серверами, управление ролями), конвертировать все отчеты в SQL отчеты (через консоль SCCM, выбрать необходимые отчеты и нажать “Copy Reports to Reporting Services”). Далее миграция отчетов производится средствами SQL Server Reporting Services Report Builder или утилитой ReportSync.
Для «миграции» sms_def.mof файлов необходимо заново импортировать их в SCCM 2012 или просто опросить WMI любой клиентской машины содержащий необходимые классы и добавить их в инвентаризируемые с помощью консоли SCCM 2012. Панель Administration, закладка Client Settings, далее или политика по умолчанию или новая политика клиентских компьютеров (не пользователей), раздел «Hardware Inventory» пункт «Set Classes». Кнопка Import или опрос клиентской машины и добавление классов WMI.
3. После завершения миграции всех объектов необходимо проверить успешность репликации и наличие всех объектов SCCM на всех серверах в иерархии с помощью консоли SCCM 2012.
4. Необходимо произвести настройку «Boundary Group» для распространения контента, после миграции всех «Boundaries» необходимо воспользоваться пунктом «Boundary Groups» (вкладка Hierarchy Configuration, закладки Administration).
5. Создание «Prestage Content» файла для дальнейшего распространения его сторонними механизмами (не механизмами SCCM). Для создания данного файла необходимо перейти в закладку «Software Library» и выбрать необходимые пакеты, после чего воспользоваться командой «Create Prestage Content File».
6. Развернуть «Prestage Content» файл на целевых точках распространения контента с помощью утилиты extractcontent с ключом /p.
7.4. Миграция клиентов SCCM
1. Перед установкой агентов SCCM 2012 рекомендуется заранее установить на клиентские машины ПО необходимого для работы клиента SCCM 2012. Этот шаг опциональный, но желательный так как снижает время установки клиента SCCM 2012 и количество отказов установки. До миграции клиентов они обслуживаются серверами Исходной иерархии.
2. Поскольку миграция клиента, фактически, является переустановкой агента её можно осуществить всеми способами, которыми возможно установить агента SCCM. Способы установки клиентов не изменились в новой версии SCCM.
Миграцию клиентов необходимо осуществлять поэтапно (по 500-1000 клиентов) для уменьшения нагрузки на сетевую инфраструктуру и сервера баз данных. При миграции необходимо консолидировать клиентов. Клиенты целевой иерархии могут принадлежать одному из Primary Site серверов. В каждый Primary Site сервер мигрируют все клиенты из соответствующего ему Primary Site сервера второго уровня иерархии исходной иерархии и всех его дочерних сайтов.
Для создания пакета установки агента новой иерархии в исходной иерархии необходимо скопировать содержимое пакета установки агента из новой иерархии. Установку агента необходимо производить с ключом SMSSITECODE=XXX, где XXX код родительского Primary Site сервера данному клиенту. Это необходимо для осуществления привязки клиента к иерархии.
В случае если установка агента SCCM 2012 не произведена необходимо проверить лог ccmsetup.log на клиентской машине на предмет ошибок. Если данный лог не обнаружен на машине необходимо повторить попытку установки агента на неё, так как изначальная попытка установки агента не была предпринята (возможно компьютер был выключен).
7.5. Тестирование целевой иерархии и выведение из эксплуатации исходной иерархии
1. Миграция точек распространения контента осуществляется после завершения миграции клиентов. Для миграции точек распространения контента необходимо воспользоваться пунктом «Upgrade Distribution Point» (вкладка Migration, закладки Administration).
В случае если миграция невозможна (например нет места на сервере) необходимо удалить существующую роль SCCM исходной иерархии и установить роль SCCM целевой иерархии. Для снижения нагрузки на сеть возможно использование «Prestage Content» файла.
Необходимо удаление агента SCCM 2007 с данной точки распространения перед миграцией.
2. Удаление существующих Primary Site серверов иерархии SCCM 2007 и установка соответствующих ролей (Distribution Point, Secondary Site сервер) новой иерархии. Производится с помощью пункта «Create Site Systems Server» для точек распространения контента и «Create Secondary Site» для Secondary Site серверов.
3. Тестирование целевой иерархии: проверить репликацию данных между сайтами в иерархии, проверить здоровье точек управления клиентами и точек распространения контентом, проверить возможность подключения клиентов к каждой точке управления клиентами в иерархии, возможность отправления и приема данных клиентов. Проверить работоспособность разворачиваний и всех точек распространения данных в иерархии.
4. Вывод исходной иерархии из эксплуатации.
Ссылки:
Administrator Checklists for Migration Planning in System Center 2012 Configuration Manager
Introduction to Migration in System Center 2012 Configuration Manager
Install Sites and Create a Hierarchy for Configuration Manager
Planning for Configuration Manager Sites and Hierarchy
Supported Configurations for Configuration Manager
System Center 2012 – Configuration Manager Component Add-ons and Extensions (Tools)
Migrating from Configuration Manager 2007 to Microsoft System Center 2012 R2 Configuration Manager (Лаба)
ConfigMgr client automatic site assignment behavior in a multi site environment
Performing a side-by-side Migration from Configuration Manager 2007 (WindowsNoob)
System Center 2012 Configuration Manager Migration — Deep(ish) Dive Part 1 (troubleshooting)
System Center 2012 Configuration Manager Survival Guide
Дельные посты:
www.css-security.com/blog/sccm-2012-migration-made-easy-part-1
www.css-security.com/blog/sccm-2012-migration-made-easy-part-2
www.css-security.com/blog/sccm-2012-migration-made-easy-part-3
anoopcnair.com/2015/08/20/upgrading-from-sccm-2007-to-sccm-2012-with-adaptiva-onesite
activedirectory.ncsu.edu/services/sccm
