Главная System Center, Без рубрики, Новое ConfigMgr 2007 – идем в регионы!
  • ConfigMgr 2007 – идем в регионы!

    pict_filials По моему, большинство компаний которые так или иначе используют ConfigMgr имеют хотя бы один филиал. А раз есть филиал и скорее всего он не один, то появляется большое желание развернуть ConfigMgr и в филиалах. Желание понятно, теперь давайте рассмотрим какие же у нас есть варианты для его осуществления:

    • Primary site
    • Secondary site
    • Branch DP

    Primary Site

    Я не буду рассматривать установку Primary Site, она уже описана на сайте ITband.ru и в других источниках. Остановлюсь лишь на вариантах, когда не обойтись без Primary Site:

    • мы попадаем под ограничения по количеству поддерживаемых систем и поэтому не можем использовать Secondary Site. Подробнее: Configuration Manager Site Capacity Planning
    • создание Primary сайтов в «узловых» филиалах, для снижения нагрузки на оборудование и канал Центр – Филиалы.
    • в филиале уже существует развитая служба ИТ, полностью самостоятельная и управлять этим сайтом будет именно она;
    • сотрудники филиала должны иметь доступ к отчетам SCCM, причем выводится им должны только сведения по их филиалу (другой вариант – создание собственных отчетов, которые включают информацию только по конкретному филиалу, с фильтрацией на уровне SQL запросов);
    • когда нам нужно обеспечить непрерывность бизнеса, и ConfigMgr относится у нас к либо к самому набору бизнес-критикал приложений, либо к средствам обеспечения непрерывность этих приложений, и в случае выхода из строя Центра, филиалы должны продолжать функционировать.

    Из минусов данного подхода, пожалуй самым явным является вопрос цены. Primary Site требует для своей работы не только лицензии на ConfigMgr, но и экземпляра SQL Server. Кроме того, большое количество Primary сайтов усложняет администрирование, поскольку некоторые настройки (такие как настройки Client Agent, Inventory) определяются не для всей иерархии, а для Primary сайтов. Отсекайте лишнее и не плодите сущностей сверх меры.

    Branch DP

    Branch DP это не сайт и не сервер, это роль клиента. Использовать ее следует лишь в небольших филиалах, да и то, только в том случае, если в филиальной сети нет ни одной серверной ОС.

    Особенности Branch DP:

    • пакеты передаются не в сжатом формате, хотя и с использованием технологии BITS.
    • не работает PXE Point, таким образом, загрузка Boot Image пойдет только с PXE Share
    • Branch DP раздает пакеты клиентам только по протоколу SMB
    • Branch DP обеспечивает экономию только на трафике пакетов, весь остальной трафик (политики, инвентариация и проч) будет передаваться каждым клиентом самостоятельно без применения каких либо механизмов сжатия.

    Хотя естественно, если у вас нет серверной ОС, а предоставить сервис ConfigMgr необходимо, выходом будет именно использование Branch DP.

    Secondary site

    Что же нам остается для использования на филиалах? Конечно Secondary Site ConfigMgr. И так, что нам нужно для использования Secondary (вторичных) сайтов и какую пользу мы можем получить при их использовании?

    Во-первых нам не нужна база SQL, все данные будут заноситься в базу родительского сайта. Во-вторых нам не нужна лицензия на ConfigMgr Server, поскольку использование Secondary site бесплатно. А необходима нам всего лишь одна серверная ОС с достаточным местом для хранения пакетов. Естественно, есть и ограничения: нельзя ставить ConfigMgr на серверы терминалов и крайне не рекомендуется его устанавливать на контроллеры домена.

    Давайте на минуту отвлечемся от ConfigMgr и рассмотрим основные схемы построения иерархии Центр – Филиалы. Вероятнее всего, что для читателей этой статьи стержнем иерархии будет Active Directory. В различных организациях по разному подходили к процессу построения филиальной ИТ структуры с точки зрения AD. Я думаю, что можно выделить три глобальных подхода:

    Один домен – один лес Active Directory.

    В каждом филиале мы ставили по одному или несколько контроллеров домена, им назначали сайт AD и клиенты работали с единым пространством AD. С точки зрения установки Secondary Site ConfigMgr этот вариант не интересен в рамках статьи. Он прост и достаточно хорошо описан в соотвесвующей документации как официальной, так и документации сообщества.

    Несколько доменов – один лес Active Directory.

    Для филиала у нас выделяется отдельный дочерний домен или отдельное дерево, но лес AD, а соотвественно и его схема общая для всех филиалов. Для установки Secondary site это вариант чуть-более сложный чем установка сайтов в едином домене. Единственная видимая сложность – не забыть создать в каждом домене контейнер System\SystemManagement и дать на него соответствующие права необходимым пользователям\компьютерам. Естественно необходим корректно работающий DNS, но я надеюсь что он у вас и так работает 😉

    Несколько лесов AD, соединенных довериями.

    Каждый филиал сам себе лес AD и домен, со своей схемой и администраторами. Именно этот случай, как самый сложный и интересный с точки зрения установки ConfigMgr 2007 мы и рассмотрим сегодня.

    Внимание!

    Компания Microsoft не поддерживает работу вторичных сайтов в доверенных лесах. Автор не несет никакой ответсвенности за работоспособность данного решения. Часть описанных решений являются не рекомендуемыми официально, другая часть и вовсе являются не поддерживаемыми. Цель данной статьи не создать пошаговую инструкцию по установке Secondary Site Server, а показать способы и механизмы работы.

    Описание предоставлено ТОЛЬКО в учебных целях. Не пытайтесь повторить!

    Ну что ж, дисклаймер объявлен, ответственность снята, теперь можно переходить к делу J

    Я решил немного усложнить задачу, пусть на филиале у нас будут только два сервера и оба они являются контроллерами домена. Согласитесь, довольно распространенная схема в российских реалиях. Microsoft не рекомендует (но и не запрещает), устанавливать ConfigMgr Site Server на контроллеры домена. К сожалению реалии иногда отходят от рекомендаций.

    Для начала определимся с окружением:

    1. Центральный офис в домене\лесу: office.domain.ru. Уровень леса Native 2003. ОС: Windows Server 2003 R2 SP2
    2. Сервер SCCM2007 является Central Primary Site Server ConfigMgr 2007. FQDN: sccm2007.office.domain.ru (SITECODE = ABC), он управляет клиентами центрального офиса и к нему подключаются вторичные сайты в нашей структуре. Это отдельный сервер, не несущий больше никаких ролей. База данных SQL вынесена на отдельный SQL сервер.
    3. Филиал в домене\лесу: penza.domain. Уровень леса Native 2003. ОС: Windows Server 2003 R2 SP2
    4. В домене penza.domain существует только два сервера. Оба сервера являются контролерами домена. Сайт будет установлен на сервер PE_BK.penza.domain (SITECODE = PE0)
    5. Между лесами настроены транзитивные двухсторонние отношения доверия. Если вы не знаете, как настроить доверие, обратитесь к документации.
    6. Существует стабильный канал связи между центральным офисом и филиалом, пропускная способность которого равна 1 Мбит\сек. С 8:00 до 20:00 данный канал должен использоваться только для передачи данных пользователей. В остальное время ограничения на передачу данных по каналу нет.
    7. На фаерволах между центральным офисом и филиалом настоенно разрешение на пропуск трафика ConfigMgr. Список необходимых портов можно найти в документе Ports Used by Configuration Manager.
    8. Сайты будут работать в Mixed Mode.

    Мы можем установить Secondary Site ConfigMgr двумя способами: с помощью консоли администрирования ConfigMgr или с помощью установочного диска. Я предпочитаю первый вариант, поскольку он является более наглядным в плане задания настроек и требует передачи меньшего количества трафика. (150-350Мб для установки роли Secondary Site Server). Кроме того существует возможность автоматического развертывания Secondary Site, она описана в документе: Scripted Secondary Site Installation Example.

    Если вы планируете к передачи на филиальную distribution Point (DP) большое количество пакетов, то вам стоит обратить внимание на возможность offline копирования данных. Запишите сжатые файлы PCK (из каталогов SMSPKG) необходимых вам пакетов на DVD диски или винтчестер и отправьте с курьером или почтой. Естественно если у вас хороший канал связи и вы можете его загрузить для передачи трафика пакетов или если у вас малое количество пакетов, то вы можете воспользоваться штатным механизмом распространения пакетов по DP.

    И так, сжатые копии пакетов записаны на нескольких DVD дисках и с оказией отправлены в сторону филиала. Пока они путешествую в недрах Почты России мы должны установить на филиале Secondary Site Server и клиентов.

    Краткий план, того что нам необходимо сделать (я специально не буду описывать все моменты подробно, если вы самостоятельно не знаете как их сделать, не нужно пытаться повторить их):

    1. необходимо расширить схему леса AD на филиале. Для этого достаточно скопировать файл Extadsch.exe на КД филиала и запустить его там.

    extadsch

    1. В домене penza.domain создать учетную запись ConfigMgr_Admin и сделать ее членом группы Builtin\Administrators и DomainAdmins выбранного сервера (PE_BK).
    2. В домене office.domain.ru создать учетную запись ConfigMgr_Penza и добавить ее в члены локальных групп на сервере ConfigMgr: SCCM2007\SMS Admins, SCCM2007\SiteToSiteConnections. К этим же группам необходимо добавить учетную запись PENZA\PE_BK$, поскольку мы не можем указать через мастер установки вторичного сайта необходимую учетную запись (OFFICE\ConfigMgr_Penza). Это можно сделать позднее в свойствах соответствующего sender на центральном сайте.
    3. Кроме того необходимо добавить учетную запись PENZA\PE_BK$ в параметры безопасности (share+ntfs) \\SCCM2007\
      SMS_SITE.
    4. С помощью ADSI создать контейнер Penza\System\SystemManagement и убедиться, что у учетной записи PENZA\ConfigMgr_Admin есть необходимые права на контейнер.
    5. На сервере PE_BK необходимо убедиться, что для сетевого подключения прописаны DNS суффиксы: penza.domain и office.domain.ru и что имя sccm2007.office.domain.ru успешно разрешается в IP адрес.
    6. На сервере PE_BK должны быть установлены следующие компоненты:
      1. IIS (BITS+ASP+WebDAV);
      2. .net Framework 2.0 SP2;
      3. Для Windows Server 2003 должен быть установлен SP2 и следующие обновления: KB932303, KB942841, KB940848, KB936059.

    С приготовлениями покончено, пора переходить к установке 🙂

    Установка Secondary Site из консоли администрирования

    Из консоли администрирования центрального Primary Site (сервер SCCM2007) начинаем установку нового вторичного сайта, при этом указываем соответсвующие учетные записи и настройки. Для этого в консоли администрирования выбираем: Site Database – Site Management – Primary Site -> New Secondary Site. Вводим имя нового сайта и его код (PE0 – [PE0 Penza Secondary Site])

    wizard_install_secondary_site_1

    Указываем короткое имя сервера и папку для установки (PE_BK, G:\ConfigMgr). Естественно диск G: должен быть на сервере.

    wizard_install_secondary_site_2

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

    wizard_install_secondary_site_3

    Выбираем создание нового адреса для сайта.

    wizard_install_secondary_site_4

    В параметрах нового адреса указываем FQDN имя сервера PE_BK, а так же данные учетной записи PENZA\ConfigMgr_Admin

    wizard_install_secondary_site_5

    Задаем параметры родительского сайта для вторичного сервера.

    wizard_install_secondary_site_6

    Проверяем Summary и начинаем установку.

    Нам необходимо проконтролировать отправку файлов установки на сервер PE_BK. Для этого мы смотрим на сервере SCCM2007 журнал sender.log. В котором мы должны фиксировать успешные отправки пакетов для сервера PE_BK. Если нам необходимо каким-либо образом ограничить полосу пропускания для трафика ConfigMgr, то сделать это можно в свойствах адреса для соответствующего сайта. Например таким образом:

    Несколько слов, о том как работает данный режим. ConfigMgr не пытается как-либо ограничить саму полосу пропускания трафика. SCCM работает в пульсирующем режиме и при необходимости отправляет «холостые» пакеты. Рассмотрим пример. Пусть мы передаем за одну минуту 500Кб. Rate limit = 50%. Таким образом каждые 6 секунд сервер ConfigMgr будет посылать пакет данных. При этом в первые 6 секунду пакет данных будет иметь 0 байт данных, а в 12 секунду уже 50 кбайт. И такой цикл будет продолжаться до тех пор, пока либо не будут переданы все необходимые данные, либо не изменится значение параметра Rate Limit.

    Если мы видим по логу sender.log что данные нормально отправляются на сервер PE_BK, нам остается запустить терпением и подождать пока файлы установки скопируются на сервер. Они копируются в файл SMS_BOOTSTRAP.PKG и его размер может быть в диапазоне 150-350Мб.

    sender log

    Чаще всего началу копирования файлов мешают следующие вещи:

    1. ошибки доступа. Центральный сайт не имеет административных полномочий для записи в \\secondary\Admin$;
    2. ошибки DNS. С сервера вторичного сайта невозможно разрешить короткое имя первичного сайта или наоборот;
    3. закрытые порты или часть портов на фаерволах;
    4. проблемы авторизации на серверах, неверно заданные учетные данные, ресинхронизация времени;
    5. нехватка места на сервере вторичного сайта.

    После того, как все необходимые файлы будут скопированы, пакет SMS_BOOTSTRAP.PKG будет распакован во временную папку на диске установки ConfigMgr. Кроме того в корне этого диска к файлу SMS_BOOTSTRAP.PKG добавится файл настроек установки SMS_BOOTSTAP.INI, файл службы установки SMS_BOOTSTAP.EXE и файл лога установки SMS_BOOTSTAP.LOG

    Если установка прошла успешно, в логе SMS_BOOTSTAP.LOG будет содержаться всего одна фраза: SMS_BOOTSTRAP stopped. Если установка окончилась ошибкой, данный файл будет содержать всю информацию о ходе установки до момента ошибки. Обращаю ваше внимание на то, что статус сайта в консоли администрирования ConfigMgr после работы SMS_BOOTSTAP будет все еще pending. Происходит это из-за невозможности автоматического обмена ключами между первичным и вторичным сайтом. Необходимо произвести обмен ключами в ручном режиме. Для воспользуемся средством preinst (каталог установки %ConfigMgr%\bin\i386\00000409\preinst.exe), чтобы запросить ключи шифрования и вручную обменять два сайта ключами.

    Для этого на Central Primary Site (сервер SCCM2007)выполняем команду

    preinst /keyforchild

    keyforchild

    Полученный файл ABC.CT5 необходимо вручную скопировать на сервер PE_BK и подложить его в папку G:\ConfigMgr\inbox\hman.box (Внимание! Именно в hman, а не в hman.box\pubkey).

    На сервере Secondary Site (PE_BK)выполняем команду

    preinst /keyforparent

    keyforparent

    Полученный CT4 файл необходимо вручную подложить в папку inbox\hman.box сервера SCCM2007.

    Если обмен ключами был произведен правильно и остальные настройки произведены верно, состояние вторичного сайта в консоли администрирования ConfigMgr изменится с Pending на Active в течение 5-10 минут. Контролировать применились ключи или нет можно по логу despoler.log

    После этого я рекомендую «толкнуть» с центрального сайта синхронизацию с вновь созданным вторичным сайтом.

    preinst /syncchild PE0

    syncchild

    Затем нам необходимо выполнить еще ряд действий:

    • Проверить состояние статусов для центрального и вторичного сайта. В консоли администрирования перейти к разделу Site Status.
    • Для Secondary Site задать границы.
    • В свойствах Site Database – Site Management – Site Settings – Primary Site – [PE0 – Penza Secondary Site] – Site Systems – PE_BK произвести настройку ConfigMgr Distribution Point, указав для нее созданную границу, проверив, что для сервера задано FQDN имя, а сама DP настроена на ответ клиента
    • Настроить необходимые нам Discovery Methods.

    Копирование пакетов

    Secondary Site установлен успешно и теперь пришло время назначить на него все необходимые для работы пакеты. Простой вариант – распространения пакетов через консоль администрирования не интересен как раз за счет своей простоты, мы же воспользуемся более сложным вариантом. В самом начале статьи мы записали сжатые копии файлов пакетов (X:\SMSPKG на Primary Site Server) и отправили их почтой или курьером на филиал. Предположим что диск со сжатыми копиями не потерялся в недрах Почты России и даже был доставлен на филиал в срок. И так, у нас есть DVD-диск с файлами вида: ABCxxxxx.PCK (код нашего Primary Site = ABC).

    Один пакет назначить через консоль администрирования все же придется. При этом он может быть самым маленьким по размеру, для нас важен факт создания необходимых служебных папок (SMSPKG, SMSPGKx) на вторичном сервере . После того как мы назначили распространение пакета на филиальную DP, пакет передается через сеть и на вторичном сервере создается необходимая структура папок. Сейчас нас интересует папка X:\SMSPKG (x: – диск указанный в свойствах DP, либо же диск с самым большим свободным дисковым пространством). В данную папку необходимо произвести копирование всех файлов PCK переданных на филиал с помощью DVD диска или винтчестера.

    Кроме того для работы нам понадобиться комплект SMS 2003 Toolkit v2 или ConfigMgr 2007 Toolkit v2, а точнее средство PreloadPkgOnSite с помощью которого в базу данных первичного сайта будет добавлена информация о восстановленных пакетах. Синтаксис использования довольно прост:

    PreloadPkgOnSite.exe ABCxxxxx

    preload_configmgr2007_2

    Новая версия PreloadPkgOnSite из поставки ConfigMgr 2007 Toolkit v2 запрашивает подтверждение при ряде действий, поэтому для «скриптовая» я могу посоветовать использовать более старую версию PreloadPkgOnSite из поставки SMS 2003 Toolkit v2.

    Если мы откроем лог distmgr.log то нам должны отобразиться шаги по добавлению пакета.

    preload_log

    После этого, в консоли администрирования центрального сайта, мы можем назначить этот пакет на распространение на DP вторичного сайта. И в логе sender.log центрального сайта убедиться, что на вторичный сайт отправляется не весь пакет, а только частичная служебная информация.

    preload_sender_log

     

    Установка клиентов

    Возможные варианты установки клиентов очень хорошо описаны в статье «Развертывание клиентов SCCM 2007» на нашем сайте, поэтому я не буду заострять на этом внимание. Единственное о чем вам необходимо помнить, это о том, что в данный момент у вас не будет работать автоматическое обнаружение клиентами сайта ConfigMgr.

    Методы обнаружения сайта клиентами

    Для полноценной работы клиента ConfigMgr необходимо, чтобы клиент мог найти сайт, в границах которого он находится, мог найти обслуживающую его Management Point и ближайщую к нему Distribution Point. Если бы мы устанавливали Primary Site Server, то проблем в общем случае нет:

    1. Схема Active Directory расширена
    2. Создан контейнер System\SystemManagement
    3. В нем есть записи о ConfigMgr Primary Site
    4. Клиент их автоматически обнаруживает
    5. PROFIT!!!

    Иным образом дело обстоит с вторичными сайтами, да еще и в доверенных лесах. Естественно, что при таком сценарии у нас не будет работать автообнаружение с помощью Active Directory. Но существуют иные варианты обнаружения клиентом информации о сайте:

    Ручное задание параметра клиента (MP, SLP) при установке клиента.

    + Мы четко знаем на какие MP\SLP настроен клиент

    + Простота работы, главное не ошибиться с FQDN именем при установке клиента

    – Если мы хотим чтото поменять, нам нужно инициировать переустановку клиента либо изменять параметры реестра.

    regedit

    regedit2

    Пример скрипта установки:

    \\sccm2007\sms_abc\client\ccmsetup.exe /logon SMSCACHESIZE=2048 SMSSITECODE=AUTO FSP=SCCM2007.OFFICE.DOAMIN.RU CCMLOGMAXSIZE=512000 CCMLOGMAXHISTORY=1 SMSMP= SCCM2007.OFFICE.DOAMIN.RU SMSSLP= SCCM2007.OFFICE.DOAMIN.RU

    Подробнее см. About Configuration Manager Client Installation Properties.

    Использование WINS для поиска клиентом информации о сайт серверах

    + Автоматическое обнаружение

    – Нужна установленная и работающая служба WINS

    – На клиента должен быть задан адрес WINS сервера

    Пример настройки WINS:


    Подробнее см. How to Manually Add Configuration Manager Site Information to WINS

    Использование локального файла LMHOST для определения информации о клиенте

    + Обрабатывается в первую очередь

    – Ручное задание настроек для каждого файла

    – Сложности с изменением настроек

    – «Не явный» подход – другой администратор может и не знать о файле LMHOST

    -Обработка файла LMHOST может быть выключена на клиенте.

    Пример настроенного файла LMHOST:

    192.168.0.14 SCCM2007 #PRE

    192.168.0.14 "SMS_SLP x1A" #PRE

    192.168.0.14 "MP_ABC x1A" #PRE

    Подробнее см. NetBIOS Suffixes (16th Character of the NetBIOS Name)

    Все вышеперечисленные варианты являются вполне работоспособными. Но существует еще один не документированный и не поддерживаемый вариант: модифицировать Active Directory для автообнаружения центрального сервера J

    Редактирование AD

    Если вы установили Secondary site правильно, то в Active Directory Users & Computers внутри контейнера System\System Management вы обнаружите запись CN=SMS-Site-PE0 класс mSSMSSite.

    Если мы хотим, чтобы у нас заработало автообнаружение клиентами сайта ConfigMgr с помощью Active Directory нам понадобиться немного ADSI магии.

    Не стоит топтаться грязными кованными сапогами по трепетному сердцу Active Directory!!!

    И так, для нормальной работы автообнаружения нам нужно дополнить Active Directory двумя записями определяющими параметры SLP и MP. Для этого необходимо воспользоваться ADSI.

    В оснастке ADSI переходим к разделу DC=penza, DC=local -> CN = System -> CN = System Management -> New –> Object

    Вначале создадим запись о Management Point. Для этого выбираем класс объекта mSSMSManagementPoint

    После создания записи, необходимо переопределить значение следующих атрибутов:

    Cn SMS-MP-ABC-SCCM2007
    dNSHostName FQDN Primary Site Server MP
    mSSMSDefualtMP True
    mSSMSDeviceManagementPoint True
    mSSMSMPName SCCM2007
    mSSMSSiteCode ABC
    mSSMSVersion 6487
    Name SMS-MP-ABC-SCCM2007

    adsi

    adsi2

    adsi3

    adsi4

    Теперь создаем объект класса mSSMSServerLocatorPoint и после создания переопределяем следующие атрибуты:

    Cn SMS-SLP-ABC-SCCM2007
    mSSMSMPName SCCM2007.OFFICE.DOMAIN.RU
    mSSMSSiteCode ABC
    Name SMS-SLP-ABC-SCCM2007

    Теперь необходимо проверить работу автообнаружения на клиенте. Для этого открываем лог LocacationService.log, а так же консоль управления клиентом ConfigMgr на клиенте (Пуск-Панель управления-Configuration Manager – Advanced) и нажимаем кнопку Discover. Если мы все сделали правильно, то отобразится окно успешного обнаружения клиентом сайта.

    Тестирование работы

    Вне зависимости от способа обнаружения клиентом серверов сайта, после установки и настройки всех параметров не лишним будет провести простой тест на работоспособность клиентов. Для этого создайте новый тестовый пакет и программу: APP Test. В пакете должен содержаться только один файл: test.cmd. В котором будет находиться следующая команда:

    ping 127.0.0.1 > null

    Отправьте данный файл на все DP которые обслуживают клиентов, которых мы хотим проверить, а программу объявите (advertisement) для коллекции компьютеров, работу которых вы хотите проверить. Не забудьте указать Mandatory Time: AS SOON AS, с которого будет выполнятся программа. Кроме того рекомендую для этой программы включить режим подавления сообщений пользователю о доступности программы (Suppress).

    Проверяйте работу программы по отчету :

    Report Name: Status of a specific advertisement
    Category: Software Distribution – Advertisement Status

    Данное тестовое приложение позволяет проверить:

    • Работу DP, в плане получения пакетов программ от центрального сайта
    • Работу DP и клиента, в плане передачи пакета на клиента
    • Работу MP
    • Работу клиента

    Пожалуй это самое простой и быстрый способ проверить работоспособность клиентов.

    Теперь на выходе мы имеем полностью настроенный и работоспобный вторичный (secondary) сайт ConfigMgr

    Алексей Тараненко

