ConfigMgr 2012 - Как автоматически сделать обновления доступными для компьютеров, не вынуждая их быть установленным?
Нет ничего для остановки Вас проверяющий их в системе управления версиями как SVN. Однако я сказал бы, что необходимо проверить их в совершенно отдельном репозитории, не пытайтесь совместно использовать его с repo, который разработчики используют для кода, это будет становиться очень большим и мешать копировать их источник. Для Вас действительно ли возможно совместно использовать объем для отчетов как только для чтения? Это мешало бы случайным удалениям произойти.
Посмотрите это обсуждение Управления версиями Stackoverflow для двоичных файлов
Я знаю, что этот вопрос немного устарел, но здесь публикуются некоторые неправды. Нет ничего плохого в том, как работает SCCM 2012, проблема заключается в непонимании того, как он развертывает программное обеспечение и обновления. Было бы несправедливо цитировать Microsoft, когда они говорят, что ведет себя «намеренно» и что вы ничего не можете сделать, кроме как установить крайний срок в далеком будущем. Это на самом деле задумано, но основано на ВАШЕМ дизайне. Вы не установили периоды обслуживания, поэтому, конечно, обновления будут применяться, как только истечет срок. Это то, что он делает по умолчанию. В этом типе дизайна вы должны установить крайний срок на будущее, чтобы избежать запуска установки. Однако это НЕ единственный способ делать то, что вы хотите, и не самый простой.
Знаете ли вы, что можно изменить поведение SCCM по умолчанию: " потому что теперь он не будет запускать установки или обновления, пока не будет явным образом указано.
Это очень мощный инструмент, но с оговоркой, что теперь у вас есть полный ручной контроль над тем, когда можно запускать установки и когда могут происходить перезагрузки - как вы и хотели. Теперь у этих флажков есть смысл. Например, если у вас есть правила автоматического развертывания, такие как Endpoint Protection Definitions, вам необходимо убедиться, что они могут быть установлены вне периодов обслуживания, если вам не нравится каждый день входить на серверы, чтобы их применять. У вас есть возможность подавить перезагрузку, даже если установке разрешено запускаться вне окон обслуживания. Одним из преимуществ является то, что вы можете легко развернуть что угодно и просто использовать «Как можно скорее» при выборе назначений и сроков для ручной установки, и если вы хорошо разбираетесь в настройках окон обслуживания, вы можете развернуть исправления один раз, но запланируйте фактическую установку и перезагрузку, используя другие коллекции с новыми окнами обслуживания. Помните, что окна обслуживания суммируются для всех коллекций, поэтому проектируйте среду соответствующим образом.
Предполагая, что SCCM 2012 ведет себя как SCCM 2007, отсутствие окна обслуживания означает, что машины в этой коллекции будут устанавливать обновления всякий раз, когда они захотят (в крайний срок или после него), как вы нашли.
Лично я собираю коллекции на основе членства в группах безопасности AD. Серверы, входящие в группу Обслуживание вторника , например, становятся членами коллекции Обслуживание вторника , и (сюрприз) обновляются во вторник вечером.
Серверы, которые не могут быть задействованы. перезагружаемые еженедельно, хранятся в коллекции, не имеющей целевых развертываний обновлений, и поэтому они никогда не загружают и не применяют никаких обновлений, кроме обновлений определений.
В тех случаях, когда я могу обновить эти критически важные серверы, Я просто временно добавляю их в группу безопасности AD, на которую нацелена коллекция с подходящим периодом обслуживания, или просто заранее создаю новую.
Не уверен, что этот подход подходит вам, но, возможно, он может дать вам некоторые идеи.
Have you tried setting the deadline to ridiculously long into the future?
That's how I handle advertisements to my servers in SCCM 2008. I set the deadline for 1 year from the date I roll out the advertisements to the servers. Nice and convenient, since when the patching window rolls around, all the updates are there, waiting to be installed, but won't kick off without manual intervention. Also requires less effort on my part than mucking around in those settings you're trying to get to work as expected.
Почему бы просто не сделать ваше развертывание «доступным», а не «обязательным»? Таким образом, обновления будут появляться в Центре программного обеспечения, но не будут устанавливаться автоматически.
Кроме того, периоды обслуживания применяются к Клиенту, а не к Коллекции.
«Дополнительная проблема заключается в том, что если машина является членом более чем одной коллекции, для которой нацелены Развертывания, и для одной из этих коллекций не определен период обслуживания, окна обслуживания других коллекций фактически игнорируются. "
Фактически период обслуживания КЛИЕНТА будет суммой любого обслуживания к нему прилагаются окна. Итак, если у вас есть одночасовое окно обслуживания, применяемое через членство в одной коллекции, и клиент также является членом коллекции без определенного окна обслуживания,
You seem to have the wrong answer selected. The check boxes you have circled in your graphic clearly only apply to Machines that have a maintenance window defined. It plainly says as much in the line of text above the check boxes. In SCCM, if no maintenance window is assigned, it is assumed that it's ok to maintain that server any old time. Which makes perfect sense. If you'd like those check boxes to apply to your deployments, then you need to set a maintenance window. If you set one in the past, and specify no recurrence then the maintenance window has expired for everything in that collection and there will never be another maintenance window for it. In this scenario, the only way they can be installed now, is if you do it manually.
Caveat: This is only true if those machines are not in any other collections with recurring maintenance windows. In that scenario, this maintenance window is ignored since it is expired, and the other will be observed since they are cumulative.
Seems pretty straight forward to me. And yes, the behavior is by design.. You just designed your deployment wrong. :)
Your mistake was in assuming that since no maintenance window is defined, it's NEVER ok to install those patches, when exactly the opposite is true. The reason for this is that people need to be able to install patches and software, and make changes to systems whether or not a maintenance window is defined. (think highly reboot tolerant machines like workstations.) For these systems the extra step of defining maintenance windows is cumbersome, and can cause problems with software distribution, etc., due to overlap of policies, etc. This way allows to you keep the number of maintenance windows to a minimum, and hence easy to manage and predict what the behavior will be for your deployment.
As you have it set in your image.. If you had a maintenance window set in the past, with no recurrence, you would have exactly the behavior that you wanted. :)
All of this being said.. Now if you throw the various group policy settings that govern automatic updates into the mix, it can be very confusing. Microsoft could simplify the interface for software updates quite a bit, or add some explanations to the settings that exist. That goes for SCCM 2007 as well.
Дальше становится хуже. По моему опыту с продолжающимся развертыванием исправлений, чтобы попытаться обеспечить соответствие, и это может быть реальной проблемой. Вот почему. Как правило, политики назначаются клиентам на основании коллекции, в которой они находятся. Коллекции обновляются периодически, но не все одновременно. Теперь представьте сценарий, в котором вы устанавливаете клиент на сервер, зная, что для установки клиента не потребуется перезагрузка.
Сервер в конечном итоге будет находиться в коллекции с Окном обслуживания и в коллекции с текущим развертыванием критических исправлений. Но так уж случилось, что временная шкала, которая разворачивается, такова: сначала обновляется коллекция с развертыванием, затем клиент достигает своего 'интервала цикла оценки извлечения политики, перед обновлением Коллекции с назначенным ей Окном обслуживания. В результате сервер может применить исправления и перезагрузить компьютер в неподходящее время.
К сожалению, мы не можем назначить Окно обслуживания для "Все системы" Коллекции, чтобы создать Окно обслуживания по умолчанию. Часть моего решения этой проблемы, задуманного до сих пор, состоит в том, чтобы отразить коллекцию «Все системы» с коллекцией, которая имеет ее как Включенную коллекцию, часто устанавливать обновления для этой коллекции и назначать для нее Окно обслуживания. И хотя мы, возможно, захотим продолжить развертывание критических исправлений для настольных компьютеров, мы можем захотеть истечь их срок для серверов или, по крайней мере, изменить их с Требуемых на Доступные после основного технического обслуживания.
Kei te mahi au i te whakahou i nga kaitoha mo te wa tuatahi ma te whakamahi i te SCCM.
Me te whakaaro ko te SCCM 2012 he rite ki te SCCM 2007, ko te korenga o te matapihi tiaki ko nga miihini kei roto i taua kohinga ka whakauru whakahou i nga waa e pai ana ki a ratau (i te ra i muri mai ranei o te waa kati), kua kitea e koe.
I ano kua kitea ko tenei te keehi. Me toha e koe he matapihi tiaki ka pa ranei nga whakahou i nga wa katoa e pai ana ratou.
Mo nga whakahoutanga a te kaitoha, ko taaku e mahi nei ko te tohatoha i nga whakahou i te waatea ki nga kaiwhakarato engari me whakauru me te tono a ringa ratou (i muri i te tango i te whakaahua o te miihini mena he VM tera.) i te ra tiimata moata, tirohia kia kaua e hurihia e ahau te whakaahua ka hoki.
Здесь много запутанных полуправдивых ответов. Обведенные вами параметры применяются только в том случае, если к машине применен интервал обслуживания. Если вы хотите, чтобы ваши системы никогда не перезагружались, если вы не инициируете это, вам следует сделать окно обслуживания либо в далеком будущем, либо в далеком прошлом.
Без окна обслуживания SCCM разрешит перезагрузку системы после установки обновлений. Способ заблокировать такое поведение находится в настройках клиента SCCM, которые находятся в разделе «Администрирование» -> «Настройки клиента».