Отслеживание оценки соответствия обновлений программного обеспечения
Область применения: Configuration Manager
Прежде чем развертывать обновления программного обеспечения для клиентов, клиенты должны выполнить проверку соответствия требованиям по обновлению программного обеспечения. Рекомендуется разрешить клиентам достаточно времени для завершения проверки и соответствия отчета, чтобы просмотреть результаты соответствия требованиям и развернуть только необходимые обновления на клиентах.
При установке и синхронизации точки обновления программного обеспечения (SUP) создается политика компьютера на уровне сайта, которая сообщает клиентским компьютерам, что обновления программного обеспечения Configuration Manager включены для сайта. Когда клиент получает политику компьютера, запуск проверки соответствия требованиям планируется на произвольный момент времени в течение двух следующих часов. При запуске сканирования агент клиента обновлений программного обеспечения очищает журнал сканирования, отправляет запрос на поиск сервера Служб обновления Windows Server (WSUS), который должен использоваться для проверки, и обновляет локальную групповую политику с расположением WSUS.
Общие сведения о процессе оценки соответствия требованиям см. в статье об оценке соответствия обновлений программного обеспечения.
Политика проверки обновлений программного обеспечения
Прежде чем клиент сможет попытаться проверить наличие обновлений, он нуждается в политике UpdateSource. Эта политика создается на сервере сайта после успешной синхронизации SUP. В этом разделе описывается, как эта политика создается следующим процессом:
Шаг 1. После успешной синхронизации WSyncMgr обновляет версию содержимого и время последней синхронизации в базе данных.
После успешной синхронизации на первичном сайте WSyncMgr обновляет время последней синхронизации и версию содержимого в базе данных для SUP. Это делается путем выполнения хранимой spProcessSUMSyncStateMessage
процедуры. В следующем примере трассировки SQL Server Profiler эта хранимая процедура выполняется для обновления версии содержимого до 36:
объявление @Error int; exec spProcessSUMSyncStateMessage N'2014-01-17:59:54', N'PS1, N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}, 1, 0, '36', @Error выходные данные, N'PS1SITE. CONTOSO. COM
Шаг 2. SMSDBMON активируется и удаляется. ФАЙЛ STN в policypv.box
spProcessSUMSyncStateMessage
обновляет таблицу Update_SyncStatus
с новой версией содержимого и временем синхронизации. Это обновление Update_SyncStatus
таблицы активирует SMSDBMON для удаления <UpdateSource_UniqueID>. Файл STN (STN обозначает уведомление средства сканирования) в policypv.box, чтобы указать изменение определения средства сканирования. Следующие данные записываются в систему SMSDBMON.log.
RCV: ОБНОВЛЕНИЕ Update_SyncStatus для UpdSyncStatus_iu [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND: удален E:\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN (ненулевая) [46680] SMS_DATABASE_NOTIFICATION_MONITOR
Шаг 3. Поставщик политик создает или обновляет политику UpdateSource в базе данных
UpdateSource_UniqueID<>. ФАЙЛ STN уведомляет поставщика политик о том, что он должен проснуться и обновить политику UpdateSource в базе данных.
Следующие данные записываются в систему PolicyPv.log.
Найдено {C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN SMS_POLICY_PROVIDER
Добавлен идентификатор средства сканирования {C2D17964-BBDD-4339-B9F3-12D7205B39CC} SMS_POLICY_PROVIDER
Добавление к списку удаления: E:\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN SMS_POLICY_PROVIDER
В трассировке профилировщика SQL Server:
select PolicyID, PolicyAssignmentID, SourceCRC, PADBID из SettingsPolicy , где SourceID = N'PS1' и SourceType = N'UpdateSource'
Выберите версию из политики, где PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f06f0a2be}'
IF EXISTS (select PolicyID from PolicyID from PolicyID = N'{d085677-b0a6-4e33-9bd5-7b0d06f0a2be}') update Policy set Version = N'40.00' where PolicyID = N'{d0855677--b0a6-4e33-9bd5-7b0d06f0a2be}' ELSE insert Policy (PolicyID, Version) values (N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}", N'40.00')exec sp_describe_undeclared_parameters N'UPDATE Policy SET Body = @P1 where PolicyID = N'{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}''
IF EXISTS (select PADBID from PolicyAssignment where PADBID = 16777218) update PolicyAssignment set Version = N'40.00', InProcess = 1, BodyHash = null where PADBID = 16777218 ELSE insert PolicyAssignment (PolicyAssignmentID, PADBID, Version, Значения PolicyID) (N'{375c8020-3cae-4736-89ca-ccf1ce6e3709}', 16777218, N'40.00', N'{d0855677-b0a6-4e33-9bd5-7b0d06f06f0a2be}')exec sp_describe_undeclared_parameters N'UPDATE PolicyAssignment SET Body = @P1 where PADBID = 16777218'
update PolicyAssignment set InProcess = 0, BodySignature = N'BodySignatureTruncated', TombstoneBodySignature = N'TombstoneBodySignatureTruncated<>', HashAlgOID = N'1.2.840.113549.1.1.11', HashAlgId = 32780, BodyHash = N'BodyHashTruncated<', TombstoneBodyHash = N'TombstoneBodyHashTruncated<>>', где PADBID = 16777218<>
Чтобы увидеть эту политику в базе данных, выполните следующий запрос:
SELECT CONVERT(XML, Body, 1), * FROM Policy WHERE PolicyID = (SELECT PolicyID FROM SettingsPolicy WHERE SourceType = 'UpdateSource')
Эта политика содержит версию содержимого сервера обновления, который используется для поиска расположения компьютера WSUS, на котором клиент может проверяться. После создания или обновления этой политики в базе данных клиенты получают новую или обновленную политику UpdateSource во время следующего цикла оценки политики.
Шаг 4. Политика загружается и оценивается на клиенте.
Войдите в систему PolicyAgent.log на клиенте:
Успешно инициировано скачивание политики "CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bdd5- 7b0d06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00"" PolicyAgent_ReplyAssignments
Политика "CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}",PolicyVersion="40.00",PolicySource="SMS:PS1" успешно скомпилирован PolicyAgent_PolicyDownload
В PolicyEvaluator.log на клиенте:
Обновление политики CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00" PolicyAgent_PolicyEvaluator
Примененная политика CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00" PolicyAgent_PolicyEvaluator
Состояние политики для [CCM_Policy_Policy5.PolicyID="{d085677-b0a6-4e33-9bd5-7b0d06f0a2be}",PolicyVersion="40.00",PolicySource="SMS:PS1"] в настоящее время [Активный] PolicyAgent_PolicyEvaluator
Чтобы найти PolicyID
политику UpdateSource на клиенте, выполните следующий WQL-запрос:
- Пространство имен:
ROOT\ccm\Policy\Machine\RequestedConfig
- Запрос:
SELECT * FROM CCM_Policy_Policy5 WHERE PolicyCategory = 'UpdateSource'
После компиляции этой политики на клиенте сведения UpdateSource хранятся в следующем классе WMI:
Пространство имен: ROOT\ccm\Policy\Machine\ActualConfig
Класс: CCM_UpdateSource
Совет
При сравнении экземпляра CCM_UpdateSource
класса на клиенте с XML-текстом, полученным из таблицы политик, вы увидите, что содержимое XML выглядит идентично экземпляру.
Шаг 5. Агент сканирования уведомляется о том, что политика UpdateSource обновлена.
Войдите в систему ScanAgent.log на клиенте:
Внутри CScanAgent::Notify() ScanAgent
CScanAgent::OnPolicyChange— уведомление InstanceModificationEvent политики получило уведомление ScanAgent
Расположение сервера WSUS
После получения политики UpdateSource клиент имеет необходимую конфигурацию для запуска проверки. Однако обновления политики не инициируют немедленные проверки. Сканирование можно активировать вручную с помощью панели управления Configuration Manager или автоматически выполняться в следующее запланированное время. На этом этапе клиент находит компьютер WSUS с версией содержимого, указанной в политике. Этот процесс очень похож на то, как клиент находит расположение точки распространения для определенного пакета и версии.
Шаг 1. Агент сканирования создает запрос сканирования на основе доступной политики
Следующие данные регистрируются ScanAgent.log.
CScanAgent::ScanByUpdates— политика доступна для UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent::ScanByUpdates- Добавлена политика для окончательного scanRequest List UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, Policy-ContentVersion=38, Required-ContentVersion=38 ScanAgent
Шаг 2. Агент сканирования отправляет запрос на расположение WSUS в службы расположения
Агент сканирования теперь запрашивает расположение WSUS из служб расположения и ожидает ответа. В этом примере идентификатор запроса расположения — {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}. Следующие данные регистрируются ScanAgent.log.
Внутри CScanAgent::P rocessScanRequest() ScanAgent
CScanJobManager::Scan— ввел ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Initialize- ввел ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Scan- ввел ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::RequestLocations - введен ScanAgent
- Запрос расположения серверов WSUS из LS для {C2D17964-BBDD-4339-B9F3-12D7205B39CC} версии 38 ScanAgent
- -Location Request ID = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
CScanAgentCache::P ersistInstanceInCache — сохраненный экземпляр CCM_ScanJobInstance ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): - - - Расположения, запрошенные для ScanJobID={4CD06388-D509-46E4-8C00-75909EDD9EE8} (LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}), обработает запрос сканирования после того, как расположения будут доступны. ScanAgent
Каждое задание сканирования хранится в WMI в CCM_ScanJobInstance
классе:
Пространство имен: root\CCM\ScanAgent
Класс: CCM_ScanJobInstance
Шаг 3. Службы расположения отправляют запрос расположения в точку управления
Службы расположений создают запрос расположения и отправляют его в точку управления. Идентификатор пакета для запроса расположения WSUS — уникальный идентификатор UpdateSource. Следующие данные записываются в систему LocationServices.log.
CCCMWSUSLocation::GetLocationsAsyncEx LocationServices
Попытка сохранить запрос расположения WSUS для ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' и ContentVersion='38' LocationServices
Сохраненные службы location wsus request LocationServices
Попытка отправить запрос расположения WSUS для ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' LocationServices
WSUSLocationRequest: <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDDD-4339-B9F3- 12D7205B39CC}" Version="38"/AssignedSite SiteCode="PS1"/><><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2- PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses IPAddress><SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> LocationServices
Создан и отправлен запрос расположения "{C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}" для пакета {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} LocationServices
Шаг 4. Обмен сообщениями CCM отправляет сообщение запроса расположения в точку управления
Войдите в систему CcmMessaging.log:
Отправка асинхронного сообщения "{76453CC6-76BA-4B68-BE30-BA70754570BB}" в исходящую очередь "mp:[http]mp_locationmanager" CcmMessaging
Отправка исходящего сообщения "{76453CC6-76BA-4B68-BE30-BA70754570BB}". Флаги 0x200, учетная запись отправителя пустая CcmMessaging
Шаг 5. Точка управления анализирует запрос, получает расположение WSUS из базы данных и отправляет ответ.
Точка управления анализирует этот запрос и вызывает MP_GetWSUSServerLocations
хранимую процедуру, чтобы получить расположения WSUS из базы данных. Следующие данные регистрируются в MP_Location.log.
MP LM: текст сообщения: <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDDD-4339-B9F3- 12D7205B39CC}" Version="38"/AssignedSite SiteCode="PS1"/><><ClientLocationInfo onInternet="0"><ADSite Name="CM12-"CM12-"CM12-" R2- PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses IPAddress><SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_ LocationManager
MP LM: вызов MP_GetWSUSServerLocations MP_LocationManager
В трассировке профилировщика SQL Server:
exec MP_GetMPSitesFromAssignedSite N'PS1'
exec MP_GetSiteInfoUnified N'ClientLocationInfo< OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/Domain Name="CONTOSO.COM"/><><IPAddresses><IP SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>'
exec MP_GetWSUSServerLocations N'{C2D17964-BBDDD-4339-B9F3-12D7205B39CC}',N'38', N'PS1', N'PS1', N'0', N'CONTOSO. COM
После получения результатов из хранимой процедуры точка управления отправляет клиенту ответ. Войдите в систему MP_Location.log:
MP LM: текст сообщения ответа:
<WSUSLocationReply SchemaVersion="1.00"><Sites><><MPSite SiteCode="PS1"/><LocationRecords LocationRecords WSUSURL=http://PS1SITE.CONTOSO.COM:8530
"" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL=https://PS1SYS.CONTOSO.COM:8531
"" ServerName="PS1SYS.CONTOSO.COM" Version="38"/><LocationRecords><></Site></Sites></WSUSLocationReply> MP_LocationManager
Шаг 6. Обмен сообщениями CCM получает ответ и отправляет его обратно в службы расположений
Файл CcmMessaging.log на клиенте показывает, что был получен ответ. Это сообщение было доставлено в службы расположения:
Сообщение "{76453CC6-76BA-4B68-BE30-BA70754570BB}" получил ответ "{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}" в локальную очередь конечных точек "LS_ReplyLocations" CcmMessaging
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={76453CC6-76BA-4B68-BE30-BA70754570BB}): доставлен успешно на узел "PS1SYS.CONTOSO.COM". CcmMessaging
Сообщение "{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}, доставленное в конечную точку "LS_ReplyLocations" CcmMessaging
Шаг 7. Службы расположения анализирует ответ и отправляет расположение обратно в агент сканирования.
Следующие данные записываются в систему LocationServices.log.
Ответное сообщение Location LocationServices 1.20.2014 12:18:09
WSUSLocationReply: <WSUSLocationReply SchemaVersion="1.00"><Sites><><MPSite SiteCode="PS1"/><LocationRecords LocationRecords><WSUSURL="http://PS1SITE.CONTOSO.COM:8530
" ServerName="PS1SITE.CONTOSO.COM "Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531
" ServerName="PS1SYS.CONTOSO.COM" Version="38"/><LocationRecords></Site></Sites></WSUSLocationReply> LocationServices
Обратный вызов со следующими расположениями WSUS LocationServices
WSUS Path='http://PS1SITE.CONTOSO.COM:8530
, Server='PS1SITE. CONTOSO. COM,Version='38' LocationServices
WSUS Path='https://PS1SYS.CONTOSO.COM:8531
, Server='PS1SYS. CONTOSO. COM,Version='38' LocationServices
Обратный вызов с расположениями для запроса WSUS {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} LocationServices
Шаг 8. Агент сканирования уведомляет WUAHandler о добавлении источника обновления в реестр.
Агент сканирования теперь имеет политику и расположение источника обновления с соответствующей версией содержимого. Следующие данные регистрируются ScanAgent.log.
WSUSLocationUpdate, полученный для guid запроса расположения={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::OnLocationUpdate- Received Location=http://PS1SITE.CONTOSO.COM:8530
, Version=38 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute- Добавление UpdateSource={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, ContentType=2, ContentLocation=http://PS1SITE.CONTOSO.COM:8530
, ContentVersion=38 ScanAgent
Агент сканирования уведомляет WUAHandler о добавлении источника обновления. WUAHandler добавляет источник обновления в реестр и инициирует обновление групповой политики (если клиент находится в домене), чтобы узнать, переопределяет ли группа сервер обновления, который мы только что добавили. Ниже приведено WUAHandler.log в систему на новом клиенте с добавлением нового источника обновления:
Его тип источника обновления WSUS ({C2D17964-BBDDD-4339-B9F3-12D7205B39CC}), добавив его. WUAHandler
Его совершенно новый источник обновления WSUS. WUAHandler
Включение политики управляемого сервера WUA для использования сервера:http://PS1SITE.CONTOSO.COM:8530
WUAHandler
Принудительное обновление политики. WUAHandler
Ожидание 2 минут для групповой политики, чтобы уведомить об изменении политики WUA... WUAHandler
Дождитесь 30 секунд, пока политика вступают в силу с агентом WU. WUAHandler
Добавлен источник обновления ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) типа контента: 2 WUAHandler
В это время агент Обновл. Windows видит изменение конфигурации WSUS. Следующие данные регистрируются в WindowsUpdate.log.
2014-01-20 12:18:11:520 968 9d0 Агент * СЕРВЕР WSUS:
http://PS1SITE.CONTOSO.COM:8530
(Изменено)
2014-01-20 12:18:11:520 968 9d0 Agent * WSUS status server:http://PS1SITE.CONTOSO.COM:8530
(Изменено)
2014-01-20 12:18:11:520 968 9d0 AU Sus server изменились с помощью политики.
Следующие разделы реестра проверяются и задаются:
Подраздел реестра | Value name | Тип | Data |
---|---|---|---|
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUServer; | REG_SZ | Полный URL-адрес сервера WSUS, включая порт. Например: http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUStatusServer | REG_SZ | Полный URL-адрес сервера WSUS, включая порт. Например: http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU |
UseWUServer; | REG_DWORD | 0x1 |
Для существующего клиента мы могли бы увидеть следующее в WUAHandler.log, чтобы указать, когда версия содержимого увеличивается:
Его тип источника обновления WSUS ({C2D17964-BBDDD-4339-B9F3-12D7205B39CC}), добавив его. WUAHandler
Источник обновления WSUS уже существует, он увеличил версию до 38. WUAHandler
Шаг 9. Агент сканирования инициирует проверку
После успешного добавления источника обновления агент сканирования создает сообщение о состоянии и инициирует проверку. Следующие данные регистрируются ScanAgent.log.
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): поднятое обновлениеSource ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) — сообщение о состоянии. StateId = 2 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute — успешно запрошена проверка, ScanType=1 ScanAgent
Проверка обновлений программного обеспечения на клиентах
После того как политика источника обновления и расположение источника обновления будут доступны, агент сканирования инициирует проверку. Проверка обновления программного обеспечения выполняется агентом Обновл. Windows. Однако клиент Configuration Manager взаимодействует с агентом Обновл. Windows для выполнения сканирования и получения результатов сканирования. Это взаимодействие обрабатывается компонентом обработчика агента Обновл. Windows (WUAHandler), который взаимодействует с агентом Обновл. Windows.
Шаг 1. Запрос агента сканирования и WUAHandler инициирует сканирование.
Агент сканирования запрашивает проверку из WUAHandler, которая использует API агента Обновл. Windows для запроса проверки обновления программного обеспечения из агента Обновл. Windows. Ниже приведен вход в ScanAgent.log.
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute — успешно запрошена проверка, ScanType=1 ScanAgent
Войдите в систему WUAHandler.log:
Результаты проверки будут включать заменяемые обновления только в том случае, если они заменяются пакетами обновления и обновлениями определений. WUAHandler
Критерии поиска : (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
Выполнение однозвоночной проверки обновлений. WUAHandler
Асинхронный поиск обновлений с помощью WUAgent запущен. WUAHandler
Шаг 2. Запуск проверки агента Обновл. Windows (WUA) на компьютере WSUS
Обновл. Windows агент запускает проверку после получения запроса от клиента Configuration Manager (CcmExec). Так как значение сервера Обновл. Windows уже установлено на сервер SUP, это сканирование выполняется на сервере WSUS с установленной ролью SUP. Следующие данные регистрируются в WindowsUpdate.log.
2014-01-20 12:18:42:694 3856 708 COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]
2014-01-20 12:18:42:752 3856 708 COMAPI -- SUBMITTED -- COMAPI <<: Search [ClientId = CcmExec]
2014-01-20 12:18:47:511 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, URL-адрес сервера =http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:48:662 968 f58 Агент ** START ** Agent: поиск обновлений [CallerId = CcmExec]
2014-01-20 12:18:48:662 968 f58 Агент * Включение потенциально замененных обновлений
2014-01-20 12:18:48:662 968 f58 агент * Online = Да; Игнорировать приоритет скачивания = Да
2014-01-20 12:18:48:662 968 f58 агент * критерии = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
2014-01-20 12:18:48:662 968 f58 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
2014-01-20 12:18:48:662 968 f58 агент * область поиска = {Machine}
Обновл. Windows агент теперь сканирует сервер WSUS и сообщает результаты CcmExec (в частности WUAHandler). Следующие данные регистрируются в WindowsUpdate.log.
2014-01-20 12:18:49:175 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, URL-адрес сервера =
http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:52:680 968 f58 Агент * Добавлено обновление {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 для поиска результатов
2014-01-20 12:18:52:683 968 f58 Agent * Добавлено обновление {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 для результата поиска
2014-01-20 12:18:52:694 968 f58 Агент * Найдено 163 обновлений и 70 категорий в поиске; вычисляемое приложение. Правила 622 из 1150 развернутых сущностей
2014-01-20 12:18:52:745 968 f58 Агент ** END ** Агент: поиск обновлений [CallerId = CcmExec]
2014-01-20 12:18:52:755 3856 708 COMAPI -- RESUMED -- COMAPI >>: Search [ClientId = CcmExec]
2014-01-20 12:18:53:137 3856 708 COMAPI — обновления найдены = 163
2014-01-20 12:18:53:137 3856 708 COMAPI -- END -- COMAPI: Поиск [ClientId = CcmExec]
Шаг 3. WUAHandler получает результаты от агента Обновл. Windows и помечает сканирование как завершенное
Войдите в систему WUAHandler.log:
Завершена асинхронная поисковая строка. WUAHandler
Завершен поиск всего в одном вызове. WUAHandler
Шаг 4. WUAHandler анализирует результаты сканирования
Затем WUAHandler анализирует результаты, которые включают состояние применимости для каждого обновления. В рамках этого процесса замененные обновления удаляются. Войдите в систему WUAHandler.log:
Обрезка: идентификатор обновления (70f4f236-0248-4e84-b472-292913576fa1) заменен (726b7201-862a-4fde-9b12-f36b323a6f). WUAHandler
...
Обновление (установлено): обновление системы безопасности для Windows 7 для систем на основе x64 (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104) WUAHandler
Обновление (отсутствует): обновление системы безопасности для Windows 7 для систем на основе x64 (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200) WUAHandler
...
Успешно завершена проверка. WUAHandler
Шаг 5. Обновление хранилища записывает состояние и создает сообщение о состоянии для каждого обновления в WMI
После того как результаты сканирования будут доступны, эти результаты хранятся в хранилище обновлений. Хранилище обновлений записывает текущее состояние каждого обновления и создает сообщение о состоянии для каждого обновления. Эти сообщения о состоянии перенаправляются на сервер сайта массово в конце цикла отчетов о состоянии (по умолчанию — 15 минут).
UpdatesStore.log с состоянием для записи отсутствующих обновлений (KB2862152) и возникает сообщение о состоянии:
Обработка состояния обновления из обновления (505fda07-b4f3-45fb-83d9-8642554e2773) с ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdateStoreStore
Состояние обновления из обновления (505fda07-b4f3-45fb-83d9-8642554e2773) не было сообщено до создания нового экземпляра. UpdatesStore
Сообщение о состоянии для обновления (505fda07-b4f3-45fb-83d9-8642554e2773) с состоянием (отсутствует). UpdatesStore
Успешно добавлен экземпляр WMI состояния обновления (505fda07-b4f3-45fb-83d9-8642554e2773). UpdatesStore
StateMessage.log, показывающее сообщение о состоянии, записанное с идентификатором состояния 2 (отсутствует):
Добавление сообщения с помощью TopicType 500 и TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 в WMI StateMessage
Сообщение о состоянии (идентификатор состояния: 2) с TopicType 500 и TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 было записано для SYSTEM StateMessage
Для каждого обновления создается или обновляется экземпляр CCM_UpdateStatus
класса и сохраняется текущее состояние обновления. Класс CCM_UpdateStatus
расположен в ROOT\CCM\SoftwareUpdates\UpdatesStore
пространстве имен.
Аналогичным образом создается или обновляется экземпляр CCM_StateMsg
класса и сохраняется текущее состояние обновления. Класс CCM_StateMsg
расположен в ROOT\CCM\StateMsg
пространстве имен.
Шаг 6. Сообщения о состоянии отправляются в точку управления
Как упоминалось ранее, сообщения о состоянии отправляются в точку управления на основе расписания цикла отчетов о состоянии, которое по умолчанию настроено на 15 минут. После отправки сообщения о состоянии в точку MessageSent
управления свойство для экземпляра сообщения о состоянии в CCM_StateMsg
классе имеет значение True.
В StateMessage.log:
Тело StateMessage: <усеченный> текст xml-отчета StateMessage
Успешно перенаправленные сообщения о состоянии в mp StateMessage
Ниже показано, как выглядит текст сообщения о состоянии для обновления. Обычно этот xml-текст слишком велик для журнала и усечен в CMTrace. Однако весь текст XML можно увидеть в Блокноте.
Текст StateMessage: <?xml version="1.0" encoding="UTF-16"?>
<Идентификатор клиента 1/ClientInstalled 1/ClientInstalled><>ClientType 1<</ClientType><>ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/<><><><>< Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="201401201855.573000+000" SerialNumber="232"><Идентификатор раздела="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" UserSID="" UserSID=" "/><State ID="2" Критическое значение="0"/><UserParameters Flags="0" Count="1"><Param 200</Param><>/UserParameters></StateMessage/ReportBody></ReportMessage><>
Успешно перенаправленные сообщения о состоянии в mp StateMessage
Поток обработки сообщений о состоянии
Теперь мы знаем, как записывается сообщение о состоянии и расположение WMI, в котором хранятся эти сообщения о состоянии. Мы также знаем, что неотступные сообщения о состоянии на клиенте отправляются в точку управления каждые 15 минут по умолчанию для каждого цикла отчетов о состоянии. Это расписание можно изменить в режиме обмена сообщениями о состоянии пользовательских или стандартных параметров клиента.
Хотя StateMessage.log сообщает о успешно переадресации сообщений о состоянии в депутат, компонент сообщения о состоянии фактически не отправляет эти сообщения. Все сообщения, отправленные и полученные из точки управления, обрабатываются компонентом обмена сообщениями CCM на клиенте. Обмен сообщениями CCM — это фактический компонент, который взаимодействует с точкой управления для отправки и получения данных. Точка управления имеет различные очереди, определенные для обработки различных типов входящего трафика. Для сообщений о состоянии очередь, обрабатывающая этот трафик, является очередью MP_RelayEndpoint
.
Шаг 1. Компонент сообщения о состоянии начинает отправлять сообщения в точку управления
В StateMessage.log:
Текст StateMessage: <?xml version="1.0" encoding="UTF-16"?><Идентификатор идентификатора идентификатора reportHeader><><ClientInstalled 1/ClientInstalled><>ClientType 1<</ClientType><>ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/<><>< Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="201401201855.573000+000" SerialNumber="232"><Идентификатор раздела="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" UserSID="" UserSID=" "/><State ID="2" Критическое значение="0"/><UserParameters Flags="0" Count="1"><Param 200</Param><>/UserParameters></StateMessage/ReportBody></ReportMessage><>
Успешно перенаправленные сообщения о состоянии в mp StateMessage
Шаг 2. Обмен сообщениями CCM отправляет сообщение, содержащее xml-текст сообщения состояния в точку управления.
Обмен сообщениями CCM успешно отправляет сообщение MP_RelayEndpoint
в очередь. Это сообщение не имеет ответа, в отличие от того, что мы заметили ранее в разделе "Запрос расположения WSUS", где сообщение с запросом расположения получило ответ.
В CcmMessaging.log:
Отправка асинхронного сообщения "{95F79010-D0EB-49A6-8A1E-389783105F2}" в исходящую очередь "mp:mp_relayendpoint" CcmMessaging
Отправка исходящего сообщения "{95F79010-D0EB-49A6-8A1E-3897883105F2}". Флаги 0x200, учетная запись отправителя пустая CcmMessaging
POST: Host=PS1SYSYS. CONTOSO.COM, Path=/ccm_system/request, Port=443, Protocol=https, Flags=512, Options=480 CcmMessaging
Сообщение "{95F79010-D0EB-49A6-8A1E-3897883105F2}" не имеет ответа CcmMessaging
OutgoingMessage(Queue='mp_mp_relayendpoint', ID={95F79010-D0EB-49A6-8A1E-3897883105F2}): доставлен успешно на узел "PS1SYS.CONTOSO.COM". CcmMessaging
Шаг 3. Сообщение получено в точке управления, а затем MP_Relay обрабатывает сообщение и создает SMX-файл.
По мере отправки всех сообщений с помощью ПРОТОКОЛА HTTP/HTTPS и получения службами IIS. В этом примере этот запрос выполняется в CCM_System виртуальном каталоге.
В журнале IIS:
192.168.2.12 CCM_POST /ccm_system/request - 443 - 192.168.2.62 ccmhttp - 200 0 0 542 31
После успешного получения сообщения на точке MP_Relay
управления компонент обрабатывает это сообщение, преобразует сообщение в SMX-файл и перемещает файл SMX в соответствующее расположение в зависимости от того, находится ли точка управления на сервере сайта.
- На удаленной точке управления: \SMS\mp\outboxes\StateMsg.box
- В точке управления, размещенной на сервере сайта: \inboxes\auth\StateSys.box\incoming
В MP_Relay.log в точке управления, расположенной на сервере сайта:
Обработчик сообщений mp: начало обработки сообщений для Ретранслятора----------------------- MP_RelayEndpoint
Обработчик сообщений mp: FileType=SMX MP_RelayEndpoint
Текст сообщения: <усеченный> MP_RelayEndpoint xml-текст
Ретрансляция: исходящий dir: E:\ConfigMgr\inboxes\auth\statesys.box\входящие MP_RelayEndpoint
Приоритет в сообщении = 5 MP_RelayEndpoint
Каталог приоритета состояния = E:\ConfigMgr\inboxes\auth\stateys.box\входящих MP_RelayEndpoint
Inv-Relay: задача успешно завершена MP_RelayEndpoint
В MP_Relay.log на удаленной точке управления:
Обработчик сообщений mp: начало обработки сообщений для Ретранслятора------------------------------ MP_RelayEndpoint
Обработчик сообщений mp: FileType=SMX MP_RelayEndpoint
Текст сообщения:
<?xml version="1.0" encoding="UTF-16"?>
<Идентификатор клиента 1/ClientInstalled 1/ClientInstalled><>ClientType 1<</ClientType><>ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/<><><><>< Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="201401201855.573000+000" SerialNumber="232"><Идентификатор раздела="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" UserSID="" UserSID=""/><State ID="2" Критическое значение="0"/><UserParameters Flags="0" Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report> MP_RelayEndpoint
Задача Inv-Relay: обработка текста сообщения MP_RelayEndpoint
Ретрансляция: исходящий dir: C:\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Приоритет в сообщении = 5 MP_RelayEndpoint
Каталог приоритета состояния = C:\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay: задача успешно завершена MP_RelayEndpoint
Текст XML выглядит идентично тому, что вошедшего в систему StateMessage.log на клиенте.
Шаг 4. Диспетчер диспетчера файлов MP отправляет SMX-файл на сервер сайта (только если точка управления не размещена на сервере сайта).
Если точка управления удалена на сервер сайта, после поступления файла в папку outboxes\StateMsg.box диспетчер файлов MP (MPFDM) отвечает за перемещение этих файлов в папку "Входящие" на сервере сайта. При совместном расположении точки управления на сервере сайта эти файлы перемещаются непосредственно в соответствующую папку папки "Входящие", поэтому MPFDM не участвует.
В MPFDM.log на удаленной точке управления:
Перемещен файл C:\SMS\MP\OUTBOXES\statemsg.box\TAZGYTSJ. SMX в \\PS1SITE.CONTOSO.COM\SMS_PS1\inboxes\auth\statesys.box\входящие\TAZGYTSJ. SMX SMS_MP_FILE_DISPATCH_MANAGER
Чтобы MPFDM перемещал файлы в соответствующую папку "Входящие", точка удаленного управления должна иметь доступ к реестру сервера сайта, чтобы определить расположения источника папки "Входящие". Поэтому служба удаленного реестра должна выполняться, а доступ к реестру не должен блокироваться групповой политикой. MPFDM определяет расположения папки "Входящие", доступ к следующему разделу реестра на сервере сайта:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Inbox Source
Шаг 5. Компонент StateSys на сервере сайта обрабатывает сообщение о состоянии в базу данных.
После прибытия файла в папку \inboxes\auth\StateSys.box на сервере сайта компонент State System Manager (StateSys) просыпается и обрабатывает ФАЙЛЫ SMX.
В StateSys.log с включенным подробным ведением журнала:
Активация уведомления в папке "Входящие", приостановка в течение 10 секунд...... SMS_STATE_SYSTEM
Найдено новое сообщение о состоянии для обработки, запуск потоков обработки SMS_STATE_SYSTEM
Поток "Поток обработки сообщений состояния" #0" id:4316 запущен SMS_STATE_SYSTEM
общий объем загруженных блоков (1) SMS_STATE_SYSTEM
CMessageProcessor — файл обработки: YCE2H3VD. SMX SMS_STATE_SYSTEM
CMessageProcessor — обработано 1 записей с 0 недопустимыми записями. SMS_STATE_SYSTEM
CMessageProcessor — обработано 1 файлов сообщений в этом пакете с 0 плохими файлами. SMS_STATE_SYSTEM
общий объем загруженных блоков (0) SMS_STATE_SYSTEM
Поток "Поток обработки сообщений состояния" #0" id:4316 обычно завершается SMS_STATE_SYSTEM
В StateSys.log без подробного ведения журнала включено:
Найдено новое сообщение о состоянии для обработки, запуск потоков обработки SMS_STATE_SYSTEM
Поток "Поток обработки сообщений о состоянии" #0" id:1988 начал SMS_STATE_SYSTEM
общий объем загруженных блоков (1) SMS_STATE_SYSTEM
общий объем загруженных блоков (0) SMS_STATE_SYSTEM
Поток "Поток обработки сообщений состояния" #0" id:1988 завершается обычно SMS_STATE_SYSTEM
Файл StateSys.log не регистрирует имя файла, если для System Manager не включен подробный журнал .
ФАЙЛ SMX, который перемещается в папку StateSys.box, содержит XML-код текста сообщения. Когда StateSys обрабатывает этот файл, он вызывает spProcessStateReport
хранимую процедуру и передает этот xml-текст в хранимую процедуру в качестве параметра.
В трассировке профилировщика SQL Server:
exec dbo.spProcessStateReport N'<?xml version="1.0" encoding="UTF-16"?>
<Идентификатор клиента 1/ClientInstalled 1/ClientInstalled><>ClientType 1<</ClientType><>ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/<><><><>< Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>2014012020131.071000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="201401201855.573000+000" SerialNumber="239"><Идентификатор раздела="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" UserSID"="/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report>'
spProcessStateReport
представляет собой хранимую процедуру CLR, а определение СРЕДЫ CLR имеет логику для определения типа обрабатываемого сообщения о состоянии. В зависимости от типа сообщения о состоянии он обрабатывает соответствующее сообщение состояния и вставляет данные в базу данных.
Понятные имена всех типов и идентификаторов разделов сообщений о состоянии можно найти, запросив таблицу SR_StateNames
с помощью следующей команды:
SELECT * FROM SR_StateNames
Сводка обновлений программного обеспечения
Прежде чем данные о соответствии обновлений программного обеспечения можно представить в консоли или отчетах, данные о соответствии обновлений программного обеспечения должны быть обобщены. Это необходимо, так как консоль и отчеты обычно отображают только суммированные данные. Компонент системы состояния на сервере сайта выполняет сводку обновления программного обеспечения вместе с суммированием для других компонентов, таких как приложения, развертывания DCM и работоспособности клиента. Вы можете найти сведения обо всех задачах суммирования, выполняемых системой состояния, запросить vSR_SummaryTasks
представление в базе данных Configuration Manager. Система состояний выполняет эти задачи в настроенном расписании и записывает сведения о каждой задаче в StateSys.log:
SMS_STATE_SYSTEM запущенной задачи TaskName<>
Задача "<Имя_задачи>" успешно завершена после выполнения в течение 15 секунд с состоянием 8. SMS_STATE_SYSTEM
Для большинства этих задач состояние, зарегистрированное StateSys.log, не является кодом ошибки. Вместо этого это количество строк, возвращаемых соответствующей хранимой процедурой SQL Server, которая выполняет сводные данные.
Задачи сводных данных, относящиеся к обновлениям программного обеспечения:
Средство оценки соответствия назначений СУММ
Суммирует сообщения о состоянии для всех назначений групп обновления программного обеспечения (развертывания). Эта задача выполняется каждый час по умолчанию. Его можно инициировать вручную для определенного развертывания в развертываниях консоли>> Configuration Manager, щелкните правой кнопкой мыши развертывание и нажмите кнопку "Выполнить сводку".
Сводка состояния группы обновления СУММ
Суммирует состояние групп обновления. Эта задача выполняется каждый час по умолчанию. Его можно инициировать вручную для определенной группы обновлений в группах обновлений программного обеспечения в>консоли >Configuration Manager Software Update>Groups, щелкните правой кнопкой мыши группу обновлений и нажмите кнопку "Выполнить сводку".
Вы также можете изменить расписание этой задачи, щелкнув правой кнопкой мыши группы обновлений программного обеспечения или выбрав "Сводные данные расписания" на ленте.
Сводка состояния обновления СУММ
Суммирует состояние обновлений для всех клиентов. Эта задача выполняется каждый час по умолчанию. Его можно инициировать вручную в консоли >Configuration Manager Software Library>Software Updates, а затем нажмите кнопку "Выполнить сводку". Вы также можете изменить расписание по умолчанию, выбрав "Сводка расписания".
Состояние обновления миграции СУММ
Переносит состояние обновления внутри базы данных. Эта задача выполняется каждые 24 часа по умолчанию. Его нельзя инициировать вручную из консоли Configuration Manager.
Удаление устаревшего состояния СУММ
Удаляет устаревший статус из определенных таблиц обновления программного обеспечения в базе данных. Эта задача выполняется каждые 24 часа по умолчанию. Его нельзя инициировать вручную из консоли Configuration Manager.
Переключение точек обновления программного обеспечения
В System Center 2012 Configuration Manager с пакетом обновления 1 (SP1) и более поздних версиях сайт может иметь несколько SUP. Это обеспечивает отказоустойчивость для ситуаций, когда sup становится недоступным. Дополнительные сведения о отработки отказа и переключении sups см. в следующих статьях: