Beschrijving van statusberichten in Configuration Manager
In dit artikel wordt het systeem voor statusberichten in Configuration Manager beschreven.
Oorspronkelijke productversie: Configuration Manager (huidige vertakking)
Oorspronkelijk KB-nummer: 4459394
Informatie over statusberichten
Statusberichten in Configuration Manager zijn een mechanisme dat een clientvoorwaarde op een bepaald moment weergeeft. Statusberichten werken daarentegen om beheerders te helpen de werkstroom van gegevens bij te houden via verschillende Configuration Manager-onderdelen.
Een statusberichtviewer is rechtstreeks ingebouwd in de console, zodat statusberichten kunnen worden bekeken en bijgehouden. Er is geen equivalente viewer voor statusberichten. Het resultaat van statusberichten wordt weergegeven in:
- rapporten
- verschillende gegevens in de console, zoals het aantal systemen dat moet worden bijgewerkt
- clientlogboeken
Statusberichten bevatten beknopte informatie over in-place voorwaarden op de client. Het systeem voor statusberichten wordt gebruikt door specifieke onderdelen van Configuration Manager, waaronder:
- software-updates
- gewenst configuratiebeheer
- netwerktoegangsbeveiliging
Essentiële software-updategegevens zijn afhankelijk van het systeem voor statusberichten in Configuration Manager. Het begrijpen van statusberichten wordt nog belangrijker in toekomstige versies van Configuration Manager, omdat meer onderdelen hiervan profiteren.
In het volgende diagram ziet u een goede beschrijving van de werking van het systeem voor statusberichten.
Het groene vak vertegenwoordigt het systeem voor statusberichten. De onderdelen in het vak zijn onderdelen die informatie aan het systeem invoeren.
Wanneer statusberichten worden ontvangen, treden er twee dingen op:
- Statusberichten worden opgeslagen in de WMI-provider (Windows Management Instrumentation).
- Het statussysteem scrapt WMI op een cyclus van 15 minuten (standaard) voor statusberichten die niet zijn verzonden en stuurt deze vervolgens door naar het beheerpunt. De cyclusperiode kan worden gewijzigd.
In het diagram wordt het installatiestuk van de client afzonderlijk weergegeven voor duidelijkheid. Tijdens de clientinstallatie bevindt het beheerpunt zich en is gericht op statusberichten. Statusberichten over de clientinstallatie worden doorgestuurd naar het terugvalstatuspunt (FSP) (als deze is geconfigureerd) onder een van de volgende voorwaarden:
- Het beheerpunt is niet bereikt.
- Het beheerpunt is om een of andere reden niet beschikbaar.
Voor al het andere gaat verkeer rechtstreeks naar het beheerpunt.
Statusberichten die bij het beheerpunt binnenkomen, worden door het MP Relay-onderdeel in de .smx bestanden verwerkt en in de auth\statesys.box\incoming map op de siteserver geplaatst. Vervolgens worden ze verwerkt in de database om de werkstroom te voltooien.
Dieper graven
We moeten ervoor zorgen dat uitgebreide logboekregistratie is ingeschakeld voor:
- de client
- het beheerpunt
- de statusberichtenonderdelen op de siteserver
Als u uitgebreide logboekregistratie of foutopsporing wilt instellen op een Configuration Manager-client of -beheerpunt, bewerkt of maakt u de volgende registervermeldingen:
| Registersubsleutel | DWORD-naam | Waardegegevens |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Logniveau | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Ingeschakeld | Waar |
Bewerk op de siteserver de volgende registervermelding om uitgebreide logboekregistratie in te schakelen en start vervolgens de SMS_Executive service (of het statussysteemonderdeel) opnieuw op:
| Registersubsleutel | DWORD-naam | Waardegegevens |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Uitgebreide logboekregistratie | 1 |
Voor het traceren van SQL-opdrachten moet SQL-tracering zijn ingeschakeld voor Configuration Manager-onderdelen. Maar niet veel nuttige gegevens kunnen rechtstreeks worden verkregen via de tracering. Dit geldt zelfs als Profiler is ingeschakeld. Daarom onderzoeken we de Updatesdeployment.log en Statemessage.log bestanden op de client. Door de statusberichten in deze logboeken te interpreteren, kunnen we een duidelijk beeld krijgen van wat er gebeurt tijdens de verschillende stappen in het proces.
Voordat we voorbeelden van logboekcode bekijken, moeten we de indeling van het statusbericht begrijpen. Het statusbericht zelf bestaat uit verschillende onderdelen, waaronder onderwerptype en statusbericht-id. Op sommige locaties in de logboeken lijkt het onderwerptype al voor u te worden geïnterpreteerd.
U ziet onderwerptype en statusbericht-id niet altijd samen in hetzelfde logboek. Het ene type gegevens zonder het andere helpt u niet om te bepalen wat er nodig is. Zelfs als u zowel onderwerptype als statusbericht-id hebt, is de informatie niet nuttig, tenzij u deze kunt interpreteren.
De volgende grafiek kan u helpen bij het interpreteren van de combinatie van en StateID het verkrijgen van TopicType zinvolle gegevens.
select * from v_StateNames
Notitie
De volgende grafiek bevat de codes voor het onderwerptype 300, 400 en 500.
Statusberichtengegevens
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Nalevingsstatus onbekend |
| 300 | 1 | compatibel |
| 300 | 2 | Niet-compatibel |
| 300 | 3 | Conflict gedetecteerd |
| 301 | 0 | Afdwingingsstatus onbekend |
| 301 | 1 | Update(s) installeren |
| 301 | 2 | Wachten op opnieuw opstarten |
| 301 | 3 | Wachten tot een andere installatie is voltooid |
| 301 | 4 | Update(s) zijn geïnstalleerd |
| 301 | 5 | Systeem opnieuw opstarten in behandeling |
| 301 | 6 | Kan update(s) niet installeren |
| 301 | 7 | Update(s) downloaden |
| 301 | 8 | Gedownloade update(s) |
| 301 | 9 | Kan update(s) niet downloaden |
| 301 | 10 | Wachten op onderhoudsvenster voordat u de installatie installeert |
| 301 | 11 | Wachten op een orchestrator van derden om de installatie te starten |
| 302 | 0 | Evaluatiestatus onbekend |
| 302 | 1 | Evaluatie geactiveerd |
| 302 | 2 | Evaluatie voltooid |
| 302 | 3 | Evaluatie is mislukt |
| 400 | 0 | Detectiestatus onbekend |
| 400 | 1 | Niet vereist |
| 400 | 2 | Niet gedetecteerd |
| 400 | 3 | Gedetecteerd |
| 401 | 0 | Nalevingsstatus onbekend |
| 401 | 1 | compatibel |
| 401 | 2 | Niet-compatibel |
| 401 | 3 | Conflict gedetecteerd |
| 401 | 4 | Error |
| 401 | 5 | Niet van toepassing |
| 401 | 6 | Niet gedetecteerd |
| 401 | 7 | Afgedwongen |
| 402 | 0 | Afdwingingsstatus onbekend |
| 402 | 1 | Afdwingen gestart |
| 402 | 2 | Afdwingen die wachten op inhoud |
| 402 | 3 | Wachten tot een andere installatie is voltooid |
| 402 | 4 | Wachten op onderhoudsvenster voordat u de installatie installeert |
| 402 | 5 | Opnieuw opstarten vereist voordat de installatie wordt uitgevoerd |
| 402 | 6 | Algemene fout |
| 402 | 7 | Installatie in behandeling |
| 402 | 8 | Update installeren |
| 402 | 9 | Systeem opnieuw opstarten in behandeling |
| 402 | 10 | Update is geïnstalleerd |
| 402 | 11 | Kan update niet installeren |
| 402 | 12 | Update downloaden |
| 402 | 13 | Gedownloade update |
| 402 | 14 | Kan update niet downloaden |
| 500 | 0 | Detectiestatus onbekend |
| 500 | 1 | Bijwerken is niet vereist |
| 500 | 2 | Update is vereist |
| 500 | 3 | Update is geïnstalleerd |
| 501 | 0 | Scanstatus onbekend |
| 501 | 1 | Scannen wacht op cataloguslocatie |
| 501 | 2 | Scan wordt uitgevoerd |
| 501 | 3 | Scan voltooid |
| 501 | 4 | Scannen is in behandeling voor opnieuw proberen |
| 501 | 5 | Scannen is mislukt |
| 501 | 6 | Scannen voltooid met fouten |
Zie Statusberichten in Configuration Manager voor meer informatie.
In het volgende voorbeeld worden de Updatesdeployment.log- en Statemessage.log-bestanden uitgelijnd en vergeleken. Zorg ervoor dat de logboeken naar hetzelfde statusbericht verwijzen door hetzelfde TopicID uit te lijnen (groene tekst). Het geeft duidelijk aan dat de twee logboeken verwijzen naar hetzelfde statusbericht. De TopicType tekst wordt weergegeven in lichtblauwe tekst. U ziet dat in één logboek mogelijk het werkelijke getal wordt weergegeven dat kan worden geïnterpreteerd vanuit de gegevensgrafiek Statusberichten. De andere kan een algemene waarde weergeven (al geïnterpreteerd). De statusbericht-id (StateId) wordt weergegeven in paarse tekst.
Door de id van het TopicType statusbericht (StateId) uit de grafiek te combineren, kunt u precies bijhouden wat er in de logboeken gebeurt. In dit voorbeeld bevatten deze codevoorbeelden de volgende informatie:
- Evaluatie bijwerken
- Het resultaat van de evaluatie
- De update die wordt gedownload
- De update die wordt geïnstalleerd
- Opnieuw opstarten van systeem in behandeling
Het is slechts één voorbeeld van hoe statusberichten naar het statussysteem worden verzonden.
Gegevensstroom voor statusberichten
De volgende afbeelding is een echt voorbeeld van hoe statusberichtengegevens naar het beheerpunt gaan en naar de database worden verwerkt.
In dit voorbeeld wordt een testclient gebruikt. Het begint met het afdwingen van de client om WMI te scrapen voor alle statusberichten en verzendt die informatie vervolgens naar het beheerpunt in de volgende pollingcyclus.
In WMI worden statusberichten opgeslagen in de root\ccm\statemsg naamruimte. In die naamruimte zijn er twee klassen van belang: CCM_StateMsg_SerialNum en CCM_StateMsg.
De CCM_StateMsg_SerialNum klasse wordt gebruikt om het laatste serienummer op te nemen dat wordt gebruikt voor een statusbericht. Elk statusbericht heeft een uniek serienummer, vergelijkbaar met de hardware-inventaris. Op deze manier kan de siteserver bijhouden of er statusberichten van het systeem ontbreken. Het is belangrijk omdat ontbrekende statusberichten onvolledige of onnauwkeurige statusrapportage kunnen veroorzaken.
De CCM_StateMsg klasse bevat de statusberichten zelf. In het klasse-exemplaar vindt u alle statusberichten die worden vastgelegd.
Als u een van deze berichten opent, vindt u de details van het statusbericht en enkele gegevens die we eerder hebben besproken, zoals wordt weergegeven in het volgende voorbeeld.
We kunnen de gegevens opnieuw verzenden naar het beheerpunt en de voortgang bijhouden met behulp van de volgende hersynchronisatiescripts.
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()
Dit script is te vinden op internet op verschillende locaties. Er wordt gebruikgemaakt van de Configuration Manager SDK om ervoor te zorgen dat de client de gegevens opnieuw verzendt naar het beheerpunt.
Normaal gesproken wordt een Visual Basic-script (VBScript) uitgevoerd met behulp van cscript. U ziet dat het script kan mislukken als u het zelf probeert uit te voeren. Het probleem is dat Configuration Manager een 32-bits toepassing is die wordt uitgevoerd op een 64-bits server. De standaardversie van cscript is de 64-bits versie en werkt over het algemeen prima met vbScript. In dit geval vereist de aanroep die wordt uitgevoerd echter de 32-bits versie waarvan cscript u de syswow64-map niet meer hebt.
Wanneer de volgende pollingcyclus voor statusberichten plaatsvindt, worden alle statusberichten naar het beheerpunt verzonden.
In het bestand Statemessage.log ziet u dat de statusberichtgegevens worden opgehaald, opgemaakt in XML en vervolgens naar het beheerpunt worden verzonden. De informatie over het statusbericht moet er ongeveer uitzien als in het volgende voorbeeld:
<! [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-naam<>/NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent>
<Datum/datum< van ReportType Full</ReportType><>Date>/Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number"><Topic ID="21e49ac6-a273-4a 61-9794-eb675bc743e5" Type="500" IDType="3"/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>102</Param></UserParameters></StateMessageserParameters></StateMessage></ReportBody/ReportBody></Report>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[Statusberichten doorgestuurd naar het beheerpunt]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Notitie
Dit voorbeeld wordt afgekapt tot één statusbericht vanwege de grootte van het XML-bestand.
Hoewel het Statemessage.log-bestand registreert dat de berichten naar het beheerpunt worden verzonden, worden gegevens niet daadwerkelijk naar het beheerpunt verplaatst. In het volgende voorbeeld ziet u dat CCMMessaging deze bewerking wordt uitgevoerd. Er is meer achter de schermen op dit moment. Het is echter voldoende om te weten dat CCMMessaging de gegevens naar het beheerpunt worden verzonden (in dit geval het MP_Relay onderdeel).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): geleverd om 'host_name' te hosten.]LOG]!>
Wanneer de gegevens binnenkomen voor verwerking MP_Relayop, worden deze verwerkt en vertaald naar de .smx bestandsindeling en vervolgens in de auth\statesys.box\incoming map geplaatst.
Inv-Relay-taak: berichttekst verwerken
Relay: FileType= SMX
Relay: Postvak UIT: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Relay: 0 bijlagen ontvangen
Relay: 0 van 0 bijlagen zijn verwerkt
Inv-Relay: taak is voltooid
In de auth\statesys.box\incoming map ziet u de .smx bestanden die worden verwerkt. Normaal gesproken ziet u ze hier niet. Maar als de bestanden in deze map blijven staan, moet u onderzoeken wat de berichten zijn en waarom ze niet worden verwerkt. Als u een .smx bestand vindt, kunt u het openen met behulp van een teksteditor zoals Kladblok om de details te bekijken. De opmaak van het bestand kan echter onleesbaar zijn, zoals in het volgende voorbeeld:
Als u de naam van het .smx bestand wijzigt door de .xml extensie toe te voegen, zodat het bestand file_name.smx.xml wordt genoemd en u dubbelklikt op de nieuwe bestandsnaam, wordt het XML-bestand geopend in Internet Explorer en is het veel gemakkelijker te lezen.
De volgende afbeelding is een voorbeeld van een XML-bestand dat is geopend in Internet Explorer. De details van het computer- en statusbericht zijn gemarkeerd. Het bevat de informatie die we eerder hebben besproken, gecombineerd met de unieke waarde voor statusbericht-id .
Notitie
Als u de naam van deze bestanden wijzigt, kopieert u ze eerst naar een andere map, zodat u geen invloed hebt op de map Statesys.box .
Ten slotte moeten de statusberichten in de database worden verwerkt. In het bestand Statesys.log ziet u dergelijke berichten die vergelijkbaar zijn met het volgende voorbeeld:
Nieuwe statusberichten gevonden die moeten worden verwerkt, thread wordt gestart
Thread "Thread verwerken statusbericht #0" id:5076 gestart
CMessageProcessor - Bovenliggende site 'site_name' gedetecteerd
CMessageProcessor - Verwerkingsbestand: mdlbp169. SMW
CMessageProcessor - Verwerkte 1 records met 0 ongeldige records.
CMessageProcessor : bestand mdlbp169 gerepliceerd. SMW" naar bovenliggende site site_name.
CMessageProcessor - Verwerkte 1 berichtbestanden in deze batch, met 0 ongeldige bestanden.
Thread 'Thread voor verwerking van statusberichten #0' id:5076 is normaal beëindigd
Het databaseverwerkingsonderdeel kan zichtbaar worden gemaakt door SQL-tracering in te schakelen, maar dit helpt niet veel. In plaats daarvan moeten we de SQL Profiler gebruiken. De profiler geeft ons een hint van wat er achter de schermen gebeurt, maar niet helemaal. Verschillende opgeslagen SQL-procedures zijn verantwoordelijk voor het verwerken van statusberichten. Bovendien slaan verschillende tabellen in de database de statusberichtengegevens op. De opgeslagen procedures die de verwerking van statusberichten uitvoeren, beginnen meestal met de naam spProcess. Er zijn veel van dergelijke procedures.
De siteserver houdt statusberichten bij wanneer ze binnenkomen, zodat deze eventuele ontbrekende berichten kunnen markeren en periodiek een hersynchronisatie kunnen aanvragen wanneer dat nodig is. Statusberichten zijn belangrijk. Je wilt niets missen.
Wanneer statusberichten binnenkomen, wordt de unieke id gelezen en opgeslagen in de database. Naarmate de verwerking zich blijft voordoen, worden de gegevens regelmatig bijgewerkt. Als er een hiaat wordt gedetecteerd, worden die gegevens gemarkeerd en opgeslagen als ontbrekende statusberichten in de SR_MissingMessageRanges tabel. Deze tabel is idealiter leeg. In productie ziet u echter mogelijk gegevens in de tabel. Deze tabel helpt statusberichten bij te houden waarvoor een hersynchronisatie is vereist.
Het sitebeheerbestand bevindt zich in de database. Als u de specifieke instellingen voor STATE_MESSAGE_SYSTEMwilt ophalen, voert u de volgende query uit op een primaire of CAS-site:
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))
instellingen voor STATE_MESSAGE_SYSTEM
| Naam | Waarde1 | Waarde2 | Waarde3 |
|---|---|---|---|
| Heartbeat msg-interval | 60 | ||
| Polling-interval voor Postvak IN | 900 | ||
| Grootte van segment van laadprogramma | 256 | ||
| Loaderthreads | 4 | ||
| Maximum aantal opgehaalde segmenten | 100 | ||
| Minimale ontbrekende berichtleeftijd | 2880 | ||
| Interval voor opnieuw synchroniseren van controle | 15 | ||
| Configuratie opnieuw proberen | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Notitie
- Het interval voor opnieuw synchroniseren is ingesteld op 60 minuten. Dit is het schema voor het controleren van systemen waarvoor statusbericht opnieuw moet worden gesynchroniseerd.
- Minimale ontbrekende berichtleeftijd is ingesteld op 2880. Dit is hoe lang een bericht moet ontbreken voordat een hersynchronisatie wordt aangevraagd.