В первой части мы подготовили сервер к установке ролей System Center 2012 Configuration Manager и приступаем к установке Central Administration Site и Primary Site.
Установка простая, открываем папку с нашим распакованным ISO образом.
Запускаем splash.hta
Запускаем Install, затем Next и выбираем Install a Configuration Manager central administration site. Во второй части, когда будем устанавливать Primary Site, надо будет выбрать Install a Configuration Manager primary site.
Вводим лицензионный ключи или оставляем ознакомительную версию на 180 дней. Next.
Принимаем пользовательское соглашение для SCCM 2012. Next. Принимаем соглашение для SQL и Silverlight.
Выбираем папку для скачивания необходимых файлов для установки.
В следующих окнах выбираем нужные нам языки. Затем вводим код сайта и имя нашего CAS-сервера.
Имя сервера и базы данных. Next.
Если мы хотим установить SMS Provider оставляем значение и нажимаем next.
Доходим до Prerequisite Check, если ошибок нет, то продолжаем установку.
Во время установки можно открыть файл C:\ConfigMgrSetup.log и мониторить процесс установки на наличие ошибок.
Ждем примерно полчаса и смотрим на успешный результат установки.
Перезагружаем сервер и запускаем консоль System Center 2012 Configuration Manager’a.
Установка Primary Site.
Все шаги установки проходить не будет, остановим внимание на пару из них. Первым делом, после того как нажмем Install выбираем Install a Configuration Manager primary site.
Далее все как в статье, на шаге Site and Installion Settings вводим другой код сайта, например PRM.
На экране Primary Site Installation в поле Join the primary site to an existing hierarchy вводим FQDN нашего CAS сервера.
На Primary Site на шаге Site System Role, Management Point и Distribution Point устанавливаем на наш Primary Site.
Дожидаемся успешной установки, перезагружаем сервер и заходим в консоль Configuration Manager’a в Monitoring — Site Heirarchy.
В заголовке пишите что это RTM, так как готовый продукт СИЛЬНО отличается от кандидата!
ну RTM как бы и есть финальный релиз — «Release To Manufacturing».
«Финальная версия» продукта и «RTM-версия» — синонимы.
Проблема в том, что вы рассмотрели последнюю RC версию.
Я ставлю 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
Почему-то не опубликовался комментарий. Дублирую:
Развернул сервер SCCM-PR1 (Primary Site 1). Один в инфраструктуре. Но в логах сыпятся ошибки: Диспетчер управления точкой управления обнаружил, что точка управления не отвечает на HTTP-запросы. Ошибка HTTP: 2147500037.
При установке SCCM указал использовать https
Сертификат был выдан центром сертификации в домене, когда заходишь на https://sccm-pr1.domain.local через браузер и на https://sccm-pr1 не ругается на сертификат.
То, что рекомендует сделать MS не помогает:
http://prntscr.com/7935pb
Перезапускал и сами службы и весь сервер.
Что такое может быть?
ну перед тем как включать https на точке управления надо выполнить ряд требований, почитайте:
http://wibier.me/https-communication-sccm-2012-sp1-part-1/ здесь 3 части
официальная дока — https://technet.microsoft.com/en-us/library/gg682023.aspx
http://blogs.technet.com/b/configmgrdogs/archive/2015/01/22/configmgr-2012-r2-certificate-requirements-and-https-configuration.aspx
и зачем переводить на https я не очень понимаю, лишние накладные расходы и траблшутинг.
Антон, вопрос по архитектуре.
Не совсем понимаю предназначение видов сайтов. Если можно на примере поправьте. У нас сеть относительно небольшая ~ 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) и совместно с ними просчитать все нюансы. Вверху сайта есть форма контактов, можно туда написать.
Антон спасибо за ответ!
Отписался в почту.
Добрый день. Столкнулся с глобальной проблемой. Пошел по пути Stand-Alone Primary site, все уже настроено и функционирует в продуктивной среде. Появилась необходимость поднять еще один Stand-Alone Primary site в удалённом филиале. Подскажите, есть шанс мой Primary site головного офиса включить в CAS?
Primary Site – Управляет вашими клиентами и как сказано в документации “in well-connected networks”, давайте переведем как “с нормальным, таким, сетевым соединением”. Собственно, в небольших типовых конфигурациях имеет смысл использовать только его, если вы планируете разветвленную структуру с офисами в разных городах, то в главном офисе разворачиваем CAS, в регионах Primary Site.
Поправь описание в первой части, а то из него выходит что если есть филиалы то обязательно нужен кас.