В первой части мы подготовили сервер к установке ролей System Center 2012 Configuration Manager и приступаем к установке Central Administration Site и Primary Site.

Установка простая, открываем папку с нашим распакованным ISO образом.

scr-00014

Запускаем splash.hta

scr-00015

Запускаем Install, затем Next и выбираем Install a Configuration Manager central administration site. Во второй части, когда будем устанавливать Primary Site, надо будет выбрать Install a Configuration Manager primary site.

scr-00016

Вводим лицензионный ключи или оставляем ознакомительную версию на 180 дней. Next.

Принимаем пользовательское соглашение для SCCM 2012. Next. Принимаем соглашение для SQL и Silverlight.

Выбираем папку для скачивания необходимых файлов для установки.

scr-00017

В следующих окнах выбираем нужные нам языки. Затем вводим код сайта и имя нашего CAS-сервера.

scr-00023

Имя сервера и базы данных. Next.

scr-00018

Если мы хотим установить SMS Provider оставляем значение и нажимаем next.

Доходим до Prerequisite Check, если ошибок нет, то продолжаем установку.

scr-00024

Во время установки можно открыть файл C:\ConfigMgrSetup.log и мониторить процесс установки на наличие ошибок.

scr-00000

Ждем примерно полчаса и смотрим на успешный результат установки.

scr-00022

Перезагружаем сервер и запускаем консоль System Center 2012 Configuration Manager’a.

scr-00001

Установка Primary Site.

Все шаги установки проходить не будет, остановим внимание на пару из них. Первым делом, после того как нажмем Install выбираем Install a Configuration Manager primary site.

msr-00002

Далее все как в статье, на шаге Site and Installion Settings вводим другой код сайта, например PRM.

scr-00003

На экране Primary Site Installation в поле Join the primary site to an existing hierarchy вводим FQDN нашего CAS сервера.

На Primary Site на шаге Site System Role, Management Point и Distribution Point устанавливаем на наш Primary Site.

scr-00007

Дожидаемся успешной установки, перезагружаем сервер и заходим в консоль Configuration Manager’a в MonitoringSite Heirarchy.

scr-weeeew

