Описание обмена сообщениями о состоянии в Configuration Manager
В этой статье описывается система обмена сообщениями о состоянии в Configuration Manager.
Исходная версия продукта: Configuration Manager (current branch)
Исходный номер базы знаний: 4459394
Общие сведения о обмене сообщениями о состоянии
Обмен сообщениями о состоянии в Configuration Manager — это механизм, который отражает состояние клиента в определенный момент времени. Сообщения о состоянии, напротив, помогают администраторам отслеживать рабочий процесс данных с помощью различных компонентов Configuration Manager.
Средство просмотра сообщений о состоянии встроено прямо в консоль, чтобы можно было просматривать и отслеживать сообщения о состоянии. Для сообщений о состоянии нет эквивалентного средства просмотра. Результат сообщений о состоянии рассматривается в следующих элементах:
- отчетов
- различные данные в консоли, такие как количество систем, которые должны быть обновлены
- журналы клиентов
Сообщения о состоянии содержат краткие сведения об условиях на месте клиента. Система обмена сообщениями о состоянии используется определенными компонентами Configuration Manager, в том числе:
- обновления программного обеспечения
- Управление требуемой конфигурацией
- Защита доступа к сети
Критически важные данные обновления программного обеспечения зависят от системы обмена сообщениями о состоянии в Configuration Manager. Понимание обмена сообщениями о состоянии станет еще более важным в будущих версиях Configuration Manager, так как дополнительные компоненты используют его.
На следующей схеме представлено хорошее описание работы системы обмена сообщениями о состоянии.
Зеленый прямоугольник представляет систему обмена сообщениями о состоянии. Компоненты внутри поля — это компоненты, которые передают информацию в систему.
При получении сообщений о состоянии происходит две вещи:
- Сообщения о состоянии хранятся в поставщике инструментария управления Windows (WMI).
- Система состояния удаляет WMI в течение 15-минутного цикла (по умолчанию) для любых сообщений о состоянии, которые не были отправлены, а затем перенаправляет их в точку управления. Период цикла можно изменить.
На схеме часть установки клиента отображается отдельно для ясности. Во время установки клиента точка управления расположена и ориентирована на сообщения о состоянии. Сообщения о состоянии установки клиента перенаправляются в резервную точку состояния (FSP) (если она настроена) в соответствии с одним из следующих условий:
- Точка управления не достигнута.
- Точка управления по какой-то причине не работает.
Для всего остального трафик переходит непосредственно к точке управления.
Сообщения о состоянии, поступающие в точку управления, обрабатываются в файлы компонентом Ретранслятора MP и помещаются .smx в папку auth\statesys.box\incoming на сервере сайта. Затем они обрабатываются в базе данных, чтобы завершить рабочий процесс.
Более подробный анализ
Необходимо убедиться, что подробное ведение журнала включено для:
- клиент
- точка управления
- компоненты обмена сообщениями о состоянии на сервере сайта
Чтобы задать подробное или отладочное ведение журнала в клиенте Или точке управления Configuration Manager, измените или создайте следующие записи реестра:
| Подраздел реестра | Имя DWORD | Данные |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
LogLevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Включен | Верно |
На сервере сайта измените следующую запись реестра, чтобы включить подробное ведение журнала, а затем перезапустите SMS_Executive службу (или компонент системы состояния):
| Подраздел реестра | Имя DWORD | Данные |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Подробное ведение журнала | 1 |
Для трассировки команд SQL требуется, чтобы трассировка SQL была включена для компонентов Configuration Manager. Но не так много полезных данных можно получить непосредственно из трассировки. Это верно, даже если профилировщик включен. Поэтому мы рассмотрим 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 | Ошибка |
| 401 | 5 | Н/Д |
| 401 | 6 | Не обнаружено |
| 401 | 7 | Принудительно |
| 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 body: <?xml version="1.0" encoding="UTF-16"?>
<Report ReportHeader><><Identification><Machine><ClientInstalled 1/ClientInstalled>><ClientType 1<</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 Data</ReportContent>
<ReportType Full</ReportType><>Date></Date>><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></ReportBody></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_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): доставлен успешно для размещения "host_name".LOG]!>
Когда данные поступают для обработки MP_Relay, он обрабатывается и преобразуется в формат файла, а затем помещает .smx его в папку auth\statesys.box\incoming .
Задача Inv-Relay: обработка текста сообщения
Ретрансляция: FileType= SMX
Ретранслятор: dir outbox: 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-файл открывается в Internet Explorer и гораздо проще читать.
Ниже приведен пример XML-файла, открытого в Internet Explorer. Выделены сведения о сообщении компьютера и состояния. Он содержит сведения, которые мы ранее обсуждали, в сочетании с уникальным значением идентификатора сообщения о состоянии.
Примечание.
При переименовании этих файлов сначала скопируйте их в другую папку, чтобы не повлиять на папку 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 | Значение2 | Значение3 |
|---|---|---|---|
| Интервал msg heartbeat | 60 | ||
| Интервал опроса в папке "Входящие" | 900 | ||
| Размер блока загрузчика | 256 | ||
| Потоки загрузчика | 4 | ||
| Максимальное получение блоков | 100 | ||
| Минимальный возраст отсутствующих сообщений | 2880 | ||
| Интервал проверки повторной синхронизации | 15 | ||
| Повторная настройка | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200 28800 86400</Retry></Config> | 0 |
Примечание.
- Интервал проверки повторной синхронизации имеет значение 60 минут. Это расписание для проверки систем, требующих повторной синхронизации сообщений о состоянии.
- Для минимального возраста отсутствующих сообщений задано значение 2880. Это время, когда сообщение должно быть пропущено до запроса повторной синхронизации.