none
Схема установки обновлений на сервера RRS feed

 > 

  • Вопрос

  • Question
    Нужно войти
    0
    Нужно войти

    Есть компания. В компании есть куча структурных подразделений. В каждом подразделении есть свои сервера.

    Есть ежемесячный список от СИБа который необходимо поставить на все сервера.

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

    Но все равно же хочется упросить себе жизнь. 

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

    1. Создаю под каждое возможное окно свою коллекцию. И когда согласовал перезагрузку добавляю соответсвующий сервер в эту коллекцию. Но тут после установки необходимо не забыть удалить этот сервер из этой коллекции, чтоб его в следующий раз не зацепило, когда я например буду использовать это окно для других серверов.

    2. Создаю столько коллекций, сколько может быть отдельно перезагружаемых серверов. Договариваюсь с пользователем на перезагрузку сервер srv1, который в коллекции col_srv1, назначаю Deploy на эту коллекцию.

    Интересен ваш опыт в подобных ситуациях. Может есть более удобная схема?

    16 октября 2018 г. 13:58
    |

Ответы

  • Question
    Нужно войти
    2
    Нужно войти

    Довольно сложно реализовать это удобно именно через SCCM.

    Какой уровень домена? Можно попробовать строить коллекции на основе членства во временных группах AD - Temporary Active Directory Group Membership (доступны при функц. уровне AD 2016).

    Схема такая: добавляете необходмый сервер в группу AD с неким MemberTimeToLive (например 2-3 дня).

    Коллекцию в SCCM строите на основе членсва в данной группе. SCCM обновляет группу, видит что в ней появился новый сервер, применяет на него политики установки обнвовлений. ОБновления ставяться, сервер перезагружается. Через 3 дня он автоматически исключается из группы, настройки обнволения возвращаются на стандартные.

    17 октября 2018 г. 9:05
    |
  • Question
    Нужно войти
    1
    Нужно войти

    вы написали что вам интересен опыт, я поделился своим.

    действительно ваша проблема мной была не понята. исходя из пояснения всплывает вопрос - кто является источником данны (какой сервак и когда можно бутать)? есть шанс минимизировать ручного управления многих людей? кто ответвеннен за то были патчи установлены или нет?

    Если на последний вопрос ответ - начальники локальных отделов - делегируйте им права на свои серваки и пусть сами ставят когда захотят. Если вы отвечаете, то я вижу административное решение - на уровне приказа по отделу отдел выбирает время установки обнов и день. Вы настраиваете напоминалки за 2 дня до, и за день до, а ответвенный в отделе должен 1 день в месяц дежурить и контролировать процесс.

    The opinion expressed by me is not an official position of Microsoft

    16 октября 2018 г. 15:28
    |
    Модератор

Все ответы

  • Question
    Нужно войти
    2
    Нужно войти
    настроен всус на котором апрувятся обновы раз в месяц после теста и групповые политики которые говорят каким сервакам, что и когда делать

    The opinion expressed by me is not an official position of Microsoft

    16 октября 2018 г. 14:18
    |
    Модератор
  • Question
    Нужно войти
    0
    Нужно войти

    Может я как то не так объяснил суть вопроса? у меня нет возможности жестко привязаться к какой либо конкретной схеме.

    В этом месяце сервер srv1 можно обновлять в четверг, в следующем месяце можно обновлять и перезагружать в пятницу. А в третьем месяце вообще его трогать нельзя. Как будет удобнее построить работу и настроить SCCM?

    Зачем мне WSUS, если у меня SCCM есть, в котором я могу говорить сервакам что и когда делать. 

    Вопрос в том, как именно говорить это сервакам?

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

    16 октября 2018 г. 14:27
    |
  • Question
    Нужно войти
    1
    Нужно войти

    вы написали что вам интересен опыт, я поделился своим.

    действительно ваша проблема мной была не понята. исходя из пояснения всплывает вопрос - кто является источником данны (какой сервак и когда можно бутать)? есть шанс минимизировать ручного управления многих людей? кто ответвеннен за то были патчи установлены или нет?

    Если на последний вопрос ответ - начальники локальных отделов - делегируйте им права на свои серваки и пусть сами ставят когда захотят. Если вы отвечаете, то я вижу административное решение - на уровне приказа по отделу отдел выбирает время установки обнов и день. Вы настраиваете напоминалки за 2 дня до, и за день до, а ответвенный в отделе должен 1 день в месяц дежурить и контролировать процесс.

    The opinion expressed by me is not an official position of Microsoft

    16 октября 2018 г. 15:28
    |
    Модератор
  • Question
    Нужно войти
    2
    Нужно войти

    Довольно сложно реализовать это удобно именно через SCCM.

    Какой уровень домена? Можно попробовать строить коллекции на основе членства во временных группах AD - Temporary Active Directory Group Membership (доступны при функц. уровне AD 2016).

    Схема такая: добавляете необходмый сервер в группу AD с неким MemberTimeToLive (например 2-3 дня).

    Коллекцию в SCCM строите на основе членсва в данной группе. SCCM обновляет группу, видит что в ней появился новый сервер, применяет на него политики установки обнвовлений. ОБновления ставяться, сервер перезагружается. Через 3 дня он автоматически исключается из группы, настройки обнволения возвращаются на стандартные.

    17 октября 2018 г. 9:05
    |