Особенности распространения обновлений через ConfigMgr

Статусы соответствия сканирования обновлений

1. Относительно MS Update, то есть всех обновлений в облаке. В ConfigMgr это не реализуется, однако может рассчитываться сторонним ПО, например, сканерами уязвимостей.
2. Относительно БД SUP/WSUS, то есть синхронизированных обновлений. Таков, например, отчёт Compliance 5 - Specific computer.
3. Относительно группы обновлений (Software Update Group), то есть списка, определённого администратором. Пример отчёта:  Compliance 3 - Update group (per update).
4. Относительно конкретного обновления. Пример отчёта: Compliance 2 - Specific software update. 

Развёртывание обновлений

1. Развёрнутая SUG не должна быть большой. В документации описан лимит в 1000 обновлений, по моему же персональному мнению стоит избегать групп из 100+ обновлений. Причина этого проста: развёрнутая группа - это политика, которая должна быть закачана и обработана клиентом. Чем она больше - чем больше нагрузка на машины, ведь клиент ConfigMgr должен фактически сравнить два списка - требуемых и развёрнутых в группе обновлений - и выбрать общую часть.
2. Даже не развёрнутая SUG не должна быть большой, ну и самих SUG не должно быть чересчур много. Серверу необходимо будет рассчитывать и суммаризировать состояния соответствия для каждой, чем больше групп и обновлений в группе, тем больше нагрузка на SQL.
3. SUPkg не должна быть большой. Клиенты выберут то, что им нужно скачать из пакета, поэтому для них размер пакета не имеет значения, однако серверная часть будет делать новые снепшоты пакета, сжимать его и рассылать на DP и другие сайты  каждый раз, когда пакет обновляется. А обновляются SUPkg часто и, иногда, без ведома администратора: например, при удалении истёкших (expired) обновлений из БД они удаляются и из SUPkg.
4. SUPkg надо собирать аккуратно, их имеет смысл распространить на все или большинство DP. Разбирательство на тему "почему клиент X не смог закачать и установить обновление Y" требуют выяснения всех развертываний данного обновления на данном клиенте, изучения их настроек, а также поиска всех пакетов, в которое входит данное обновление, и их расположения на DP. Поскольку найти в какие пакеты закачано обновление Y из консоли весьма нетривиально без прокликивания всех пакетов, то такие расследования доставляют крайне мало удовольствия.
5. Коллекция для развёртывания не должна быть большой. Во-первых, правильно всё-таки распространять обновления волнами (или, как теперь модно называть, кольцами, update rings), чтобы нивелировать риски распространения обновления, которое "всё поломает", на все машины компании. Во-вторых, в очень больших окружениях генерация политики на множество клиентов может занять существенное время и нагрузить SQL. В третьих, напомню, что политики будут применены клиентами в течение часа (по умолчанию), а значит все клиенты начнут работу с обновлениями как раз в этот промежуток времени - и в больших окружениях могут изрядно нагрузить серверную часть закачками и отчётностью.
6. Настройки развёртывания и окон обслуживания должны быть щадящими. Про это мы немного поговорим ниже.
7. ADR должен закачивать минимально нужное количество обновлений. Тут всё просто, ради экономии трафика, времени и места на диске.

1. Клиент получит политику развёртывания: в течение 60 минут.
2. Сразу после получения политики клиент запустит оценку применимости развёрнутых обновлений - сравнит два списка - и соберёт список на установку. Здесь есть два нюанса:
   1. Разумеется, при выполнении цикла сканирования WUA кэширует его результаты и при повторном сканировании не обращается к SUP/WSUS (делает offline scan). Однако у этого кэша есть TTL, и он составляет 24 часа. Если TTL истёк, то будет выполнена попытка просканировать обновления (non-forced online scan).
   2. Клиент отчитается о результатах оценки на сервер в виде сообщения о состоянии (state message): в течение 15 минут.
3. Клиент обработает политику, и выберет время доступности развёртывания (Available Time):
   1. Именно в это время начнётся закачка обновлений из списка установки с DP в кэш - но только в том случае, если развёртывание обязательное (Purpose = Required).
   2. Пользователю будет отправлена нотификация о том, что ему доступно новое ПО - или не отправлена, если так указано в развёртывании.
4. Клиент выберет время для установки обновлений на базе настроек развёртывания и окон обслуживания.
   1. Перед установкой клиент на всякий случай снова отсканирует обновления, если TTL истёк.
   2. Еще один повод не делать большие SUG: если клиент получит список на установку в рамках одного развёртывания дольше, чем окно обслуживания на коллекции, то установка будет ждать более долгого окна. По умолчанию обычные обновления требуют 10 минут, кумулятивные - 60 - посмотреть это можно в настройках индивидуального обновления.
5. В момент Х клиент начнёт установку обновлений и перезагрузит машину при необходимости, не забывая отчитываться о каждом шаге на сервер в виде сообщения о состоянии.
   1. Если на момент Х обновления были вытеснены из кэша другим ПО, то они будут закачаны заново. Это повод сделать кэш побольше.
   2. Сразу после установки или после перезагрузки клиент делает оффлайн сканирование (forced offline scan) по умолчанию, об этом надо заботиться отдельно.
6. Сервер обработает сообщения о состоянии и рассчитает состояние соответствия развёртывания, о котором мы также поговорим ниже.
7. Поскольку для развёртываний обновлений (как и приложений) нельзя указать время истечения (Expiration time), то целевая конфигурация будет проверяться и, при необходимости, применяться до удаления развёртывания - по расписанию переоценки обновлений (Software Update Re-Evaluation Cycle).

