Описание сообщений о состоянии в Configuration Manager
В этой статье описывается система обмена сообщениями о состоянии в Configuration Manager.
Исходная версия продукта: Configuration Manager (текущая ветвь)
Исходный номер базы знаний: 4459394
Общие сведения о обмене сообщениями о состоянии
Обмен сообщениями о состоянии в Configuration Manager — это механизм, который отражает условие клиента в определенный момент времени. Сообщения о состоянии, напротив, помогают администраторам отслеживать рабочий процесс данных с помощью различных компонентов Configuration Manager.
Средство просмотра сообщений о состоянии встроено прямо в консоль, чтобы можно было просматривать и отслеживать сообщения о состоянии. Для сообщений о состоянии нет эквивалентного средства просмотра. Результат сообщений о состоянии можно увидеть в следующих элементах:
- Отчеты
- различные данные в консоли, например количество систем, которые необходимо обновить
- журналы клиента
Сообщения о состоянии содержат краткие сведения об условиях на месте клиента. Система обмена сообщениями о состоянии используется определенными компонентами Configuration Manager, в том числе:
- обновления программного обеспечения
- управление требуемой конфигурацией
- защита сетевого доступа
Критически важные данные обновления программного обеспечения зависят от системы обмена сообщениями о состоянии в Configuration Manager. Понимание сообщений о состоянии станет еще более важным в будущих версиях Configuration Manager, так как все больше компонентов пользуются этим.
На следующей схеме показано, как работает система обмена сообщениями о состоянии.
Зеленый прямоугольник представляет систему обмена сообщениями о состоянии. Компоненты внутри коробки являются компонентами, которые передают информацию в систему.
При получении сообщений о состоянии возникают две вещи:
- Сообщения о состоянии хранятся в поставщике инструментария управления Windows (WMI).
- Система состояний выполняет очистку WMI за 15-минутный цикл (по умолчанию) для всех сообщений о состоянии, которые не были отправлены, а затем перенаправляет их в точку управления. Период цикла можно изменить.
На схеме часть установки клиента показана отдельно для ясности. Во время установки клиента точка управления находится и предназначена для сообщений о состоянии. Сообщения о состоянии об установке клиента перенаправляются в резервную точку состояния (FSP) (если она настроена) при одном из следующих условий:
- Точка управления не достигнута.
- По какой-то причине точка управления не работает.
Во всех остальных ситуациях трафик направляется непосредственно к точке управления.
Сообщения о состоянии, поступающие в точку .smx управления, обрабатываются в файлах компонентом MP Relay и помещаются в папку auth\statesys.box\incoming на сервере сайта. Затем они обрабатываются в базе данных для завершения рабочего процесса.
Копание глубже
Необходимо убедиться, что подробное ведение журнала включено для:
- клиент
- точка управления
- компоненты обмена сообщениями о состоянии на сервере сайта;
Чтобы настроить подробное ведение журнала или ведение журнала отладки в Configuration Manager клиенте или точке управления, измените или создайте следующие записи реестра:
| Подраздел реестра | Имя DWORD | Value data |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Loglevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Включено | Верно |
На сервере сайта измените следующую запись реестра, чтобы включить подробное ведение журнала, а затем перезапустите SMS_Executive службу (или компонент системы состояния):
| Подраздел реестра | Имя DWORD | Value data |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Подробное ведение журнала | 1 |
Трассировка команд SQL требует включения трассировки SQL для Configuration Manager компонентов. Но не так много полезных данных можно получить непосредственно из трассировки. Это верно, даже если profiler включен. Поэтому мы рассмотрим Updatesdeployment.log и Statemessage.log файлы на клиенте. Интерпретируя сообщения о состоянии в этих журналах, мы можем получить четкое представление о том, что происходит на различных этапах процесса.
Прежде чем мы рассмотрим примеры кода журнала, необходимо понять формат сообщения о состоянии. Само сообщение состояния состоит из нескольких частей, включая тип раздела и идентификатор сообщения о состоянии. В некоторых местах в журналах тип раздела уже интерпретирован.
Тип раздела и идентификатор сообщения состояния не всегда отображаются вместе в одном журнале. Один тип данных без другого на самом деле не помогает определить, что необходимо. Однако даже если у вас есть как тип раздела , так и идентификатор сообщения состояния, эти сведения не будут полезны, если вы не можете интерпретировать их.
Следующая диаграмма поможет вам интерпретировать сочетание TopicType и StateID получить значимые данные.
select * from v_StateNames
Примечание.
На следующей диаграмме представлены коды типов тем серий 300, 400 и 500.
Данные сообщений о состоянии
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Состояние соответствия неизвестно |
| 300 | 1 | Соответствует |
| 300 | 2 | Не соответствует требованиям |
| 300 | 3 | Обнаружен конфликт |
| 301 | 0 | Неизвестное состояние принудительного применения |
| 301 | 1 | Установка обновлений |
| 301 | 2 | Ожидание перезапуска |
| 301 | 3 | Ожидание завершения другой установки |
| 301 | 4 | Обновления успешно установлены |
| 301 | 5 | Ожидающий перезапуск системы |
| 301 | 6 | Не удалось установить обновления |
| 301 | 7 | Скачивание обновлений |
| 301 | 8 | Скачанные обновления |
| 301 | 9 | Не удалось скачать обновления |
| 301 | 10 | Ожидание периода обслуживания перед установкой |
| 301 | 11 | Ожидание запуска установки сторонним оркестратором |
| 302 | 0 | Состояние оценки неизвестно |
| 302 | 1 | Активация оценки |
| 302 | 2 | Оценка выполнена успешно |
| 302 | 3 | Сбой оценки |
| 400 | 0 | Состояние обнаружения неизвестно |
| 400 | 1 | Не требуется |
| 400 | 2 | Не обнаружено |
| 400 | 3 | Обнаружено |
| 401 | 0 | Состояние соответствия неизвестно |
| 401 | 1 | Соответствует |
| 401 | 2 | Не соответствует требованиям |
| 401 | 3 | Обнаружен конфликт |
| 401 | 4 | Error |
| 401 | 5 | Неприменимо |
| 401 | 6 | Не обнаружено |
| 401 | 7 | Enforced |
| 402 | 0 | Неизвестное состояние принудительного применения |
| 402 | 1 | Начало принудительного применения |
| 402 | 2 | Принудительное применение в ожидании содержимого |
| 402 | 3 | Ожидание завершения другой установки |
| 402 | 4 | Ожидание периода обслуживания перед установкой |
| 402 | 5 | Перед установкой требуется перезагрузка |
| 402 | 6 | Общий сбой |
| 402 | 7 | Ожидающая установка |
| 402 | 8 | Установка обновления |
| 402 | 9 | Ожидающий перезапуск системы |
| 402 | 10 | Обновление успешно установлено |
| 402 | 11 | Не удалось установить обновление |
| 402 | 12 | Скачивание обновления |
| 402 | 13 | Скачаемое обновление |
| 402 | 14 | Не удалось загрузить обновление |
| 500 | 0 | Состояние обнаружения неизвестно |
| 500 | 1 | Обновление не требуется |
| 500 | 2 | Требуется обновление |
| 500 | 3 | Обновление установлено |
| 501 | 0 | Состояние сканирования неизвестно |
| 501 | 1 | Сканирование ожидает расположения каталога |
| 501 | 2 | Проверка выполняется |
| 501 | 3 | Сканирование завершено |
| 501 | 4 | Проверка ожидает повтора |
| 501 | 5 | Сбой сканирования |
| 501 | 6 | Проверка завершена с ошибками |
Дополнительные сведения см. в разделе Сообщения о состоянии в Configuration Manager.
В следующем примере выполняется выравнивание и сравнение файлов Updatesdeployment.log и Statemessage.log. Убедитесь, что журналы ссылаются на одно и то же сообщение о состоянии, выравнивая один и тот же TopicID (зеленый текст). Он четко указывает, что два журнала ссылаются на одно и то же сообщение о состоянии. Отображается TopicType светло-синим текстом. Обратите внимание, что в одном журнале может отображаться фактическое число, которое можно интерпретировать из диаграммы данных сообщений о состоянии . В другом может отображаться универсальное значение (уже интерпретируемое).
Идентификатор сообщения о состоянии (StateId) отображается фиолетовым текстом.
Объединяя TopicTypeидентификатор сообщения о состоянии и (StateId) из диаграммы, можно точно отслеживать, что происходит в журналах. В этом примере в этих примерах кода отображаются следующие сведения:
- Оценка обновлений
- Результат оценки
- Скачиваемое обновление
- Устанавливаемое обновление
- Ожидающий перезапуск системы
Это лишь один из примеров отправки сообщений о состоянии в систему состояний.
Поток данных обмена сообщениями о состоянии
На следующем рисунке показан фактический пример того, как данные сообщений о состоянии поставляются в точку управления и обрабатываются в базу данных.
В этом примере используется тестовый клиент. Он начинается с принудительного извлечения WMI для всех сведений о состоянии сообщений, а затем отправляет эти сведения в точку управления в следующем цикле опроса.
В WMI сообщения о состоянии хранятся в root\ccm\statemsg пространстве имен. В этом пространстве имен есть два интересующих класса: CCM_StateMsg_SerialNum и CCM_StateMsg.
Класс CCM_StateMsg_SerialNum используется для записи последнего серийного номера, используемого для сообщения о состоянии. Каждое сообщение о состоянии имеет уникальный серийный номер, аналогичный инвентаризации оборудования. Таким образом, сервер сайта может отслеживать отсутствие каких-либо сообщений о состоянии из системы. Это важно, так как отсутствующие сообщения о состоянии могут привести к неполным или неточным отчетам о состоянии.
Класс CCM_StateMsg содержит сами сообщения о состоянии. В экземпляре класса можно найти все записанные сообщения о состоянии.
Если открыть одно из этих сообщений, вы найдете сведения о сообщении о состоянии и некоторые данные, которые мы обсуждали ранее, как показано в следующем примере.
Мы можем повторно отправить данные в точку управления и отслеживать ход их выполнения с помощью следующих скриптов повторной синхронизации.
RefreshServerComplianceState()
Sub RefreshServerComplianceState()
dim newCCMUpdatesStore
set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
newCCMUpdatesStore.RefreshServerComplianceState
wscript.echo "Ran RefreshServerComplianceState."
End Sub
$UpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$UpdatesStore.RefreshServerComplianceState()
Этот скрипт можно найти в Интернете в разных местах. Пакет SDK для Configuration Manager используется для повторной отправки данных клиентом в точку управления.
Как правило, скрипт Visual Basic (VBScript) выполняется с помощью cscript. Обратите внимание, что сценарий может завершиться ошибкой, если вы попытаетесь запустить его самостоятельно. Проблема заключается в том, что Configuration Manager — это 32-разрядное приложение, работающее на 64-разрядном сервере. Версия cscript по умолчанию — это 64-разрядная версия и, как правило, хорошо работает с любым VBScript. Однако в этом случае для выполняемого вызова требуется 32-разрядная версия cscript папки syswow64.
При выполнении следующего цикла опроса сообщений о состоянии все сообщения о состоянии отправляются в точку управления.
В файле Statemessage.log видно, что сведения о сообщении о состоянии извлекаются, форматируются в ФОРМАТЕ XML, а затем отправляются в точку управления. Сведения о сообщении о состоянии должны выглядеть примерно так:
<! [LOG[Текст StateMessage: <?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType ClientType><ClientID>GUID:GUID</ClientID>
<ClientVersion>client_version_number</ClientVersion><NetBIOSName>name</NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message/<ReportContent>
<ReportType>Full</ReportType><Date<>/Date/Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number"><Topic ID="21e49ac6-a273-4a61-9794-eb675bc743e5" Type="500" IDType="3"/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>102</ Param></UserParameters></StateMessageserParameters></StateMessage></Report><>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[Успешно перенаправлены сообщения о состоянии в точку управления]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Примечание.
Этот пример усекается до одного сообщения о состоянии из-за размера XML-файла.
Хотя файл Statemessage.log записывает, что сообщения отправляются в точку управления, система обмена сообщениями о состоянии фактически не перемещает данные в точку управления. В следующем примере показано, что CCMMessaging выполняет эту операцию. На данный момент еще больше, что происходит за кулисами. Однако достаточно знать, что CCMMessaging отправляет данные в точку управления (в данном случае компонент MP_Relay ).
<! [LOG[OutgoingMessage(Queue='mp_mp_relay endpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): успешно доставлено для размещения host_name.] LOG]!>
Когда данные поступают для обработки в MP_Relay, они обрабатываются и переводятся в .smx формат файла, а затем помещают в папку auth\statesys.box\incoming .
Задача Inv-Relay: обработка текста сообщения
Ретранслятор: FileType= SMX
Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Ретранслятор: получено 0 вложений
Ретранслятор: 0 из 0 вложений успешно обработаны
Inv-Relay: задача успешно завершена
В папке auth\statesys.box\incoming отображаются обрабатываемые .smx файлы. Как правило, вы не увидите их здесь. Но если файлы остаются в этой папке, необходимо выяснить, что такое сообщения и почему они не обрабатываются. Если вы нашли .smx файл, его можно открыть с помощью текстового редактора, например Блокнота, чтобы просмотреть подробные сведения. Однако форматирование файла может быть нечитаемым, как показано в следующем примере:
Если переименовать .smx файл, добавив .xml расширение, чтобы файл получил имя file_name.smx.xml, а затем дважды щелкнуть новое имя файла, XML-файл откроется в Интернет-Обозреватель и его гораздо проще прочитать.
На следующем рисунке показан пример XML-файла, открытого в Обозреватель Интернета. Выделены сведения о компьютере и сообщении о состоянии. Он содержит сведения, которые мы обсуждали ранее, в сочетании с уникальным значением идентификатора сообщения о состоянии .
Примечание.
При переименовании этих файлов сначала скопируйте их в другую папку, чтобы не влиять на папку Statesys.box .
Наконец, сообщения о состоянии должны быть обработаны в базе данных. В файле Statesys.log отображаются такие сообщения, как в следующем примере:
Обнаружены новые сообщения о состоянии для обработки, запуск потока обработки
Поток "Поток обработки сообщений о состоянии #0" id:5076 запущен
CMessageProcessor — обнаружен родительский сайт "site_name"
CMessageProcessor — файл обработки: mdlbp169. SMW
CMessageProcessor — обработана 1 запись с 0 недопустимыми записями.
CMessageProcessor — успешно реплицированный файл mdlbp169. SMW" для родительского сайта site_name.
CMessageProcessor — обработано 1 файл сообщения в этом пакете с 0 плохими файлами.
Поток "Поток обработки сообщений о состоянии #0" id:5076 завершается обычно
Компонент обработки базы данных можно сделать видимым, включив трассировку SQL, но это не очень помогает. Вместо этого необходимо использовать профилировщик SQL. Профилировщик дает нам намек на то, что происходит за кулисами, но не полностью. За обработку сообщений о состоянии отвечает несколько хранимых процедур SQL. Кроме того, в нескольких таблицах в базе данных хранятся данные сообщений о состоянии. Хранимые процедуры, которые выполняют обработку сообщений о состоянии, обычно начинаются с имени spProcess. Существует множество таких процедур.
Сервер сайта отслеживает сообщения о состоянии по мере их поступления, поэтому он может помечать любые отсутствующие сообщения и периодически запрашивать повторную синхронизацию при необходимости. Сообщения о состоянии важны. Ты не хочешь пропустить ни одного.
По мере поступления сообщений о состоянии уникальный идентификатор считывается и сохраняется в базе данных. По мере продолжения обработки данные регулярно обновляются. При обнаружении пробела эти данные помечаются и сохраняются как отсутствующие сообщения о состоянии в SR_MissingMessageRanges таблице. В идеале эта таблица будет пустой. Однако в рабочей среде могут отображаться данные в таблице. Эта таблица помогает отслеживать сообщения о состоянии, для которых требуется повторная синхронизация.
Файл элемента управления сайтом находится в базе данных. Чтобы получить определенные параметры для STATE_MESSAGE_SYSTEM, выполните следующий запрос на первичном сайте или сайте CAS:
select * from SC_Component_Property where ComponentID in (select ID from SC_Component where ComponentName like 'SMS_STATE_SYSTEM') and sitenumber in (select SiteNumber from SC_SiteDefinition where Sitecode = (Select ThisSiteCode from SMSData))
параметры STATE_MESSAGE_SYSTEM
| Имя | Значение1 | Value2 | Значение 3 |
|---|---|---|---|
| Интервал msg heartbeat | 60 | ||
| Интервал опроса папки "Входящие" | 900 | ||
| Размер блока загрузчика | 256 | ||
| Потоки загрузчика | 4 | ||
| Максимальное число фрагментов, извлекаемых | 100 | ||
| Минимальный возраст отсутствующих сообщений | 2880 | ||
| Интервал проверки повторной синхронизации | 15 | ||
| Конфигурация повторных попыток | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Примечание.
- Параметр Resync Check Interval имеет значение 60 минут. Это расписание для проверки систем, требующих повторной синхронизации сообщений о состоянии.
- Минимальный возраст отсутствующих сообщений имеет значение 2880. Это то, сколько времени должно отсутствовать сообщение, прежде чем запрашивается повторная синхронизация.