Давно “мечтал” написать на эту тему, все лень было… Запаситесь печеньками, это надолго 😉 Тут может быть какое-то количество ошибок - сообщите мне если обнаружите их, пожалуйста. Трудно вычитать ~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 сервера.

7. Приблизительный процесс миграции

Миграция происходит поэтапно. Переходить к следующему этапу миграции можно только после полного завершения предыдущего этапа. В случае отказа целевой иерархии возможен безболезненный возврат ИТ инфраструктуры на исходную иерархию, так как миграция не предполагает внесения каких-либо изменений препятствующих функционированию исходной иерархии (до этапа миграции клиентов).

На первом этапе миграции необходимо создать целевую иерархию SCCM параллельно с существующей иерархией.

Второй этап заключается в подготовка иерархий и сборе информации об исходной иерархии.

На третьем этапе происходит миграция объектов SCCM.

На четвертом этапе происходит миграция клиентов SCCM.

Пятым этапом является тестирование целевой иерархии и выведение из эксплуатации исходной иерархии.

7.1. Развертывание иерархии SCCM 2012

1. Подготовка аппаратной платформы для установки серверов иерархии.

1. Установка или разворачивание операционной системы и обновлений.

2. Установка сервера баз данных.

3. Установка ПО необходимого для полноценного функционирования CAS сервера.

4. Установка CAS сервера.

В процессе установки необходимо будет указать языки, которые должны быть поддерживаемы иерархией SCCM, сервер баз данных (аккаунт от имени которого происходит установка CAS сервера должен обладать соответствующими правами для доступа к серверу баз данных, кроме того, на сервере баз данных должен быть включен доступ по TCIIP), необходимо указать код сайта CAS сервера. Можно использовать любой дистрибутив, так как возможность ввода лицензии после установки сервера – предусмотрена.

1. Проверка работоспособности CAS сервера: проверить здоровье компонентов CAS сервера (панель Monitoring, закладка «Site Status» и «Component Status»), проверка работоспособности консоли.

2.  Подготовка второго сервера для установки первого Primary Site сервера (повторение шагов 2-4).

3. Установка Primary Site сервера.

В процессе установки необходимо указать сервер баз данных (аккаунт от имени которого происходит установка сервера должен обладать соответствующими правами для доступа к серверу баз данных, кроме того, на сервере баз данных должен быть включен доступ по TCIIP), код сайта и указать сервер, который будет родительским данному Primary Site серверу, то есть CAS сервер новой иерархии. Для установки Primary Site сервера используется тот же дистрибутив что и для установки CAS сервера.

1. Проверка работоспособности 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»), проверить возможность подключения клиентов к каждой точке управления клиентами в иерархии, возможность отправления и приема данных клиентов.

2. Установка всех остальных Primary site серверов в иерархии (повторение шагов 8 и 9).

3. Проверка работоспособности иерархии SCCM 2012: проверить здоровье компонентов всех серверов иерархии (панель Monitoring, закладка «Site Status» и «Component Status»), проверить репликацию данных в иерархии (панель Monitoring, закладка «Site Hierarchy»), кроме того возможно осуществить проверку с помощью просмотра лог файлов на каждом конкретном сервере.

4. Установка необходимых дополнительных ролей на сервера иерархии и настроек (способы обнаружения клиентов, клиентские политики, «push» установка клиентов и так далее)

5. Настройка прав доступа пользователей к иерархии и настройка «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 сервера – могут быть мигрированы). Таким образом, выбор объектов для миграции и готовность целевой иерархии к обслуживанию клиентов определяется потребностями организации.

1. Для миграции всех объектов необходимо последовательно создавать работы миграции (пункт 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.

1. После завершения миграции всех объектов необходимо проверить успешность репликации и наличие всех объектов SCCM на всех серверах в иерархии с помощью консоли SCCM 2012.

2. Необходимо произвести настройку «Boundary Group» для распространения контента, после миграции всех «Boundaries» необходимо воспользоваться пунктом «Boundary Groups» (вкладка Hierarchy Configuration, закладки Administration).

3. Создание «Prestage Content» файла для дальнейшего распространения его сторонними механизмами (не механизмами SCCM). Для создания данного файла необходимо перейти в закладку «Software Library» и выбрать необходимые пакеты, после чего воспользоваться командой «Create Prestage Content File».

4. Развернуть «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 с данной точки распространения перед миграцией.

1. Удаление существующих Primary Site серверов иерархии SCCM 2007 и установка соответствующих ролей (Distribution Point, Secondary Site сервер) новой иерархии. Производится с помощью пункта «Create Site Systems Server» для точек распространения контента и «Create Secondary Site» для Secondary Site серверов.

2. Тестирование целевой иерархии: проверить репликацию данных между сайтами в иерархии, проверить здоровье точек управления клиентами и точек распространения контентом, проверить возможность подключения клиентов к каждой точке управления клиентами в иерархии, возможность отправления и приема данных клиентов. Проверить работоспособность разворачиваний и всех точек распространения данных в иерархии.

3. Вывод исходной иерархии из эксплуатации.

Ссылки:

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

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

Дельные посты:

http://www.css-security.com/blog/sccm-2012-migration-made-easy-part-1/

http://www.css-security.com/blog/sccm-2012-migration-made-easy-part-2/

http://www.css-security.com/blog/sccm-2012-migration-made-easy-part-3/

http://anoopcnair.com/2015/08/20/upgrading-from-sccm-2007-to-sccm-2012-with-adaptiva-onesite/

https://activedirectory.ncsu.edu/services/sccm/