1. При планировании развёртывания, а также циклов сканирования и переоценки обновлений, учитывайте TTL кэша и сопутствующую активность клиента WUA: SUP/WSUS должен быть доступен.
2. Назначайте Available Time не "прямо сейчас": дайте время для того, чтобы обновлённый SUPkg дошёл до назначенных DP.
3. Делайте Required-развёртывания. Во-первых, развёртывание в режиме Available даёт 90% гарантию того, что обновления установлены не будут :). Во-вторых, режим Available не позволяет заранее поместить дистрибутивы в кэш, а это, напомню, иногда гигабайты. Компромиссный вариант - Required-развёртывание с дедлайном в далёком будущем.
4. Назначайте Deadline не "прямо сейчас". а лучше через неделю. Это даст возможность пользователю, если таковой за машиной сидит, установить обновления тогда, когда ему будет это удобно.
5. Не делайте развертывания "втихую" в режиме Hide all notifications. Пользователю вряд ли понравится получить внезапные (для него) замедление работы машины с последующей перезагрузкой. Также при этом он не сможет поставить обновления добровольно.
6. Не подавляйте перезапуск, кроме критичных систем: это также 90% гарантия того, что обновления не будут поставлены месяцами, а следующий релиз WannaCry/NotPetya найдёт чем поживиться в вашем окружении.

Статусы соответствия развёртывания обновлений

Типичные проблемы

Развёртывание обновлений остаётся в состоянии Unknown даже если клиент активен/онлайн в консоли

Обновления не закачиваются

1. Обновление отсутствует в пакете, который распространён на DP в группе границ клиента
2. Что-то мешает закачке и проверке хеша: сетевое оборудование (ох уж эти оптимизаторы WAN-линков!), антивирусное ПО
3. Нет места на диске или кэше: скорее всего первое, если вы не злоупотребляете галочкой "Persist content in client cache"

Обновления устанавливаются с ошибками

1. Недостаток ресурсов: памяти, места на диске - а также "железные" проблемы любого сорта
2. Повреждена установка обновляемого продукта: самое частое - хранилище компонентов  ОС Windows (CBS Store), установка MSI-версий Office.

Клиенты вечно ждут окна обслуживания

1. Неповторяющееся окно в прошлом или далёком будущем. Это ошибка администратора, которую может быть нетривиально решить, если коллекций и окон обслуживания на них много. Напомню, что есть штатный отчёт по окнам обслуживания, доступным конкретному клиенту, ну и порекомендую не злоупотреблять неповторяющимися окнами.
2. Если на клиента назначено хотя бы одно окно обслуживания только для обновлений (Software Updates/Type=4), то он не будет устанавливать обновления в окно для всех развёртываний (All Deployments, Type=1). Это поведение будет рано или поздно исправлено, пока же я рекомендую учитывать его при развёртываниях.

Развёртывание обновлений успешно, однако некоторые обновления не установлены

Продолжение следует

Переход на распространение обновлений через ConfigMgr

1. Настройки, связанные с членством машины в группе AD, будут применены только после перезагрузки машины (или сброса кэша Kerberos). Поэтому позаботьтесь или о перезагрузке пилотных машин после добавления в группу, либо о развертывании минималистичного скрипта.
2. Помните про трафик и нагрузку на сервер WSUS, связанные с полным сканированием: если пилотная группа окажется чересчур велика, то вы рискуете перегрузить каналы связи и/или пул приложения WSUS в IIS. Впрочем, при соблюдении лучших практик по настройке WSUS из предыдущей части последнее маловероятно.

Типичные проблемы

Group Policy Conflict

Сетевые проблемы

1. Файрволлы
2. DNS
3. Прокси (да, агент WUA умеет читать пользовательские настройки)
4. …

Проблемы Windows Update Agent

1. Windows 7 и 2008 R2: https://support.microsoft.com/en-us/help/3138612/windows-update-client-for-windows-7-and-windows-server-2008-r2-march-2
2. Windows 8.1 и 2012 R2: https://support.microsoft.com/en-us/help/3138615/windows-update-client-for-windows-8-1-and-windows-server-2012-r2-march

$KB = 'KB3138612'
If(Get-WmiObject -Namespace 'root/cimv2' -Class 'Win32_QuickFixEngineering' -Filter "HotFixId = '$KB'"){Write-Output "$KB is installed"; Exit}
Else {Exit} 

Всевозможные проблемы на уровне ОС

Ошибка "Exceeded max server round trips: 0x80244010" при первичном сканировании

Продолжение следует

Развертывание инфраструктуры SUP в ConfigMgr

Кау устроены обновления

Как работает инфраструктура обновлений

Как работает «домашний» клиент

Как работает клиент WSUS

Как работает ConfigMgr/SUP

Дизайн инфраструктуры

Настройки SUP/WSUS

Подводные камни

Продолжение следует

select SMS_R_SYSTEM.ItemKey,
 SMS_R_SYSTEM.DiscArchKey,
 SMS_R_SYSTEM.Name0,
 SMS_R_SYSTEM.SMS_Unique_Identifier0,
 SMS_R_SYSTEM.Resource_Domain_OR_Workgr0,
 SMS_R_SYSTEM.Client0
 from vSMS_R_System AS SMS_R_System
 INNER JOIN VB_SCCM_Programs_DATA AS SMS_G_System_SCCM_Programs
 ON SMS_G_System_SCCM_Programs.MachineID = SMS_R_System.ItemKey
 INNER JOIN vSMS_G_System_SoftwareFile AS SMS_G_System_SoftwareFile
 ON SMS_G_System_SoftwareFile.ClientId = SMS_R_System.ItemKey
 where (SMS_G_System_SoftwareFile.FileName = N'PATCHSET13.dll'
 OR SMS_G_System_SCCM_Programs.PkgID00 = N'PR10028A' OR SMS_G_System_SCCM_Programs.PkgID00 = N'PR20028A'))

