none
WSUS И DFS RRS feed

  • Вопрос

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

    Исходные данные: несколько площадок по топологии звезда, связаны относительно медленными каналами ( от 1 до 4 мб/с) Планируется поставить в центре WSUS сервер, работающий с внешним SQL сервером (находится тоже в центре). Хотелось бы разместить папку wsuscontent на ресурсе DFS, а реплики DFS есть на каждой площадке. Возможен ли такой вариант работы и откуда клиенты WSUS будут забирать обновления? Просто не хотелось бы иметь больше одного WSUS, но надо снизить нагрузку на каналы связи.. Ибо вариант, когда пара сотен клиентов из периферийных площадок начнут забирать какой-нибудь service pack мегабайт на 100, как то не хочется пробовать.. Каковы могут быть решения?

    13 апреля 2010 г. 8:49

Ответы

  • а почему бы не ....

    - есть центральный WSUS тянущий обновления с MS

    - на дочерних площадках ставится WSUS (на встроенной MSDE) и настраивается как подчиненный сервер (downstream server)

      подчиненые сервера настраиваются на расписание ночью проверять обновления на центральном

     

    - от куда будут тянуть обновления ?

    я бы сделал так:

    для всех площадок создал в AD сайты и к ним прикрепил соответсвующую политику.

    таки образом получаем, что где находится клиент (сайт AD) от туда и тянет обновления.

    13 апреля 2010 г. 10:12
  • WSUS работает over IIS

    клиент обращается по HTTP (HTTPS)

    поэтому как тут прикрутить DFS

    13 апреля 2010 г. 10:15
  • Они и не будут ходить в и-нет за обновлениями. Они будут ходить на ваш центральный WSUS через прокси и этот прокси будет кешировать для них обновления. Запретите устаревание кеша вообще и заранее продумайте объём кеша.


    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    13 апреля 2010 г. 22:11

Все ответы

  • а почему бы не ....

    - есть центральный WSUS тянущий обновления с MS

    - на дочерних площадках ставится WSUS (на встроенной MSDE) и настраивается как подчиненный сервер (downstream server)

      подчиненые сервера настраиваются на расписание ночью проверять обновления на центральном

     

    - от куда будут тянуть обновления ?

    я бы сделал так:

    для всех площадок создал в AD сайты и к ним прикрепил соответсвующую политику.

    таки образом получаем, что где находится клиент (сайт AD) от туда и тянет обновления.

    13 апреля 2010 г. 10:12
  • WSUS работает over IIS

    клиент обращается по HTTP (HTTPS)

    поэтому как тут прикрутить DFS

    13 апреля 2010 г. 10:15
  • в AD сайты есть и настроены. С политиками тоже все ясно.  Вариант с нижестоящими WSUS понятен, но не хочется "лишние" серверы...

    Клиент обращается по HTTP в центр, но данные (собственно сами обновления берет из ближайшего места..) Возможно такое? Вообще, на сайте MS есть комментарии по настройке NLB кластера WSUS, там и про DFS говорится, да больно мощно там все завернуто, мне бы попроще :)

     

    13 апреля 2010 г. 11:46
  • Ставьте в площадках кеширующий прокси и кешируйте обновления. В моём случае это SQUID и всё работает замечательно.
    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    13 апреля 2010 г. 11:53
  • Ставьте в площадках кеширующий прокси и кешируйте обновления. В моём случае это SQUID и всё работает замечательно.
    Не пойдет - наш WSUS забирает обновления не из инета, а также с вышестоящего сервера, а клиентам вообще нельзя в инет ходить
    13 апреля 2010 г. 12:45
  • Они и не будут ходить в и-нет за обновлениями. Они будут ходить на ваш центральный WSUS через прокси и этот прокси будет кешировать для них обновления. Запретите устаревание кеша вообще и заранее продумайте объём кеша.


    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    13 апреля 2010 г. 22:11
  • Для того, чтобы клиенты под ХР ходили на WSUS через прокси необходимо настроить "системный прокси" командой proxycfg в CMD конмоли, или через реестр.

    в Vista и выше используется команда netsh winhttp set proxy


    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    14 апреля 2010 г. 12:07
  • Ибо вариант, когда пара сотен клиентов из периферийных площадок начнут забирать какой-нибудь service pack мегабайт на 100, как то не хочется пробовать.. Каковы могут быть решения?

    Поставьте на клиентов Windows Management Framework  http://support.microsoft.com/kb/968929

    Это установит на клиентов BITS 4.0, который умеет кэшировать свой контент - это как раз то что вам нужно, т.к. обновления загружаются по BITS. Технология называется BranchCache и Peer Caching. Но их надо включить!

    Настройка http://msdn.microsoft.com/en-us/library/aa964314(v=VS.85).aspx


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    15 апреля 2010 г. 14:27
    Модератор
  • Поставьте на клиентов Windows Management Framework  http://support.microsoft.com/kb/968929

    Это установит на клиентов BITS 4.0

    Только вот там написано, что BITS 4.0, в отличие от остальных компонентов (WinRM 2.0, PowerShell 2.0), доступен только начиная с Windows Vista или Server 2008; для XP есть максимум BITS 2.5.
    15 апреля 2010 г. 18:08
  • У вас клиенты XP? Неважно - кэширование BITS работает и для младших версий - просто его включите через GPO.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    21 апреля 2010 г. 5:23
    Модератор