Beschreibung der Statusnachrichten in Configuration Manager
In diesem Artikel wird das Statusnachrichtensystem in Configuration Manager beschrieben.
Ursprüngliche Produktversion: Configuration Manager (Current Branch)
Ursprüngliche KB-Nummer: 4459394
Grundlegendes zu Statusnachrichten
Statusnachrichten in Configuration Manager sind ein Mechanismus, der eine Clientbedingung zu einem bestimmten Zeitpunkt widerspiegelt. Statusmeldungen funktionieren dagegen, damit Administratoren den Workflow von Daten über verschiedene Configuration Manager-Komponenten nachverfolgen können.
Eine Statusmeldungsanzeige ist direkt in die Konsole integriert, sodass Statusmeldungen angezeigt und nachverfolgt werden können. Für Statusmeldungen gibt es keinen entsprechenden Viewer. Das Ergebnis von Statusmeldungen wird in:
- reports
- verschiedene Daten in der Konsole, z. B. die Anzahl der Systeme, die aktualisiert werden müssen
- Clientprotokolle
Statusmeldungen enthalten präzise Informationen zu Bedingungen, die auf dem Client vorhanden sind. Das Statusnachrichtensystem wird von bestimmten Komponenten von Configuration Manager verwendet, einschließlich:
- Softwareupdates
- Gewünschte Konfigurationsverwaltung
- Netzwerkzugriffsschutz
Kritische Softwareupdatedaten basieren auf dem Statusnachrichtensystem in Configuration Manager. Das Verständnis von Statusnachrichten wird in zukünftigen Versionen von Configuration Manager noch wichtiger, da mehr Komponenten davon profitieren.
Das folgende Diagramm enthält eine gute Beschreibung der Funktionsweise des Statusnachrichtensystems.
Das grüne Feld stellt das Statusnachrichtensystem dar. Die Komponenten innerhalb des Felds sind Komponenten, die Informationen an das System weitergeben.
Wenn Statusmeldungen empfangen werden, treten zwei Dinge auf:
- Statusmeldungen werden im WMI-Anbieter (Windows Management Instrumentation) gespeichert.
- Das Zustandssystem verschrottet WMI auf einem 15-Minuten-Zyklus (Standard) für alle Statusmeldungen, die nicht gesendet wurden, und leitet sie dann an den Verwaltungspunkt weiter. Der Zykluszeitraum kann geändert werden.
Im Diagramm wird das Clientinstallationsstück separat zur Übersichtlichkeit angezeigt. Während der Clientinstallation befindet sich der Verwaltungspunkt und richtet sich an Statusmeldungen. Statusmeldungen zur Clientinstallation werden unter einer der folgenden Bedingungen an den Fallbackstatuspunkt (FSP) weitergeleitet (sofern er konfiguriert ist):
- Der Verwaltungspunkt ist nicht erreicht.
- Der Verwaltungspunkt ist aus irgendeinem Grund ausgefallen.
Für alles andere geht der Datenverkehr direkt an den Verwaltungspunkt.
Statusmeldungen, die am Verwaltungspunkt eingehen, werden von der MP Relay-Komponente in die .smx Dateien verarbeitet und in den auth\statesys.box\incoming Ordner auf dem Standortserver abgelegt. Anschließend werden sie in die Datenbank verarbeitet, um den Workflow abzuschließen.
Tiefergehen
Wir müssen sicherstellen, dass die ausführliche Protokollierung für Folgendes aktiviert ist:
- der Client
- der Verwaltungspunkt
- die Statusnachrichtenkomponenten auf dem Standortserver
Zum Festlegen ausführlicher oder Debugprotokollierung auf einem Configuration Manager-Client oder Verwaltungspunkt bearbeiten oder erstellen Sie die folgenden Registrierungseinträge:
| Registrierungsunterschlüssel | DWORD-Name | Wertdaten |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
LogLevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Aktiviert | Richtig |
Bearbeiten Sie auf dem Standortserver den folgenden Registrierungseintrag, um ausführliche Protokollierung zu aktivieren, und starten Sie dann den SMS_Executive Dienst neu (oder die Zustandssystemkomponente):
| Registrierungsunterschlüssel | DWORD-Name | Wertdaten |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Ausführliche Protokollierung | 1 |
Die Ablaufverfolgung von SQL-Befehlen erfordert, dass die SQL-Ablaufverfolgung für Configuration Manager-Komponenten aktiviert ist. Aber nicht viel nützliche Daten können direkt aus der Ablaufverfolgung abgerufen werden. Dies gilt auch dann, wenn Profiler aktiviert ist. Daher untersuchen wir die dateien Updatesdeployment.log und Statemessage.log auf dem Client. Durch die Interpretation der Statusmeldungen in diesen Protokollen können wir ein klares Bild davon erhalten, was bei den verschiedenen Schritten des Prozesses geschieht.
Bevor wir Protokollcodebeispiele untersuchen, müssen wir das Statusmeldungsformat verstehen. Die Statusnachricht selbst besteht aus mehreren Teilen, einschließlich Thementyp und Statusnachrichten-ID. An einigen Stellen in den Protokollen scheint der Thementyp für Sie bereits interpretiert zu werden.
Im selben Protokoll wird der Thementyp und die Statusnachrichten-ID nicht immer angezeigt. Eine Art von Daten ohne den anderen hilft Ihnen nicht wirklich zu bestimmen, was erforderlich ist. Selbst wenn Sie jedoch sowohl über die Thementyp - als auch über die Statusnachrichten-ID verfügen, sind die Informationen nicht hilfreich, es sei denn, Sie können sie interpretieren.
Das folgende Diagramm kann Ihnen dabei helfen, die Kombination von TopicType und StateID zum Abrufen aussagekräftiger Daten zu interpretieren.
select * from v_StateNames
Notiz
Das folgende Diagramm enthält die Codes 300, 400 und 500 Datenreihe Thementyp .
Statusnachrichtendaten
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Compliancestatus unbekannt |
| 300 | 1 | Konform |
| 300 | 2 | Nicht konform |
| 300 | 3 | Konflikt erkannt |
| 301 | 0 | Erzwingungsstatus unbekannt |
| 301 | 1 | Installieren von Updates |
| 301 | 2 | Warten auf neustarten |
| 301 | 3 | Warten auf den Abschluss einer weiteren Installation |
| 301 | 4 | Erfolgreich installierte Updates |
| 301 | 5 | Ausstehender Systemneustart |
| 301 | 6 | Fehler beim Installieren von Update(en) |
| 301 | 7 | Herunterladen von Updates |
| 301 | 8 | Heruntergeladene Updates |
| 301 | 9 | Fehler beim Herunterladen von Updates. |
| 301 | 10 | Warten auf Wartungsfenster vor der Installation |
| 301 | 11 | Warten auf den Orchestrator eines Drittanbieters, um die Installation zu initiieren |
| 302 | 0 | Auswertungsstatus unbekannt |
| 302 | 1 | Auswertung aktiviert |
| 302 | 2 | Die Auswertung war erfolgreich. |
| 302 | 3 | Fehler bei der Auswertung |
| 400 | 0 | Erkennungsstatus unbekannt |
| 400 | 1 | Nicht erforderlich |
| 400 | 2 | Nicht erkannt |
| 400 | 3 | Erkannt |
| 401 | 0 | Compliancestatus unbekannt |
| 401 | 1 | Konform |
| 401 | 2 | Nicht konform |
| 401 | 3 | Konflikt erkannt |
| 401 | 4 | Fehler |
| 401 | 5 | Nicht zutreffend |
| 401 | 6 | Nicht erkannt |
| 401 | 7 | Erzwungen |
| 402 | 0 | Erzwingungsstatus unbekannt |
| 402 | 1 | Erzwingung gestartet |
| 402 | 2 | Erzwingung wartet auf Inhalt |
| 402 | 3 | Warten auf den Abschluss einer weiteren Installation |
| 402 | 4 | Warten auf Wartungsfenster vor der Installation |
| 402 | 5 | Neu starten erforderlich vor der Installation |
| 402 | 6 | Allgemeiner Fehler |
| 402 | 7 | Ausstehende Installation |
| 402 | 8 | Update wird installiert. |
| 402 | 9 | Ausstehender Systemneustart |
| 402 | 10 | Erfolgreich installiertes Update |
| 402 | 11 | Update konnte nicht installiert werden. |
| 402 | 12 | Herunterladen eines Updates |
| 402 | 13 | Herunterladen eines Updates |
| 402 | 14 | Update kann nicht heruntergeladen werden |
| 500 | 0 | Erkennungsstatus unbekannt |
| 500 | 1 | Update ist nicht erforderlich |
| 500 | 2 | Update ist erforderlich |
| 500 | 3 | Update ist installiert |
| 501 | 0 | Scanstatus unbekannt |
| 501 | 1 | Scan wartet auf den Katalogspeicherort |
| 501 | 2 | Scan wird ausgeführt |
| 501 | 3 | Überprüfung abgeschlossen |
| 501 | 4 | Überprüfung steht noch aus |
| 501 | 5 | Fehler beim Scannen. |
| 501 | 6 | Überprüfung mit Fehlern abgeschlossen |
Weitere Informationen finden Sie unter Statusmeldungen in Configuration Manager.
Im folgenden Beispiel werden die dateien Updatesdeployment.log und Statemessage.log ausgerichtet und verglichen. Stellen Sie sicher, dass die Protokolle auf dieselbe Statusmeldung verweisen, indem Sie denselben TopicID (grünen Text) ausrichten. Es weist eindeutig darauf hin, dass die beiden Protokolle auf dieselbe Statusmeldung verweisen. Dies TopicType wird in hellblauem Text angezeigt. Beachten Sie, dass ein Protokoll möglicherweise die tatsächliche Zahl anzeigt, die aus dem Statusnachrichtendatendiagramm interpretiert werden kann. Die andere kann einen generischen Wert (bereits interpretiert) anzeigen. Die Statusmeldungs-ID (StateId) wird in lila Text angezeigt.
Indem Sie die ID und die TopicType Statusmeldung (StateId) aus dem Diagramm kombinieren, können Sie genau verfolgen, was in den Protokollen passiert. In diesem Beispiel zeigen diese Codebeispiele die folgenden Informationen:
- Aktualisieren der Auswertung
- Das Ergebnis der Auswertung
- Das heruntergeladene Update
- Das update, das installiert wird
- Ein ausstehender Systemneustart
Es ist nur ein Beispiel dafür, wie Statusmeldungen in das Zustandssystem gesendet werden.
Statusnachrichtendatenfluss
Die folgende Abbildung ist ein tatsächliches Beispiel dafür, wie Statusnachrichtendaten an den Verwaltungspunkt gehen und an die Datenbank verarbeitet werden.
In diesem Beispiel wird ein Testclient verwendet. Zunächst wird der Client gezwungen, WMI für alle Statusnachrichteninformationen zu verschrotten und diese Informationen dann an den Verwaltungspunkt im nächsten Abrufzyklus zu senden.
In WMI werden Statusmeldungen im root\ccm\statemsg Namespace gespeichert. In diesem Namespace gibt es zwei Interessante Klassen: CCM_StateMsg_SerialNum und CCM_StateMsg.
Die CCM_StateMsg_SerialNum Klasse wird verwendet, um die letzte Seriennummer aufzuzeichnen, die für eine Statusmeldung verwendet wird. Jede Statusnachricht weist eine eindeutige Seriennummer auf, ähnlich der Hardwareinventur. Auf diese Weise kann der Standortserver nachverfolgen, ob statusmeldungen aus dem System fehlen. Es ist wichtig, dass fehlende Statusmeldungen unvollständige oder ungenaue Zustandsberichte verursachen können.
Die CCM_StateMsg Klasse enthält die Statusmeldungen selbst. In der Klasseninstanz finden Sie alle Zustandsmeldungen, die aufgezeichnet werden.
Wenn Sie eine dieser Nachrichten öffnen, finden Sie die Details der Statusmeldung und einige Daten, die wir zuvor behandelt haben, wie im folgenden Beispiel gezeigt.
Wir können die Daten erneut an den Verwaltungspunkt senden und den Fortschritt mithilfe der folgenden resync-Skripts nachverfolgen.
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()
Dieses Skript befindet sich im Web an verschiedenen Speicherorten. Es verwendet das Configuration Manager SDK, um zu bewirken, dass der Client seine Daten an den Verwaltungspunkt erneut sendet.
In der Regel wird ein Visual Basic-Skript (VBScript) mithilfe von cscript. Beachten Sie, dass das Skript möglicherweise fehlschlägt, wenn Sie versuchen, es selbst auszuführen. Das Problem besteht darin, dass Configuration Manager eine 32-Bit-Anwendung ist, die auf einem 64-Bit-Server ausgeführt wird. Die Standardversion von 64-Bit ist die 64-Bit-Version und funktioniert in der Regel mit jedem VBScript.The default version of cscript is the 64-bit version and generally works fine with any VBScript. In diesem Fall erfordert der aufruf, der ausgeführt wird, dass die 32-Bit-Version des cscript Syswow64-Ordners nicht mehr verfügbar ist.
Wenn der nächste Statusmeldungsabfragungszyklus auftritt, werden alle Statusmeldungen an den Verwaltungspunkt gesendet.
In der datei Statemessage.log können Sie sehen, dass die Statusmeldungsinformationen abgerufen, in XML formatiert und dann an den Verwaltungspunkt gesendet werden. Die Statusmeldungsinformationen sollten dem folgenden Beispiel ähneln:
<! [LOG[StateMessage body: <?xml version="1.0" encoding="UTF-16"?>
<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<>/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></ReportBody></Report>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[Erfolgreich weitergeleitete Statusmeldungen an den Verwaltungspunkt]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Notiz
Dieses Beispiel wird aufgrund der Größe der XML-Datei auf eine einzelne Statusmeldung abgeschnitten.
Obwohl die Statemessage.log Dateieinträge, die die Nachrichten an den Verwaltungspunkt verteilt werden, werden die Daten vom Statusnachrichtensystem nicht tatsächlich an den Verwaltungspunkt verschoben. Im folgenden Beispiel können Sie sehen, dass CCMMessaging dieser Vorgang ausgeführt wird. Es gibt mehr, die sich an diesem Punkt hinter den Kulissen befinden. Es reicht jedoch aus, zu wissen, dass CCMMessaging die Daten an den Verwaltungspunkt (in diesem Fall die MP_Relay Komponente) gesendet werden.
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Erfolgreich an den Host "host_name" übermittelt.]LOG]!>
Wenn die Daten zur Verarbeitung MP_Relayantreffen, wird sie verarbeitet und in das .smx Dateiformat übersetzt und dann in den auth\statesys.box\incoming Ordner eingefügt.
Inv-Relay-Aufgabe: Verarbeiten des Nachrichtentexts
Relay: FileType= SMX
Relay: Postausgangsverzeichnis: C:\Programme (x86)\Microsoft Configuration Manager\Posteingänge\auth\statesys.box\incoming
Relay: Empfangene 0 Anlagen
Relay: 0 von 0 Anlagen erfolgreich verarbeitet
Inv-Relay: Aufgabe erfolgreich abgeschlossen
auth\statesys.box\incoming Im Ordner können Sie die .smx verarbeiteten Dateien sehen. In der Regel werden sie hier nicht angezeigt. Wenn die Dateien jedoch in diesem Ordner verbleiben, müssen Sie untersuchen, was die Nachrichten sind und warum sie nicht verarbeitet werden. Wenn Sie eine .smx Datei finden, können Sie sie mit einem Texteditor wie Editor öffnen, um die Details anzuzeigen. Die Formatierung der Datei kann jedoch nicht lesbar sein, wie im folgenden Beispiel gezeigt:
Wenn Sie die Datei umbenennen, indem Sie die .smx .xml Erweiterung so hinzufügen, dass die Datei file_name.smx.xml heißt, und Doppelklicken Sie dann auf den neuen Dateinamen, wird die XML-Datei in Internet Explorer geöffnet und ist viel einfacher zu lesen.
Die folgende Abbildung ist ein Beispiel für eine XML-Datei, die in Internet Explorer geöffnet wird. Die Details der Computer- und Statusmeldung werden hervorgehoben. Sie enthält die Informationen, die wir zuvor erläutert haben, kombiniert mit dem eindeutigen Statusnachrichten-ID-Wert .
Notiz
Wenn Sie diese Dateien umbenennen, kopieren Sie sie zuerst in einen anderen Ordner, sodass Sie sich nicht auf den Ordner Statesys.box auswirken.
Schließlich müssen die Statusmeldungen in der Datenbank verarbeitet werden. In der datei Statesys.log können Sie solche Meldungen wie im folgenden Beispiel sehen:
Es wurden neue Statusmeldungen gefunden, die verarbeitet werden sollen, und der Verarbeitungsthread wurde gestartet.
Thread "State Message Processing Thread #0" id:5076 started
CMessageProcessor – Erkannte übergeordnete Website "site_name"
CMessageProcessor - Verarbeitungsdatei: mdlbp169. SMW
CMessageProcessor – Verarbeitete 1 Datensätze mit 0 ungültigen Datensätzen.
CMessageProcessor - Erfolgreich replizierte Datei "mdlbp169. SMW" zur übergeordneten Website site_name.
CMessageProcessor – Verarbeitete 1 Nachrichtendateien in diesem Batch mit 0 ungültigen Dateien.
Thread "State Message Processing Thread #0" id:5076 wurde normal beendet
Die Datenbankverarbeitungskomponente kann durch Aktivieren der SQL-Ablaufverfolgung sichtbar gemacht werden, hilft aber nicht viel. Stattdessen müssen wir den SQL-Profiler verwenden. Der Profiler gibt uns einen Hinweis darauf, was hinter den Kulissen passiert, aber nicht vollständig. Mehrere gespeicherte SQL-Prozeduren sind für die Verarbeitung von Statusmeldungen verantwortlich. Außerdem speichern mehrere Tabellen in der Datenbank die Statusnachrichtendaten. Die gespeicherten Prozeduren, die Statusnachrichtenverarbeitung durchführen, beginnen im Allgemeinen mit dem Namen spProcess. Es gibt viele solcher Verfahren.
Der Websiteserver verfolgt Statusmeldungen während der Ankunft nach, sodass alle fehlenden Nachrichten gekennzeichnet und bei Bedarf eine erneute Synchronisierung angefordert werden können. Statusmeldungen sind wichtig. Sie möchten keines verpassen.
Wenn Statusmeldungen eingehen, wird die eindeutige ID gelesen und in der Datenbank gespeichert. Wenn die Verarbeitung fortgesetzt wird, werden die Daten regelmäßig aktualisiert. Wenn eine Lücke erkannt wird, werden diese Daten gekennzeichnet und als fehlende Statusmeldungen in der SR_MissingMessageRanges Tabelle gespeichert. Im Idealfall ist diese Tabelle leer. In der Produktion werden jedoch möglicherweise Daten in der Tabelle angezeigt. Diese Tabelle hilft beim Nachverfolgen von Statusmeldungen, die eine erneute Synchronisierung erfordern.
Die Websitesteuerelementdatei befindet sich in der Datenbank. Um die spezifischen Einstellungen für STATE_MESSAGE_SYSTEMabzurufen, führen Sie die folgende Abfrage auf einer primären oder CAS-Website aus:
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))
einstellungen für STATE_MESSAGE_SYSTEM
| Name | Wert1 | Wert2 | Wert3 |
|---|---|---|---|
| Takt-Msg-Intervall | 60 | ||
| Abfrageintervall für Posteingang | 900 | ||
| Ladeblockgröße | 256 | ||
| Ladethreads | 4 | ||
| Max. Blöcke abgerufen | 100 | ||
| Min. Alter der fehlenden Nachricht | 2880 | ||
| Resync Check Interval | 15 | ||
| Wiederholungskonfiguration | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Notiz
- Das Intervall für die erneute Synchronisierung wird auf 60 Minuten festgelegt. Dies ist der Zeitplan für die Überprüfung von Systemen, die Zustandsnachrichten-Neusynchronisierungen erfordern.
- "Min Missing Message Age " ist auf 2880 festgelegt. So lange muss eine Nachricht fehlen, bevor eine erneute Synchronisierung angefordert wird.