1. Администратор, подключившись консолью к CAS, создает новую коллекцию или изменяет уже имеющуюся. Он создает Collection Query Rule на языке WQL, которое по какому-то признаку отбирает компьютеры в эту коллекцию. Коллекция теперь отображается в консоли с "песочными часами", так как ждет обновления.
2. Через механизм DRS (Data Replication Service, репликация на основе собственного кода Configuration Manager в SQL Service Broker) эта коллекция попадает в БД других первичных сайтов. Коллекции глобальны, и попадают на все первичные сайты, где бы в иерархии они ни были бы созданы, то есть, если администратор подключается консолью к перичному сайту, и создает коллекцию "там", она все равно попадает на CAS, и реплицируется на остальную иерархию. В этом случае процесс удлиняется на один шаг (Pri > CAS > Вся иерархия), поэтому работать все же рекомендуется с CAS (именно по этому он его назвали "Центральный административный сайт").
3. Компонент SMS_COLLECTION_EVALUATOR (Colleval) посредством триггеров в БД и служебных файлов в инбоксе colleval.box на каждом первичном сайте получает задание на пересчет правил членства нашей коллекции, и помещает его в один из своих пяти потоков-очередей (подробнее об этих потоках написано ниже). Если в очереди есть другие коллекции, то наша коллекция ожидает, когда обработаются те. За нашей коллекцией также может собраться очередь, пока членство в ней вычисляется. На центральном сайте компонент SMS_COLLECTION_EVALUATOR не присутствует, его там нет.
4. Опять-таки на каждом первичном сайте, Colleval на сервере SQL выполняет запрос, который написал администратор в начале нашего процесса, но конвертированный из WQL в язык T-SQL. Это ключевой момент. Скорость обработки этого запроса - главное, что оказывает влияние на работу коллекций. Пока наш запрос вычисляется на сервере, другие коллекции ждут с "песочными часами". Эту активность можно наблюдать в логе Colleval.log (включите повышенную детальность логов и SQL логирование в реестре, если хотите видеть больше), в SQL Management Studio в разделе Activity Monitor, в продвинутом случае - SQL Profiler. В работе Colleval задействована также папка инбоксов- Inbox\Colleval.box.
5. Когда членство в коллекции определено, с каждого сайта список машин через DRS посылается на CAS. Как только все первичные сайты пришлют свою часть информации, коллекция на CAS наполняется, "песочные часы" снимаются, администратор видит список компьютеров, а на первичных сайтах формируются политики из назначений, которые администратор поставил на эту коллекцию. Если на каком-то сайте линк репликации работает плохо, или SQL сервер не справляется с нагрузкой, коллекции могут "подвиснуть", в этом один из многих недостатков иерархии из нескольких первичных сайтов и CAS.

• Качество WQL запросов в правилах коллекций
• Количество коллекций и частота их обновления по расписанию
• Ресурсы и быстродействие серверов SQL
• Объем данных, из которых идет выборка
• Своевременное обслуживание БД (индексы, статистика), которое штатной Mantenance Task не обеспечивается
• Корректная работа межсайтовой репликации с первичными сайтами, если их несколько и есть CAS. Если с одним из сайтов линк отказал, коллекции могут оставаться в состоянии обновления

Потоки и работа SMS_COLLECTION_EVALUATOR

• Primary (также известен в colleval.log как Full)- отвечает за Full Collection Update по расписанию, установленному в свойствах коллекции.
• Express (Incremental) - выполняет инкрементальное обновление тех коллекций, где оно включено.
• Manual (обозначен как Single) - здесь обрабатываются коллекции, на которых администратор выполнил Update Collection Membership. В Manual попадают коллекции, у которых нет зависимостей.
• Auxiliary является дочерним потоком Manual, и обрабатывает зависимости обновляемых вручную коллекций.
• New - Для новых коллекций есть отдельный выделенный поток. Сюда попадают только что созданные коллекции, которые сразу же начинают просчитываться.

Incremental Update

Как работает расписание?

Цепочки обновления коллекций и зависимости

Рекомендации по работе с коллекциями

• Возможность обновляться по расписанию, и динамически добавлять/удалять членов без вмешательства администратора.
• Query Rule может обновляться по расписанию, Direct Rule же остается привязанным к Resource ID добавленной машины навечно.
• Не требует обслуживания (написал запрос и забыл)

Поменьше используйте LIKE обрамленный двумя символами '%', например Where SoftwareName LIKE '%Office%'. Такой запрос не использует преимущества индексов на полях, и проходит через каждую строчку в столбце, что может быть в десятки раз медленней.

SELECT
     TableName = t.name,
     IndexName = ind.name,
     IndexId = ind.index_id,
     ColumnId = ic.index_column_id,
     ColumnName = col.name,
     ind.*,
     ic.*,
     col.*
FROM
     sys.indexes ind
INNER JOIN
     sys.index_columns ic ON ind.object_id = ic.object_id and ind.index_id = ic.index_id
INNER JOIN
     sys.columns col ON ic.object_id = col.object_id and ic.column_id = col.column_id
INNER JOIN
     sys.tables t ON ind.object_id = t.object_id
WHERE
     ind.is_primary_key = 0
     AND ind.is_unique = 0
     AND ind.is_unique_constraint = 0
     AND t.is_ms_shipped = 0
ORDER BY
     t.name, ind.name, ind.index_id, ic.index_column_id;

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ARPDisplayName = "Microsoft Office Professional Plus 2013"

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ProductName = "Microsoft Office Professional Plus 2013"

(select vc.SiteID as [CollID],
vc.CollectionName, 'Not_Like' as Category, s.SQL
from v_Collections vc 
inner join Collection_Rules_SQL s
on vc.CollectionID=s.CollectionID
where
s.SQL like '%not like%')
UNION
(select vc.SiteID as [CollID],
vc.CollectionName,
'Not_Equal'
as CAT,
s.SQL
from v_Collections vc
inner join Collection_Rules_SQL s
on vc.CollectionID=s.CollectionID
where s.SQL like '%<>%')

Устранение проблем с работой коллекций

