Boundaries and Boundary Groups. Границы и группы границ.

Итак, что же такое Boundaries и Boundary Groups. Границы нужны нам для того, чтобы связать определенные диапазоны клиентов с определенными сайтами. Группы границ же нужны для того, чтобы связать эти самые диапазоны с определенным сайтом и задать для них, например, Distribution Point.

В принципе, все просто, но изначально какая-то путаница в голове. Вам, наверное, будет проще, если объяснить все это на примере Сайтов в Active Directory. Для чего у нас служат сайты в Active Directory? Чтобы разграничить группы узлов, между которыми есть узкий канал.

Например, у нас есть головной офис, в котором 400 клиентских машин, объединенных 100 Мегабитной локальной сетью (172.20.0.0/24, 172.20.1.0/24, 172.20.2.0/24). Есть у нас так же филиал, в котором 100 клиентских машин, которые так же объединены локальной сетью 100 Мегабит между собой (172.20.3.0/24, 172.20.4.0/24), а вот до центрального офиса у них есть узкий WAN канал в 64 Кбит/сек, да еще и не очень стабильный. DialUp, скажем. Конечно, по нынешним временам это фантастика, но для понимания хорошо. Так вот, нужно нам, чтобы домен был один, чтобы групповые политики применять нужные в рамках одного домена, чтобы следить было централизованно. Тут-то мы и решаем, что нам нужно заиметь 2 контроллера домена - в Центральном офисе и в Филиале, при этом клиентам филиала указать, что авторизовываться они будут на свой dc-filial, а клиенты центрального офиса будут авторизовываться на своем контроллере домена dc-center.

Итак, мы создаем два сайта. Center и Filial для которых описываем ГРАНИЦЫ (Boundaries).

Center: 172.20.0.0/24, 172.20.1.0/24, 172.20.2.0/24. Точка авторизации dc-center

Filial: 172.20.3.0/24, 172.20.4.0/24. Точка авторизации dc-filial

А теперь посмотрим на Границы и Группы границ в SCCM. В данном случае, границами у нас будут являться подсети 172.20.0.0/24, 172.20.1.0/24, 172.20.2.0/24, 172.20.3.0/24, 172.20.4.0/24. Группами границ будут являться AD сайты - Center и Filial, точки авторизации - dc-center и dc-filial же будут являться, например Distribution points.

Вся та же ситуация, все те же сети, все тот же медленный WAN канал. Нам нужно сделать так, чтобы при распространении софта в центральном офисе он лился с dp-center, а в филиале он лился с dp-filial. Т.е. хотим мы разлить какой-то софт, мы его собираем, разливаем на dp-office и на dp-filial. Благодаря группам границ мы привяжем нужные нам подсети к нужной точке распространения (Distribution point) чтобы не получилось ситуацияя, что клиенты из филиала по узкому каналу начнуть тянуть софт для установки к себе. Вместо этого мы при распространении контента укажем, что софт мы будем распространять на две точки - dp-center и dp-filial, а вот когда назначим установку - клиенты уже сами начнуть тянуть софт со своих локальных Distribution Point.

Собственно, уже сейчас у вас должна была созреть мысль "а нафига плодить в филиалах secondary, ато и primary сайты, а нафига вообще использовать CAS?" В принципе, мысль, думаю, правильная. Действительно, нафига? У вас будет одна точка управления (не путать с management point), у вас будут в удаленных филиалах свои локальные точки распространения.

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

Надеюсь, что толково разъяснил для чего нужны Boundaries и Boundary Groups.