15 КОММЕНТАРИИ

  1. В заголовке пишите что это RTM, так как готовый продукт СИЛЬНО отличается от кандидата!

    • ну RTM как бы и есть финальный релиз — «Release To Manufacturing».
      «Финальная версия» продукта и «RTM-версия» — синонимы.

  2. Я ставлю CAS на один сервер: SCCM-CAS
    Primary Site на второй сервер: SCCM-PR1
    При такой конфигурации нужно устанавливать на каждый сервер по экземпляру MS SQL Server или достаточно поставить только на SCCM-CAS? И можно ли использовать MS SQL Express?

    • у каждого сайта своя база данных, можно держать базу локальною
      sql express только для вторичных сайтов.
      вообще стоит задуваться, а нужен ли вам вообще CAS? у вас более 100 000 клиентов?

    • Нет, не больше 100 000, но у нас есть филиалы по всей стране, в которые я планирую сделать PR2, PR3 и т.д., а CAS и PR1 останутся в основоном ЦОДе

    • Наверное надо написать большой пост про архитектуру и планирование SCCM.
      Смотрите, CAS это ваша точка отказа вместе с его базой данных + он не обслуживает клиентов, основная его задача собрать данные, если уж совсем грубо + таких точек отказа будет еще на каждом первичном сайте. Кроме этого, sql репликация через sql broker — это боль, честно.
      Последний проект на 300 офисов от Калиниграда до Владивостока, более 15к клиентов обслуживается один первичный сайт в ЦОДе, вторичные (не везде) в регионах, остальное покрытие DP и где совсем все плохо с каналами, то pull-dp. В этом случае у вас одна точка отказа — это первичный сайт. Даже если у вас поломается и умрет вторичка, это не страшно, вы просто ее восстановите из первичного сайта.

    • Пост было бы не плохо такой почитать на примере того же проекта с 15000 пользователями. В нашем случае около 7000 пользователей будет.
      Получается в моём случае лкчше всего разворачивать PRI в ЦОДе, а если потребуется в филиалах — там поставить вторичные сайты и на них повесить роли DP?

      Я сначала подумал, что CAS нужен для того, чтобы рулить всей инфраструктурой с одного места, а первичные сайты для общения с клиентами, а вторичные для общения с клиентами, до которых плохое соединение.

    • В любом случае надо ТЗ, я не знаю вашей инфраструктуры и тех требований, которые вы выдвигаете к будущей Системе.
      Но вот так сразу: да, CAS не нужен. На КАСе вы будете видеть все данные, которые приходят с первичных сайтов + вы управляете конфигурацией сайтов и репликацией, на нем нет точки управления или точек распространения.
      CAS вообще поддерживает только:
      Asset Intelligence synchronization point
      Certificate registration point
      Endpoint Protection point
      Reporting services point
      Software update point
      System Health Validator point
      Windows Intune connector

  3. Почему-то не опубликовался комментарий. Дублирую:

    Развернул сервер SCCM-PR1 (Primary Site 1). Один в инфраструктуре. Но в логах сыпятся ошибки: Диспетчер управления точкой управления обнаружил, что точка управления не отвечает на HTTP-запросы. Ошибка HTTP: 2147500037.
    При установке SCCM указал использовать https

    Сертификат был выдан центром сертификации в домене, когда заходишь на https://sccm-pr1.domain.local через браузер и на https://sccm-pr1 не ругается на сертификат.

    То, что рекомендует сделать MS не помогает:
    http://prntscr.com/7935pb
    Перезапускал и сами службы и весь сервер.

    Что такое может быть?

  4. Антон, вопрос по архитектуре.
    Не совсем понимаю предназначение видов сайтов. Если можно на примере поправьте. У нас сеть относительно небольшая ~ 2000. Центральный сайт ~600 машин, остальные филиалы по ~ 100-300 машин. Как я понимаю мне надо развернуть CAS и Primary в центре, и Primary в каждом филиале. Или Primary в центре и Secondary в каждом сайте.?
    По первой пока рассчитываю внедрять только в центре, потому как с наличием железа есть вопросы.

    • CAS не надо вам, еще раз повторю CAS нужен если у вас более 100 тысяч клиентов, если у вас географически распределенная площадка, и если вам надо более одного первичного сайта. Под распределенной площадкой я подразумеваю, что клиенты находятся у вас в разных странах и подчиняются, например разным IT департаментам. CAS ну оооочень для больших инфраструктур нужен.
      Теперь, что касается вас. Нет ничего лучше, чем тех задание, т.к. по двум строчкам не распишешь, но если кратко, то в центральном офисе вы поднимаете Первичный сайт, (базу данных естественно на отдельную машину), дальше все зависит от каналов связи. На одном из проектов, я совместно с сетевиками заказчика, обнявщись циско праймом, мониторил нагрузку на сетевые каналы, и вот уже по результатам исследований решали, где будут жить вторичные сайты (т.к. там кол-во клиентов было большое и текущие каналы просто ложились под запросами политик, данных инвентаризации и т.д.), а где просто будут жить точки распространения.
      Лучше будет, если вы более подробно распишите про свою инфраструктуру, тогда можно будет все расписать.
      Самый дешевый вариант это ставить точки распространения в регионах на пользовательские машины (win7, 8), это поддерживается, а с branch cache еще и траффик будет экономить, но в этом случае вы теряете pxe загрузки и данные клиентов все равно будут уходить в центральный офис.
      Мы можем поступить двумя способами. Написать мне на почту anton [at] masyan.ru, расписав инфраструктуру или на корпоративный адрес. Во втором случае, мы можем привлечь инженеров rupts (microsoft partner technical support) и совместно с ними просчитать все нюансы. Вверху сайта есть форма контактов, можно туда написать.

  5. Добрый день. Столкнулся с глобальной проблемой. Пошел по пути Stand-Alone Primary site, все уже настроено и функционирует в продуктивной среде. Появилась необходимость поднять еще один Stand-Alone Primary site в удалённом филиале. Подскажите, есть шанс мой Primary site головного офиса включить в CAS?

Добавить комментарий