1. Проверьте межсайтовую репликацию, если у вас есть CAS. Если один из сайтов испытывает проблемы с SQL или связью с иерархией, коллекции на CAS могут прекратить обновляться, пока проблема не будет устранена.
2. Проверьте нагрузку на серверы SQL всех первичных сайтов, прежде всего по процессорам, записи на диск с БД, памятью. Если серверы с трудом справляются с нагрузкой, коллекции будут работать медленно.
3. Почитайте логи <ConfigMgr>\Logs\colleval.log и статусные сообщения нашего компонента в консоли (Monitoring > System Status > Component Status > SMS_COLLECTION_EVALUATOR) на наиболее занятых первичных сайтах, можно начать с одного. Есть ли в логах ошибки в работе с SQL сервером? Проблемы со связью, записью в таблицы? Идёт ли работа в colleval.log? Если ошибки с SQL есть, необходимо устранить их, дело не в коллекциях. Установите фильтр cmtrace.exe (вы же ей открывали colleval.log?) на слово seconds. Вы увидите в реальном времени, сколько секунд уходит на обработку правил. Если нормальная работа в colleval.log видна, переходите к следующему пункту. Помните, что все потоки Colleval пишут в этот лог, и если один из них застрял на определенной коллекции, лог все равно не встанет колом, а будет обновляться и дальше от других потоков. Обновляющийся лог это не показатель безпроблемной работы коллекций.Обратите внимание, что сообщения в логе "Failed to manage all files in inbox. Will retry on next processing cycle" не являются проблемой и не мешают работе системы - это косметический дефект, возникающий когда коллекцию создали и быстро удалили, а файлы-триггеры в инбоксе остались. Старые файлы можно удалить вручную, это не навредит.В случае необходимости, можно увеличить максимальный размер файла лога, и включить SQL логирование через реестр на сервере сайта.
4. Запустите CEViewer на одном или нескольких первичных сайтах. Предпочтение отдайте тому сайту, где больше всего клиентов, либо у которого самый медленный SQL - там запросы идут наиболее тяжело. Оцените общую ситуацию. Закладка All Queues даст представление о том, насколько быстро обновлятся коллекции, какова очередь, что вообще происходит. Что происходит в Running Evaluations? Двигается ли очередь?Зайдите во вкладки с разными видами очередей (это потоки, которые описаны в этой статье выше) и проверьте время обновления коллекций в секундах. Если у вас есть коллекции, обновляющиеся больше 60-100 секунд, это повод крепко задуматься над их оптимизацией. Есть вероятность, что ваши коллекции "висят" из-за того, что накопилась критическая масса долго выполняющихся правил. Если это так, посмотрите раздел "Рекомендации по построению коллекций", и попробуйте оптимизировать свои правила. Если проблема возникла внезапно и раньше задержек не было, скорее всего кто-то создал долго выполняющийся запрос, который мы сможем выявить в следующем шаге.
5. Откройте SQL Management Studio и выполните на SQL первичного сайта запрос, который покажет процессы SMS_COLLECTION_EVALUATOR, работающие или приостановленные прямо сейчас:

   SELECT sess.program_name,
   sqltext.TEXT,
   req.session_id,
   req.status,
   req.command,
   req.cpu_time,
   req.total_elapsed_time
   FROM sys.dm_exec_requests req
   Left join sys.dm_exec_sessions sess on sess.session_id = req.session_id
   
   CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
   WHERE sess.program_name like 'SMS_COLLECTION%'
   ORDER BY req.total_elapsed_time DESC

   Запросы выводятся в порядке времени выполнения (поле total_elapsed_time). В поле SQLText мы видим текст этих запросов. Один из них, вероятно, является "тяжелым" запросом из вашей коллекции. Может так случиться, что этот запрос никогда не завершается, поэтому в предыдущем шаге, в CEViewer вы его времени выполнения никогда не увидете. Именно этот случай произошел в начале статьи. Если запрос какой-то коллекции выполняется весьма долго, то в colleval.log вы этого также можете не увидеть. Лог будет бежать дальше, так как другие коллекции в других потоках будут считаться нормально. Например, инкрементальное обновление коллекций будет работать, в то время как обсчет новых коллекций будет введен в ступор вашим запросом.

    Посмотрите текст запроса в поле TEXT, найдите в нём откуда идет выборка данных (после оператора FROM).

    

       Скопируйте названия этих таблиц или небольшой кусок запроса вокруг них, выполните новый запрос, чтобы найти проблемную коллекцию

   select * from v_Collections
    where CollectionID in
    (select CollectionID from collection_rules where collectionID in
    (select collectionid from collection_rules_sql
    where sql like‘%ЧАСТЬ ТЕКСТА ПРОБЛЕМНОГО ЗАПРОСА%’
    ))

   В результате вы найдете проблемную коллекцию, и сможете приступить к её оптимизации. Если этот конкретный запрос прямо сейчас в статусе Running в списке задач - Зайдите на сервер SQL и проверьте размер файлов TempDB, tempdb.ldf. Растут ли эти файлы прямо сейчас? Если рост некотролируемо продолжается, попробуйте изменить запрос коллекции на тот, что будет работать нормально, или просто удалив неудачное правило.Затем на ваших SQL серверах в SQL Management Studio зайдите в Activity Monitor (прав. кнопка мыши на сервер, Activity Monitor), далее Processes, и завершите процесс от SMS_COLECTION_EVALUATOR с вашим неудачным запросом.

Терминальные серверы:

Пользовательские политики

Инвентаризация:

Software Metering

Управление пользовательскими профилями

Общие рекомендации

Задачи обслуживания сайта

Поддержание базы данных драйверов

Патчи, патчи и еще раз патчи

Внесение изменений в БД и бэкап снепшотами VM

Заключение

Инвентаризация

Классы WMI, которые просто собирают слишком много данных

Класс WMI, который может остановить работу всей инфраструктуры: Win32_UserAccount

Слишком частое расписание инвентаризации

Циклы и расписания

Обнаружение ресурсов

Запрос политик и развертывания “As soon as possible”

Сканирование и оценка обновлений

Переоценка коллекций и "тяжелые" запросы

Продолжение следует...

