Я использую System Center Configuration Manager 2012 с функцией точки обновления программного обеспечения; однако в этой среде исправление должно быть строго вручную, потому что перезагрузка сервера должна быть одобрена и запланирована разными людьми; Таким образом, мне нужно использовать SUP ConfigMgr, как если бы я использовал простой сервер WSUS с автоутверждением, но с ручной установкой.
Я создал несколько правил автоматического развертывания для автоматической загрузки и развертывания критических обновлений, а также для выполнения установки «как можно скорее»; но затем я также настроил эти правила, чтобы что-нибудь по достижении крайнего срока и чтобы система не перезагружалась даже в случае необходимости:
Кроме того, я настроил коллекции устройств, в которых эти правила развертывают обновления для не иметь любое действующее окно обслуживания.
Однако я испытываю прямо противоположное тому, что ожидал: как только новые обновления обрабатываются ADR, они автоматически устанавливаются во всех системах Центром программного обеспечения, а затем компьютеры перезагружаются.
Почему это происходит? Я что-то ошибаюсь или просто ConfigMgr 2012 ведет себя не так, как должен?
Я знаю, что этот вопрос немного устарел, но здесь публикуются некоторые неправды. Нет ничего плохого в том, как работает SCCM 2012, проблема заключается в непонимании того, как он развертывает программное обеспечение и обновления. Было бы несправедливо цитировать Microsoft, когда они говорят, что она ведет себя «намеренно» и что вы не можете ничего сделать, кроме как установить крайний срок в далеком будущем. Это на самом деле задумано, но основано на ВАШЕМ дизайне. Вы не установили периоды обслуживания, поэтому, конечно, обновления будут применяться, как только истечет крайний срок. Это то, что он делает по умолчанию. В этом типе дизайна вы должны установить крайний срок на будущее, чтобы избежать запуска установки. Однако это НЕ единственный и не самый простой способ делать то, что вы хотите.
Знаете ли вы, что можно изменить поведение SCCM по умолчанию: «все идет, если не указано иное»?
Для этого создайте новую коллекцию (назовите ее как угодно, например «Развернуть вручную») и включите коллекцию «Все системы» в ее состав. Затем установите для него свойства и установите для окна обслуживания любую дату вступления в силу в прошлом, например 01.01.2013 с 12:00 до 12:05, и установите для графика повторения значение Нет. Вы получите предупреждение о том, что повторение не установлено, но все равно нажмите OK. С этого момента каждое устройство в вашей среде SCCM будет автоматически иметь истекшее окно обслуживания, установленное на нем, и больше не сможет ничего устанавливать без нового окна обслуживания или установки флажка в поле переопределения окна обслуживания при развертывании. Это противоположно его предыдущему поведению, потому что теперь он не будет запускать установки или обновления, пока явно не будет указано иное.
Это очень мощно, но предостережение в том, что теперь у вас есть полный ручной контроль над тем, когда можно запускать установки и когда могут происходить перезагрузки - как вы и хотели. Теперь у этих флажков есть смысл. Например, если у вас есть правила автоматического развертывания, такие как Endpoint Protection Definitions, вам необходимо убедиться, что они могут быть установлены вне периодов обслуживания, если вам не нравится каждый день входить на серверы, чтобы применять их. У вас есть возможность подавить перезагрузку, даже если установке разрешено запускаться вне окон обслуживания. Одним из преимуществ является то, что вы можете легко развернуть что угодно и просто использовать «Как можно скорее» при выборе назначений и крайних сроков для ручной установки, и если вы хорошо разбираетесь в настройках окна обслуживания, вы можете развернуть исправления один раз, но запланировать фактическую установку и перезагрузитесь, используя другие коллекции с новыми окнами обслуживания. Помните, что окна обслуживания суммируются для всех коллекций, поэтому проектируйте среду соответствующим образом.
Почему бы просто не сделать ваше развертывание «доступным», а не «обязательным»? Таким образом, обновления появятся в Центре программного обеспечения, но не будут установлены автоматически.
Кроме того, окна обслуживания применяются к Клиенту, а не к Коллекции.
«Дополнительная проблема заключается в том, что если машина является членом более чем одной коллекции, для которой нацелены развертывания, и для одной из этих коллекций не определен период обслуживания, окна обслуживания других коллекций эффективно игнорируются».
Фактически окно обслуживания КЛИЕНТА будет суммой любых окон обслуживания, примененных к нему. Таким образом, если у вас есть одночасовое окно обслуживания, применяемое через членство в одной коллекции, и клиент также является членом коллекции без определенного окна обслуживания, ваше эффективное окно обслуживания составляет один час.
Вы пытались установить крайний срок на смехотворно долгое будущее?
Вот как я обрабатываю рекламные объявления на моих серверах в SCCM 2008. Я установил крайний срок на 1 год с даты, когда я разверну рекламные объявления на серверах. Приятно и удобно, поскольку, когда откроется окно установки исправлений, все обновления будут там, ожидая установки, но не запустятся без ручного вмешательства. Также требует меньше усилий с моей стороны, чем копаться в тех настройках, которые вы пытаетесь заставить работать должным образом.
Кажется, вы выбрали неправильный ответ. Флажки, обведенные вами на графике, явно относятся только к машинам, для которых определен период обслуживания. Об этом прямо сказано в строке текста над флажками. В SCCM, если период обслуживания не назначен, предполагается, что можно поддерживать этот сервер в любое время. В этом есть смысл. Если вы хотите, чтобы эти флажки применялись к вашим развертываниям, вам необходимо установить период обслуживания. Если вы установили один в прошлом и указали отсутствие повторения, то период обслуживания истек для всего в этой коллекции, и для него никогда не будет другого окна обслуживания. В этом сценарии единственный способ их установки сейчас - это сделать это вручную.
Предостережение: это верно только в том случае, если эти машины не находятся в других коллекциях с повторяющимися окнами обслуживания. В этом сценарии это окно обслуживания игнорируется, так как оно истекло, а другое будет наблюдаться, поскольку оно является кумулятивным.
Мне это кажется довольно простым. И да, такое поведение было задумано ... Вы неправильно спроектировали развертывание. :)
Ваша ошибка заключалась в предположении, что, поскольку период обслуживания не определен, НИКОГДА нельзя устанавливать эти исправления, когда верно обратное. Причина этого в том, что люди должны иметь возможность устанавливать исправления и программное обеспечение, а также вносить изменения в системы, независимо от того, определен ли период обслуживания или нет. (подумайте о машинах с высокой степенью перезагрузки, например, о рабочих станциях.) Для этих систем дополнительный этап определения окон обслуживания является громоздким и может вызвать проблемы с распространением программного обеспечения и т. д. из-за перекрытия политик и т. д. Этот способ позволяет сохранить количество окон обслуживания до минимума, и, следовательно, легко управлять и прогнозировать, каким будет поведение вашего развертывания.
Как вы установили в своем изображении ... Если бы у вас был установлен период обслуживания в прошлом, без повторения, у вас было бы именно то поведение, которое вы хотели. :)
Все это уже сказано ... Теперь, если вы добавите различные параметры групповой политики, которые управляют автоматическими обновлениями, это может сильно сбить с толку. Microsoft может немного упростить интерфейс для обновлений программного обеспечения или добавить некоторые пояснения к существующим настройкам. То же самое и с SCCM 2007.
Предполагая, что SCCM 2012 ведет себя как SCCM 2007, отсутствие окна обслуживания означает, что машины в этой коллекции будут устанавливать обновления всякий раз, когда они захотят (в крайний срок или после него), как вы обнаружили.
Лично я создаю коллекции на основе членства в группе безопасности AD. Серверы, входящие в Tuesday Maintenance
группы, например, стать членами Tuesday Maintenance
коллекция и (сюрприз) обновляются во вторник вечером.
Серверы, которые нельзя перезагружать еженедельно, хранятся в коллекции, на которую не нацелены развертывания обновлений, и поэтому они никогда не загружают и не применяют никаких обновлений, кроме обновлений определений.
В тех случаях, когда мне удается обновить эти критически важные серверы, я просто временно добавляю их в группу безопасности AD, на которую нацелена коллекция с подходящим периодом обслуживания, или просто заранее создаю новый.
Не уверен, что этот подход будет тем, что вы ищете, но, возможно, он может дать вам некоторые идеи.
Становится хуже. По моему опыту с продолжающимся развертыванием исправлений, чтобы попытаться обеспечить соответствие, и это может быть реальной проблемой. Вот почему. Как правило, политики назначаются клиентам на основании коллекции, в которой они находятся. Коллекции обновляются периодически, но не все одновременно. Теперь представьте сценарий, в котором вы устанавливаете клиент на сервер, зная, что для установки клиента не потребуется перезагрузка.
В конечном итоге сервер будет находиться в коллекции с Окном обслуживания и в коллекции с текущим развертыванием критических исправлений. Но так уж получилось, что временная шкала, которая происходит, происходит так: сначала обновляется коллекция с развертыванием, затем клиент попадает в свой интервал цикла оценки получения политики, прежде чем коллекция с назначенным ей окном обслуживания обновляется . В результате сервер может применить исправления и перезагрузиться в неподходящее время.
К сожалению, мы не можем назначить Окно обслуживания для "Все системы" Коллекции, чтобы создать Окно обслуживания по умолчанию. Часть моего решения этой проблемы, задуманного до сих пор, состоит в том, чтобы отразить коллекцию «Все системы» с коллекцией, которая имеет ее как Включенную коллекцию, часто устанавливать обновления для этой коллекции и назначать для нее Окно обслуживания. И хотя мы, возможно, захотим продолжить развертывание критических исправлений для настольных компьютеров, мы можем пожелать истечь их срок для серверов или, по крайней мере, изменить их с Требуемых на Доступные после основного технического обслуживания.
Мне также нравится идея применения единовременного окна обслуживания в прошлом.
Похоже, это может быть известная ошибка в SCCM. Однако я не могу найти какую-либо документацию MS, но, по крайней мере, OP знает, что проблема не в его настройке.
На самом деле я впервые обновляю серверы с помощью SCCM.
Предполагая, что SCCM 2012 ведет себя как SCCM 2007, отсутствие окна обслуживания означает, что машины в этой коллекции будут устанавливать обновления всякий раз, когда они захотят (в крайний срок или после него), как вы обнаружили.
Я тоже обнаружил, что это так. Вы должны назначить периоды обслуживания, иначе обновления будут применяться, когда захотят.
Что касается обновлений сервера, то я развертывал обновления как доступный к серверам, но затем войдите в систему и примените их вручную (после создания снимка машины, если это виртуальная машина).
Однако было бы неплохо нажать кнопку «установить все обновления во время следующего периода обслуживания, при необходимости перезагрузить», чтобы я мог запустить этот процесс в течение дня, а затем встать пораньше и убедиться, что мне не нужно откатывать снимок.
Здесь много запутанных полуправдных ответов. Обведенные вами параметры применяются только в том случае, если к машине применен интервал обслуживания. Если вы хотите, чтобы ваши системы никогда не перезагружались, если вы не инициируете это, вам следует сделать окно обслуживания либо в далеком будущем, либо в далеком прошлом.
Без окна обслуживания SCCM позволит системе перезагрузиться после установки обновлений. Способ заблокировать такое поведение находится в разделе «Настройки клиента SCCM», который находится в разделе «Администрирование» -> «Настройки клиента».