Beschrijving van statusberichten in Configuration Manager
In dit artikel wordt het systeem voor statusberichten in Configuration Manager beschreven.
Oorspronkelijke productversie: Configuration Manager (huidige vertakking)
Origineel KB-nummer: 4459394
Informatie over statusberichten
Statusberichten in Configuration Manager is een mechanisme dat een clientvoorwaarde op een bepaald moment weerspiegelt. Statusberichten werken daarentegen om beheerders te helpen de werkstroom van gegevens bij te houden via verschillende Configuration Manager onderdelen.
Een statusberichtviewer is rechtstreeks in de console ingebouwd, 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 statusberichtensysteem wordt gebruikt door specifieke onderdelen van Configuration Manager, waaronder:
- software-updates
- gewenst configuratiebeheer
- netwerktoegangsbeveiliging
Kritieke software-updategegevens zijn afhankelijk van het statusberichtensysteem in Configuration Manager. Het begrijpen van statusberichten wordt nog belangrijker in toekomstige versies van Configuration Manager naarmate meer onderdelen hiervan profiteren.
Het volgende diagram bevat een goede beschrijving van de werking van het statusberichtensysteem.
Het groene vak vertegenwoordigt het statusberichtensysteem. De onderdelen in de doos zijn onderdelen die informatie aan het systeem invoeren.
Wanneer statusberichten worden ontvangen, gebeuren er twee dingen:
- Statusberichten worden opgeslagen in de WMI-provider (Windows Management Instrumentation).
- Het statussysteem schraapt WMI in een cyclus van 15 minuten (standaard) voor alle 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 voor de duidelijkheid afzonderlijk weergegeven. Tijdens de installatie van de client bevindt het beheerpunt zich en is het 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 de rest gaat het verkeer rechtstreeks naar het beheerpunt.
Statusberichten die op 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 onderdelen voor statusberichten op de siteserver
Als u uitgebreide logboekregistratie of logboekregistratie voor 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 |
Loglevel | 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 uit de tracering worden verkregen. Dit geldt ook 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 statusberichten 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 zijn geïnterpreteerd.
U ziet onderwerptype en statusbericht-id niet altijd samen in hetzelfde logboek. Het ene type gegevens zonder het andere helpt u niet echt te bepalen wat er nodig is. Zelfs als u echter 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
Opmerking
De volgende grafiek bevat de onderwerptypecodes van de serie 300, 400 en 500.
Gegevens van statusberichten
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Nalevingsstatus onbekend |
| 300 | 1 | Compatibele |
| 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) is 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 installeert |
| 301 | 11 | Wachten tot de installatie van de orchestrator van derden is gestart |
| 302 | 0 | Evaluatiestatus onbekend |
| 302 | 1 | Evaluatie geactiveerd |
| 302 | 2 | De evaluatie is 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 | Compatibele |
| 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 | Afdwinging gestart |
| 402 | 2 | Afdwingen wachten op inhoud |
| 402 | 3 | Wachten tot een andere installatie is voltooid |
| 402 | 4 | Wachten op onderhoudsvenster voordat u installeert |
| 402 | 5 | Opnieuw opstarten vereist voordat u installeert |
| 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 | Bijwerken is vereist |
| 500 | 3 | Update is geïnstalleerd |
| 501 | 0 | Scanstatus onbekend |
| 501 | 1 | Scan wacht op cataloguslocatie |
| 501 | 2 | Scan wordt uitgevoerd |
| 501 | 3 | Scan voltooid |
| 501 | 4 | Opnieuw scannen is in behandeling |
| 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 wordt weergegeven in lichtblauwe tekst. U ziet dat in één logboek mogelijk het werkelijke aantal wordt weergegeven dat kan worden geïnterpreteerd in het gegevensdiagram Statusberichten . De andere kan een algemene waarde weergeven (al geïnterpreteerd). De statusbericht-id (StateId) wordt weergegeven in paarse tekst.
Door de TopicTypestatusbericht-id (StateId) uit de grafiek te combineren, kunt u precies bijhouden wat er in de logboeken gebeurt. In dit voorbeeld worden in deze codevoorbeelden de volgende informatie weergegeven:
- Evaluatie bijwerken
- Het resultaat van de evaluatie
- De update die wordt gedownload
- De update die wordt geïnstalleerd
- Een systeem opnieuw opstarten in behandeling
Het is slechts één voorbeeld van hoe statusberichten worden verzonden naar het statussysteem.
Gegevensstroom voor statusberichten
De volgende afbeelding is een echt voorbeeld van hoe gegevens van statusberichten naar het beheerpunt gaan en worden verwerkt naar de database.
In dit voorbeeld wordt een testclient gebruikt. Het begint met het afdwingen van de client om WMI te scrapen voor alle statusberichten en verzendt deze informatie vervolgens naar het beheerpunt in de volgende polling-cyclus.
In WMI worden statusberichten opgeslagen in de root\ccm\statemsg naamruimte. In die naamruimte zijn er twee interesseklassen: CCM_StateMsg_SerialNum en CCM_StateMsg.
De CCM_StateMsg_SerialNum klasse wordt gebruikt om het laatste serienummer vast te leggen 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. Dit is belangrijk omdat ontbrekende statusberichten kunnen leiden tot onvolledige of onjuiste statusrapportage.
De CCM_StateMsg klasse bevat de statusberichten zelf. In het klasse-exemplaar vindt u alle statusberichten die zijn opgenomen.
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 ervan bijhouden met behulp van de volgende scripts voor opnieuw synchroniseren.
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 op verschillende locaties op internet te vinden. De Configuration Manager SDK wordt gebruikt om ervoor te zorgen dat de client de gegevens opnieuw naar het beheerpunt verzonden.
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 map syswow64 moet verwijderen.
Wanneer de volgende pollingcyclus voor statusberichten plaatsvindt, worden alle statusberichten verzonden naar het beheerpunt.
In het Statemessage.log-bestand ziet u dat de statusberichtgegevens worden opgehaald, opgemaakt in XML en vervolgens naar het beheerpunt worden verzonden. De statusberichtinformatie moet lijken op 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>name</NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent>
<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-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[Heeft statusberichten doorgestuurd naar het beheerpunt]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Opmerking
Dit voorbeeld is afgekapt tot één statusbericht vanwege de grootte van het XML-bestand.
Hoewel het Statemessage.log-bestand registreert dat de berichten worden verzonden naar het beheerpunt, verplaatst het statusberichtensysteem gegevens niet daadwerkelijk naar het beheerpunt. In het volgende voorbeeld ziet u dat CCMMessaging deze bewerking wordt uitgevoerd. Er is meer dat op dit moment achter de schermen gebeurt. 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 op MP_Relay, 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: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Relay: 0 bijlagen ontvangen
Relay: 0 van 0 bijlagen is verwerkt
Inv-Relay: taak 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 de naam file_name.smx.xml krijgt en u vervolgens 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 de computer en het statusbericht zijn gemarkeerd. Het bevat de informatie die we eerder hebben besproken, gecombineerd met de unieke waarde voor statusbericht-id .
Opmerking
Als u de naam van deze bestanden wijzigt, kopieert u deze eerst naar een andere map, zodat u de map Statesys.box niet beïnvloedt.
Ten slotte moeten de statusberichten worden verwerkt in de database. In het bestand Statesys.log ziet u dergelijke berichten die vergelijkbaar zijn met het volgende voorbeeld:
Er zijn nieuwe statusberichten gevonden die moeten worden verwerkt, de verwerking van de thread wordt gestart
Thread 'Thread voor statusberichtverwerking #0' id:5076 gestart
CMessageProcessor - Bovenliggende site 'site_name' gedetecteerd
CMessageProcessor - Verwerkingsbestand: mdlbp169. SMW
CMessageProcessor: verwerkt 1 records met 0 ongeldige records.
CMessageProcessor - Het bestand 'mdlbp169' is gerepliceerd. SMW' naar bovenliggende site site_name.
CMessageProcessor - Verwerkt 1 berichtbestanden in deze batch, met 0 slechte bestanden.
Thread 'Thread voor statusberichtverwerking #0' id:5076 normaal beëindigd
Het databaseverwerkingsonderdeel kan zichtbaar worden gemaakt door SQL-tracering in te schakelen, maar het helpt niet veel. We moeten in plaats daarvan de SQL-profiler gebruiken. De profiler geeft ons een hint van wat er achter de schermen gebeurt, maar niet helemaal. Verschillende sql-opgeslagen 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 over het algemeen met de naam spProcess. Er zijn veel van dergelijke procedures.
De siteserver houdt statusberichten bij wanneer ze binnenkomen, zodat eventuele ontbrekende berichten kunnen worden gevlagd en periodiek een hersynchronisatie kan aanvragen wanneer dat nodig is. Statusberichten zijn belangrijk. Je wilt er geen missen.
Wanneer statusberichten binnenkomen, wordt de unieke id gelezen en opgeslagen in de database. Naarmate de verwerking doorgaat, 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. In het ideale moment is deze tabel leeg. In productie ziet u echter mogelijk gegevens in de tabel. Deze tabel helpt bij het bijhouden van statusberichten waarvoor opnieuw moet worden gesynchroniseerd.
Het sitebeheerbestand bevindt zich in de database. Voer de volgende query uit op een primaire of CAS-site om de specifieke instellingen voor STATE_MESSAGE_SYSTEMop te halen:
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-instellingen
| Naam | Waarde1 | Waarde2 | Waarde3 |
|---|---|---|---|
| Heartbeat MSG-interval | 60 | ||
| Polling-interval postvak IN | 900 | ||
| Grootte van het segment van het laadprogramma | 256 | ||
| Loader Threads | 4 | ||
| Maximum aantal segmenten opgehaald | 100 | ||
| Minimale ontbrekende berichtleeftijd | 2880 | ||
| Controle-interval opnieuw synchroniseren | 15 | ||
| Configuratie opnieuw proberen | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Opmerking
- Controle-interval opnieuw synchroniseren is ingesteld op 60 minuten. Dit is het schema voor het controleren van systemen waarvoor statusberichten opnieuw moeten worden gesynchroniseerd.
- Minimale ontbrekende berichtleeftijd is ingesteld op 2880. Dit is hoe lang een bericht moet ontbreken voordat een hersynchronisatie wordt aangevraagd.