Диалог нам понадобится для того, чтобы дать пользователю возможность изменить поведение Task Sequence. Логика работы TS будет зависеть от значения переменных TS. Например, мы можем пропустить выполнение какого-либо шага TS, если значение определенной переменной будет FALSE. В диалоге мы будем считывать значения, введенные пользователем и основываясь на этой информации будем присваивать значения переменным TS.

Из каких элементов состоит пользовательский интерфейс? Из объектов, которые еще называют Windows Controls. Они бывают разными – всевозможные списки, кнопки, вкладки, меню, поля для ввода текста, надписи и так далее. Основным элементом каждого интерфейса является форма. Собственно, это и есть окно в привычном для нас понимании. Оно может иметь заголовок и кнопки свертывания, маскимизации/минимизации, закрытия в правом верхнем углу. На форме мы располагаем остальные элементы интерфейса. Вот что мы будем использовать в нашем примере:

• Form – это форма, основа для других элементов интерфейса
• TabControl – для пользователя этот элемент выглядит как вкладки. Мы создадим в нашем диалоге 2 вкладки, чтобы эффективней расположить остальные элементы
• Label – в основном этот тип объектов используется для показа всевозможных надписей. Но мы его используем еще и с целью группировки RadioButton
• RadioButton – переключатель состоящий из нескольких элементов, мы будем использовать его для того чтобы пользователь выбрал одну опцию из нескольких предложенных
• TextBox – поле для ввода текста
• ComboBox – выпадающий список, в котором обычно пользователь может выбрать какой-либо элемент
• CheckBox – не могу подобрать заумное описание. Это просто квадратик, в котором можно поставить галочку :)
• Button - кнопка

Вообще элементов создано довольно много, полный перечень и описание можно найти на msdn. Элементы пользовательского интерфейса обладают различными свойствами: ширина, высота, местоположение, надписи, активность (доступен элемент для использования или заблокирован), видимость и пр.

Мы можем отслеживать и обрабатывать различные события, генерируемые при взаимодействии с элементами интерфейса. В данном случае, мы хотим, чтобы при нажатии кнопки Apply считались все выбранные пользователем опции и записались в переменные Task Sequence. Для этого мы воспользуемся событием Click. А точнее, мы впишем свой код в процедуру, вызываемую при возникновении события Click у кнопки Apply. Событий также создано немало и с ними можно делать много интересного: например, отслеживать изменение текста в текстовом поле, отслеживать изменение размера объекта, отслеживать момент, когда пользователь помещает указатель мыши на объект и пр. Хотите знать больше – вам опять прямая дорога в один из разделов msdn.

Логику скрипта не сложно понять, я дам только общее описание. Сначала прячем окно интерфейса Task Sequence:

$objTSProgressUI = New-Object -COMObject Microsoft.SMS.TSProgressUI

$objTSProgressUI.CloseProgressDialog()

Далее создаем объект для доступа к переменным Task Sequence

$objTSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment

В нашем диалоговом окне есть опция выбора OU и нужно как-то подгрузить список OU в ComboBox. В скрипте мы возьмем значения из заранее подготовленного текстового файла и запишем их в переменную:

$OUList = Get-Content "OUList.txt"

#delete empty lines

$OUList = $OUList | ? {$_.trim() -ne "" }

Вот пример текстового файла со списком OU:

Помещаем текстовый файл в один пакет со скриптом PowerShell. А вот пример, как можно создать такой текстовый файл с помощью PowerShell:

Get-ADOrganizationalUnit -Filter * -Properties DistinguishedName | Select-Object -ExpandProperty DistinguishedName | Out-File "C:\Windows\Temp\OUlist.txt"

Вернемся к скрипту, который рисует форму с опциями. Создадим форму и определим некоторые ее свойства:

Add-Type -AssemblyName System.Windows.Forms

$objForm = New-Object System.Windows.Forms.Form

$objForm.Text = "Don't hesitate to use deployment options"

$objForm.Size = New-Object System.Drawing.Size(670,430)

$objForm.StartPosition = "CenterScreen"

$objForm.Topmost = $True

$objForm.MaximizeBox = $false

$objForm.MinimizeBox = $false

Потом создадим элементы управления, например, TabControl:

$objTab = New-Object System.Windows.Forms.TabControl

$objTab.Size = New-Object System.Drawing.Size(653,333)

$objForm.Controls.Add($objTab)

$objTab = New-Object System.Windows.Forms.TabControl

$objTab.Size = New-Object System.Drawing.Size(653,333)

$objForm.Controls.Add($objTab)

$ApplyButton.Add_Click({

$objTSEnv.Value("OSDComputerName")=$objTextBox_PCName.Text

If($objComboBox_PCOU.SelectedIndex -ne 0) { $objTSEnv.Value("OSDDomainOUName")="LDAP://" + $objComboBox_PCOU.SelectedItem }

If($objCheckBox_SW1.Checked -eq $True) { $objTSEnv.Value("InstallApp01")=$True }

If($objCheckBox_SW2.Checked -eq $True) { $objTSEnv.Value("InstallApp02")=$True }

If($objCheckBox_SW3.Checked -eq $True) { $objTSEnv.Value("InstallApp03")=$True }

If($objCheckBox_SW4.Checked -eq $True) { $objTSEnv.Value("InstallApp04")=$True }

If($objCheckBox_SW5.Checked -eq $True) { $objTSEnv.Value("InstallApp05")=$True }

If($objCheckBox_SW6.Checked -eq $True) { $objTSEnv.Value("InstallApp06")=$True }

if($objRadioButtonYes_DisableAdmin.Checked -eq $True) { $objTSEnv.Value("OSDRandomAdminPassword")=$True}

if($objRadioButtonNo_DisableAdmin.Checked -eq $True) { $objTSEnv.Value("OSDRandomAdminPassword")=$False}

if($objRadioButtonYes_Updates.Checked -eq $True) { $objTSEnv.Value("InstallUpdates")=$True}

$objForm.Close()

})

$objForm.Add_Shown({$objForm.Activate()})