Комментарии

  1. Алекей, огромное спасибо за такую монументальную статью, по такому своеобразному продукту. Я обучался на курсах по нему, но здесь описано даже то чего там не говорили 🙂

    Ждем продолжений!

  2. Алексей, как всегда хорошая статья.
    К сожаленью в нашей действительности есть еще один фактор определения Primary/Secondary – желание вышестоящих боссов.

  3. Спасибо. Рад что понравилось 🙂

  4. Отличная статья.

  5. ОГРОМНОЕ СПАСИБО!
    Сдал экзамен со SCCM2007 (чесно без тесткингов), но с этим бы разбирался долго… а мне как раз предстоит!!!

  6. Изначально воспользовался вашей статьей при развертывании секондари сайта в одном из отдаленных офисов, там нет домен-контроллера, но вот во втором пришлось попотеть, т.к. устанавливал на DC и сразу нарвался на недочеты в статье – на домен контроллере нет локальных групп, есть локальные доменные группы, их нужно ручками создавать, SMS_SiteToSiteConnection_ и SMS_SiteSystemToSiteServerConnection_ иначе фейл. Кстати, на RODC еще интереснее развертывание SCCM, но зато такая конфигурация поддерживается майкрософт. В целом очень неплохо и я уже 3й раз обращаюсь к вашей статье. Спасибо.

  7. Насколько я помню, группы SMS_SiteToSiteConnection_ и SMS_SiteSystemToSiteServerConnection_ создаются только на первичных серверах. На вторичных этих групп нет. Соответсвенно и задавать их там нет необходимости.
    По поводу RODC ссылкой не поделитесь? Не видел если честно, что SCCM можно ставить нак RODC.

    Я рад, что статья кому-то пригодилась 🙂

  8. 3.Кроме того необходимо добавить учетную запись PENZAPE_BK$ в параметры безопасности (share+ntfs) \SCCM2007
    SMS_SITE.

    Можно поитересоваться, зачем, ведь группа SMS_SiteToSiteConnection_XYZ в которую добавляли PENZAPE_BK$ уже присутствует в правах на эти ресурсы.

  9. Да, действительно присутсвует. Но не работает. Если у вас есть проверенная практикой информация, что добавлять учетную запись компьютера туда не нужно – значит минус один шаг 🙂 Но повторюсь, в тестлабе к сожалению не заработало без явного разрещения.

  10. SMS_SiteToSiteConnection_XYZ дает необходимые права для доступа к сетевому ресурсу SMS_SITE. Это работает. Выдавать права в явном виде для PENZAPE_BK$ не требуется. При нормальной конфигурации сопутствующих сервисов.
    Обычно делается доменная группа SMS_SiteToSiteConnection, в которую включаются все учетные записи серверов ConfigMgr. Через членство в этой группе раздаются права на сетевые ресурсы, доступ к контейнерам в AD, членство в группе SiteToSiteConnection_XYZ.

    Только необходимо не забывать перегружать сервер, учетную запись которого включили в группу SMS_SiteToSiteConnection, чтобы обновился security token.

  11. Дмитрий!
    Я чуть выше говорил что согласен с тем что работать должно, но у меня не работало. Вполне допускаю что это была проблема именно стенда.

    Да и про общую группу для серверов вы верно сказали, одно дополнение если перезагрузка сервера не возможна (а для Secondary Site, который совмещается с другой ролью это не такое уж и редкое явление), придется задавать права на отдельные учетные записи объектов-компьютеров, в таком варианте перезагрузка не нужна.

    PS: Я очень рад что из всей статьи всплыл только вопрос с выдачей ( дублированием) прав. 🙂

  12. Алексей. У меня вопрос такого плана. В разных лесах/доменах существуют компьютеры с одинаковыми именами, ну типа pc-01.domain1 и pc-01.domain2. По видимому, в коллекции они группируются по имени и отображаются как одна запись. Как с такой ситуацией бороться не представляю…

  13. Честно говоря специально не эмулировал такую ситуацию, продакттим в лице Wally http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/f461053b-a96c-4c84-ac94-abcc56f3ea1d/ говорит что такое не возможно.

  14. Огромный респект, за столь ценный мануал!