none
Планирование Sccm 2012 RRS feed

  • Вопрос

  • Добрый день, планируем внедрение SCCM в компании.

    Есть:

    5 удаленных офисов

    Офис1 - 240 клиентов

    Офис2 - 130 клиентов

    Офис3 - 550 клиентов

    Офис4 - 190 клиентов

    Офис5 - 180 клиентов

    Требования:
    1. необходимо иметь возможность централизованно устанавливать обновления (здесь больше наверное про то, что хотелось бы формировать правила, создавать пакеты и т.п. с обндной точки, не переключаясь по консолям каждого из офисов)
    2. необходимо иметь возможность использовать SCCM для автоматической установки OS на рабочие станции пользователей  (что бы техподдержка в каждом офисе могла сама заливать систему на рабочии станции)
    3. необходимо иметь возможность центролизованной установки программного обеспечения на рабочие станции пользователей (то же самое, что и в пункте 1)
    4. необходимо иметь возможность центролизованной установки обновлений программного обеспечения

    Помогите пожалуйста определится с конфигурацией.

    Судя по рекомендациям microsoft, CAS мне особо и не нужен. 

    Вариантов вижу два

    1. Один PS и остальные как дочерние

    2. Один PS и в других офисах DP

    Чего бы не хотелось, чтобы клиентские машины не ходили к серверу в другой филиал, а общались только с сервером который стоит у них. Правильно я понимаю, что во второй схеме они будут обобщатся именно с PS, а с DP брать только файлы?

    24 сентября 2018 г. 9:57

Ответы

  • Добрый день!

    Инфраструктура с CAS для вас будет избыточной. Так как 1 Первичный сайт может поддерживать до 100 000 клиентов. Вам идеально подойдет вариант 1 Первичный сайт + 4 Вторичных с точками обновления (SUP).

    Так вы сможете распределить нагрузку. 

    По поводу вашей догадки о 2 варианте развития события - вы правы. Так как DP просто предоставляет контент, всеми политиками и настройками клиента управляет "точка управления" (Management Point). Но клиенты будут привязаны все равно к Первичному сайту. Так как к CAS и Вторичному они просто не могут быть привязаны, а уже первичный сайт переадресует клиента на вторичный сайт ближайший к нему (согласно настроенным границам разумеется).

    • Помечено в качестве ответа itdmit 25 сентября 2018 г. 8:39
    24 сентября 2018 г. 14:20
  • Трафик будет в виде межсайтовой репликации. Туда будет включен контент, инветаризация , обновления (например если использовать как апстрим-сервер первичный сайт) и т.д . 

    Анализировать апдейты клиенты будут у ближайшей SUP. Это можно будет смотреть в логе WUAHandler.log отвечающий за процесс сканирования обновлений имеющихся и необходимых, там будет видно куда они обращаются.

    Клиенты можно ставить различными путями. Я бы посоветовал не использовать один метод распространения так как это единая точка отказа. Например хорошо использовать метод Software Update-Based Client Installation и Push Install. К слову при использовании метода  Push Install из консоли вы сможете сами выбирать с какого сайта ставить. А метод Software Update-Based Client Installation будет работать в цикле обновлений и опубликован на WSUS-SUP ближайшем сервере.

    Права вы сможете раздать и имея standalone Primary Site . Там достаточно гибкие права, нужно только будет местной тех поддержке установить консоль для работы.

    При установке вторичного сайта будет автоматически установлена версия SQL Express, но тут стоит оговориться о том что если будете публиковать апдейты в базе данных SQL вам придется поднять версию до стандарта, так как экспресс версия быстро достигнет максимума в объеме БД 10 ГБ

    • Помечено в качестве ответа itdmit 25 сентября 2018 г. 8:38
    24 сентября 2018 г. 16:22

Все ответы

  • Добрый день!

    Инфраструктура с CAS для вас будет избыточной. Так как 1 Первичный сайт может поддерживать до 100 000 клиентов. Вам идеально подойдет вариант 1 Первичный сайт + 4 Вторичных с точками обновления (SUP).

    Так вы сможете распределить нагрузку. 

    По поводу вашей догадки о 2 варианте развития события - вы правы. Так как DP просто предоставляет контент, всеми политиками и настройками клиента управляет "точка управления" (Management Point). Но клиенты будут привязаны все равно к Первичному сайту. Так как к CAS и Вторичному они просто не могут быть привязаны, а уже первичный сайт переадресует клиента на вторичный сайт ближайший к нему (согласно настроенным границам разумеется).

    • Помечено в качестве ответа itdmit 25 сентября 2018 г. 8:39
    24 сентября 2018 г. 14:20
  • Спасибо, 

    значит вариант такой?

    Офис 1 - Первичный сайт (MP, SUP, DP...)

    Офис 2,3,4,5 - Вторичный сайт (SUP, DP...)

    - То есть какой то трафик от клиентов из офис5 все равно будет ходит в Офис1? Если в каждом вторичном будет свой SUP, то анализировать их необходимость в апдейтах будет их локальный сервер? 

    - Откуда будут ставятся клиенты, например в ОФис3?

    - Смогу я в этой иерархии раздавать определенные права местной техподдержке в каждом из офисов?

    - Вторичные сайты требуют SQL?

    24 сентября 2018 г. 14:55
  • Трафик будет в виде межсайтовой репликации. Туда будет включен контент, инветаризация , обновления (например если использовать как апстрим-сервер первичный сайт) и т.д . 

    Анализировать апдейты клиенты будут у ближайшей SUP. Это можно будет смотреть в логе WUAHandler.log отвечающий за процесс сканирования обновлений имеющихся и необходимых, там будет видно куда они обращаются.

    Клиенты можно ставить различными путями. Я бы посоветовал не использовать один метод распространения так как это единая точка отказа. Например хорошо использовать метод Software Update-Based Client Installation и Push Install. К слову при использовании метода  Push Install из консоли вы сможете сами выбирать с какого сайта ставить. А метод Software Update-Based Client Installation будет работать в цикле обновлений и опубликован на WSUS-SUP ближайшем сервере.

    Права вы сможете раздать и имея standalone Primary Site . Там достаточно гибкие права, нужно только будет местной тех поддержке установить консоль для работы.

    При установке вторичного сайта будет автоматически установлена версия SQL Express, но тут стоит оговориться о том что если будете публиковать апдейты в базе данных SQL вам придется поднять версию до стандарта, так как экспресс версия быстро достигнет максимума в объеме БД 10 ГБ

    • Помечено в качестве ответа itdmit 25 сентября 2018 г. 8:38
    24 сентября 2018 г. 16:22
  • Меня вот что смущает: если все клиенты будут прикреплены к первичному сайту, то это значит что все рабочие станции будут ходить в один из офисов для отчетности и получения какой либо информации? Как оценить в какой трафик это вырастет? Понятно, что апдейты и ПО они будут брать с SUP и DP у себя в офисе, но все настройки и т.п. будут брать с PS, это тоже наверное не мало? и плюс еще всю информацию о своем состоянии тоже будут отдавать на PS?

    26 сентября 2018 г. 11:23
  • Дмитрий начните новую тему пожалуйста. Так удобнее будет, и участники увидят что вопрос открыти актуален
    26 сентября 2018 г. 14:25