[void] $objForm.ShowDialog()

Теперь нужно написать пару слов о том, как запустить этот скрипт в Task Sequence. Во-первых, нужно добавить опциональные компоненты в используемый загрузочный образ:

Во-вторых, если просто использовать шаг Run PowerShell Script, то скрипт запустится, но пользователь не увидит ничего на экране. Чтобы сделать окно видимым, я использую шаг Run Command Line

ServiceUI.exe -process:TSProgressUI.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File OSD_options.ps1

ServiceUI.exe входит в состав Microsoft Deployment Tools (MDT). В зависимости от архитектуры загрузочного образа используем x86 или x64 версию ServiceUI.exe. Ну и не забываем, что этот файл нужно положить в тот же пакет, рядом с нашим PowerShell-скриптом. Ссылку на полную версию скрипта можно найти в самом конце статьи.

Также, нельзя умолчать о том, что существует более продвинутый способ рисования пользовательского интерфейса для скриптов на PowerShell. Он не требует расчета координат элементов. Особенно это удобно, когда элементов много. Можно буквально взять и перевернуть кнопку вверх ногами. Если коротко, то все сводится к тому чтобы в Visual Studio (можно использовать Visual Studio Express) с помощью мыши создать форму с необходимыми элементами. В итоге получаем XML-код (XAML), который мы копируем и вставляем в наш PowerShell-скрипт. Подробное описание процесса есть в статье Integrating XAML into PowerShell Концепция сильно напоминает HTML-приложение – можно сказать виток эволюции завершился, и мы вернулись к тому, с чего начали. Удачного скриптинга!

OSD_options.ps1

Как известно, группы могут быть как статическими, с набором определенных объектов, так и динамическими, наполняться объектами с помощью определенных правил.

Если у вас стоит задача создания динамического распределенного приложения, т.е. объекты будут автоматически появляться в распределенном приложении при добавлении в SCOM. Вам нужно:

1. Создать распределенное приложение с помощью Distributed Application Designer, пошаговая инструкция написана в статье https://blogs.technet.com/b/scpferublog/archive/2014/12/01/3641862.aspx.
2. Экспортировать пакет управления, который содержит ваше распределенное приложение.
3. Найти обнаружения, которые наполняют компоненты объектами. Они выглядят примерно так:

Далее вместо списка статических объектов ( IncludeList), задать правило, например, обнаружение объектов по регулярному выражению:

   <Discovery ID="SC_e80199dc58db47ab85f317d6cd562a44_Service_35027f900c494cbe970373f8ea010a74_ItemPopulation" Enabled="true" Target="SC_e80199dc58db47ab85f317d6cd562a44_Service_35027f900c494cbe970373f8ea010a74" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes />
        <DataSource ID="DS" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$Target/Id$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="MicrosoftSQLServer2012Discovery6540!Microsoft.SQLServer.2012.Database"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="SCIMembership_fbce7dd725a04618ac3cfb4e9eb7aef6"]$</RelationshipClass>
              <IncludeList>
                <MonitoringObjectId>{5b3d0894-daf9-7c0a-6e5d-01c1e716806f}</MonitoringObjectId>
                <MonitoringObjectId>{6cd04aca-6262-8bf6-85fe-541e84211e2e}</MonitoringObjectId>
                <MonitoringObjectId>{3fd4adb5-909f-2db6-eaa2-022b666abecb}</MonitoringObjectId>
                <MonitoringObjectId>{62c8ebe1-fb87-3e3d-4e57-4113348ef592}</MonitoringObjectId>
                <MonitoringObjectId>{b5d2ff79-99b3-ac25-72a9-cadd5f558aa9}</MonitoringObjectId>
              </IncludeList>

 <!-- Заменить на -->

                <Expression>
                <RegExExpression>
                  <ValueExpression>
                    <Property>$MPElement[Name="SystemLibrary7585010!System.Entity"]/DisplayName$</Property>
                  </ValueExpression>
                  <Operator>MatchesRegularExpression</Operator>
                  <Pattern>DB1|DB2</Pattern>
                </RegExExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>

В результате, данный  компонент распределенного приложения будет автоматически наполняться объектами класса Microsoft.SQLServer.2012.Database с именами DB1 или DB2.

Это происходит по причине того, что ключевой атрибут ObjectName класса  Microsoft.JEE.Application  c пакета управления Microsoft.JEE.Library имеет ограничение в 512 символов. Более подробно данная проблема описана в статье https://blogs.technet.com/b/random_happy_dev_thoughts/archive/2013/01/31/howto-monitor-ejbs-with-beanspy-in-scom-2012-on-websphere-6-1-version-2.aspx. Также в данной статье есть ссылка на пакет управления, который обнаруживает WebSphere приложения версии 6.

На данный момент существует более новая версия WebSphere 8. Я модифицировала данный пакет управления под новую версию и добавила в него монитор, который проверяет доступность приложений WebSphere.

Данная статья носит информационный характер, ссылки на веб-сайты предоставляются для удобства пользователей. Корпорация Майкрософт не несет никакой ответственности за содержание веб-сайтов, не предоставляет никаких гарантий относительно точности, полноты или законности их содержания, ссылки на которые используются в данной статье. Ссылка на внешний узел не подразумевает одобрения мнений, информации или продукции представленной на таких веб-сайтах.

Microsoft.JEE.WebSphere.8.EJBCustom.zip

Предположим, нам нужен отчет, в котором мы сможем увидеть список компьютеров, на которых присутствует определённый файл. Также мы хотим, чтобы этот отчет позволял фильтровать по операционной системе и архитектуре компьютеры, попадающие в отчет. Предварительно, я настроил и выполнил инвентаризацию файлов на клиентах. Условие задачи слегка надумано, но в момент написания статьи, мне в голову ничего более жизненного не пришло.

Я предпочитаю начинать создание отчета с написания запроса в SQL Management Studio. Если нужен отчет с какой-либо информацией, касающейся клиентов, то с большой вероятностью для построения запроса понадобится использовать представление v_R_System. В этом представлении хранится базовая информация о компьютерах, известных ConfigMgr’у.

Вот запрос, с которого я начну:
SELECT Netbios_Name0, Operating_System_Name_and0
FROM v_R_System

 
Теперь у меня есть имя компьютера и название ОС. Далее мне нужны данные по архитектуре ОС. На TechNet есть перечень представлений и краткое описание https://technet.microsoft.com/en-us/library/dn581978.aspx   Описание довольно скудное и часто приходится самостоятельно заглядывать в представления, чтобы понять, какая информация там хранится. Это можно сделать, не создавая никаких запросов вручную. В management studio кликаем правой кнопкой на представлении и выбираем пункт меню Select Top 1000 Rows:

 
Покопавшись, я отыскал представление, хранящее данные об архитектуре и добавил его в свой запрос:
SELECT Netbios_Name0, Operating_System_Name_and0, SystemType0
FROM v_R_System AS SYS
INNER JOIN v_GS_COMPUTER_SYSTEM as COMPSYS ON SYS.Resourceid= COMPSYS.Resourceid

 
Далее нам нужно найти, где хранятся данные о найденных на клиентах файлах (Software Inventory). Довольно часто можно угадать, как примерно будет называться таблица или представление. Выполняем клик правой кнопкой по папке Views в SQL Server Management Studio и фильтруем список представлений по слову file:

 
В результатах находим представление v_GS_SoftwareFile – оно-то нам и нужно. Модифицируем запрос:

Select Netbios_Name0, Operating_System_Name_and0, SystemType0, FileName
FROM v_R_System as SYS
INNER JOIN v_GS_COMPUTER_SYSTEM AS COMPSYS ON Sys.resourceid=compsys.resourceid
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
 

Список можно фильтровать по различным критериям, например, так:

SELECT Netbios_Name0, Operating_System_Name_and0, SystemType0, FileName
FROM v_R_System AS SYS
INNER JOIN v_GS_COMPUTER_SYSTEM AS COMPSYS ON Sys.resourceid=compsys.resourceid
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
WHERE FileName like '%test_file.vbs%'
AND Operating_System_Name_and0 like '%Workstation%'
AND SystemType0 like 'x64%'

 
Это был пример с фиксированными условиями отбора результатов, позже мы изменим отчет так, чтобы брать значения для критериев отбора прямо из параметров отчета.

Однако, как бы мы не фильтровали результаты запроса, мы имеем пока список файлов, а не компьютеров.  Для одного и того же компьютера в отчете может быть несколько строчек, т.к. найдено несколько файлов, удовлетворяющих критериям поиска. Для того чтобы логически перейти от списка файлов к списку компьютеров, применяем группировку и убираем не нужные поля из результата. Под ненужными полями в данном случае я подразумеваю поля, по которым мы фильтруем результат, но отображать их не хотим. Также я посчитал нужным добавить в отчет еще один столбец:

SELECT Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0
FROM v_R_System AS SYS
INNER JOIN v_GS_COMPUTER_SYSTEM AS COMPSYS ON Sys.resourceid=compsys.resourceid
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
WHERE FileName like '%test_file.vbs%' AND Operating_System_Name_and0 like '%workstation%' AND SystemType0 like 'x64%'
GROUP BY Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0

 
Сам запрос почти готов, осталось только сделать отчет на его основе. Для этого открываем консоль ConfigMgr, переходим в раздел Monitoring и выделяем папку Reporting. Справа появится ссылка на Report Manager.

 
Переходим по ссылке. Заходим в папку ConfigMgr_T01, где T01 это ваш сайт-код. Тут, пожалуй, можно создать отдельную папку для нашего отчета: My Custom Reports. В папке запускаем Report Builder:

 
Ждем пока Report Builder загрузится:

 
Здесь нужно заметить, что для подключения к Reporting Services при разработке отчетов иногда приходится запускать Report Builder, Internet Explorer и даже SQL Management Tools с повышенными привилегиями. Если что-то не работает, как это ожидается или вы не видите какие-либо элементы интерфейса, объекты, которые ожидаете увидеть – пробуйте Run as Administrator. В данном случае, у меня консоль ConfigMgr запущена с повышенными привилегиями, а, следовательно, и окно IE у меня также открывается с повышенными привилегиями.

Создаем новый отчет, выбирая Table or Matrix Wizard:

 
Создаем новый Dataset, по-нашему это набор данных. А по сути это запрос, результат которого мы будем отображать в таблице отчета.

 
На следующей странице жмем Browse, заходим в папку ConfigMgr_<код сайта> и в самом конце списка выбираем уже существующий DataSource – источник данных, т.е. база данных, к которой будем подключаться.

 
Нажимаем Next и подключаемся, используя учетные данные текущего пользователя.

 
Дальше нам нужно сконструировать запрос. Это можно сделать двумя путями: с помощью дизайнера запроса или просто напечатать код. У нас есть готовый код, так что срузу жмем кнопку Edit as Text и вставляем текст запроса в поле. Тут же можно проверить запрос, нажав кнопку Run.

 
 
На следующей странице перетаскиваем все доступные поля в область Values:

 
На остальных страницах мастера оставляем все по умолчанию. После закрытия мастера имеем такую картину:

 
Сохраняем отчет на сервере. Впринципе отчет уже можно запускать, но я сначала предпочел дать колонкам удобоваримые имена, настроить их ширину и обозначить заголовок. Также неплохо было бы сделать сортировку по столбцам, остановлюсь на этом подробнее. Для этого кликаем правой кнопкой на заголовке столбца с именем компьютера, выбираем Text Box Properties:

 
Далее переходим в раздел Interactive Sorting и включаем сортировку:

Аналогично настраиваем сортировку для всех остальных столбцов.

Теперь разберемся с параметрами отчета. Сейчас мы фильтруем результат по жестко заданным критериям в запросе. Я хочу, чтобы пользователь имел возможность изменять эти критерии при запуске отчета. Для этого мне нужно создать параметры и наборы данных, из которых будут подгружаться списки возможных значений для параметров. Добавим параметр OSNAME, предварительно создав еще один набор данных, из которого будет подгружаться список его возможных значений:

SELECT distinct Operating_System_Name_and0 from v_R_System
WHERE Operating_System_Name_and0 is not null

 
 
Параметр готов, теперь его нужно задействовать в нашем основном запросе. Кликаем правой кнопкой по Dataset1 и редактируем запрос

Сейчас можно в очередной раз сохранить отчет и проверить как работает параметр. Он работает, но мне этого мало. В данном варианте мы можем выбрать только одну из операционных систем, а я бы хотел иметь возможность также посмотреть отчет по всем операционным системам сразу. Для этого нам понадобиться создать вспомогательный параметр и изменить запросы в OSNAME_Dataset и Dataset1 (основной). При использовании параметров нужно помнить, что их имена чувствительны к регистру.
 
 

Меняем запрос в OSNAME_Dataset:

Изменяем запрос в Dataset1

 
SELECT Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0
FROM v_R_System AS SYS
INNER JOIN v_GS_COMPUTER_SYSTEM AS COMPSYS ON Sys.resourceid=compsys.resourceid
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
WHERE FileName like '%test_file.vbs%'
AND (@OSNAME = @AllValueParameter OR  SYS.Operating_System_Name_and0=@OSNAME)
AND SystemType0 like '%x64%'
GROUP BY Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0

Порядок параметров также имеет значение. В данном случае AllValueParameter должен быть первым.

Подправлю параметр OSNAME, чтобы он принимал  значение «ALL» в качестве значения по умолчанию. Можно явно указать ALL в Default Values:

 
Либо подставлять значение другого параметра:

 
В данном случае работать будут оба варианта, т.к. значение по умолчанию для параметра AllValueParameter также равно «ALL».
У нас есть отчет с одним параметром. Аналогично добавляем параметр SYSTEMTYPE (архитектура) с набором данных SYSTEMTYPE_Dataset, в котором будет список возможных значений для параметра.

 
SELECT @AllValueParameter AS SystemType0
UNION ALL
SELECT DISTINCT SystemType0
FROM v_GS_COMPUTER_SYSTEM
 
 

 
Добавляем параметр SYSTEMTYPE в наш основной запрос.

 
SELECT Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0
FROM v_R_System AS SYS
INNER JOIN v_GS_COMPUTER_SYSTEM AS COMPSYS ON Sys.resourceid=compsys.resourceid
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
WHERE FileName like '%test_file.vbs%'
AND (@OSNAME = @AllValueParameter OR  SYS.Operating_System_Name_and0=@OSNAME)
AND (@SYSTEMTYPE = @AllValueParameter OR  SystemType0 =@SYSTEMTYPE)
GROUP BY Netbios_Name0, Operating_System_Name_and0, Distinguished_Name0

На выходе получаем отчет такого вида:

 
Все работает, но мне этого все еще недостаточно. На этот раз я хочу, чтобы список доступных для выбора ОС менялся в зависимости от выбранной архитектуры. Этого можно добиться с помощью каскадирования параметров. Каскадирование позволяет динамически получать список возможных значений для одного параметра в зависимости от значения другого. В моем отчете я сначала хочу выбрать архитектуру ОС, а затем уже определиться с именем ОС. Список имен ОС должен формироваться динамически, в зависимости от выбранной архитектуры. Для этого требуется расположить параметры в следующем порядке:

 
И изменить запрос набора данных OSNAME_Dataset таким образом, чтобы фильтровать результат запроса по типу архитектуры. Для этого нам понадобится использовать данные из представления v_GS_COMPUTER_SYSTEM

SELECT @AllValueParameter AS Operating_System_Name_and0
UNION ALL
SELECT distinct Operating_System_Name_and0 FROM v_R_System AS SYS
INNER JOIN v_GS_Computer_System AS COMPSYS
ON SYS.ResourceID=COMPSYS.ResourceID
WHERE Operating_System_Name_and0 is not null
AND SystemType0=@SYSTEMTYPE

Итак, закончив с параметрами, я подумал: а что если на каком-либо компьютере присутствует несколько искомых файлов? Наверное, пользователь захочет узнать, где лежит каждый из них? Эту задачу мы решим, создав еще один отчет, в который можно будет перейти, кликнув по имени компьютера в первом отчете. Во втором отчете будет всего один параметр – имя компьютера.

Точно так же, как для первого отчета, запускаем Report Builder делаем отчет на основе запроса:
SELECT FileName, FilePath
FROM v_R_System as SYS
INNER JOIN v_GS_SoftwareFile AS SF ON sys.ResourceID=SF.ResourceID
WHERE Netbios_Name0=@COMPUTERNAME AND FileName like '%test_file.vbs%'

Параметр COMPUTERNAME создался автоматически. В заголовке отчета подставим имя компьютера. Для этого кликаем правой кнопкой мыши на поле, где написано Click to add title, переходим в TextBox properties.

В поле Value вписываем [@COMPUTERNEME]

 
Не забываем сохраняться. Нам нужно будет передать содержимое ячейки с именем компьютера из первого отчета в качестве параметра во второй отчет. Выполняем двойной клик на ячейке с надписью Netbios_Name0. В появившемся окне переходим в раздел Action и выставляем настройки в соответствии со скриншотом ниже, указав местоположение второго отчета.

 
Имя компьютера в главном отчете будет кликабельным, так что я оформлю его в стиле гиперссылки:

 
Поздравляю, мы закончили и вот что получилось в итоге:

Хинты:

• Чтобы не придумывать дизайн отчета каждый раз, можно создать пустой отчет, соответствующий вашим корпоративным стандартам и использовать его в качестве отправной точки при создании новых отчетов.
• Создавать отчеты можно не только в Report Builder, есть еще такой инструмент как Business Intelligence Development Studio