Я широко использовал вложенные коллекции в SCCM 2007, и я сейчас в процессе создания прототипа нашей новой среды SCCM 2012, которая исключила вложенные коллекции. Мне было интересно, как другие справились с этой проблемой.
Моя иерархия коллекций SCCM 2007 состоит из четырех коллекций. Внизу вложен тестовый набор систем. У каждой коллекции есть период обслуживания. В тестовой коллекции и коллекции над ней, коллекция 1, есть окна обслуживания по четвергам. В коллекции 2 есть окно обслуживания по пятницам, а в коллекции 3 - по субботам. Благодаря этому дизайну я мог создавать один пакет и рекламу каждый месяц, применяя их к тестовой коллекции в первую неделю, и после недельного опоздания перемещать ту же рекламу в коллекцию над ней после недельной задержки. (Недельная задержка - это период тестирования / проверки, требуемый администрацией.) А затем в последующие дни я перенаправлял рекламу на коллекцию над ней в последующие дни, достигая вершины, сбор 3. Используя опцию «эта коллекция и subcollections ', я смог сохранить эти обновления доступными для последующих периодов обслуживания после того, как реклама достигла вершины.
Этот дизайн кажется довольно распространенным, поэтому мне было интересно, как другие относятся к плоскому дизайну SCCM 2012 и устранению вложенных коллекций.
Во-первых, SCCM 2012 на самом деле не плоский, вы можете (и должны) создавать папки для организации различных типов коллекций в консоли.
Во-вторых, я понимаю, что это не совсем ответ на ваш вопрос, потому что вы спрашиваете о том, как одновременно развертывать настройки, приложения, обновления и т. Д. В группе коллекций, а папки в этом не помогают.
Мы делаем это с помощью правил членства «Включить коллекции» (и «Исключить коллекции»). Вы создаете то, что было бы вашей родительской коллекцией, а затем добавляете правила членства «Включить коллекции» в эту коллекцию для того, что было бы вашими вложенными коллекциями. Это в конечном итоге оказывается гораздо более гибким, чем старая система, потому что вы можете легко включать различные комбинации коллекций в свои новые «родительские» коллекции.
Например, у нас есть несколько коллекций для исправления сервера на основе задания сервера, местоположения, уровня риска и того, где он находится в нашем цикле исправлений, затем он будет включен в одну коллекцию, чтобы получить его окна обслуживания (обычно на основе чего-то вроде его местоположение / часовой пояс или шаблон использования) и включается во вторую коллекцию, чтобы получить список утвержденных обновлений (обычно в зависимости от задания и уровня риска), например: