Beskrivning av tillståndsmeddelanden i Configuration Manager
I den här artikeln beskrivs systemet för tillståndsmeddelanden i Configuration Manager.
Ursprunglig produktversion: Configuration Manager (aktuell gren)
Ursprungligt KB-nummer: 4459394
Förstå tillståndsmeddelanden
Tillståndsmeddelanden i Configuration Manager är en mekanism som återspeglar ett klientvillkor vid en viss tidpunkt. Statusmeddelanden fungerar däremot för att hjälpa administratörer att spåra arbetsflödet för data via olika Configuration Manager-komponenter.
Ett visningsprogram för statusmeddelanden är inbyggt direkt i konsolen så att statusmeddelanden kan visas och spåras. Det finns inget motsvarande visningsprogram för tillståndsmeddelanden. Resultatet av tillståndsmeddelanden visas i:
- rapporter
- olika data i konsolen, till exempel antalet system som måste uppdateras
- klientloggar
Tillståndsmeddelanden innehåller kortfattad information om villkor på plats på klienten. Systemet för tillståndsmeddelanden används av specifika komponenter i Configuration Manager, inklusive:
- programuppdateringar
- önskad konfigurationshantering
- skydd för nätverksåtkomst
Viktiga programuppdateringsdata förlitar sig på tillståndsmeddelandesystemet i Configuration Manager. Att förstå tillståndsmeddelanden blir ännu viktigare i framtida versioner av Configuration Manager när fler komponenter drar nytta av det.
Följande diagram innehåller en bra beskrivning av hur tillståndsmeddelandesystemet fungerar.
Den gröna rutan representerar systemet för tillståndsmeddelanden. Komponenterna i rutan är komponenter som matar information till systemet.
När tillståndsmeddelanden tas emot sker två saker:
- Tillståndsmeddelanden lagras i WMI-providern (Windows Management Instrumentation).
- Tillståndssystemet skrapar WMI på en 15-minuterscykel (standard) för alla tillståndsmeddelanden som inte har skickats och vidarebefordrar dem sedan till hanteringsplatsen. Cykelperioden kan ändras.
I diagrammet visas klientinstallationsdelen separat för tydlighetens skull. Under klientinstallationen finns hanteringsplatsen och är avsedd för tillståndsmeddelanden. Tillståndsmeddelanden om klientinstallationen vidarebefordras till återställningsstatuspunkten (FSP) (om den är konfigurerad) under något av följande villkor:
- Hanteringsplatsen har inte nåtts.
- Hanteringsplatsen är av någon anledning nere.
För allt annat går trafiken direkt till hanteringsplatsen.
Tillståndsmeddelanden som kommer till hanteringsplatsen bearbetas till .smx filerna av MP Relay-komponenten och placeras i auth\statesys.box\incoming mappen på platsservern. Sedan bearbetas de till databasen för att slutföra arbetsflödet.
Gräva djupare
Vi måste se till att utförlig loggning är aktiverad för:
- klienten
- hanteringsplatsen
- tillståndsmeddelandekomponenterna på platsservern
Om du vill ange utförlig eller felsök loggning på en Configuration Manager-klient eller hanteringsplats redigerar eller skapar du följande registerposter:
| Registerundernyckel | DWORD-namn | Värdedata |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Loggnivå | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Aktiverat | Sant |
På platsservern redigerar du följande registerpost för att aktivera utförlig loggning och startar sedan om SMS_Executive tjänsten (eller tillståndssystemkomponenten):
| Registerundernyckel | DWORD-namn | Värdedata |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Utförlig loggning | 1 |
Spårning av SQL-kommandon kräver att SQL-spårning är aktiverat för Configuration Manager-komponenter. Men det går inte att hämta mycket användbara data direkt från spårningen. Det är sant även om Profiler är aktiverat. Därför undersöker vi Updatesdeployment.log- och Statemessage.log-filerna på klienten. Genom att tolka tillståndsmeddelandena i dessa loggar kan vi få en tydlig bild av vad som händer i de olika stegen i processen.
Innan vi undersöker loggkodsexempel måste vi förstå statusmeddelandeformatet. Själva tillståndsmeddelandet består av flera delar, inklusive ämnestyp och tillståndsmeddelande-ID. På vissa platser i loggarna verkar ämnestypen redan tolkas åt dig.
Du ser inte alltid ämnestyp och tillståndsmeddelande-ID tillsammans i samma logg. En typ av data utan den andra hjälper dig inte att avgöra vad som behövs. Men även om du har både ämnestyp och tillståndsmeddelande-ID är informationen inte användbar om du inte kan tolka den.
Följande diagram kan hjälpa dig att tolka kombinationen av TopicType och StateID hämta meningsfulla data.
select * from v_StateNames
Kommentar
Följande diagram innehåller koderna 300, 400 och 500-serien Ämnestyp .
Tillståndsmeddelandedata
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Okänt efterlevnadstillstånd |
| 300 | 1 | Godkänd |
| 300 | 2 | Icke-kompatibel |
| 300 | 3 | Konflikt har identifierats |
| 301 | 0 | Tvingande tillstånd okänt |
| 301 | 1 | Installera uppdateringar |
| 301 | 2 | Väntar på omstart |
| 301 | 3 | Väntar på att en annan installation ska slutföras |
| 301 | 4 | Uppdateringar har installerats |
| 301 | 5 | Väntar på omstart av systemet |
| 301 | 6 | Det gick inte att installera uppdateringar |
| 301 | 7 | Ladda ned uppdateringar |
| 301 | 8 | Hämtade uppdateringar |
| 301 | 9 | Det gick inte att ladda ned uppdateringar |
| 301 | 10 | Väntar på underhållsperiod innan du installerar |
| 301 | 11 | Väntar på att orkestreraren från tredje part ska initiera installationen |
| 302 | 0 | Okänt utvärderingstillstånd |
| 302 | 1 | Utvärdering aktiverad |
| 302 | 2 | Utvärderingen har slutförts |
| 302 | 3 | Utvärderingen misslyckades |
| 400 | 0 | Okänt identifieringstillstånd |
| 400 | 1 | Krävs inte |
| 400 | 2 | Har inte identifierats |
| 400 | 3 | Identifierad |
| 401 | 0 | Okänt efterlevnadstillstånd |
| 401 | 1 | Godkänd |
| 401 | 2 | Icke-kompatibel |
| 401 | 3 | Konflikt har identifierats |
| 401 | 4 | Fel |
| 401 | 5 | Inte tillämpligt |
| 401 | 6 | Har inte identifierats |
| 401 | 7 | Framtvingat |
| 402 | 0 | Tvingande tillstånd okänt |
| 402 | 1 | Verkställigheten har startats |
| 402 | 2 | Verkställighet väntar på innehåll |
| 402 | 3 | Väntar på att en annan installation ska slutföras |
| 402 | 4 | Väntar på underhållsperiod innan du installerar |
| 402 | 5 | Omstart krävs innan du installerar |
| 402 | 6 | Allmänt fel |
| 402 | 7 | Väntar på installation |
| 402 | 8 | Installera uppdatering |
| 402 | 9 | Väntar på omstart av systemet |
| 402 | 10 | Uppdateringen har installerats |
| 402 | 11 | Det gick inte att installera uppdateringen |
| 402 | 12 | Ladda ned uppdatering |
| 402 | 13 | Hämtad uppdatering |
| 402 | 14 | Det gick inte att ladda ned uppdateringen |
| 500 | 0 | Okänt identifieringstillstånd |
| 500 | 1 | Uppdatering krävs inte |
| 500 | 2 | Uppdatering krävs |
| 500 | 3 | Uppdateringen är installerad |
| 501 | 0 | Okänt söktillstånd |
| 501 | 1 | Genomsökning väntar på katalogplats |
| 501 | 2 | Genomsökningen körs |
| 501 | 3 | Genomsökningen har slutförts |
| 501 | 4 | Genomsökning väntar på nytt försök |
| 501 | 5 | Genomsökningen misslyckades |
| 501 | 6 | Genomsökningen slutfördes med fel |
Mer information finns i Tillståndsmeddelanden i Configuration Manager.
I följande exempel justeras och jämförs filerna Updatesdeployment.log och Statemessage.log. Kontrollera att loggarna refererar till samma tillståndsmeddelande genom att justera samma TopicID (grön text). Det visar tydligt att de två loggarna refererar till samma tillståndsmeddelande. TopicType Visas i ljusblå text. Observera att en logg kan visa det faktiska talet som kan tolkas från datadiagrammet Tillståndsmeddelande. Det andra kan visa ett allmänt värde (redan tolkat). Tillståndsmeddelande-ID (StateId) visas i lila text.
Genom att kombinera TopicType meddelande-ID:t och (StateId) från diagrammet kan du spåra exakt vad som händer i loggarna. I det här exemplet visar dessa kodexempel följande information:
- Uppdatera utvärdering
- Resultatet av utvärderingen
- Uppdateringen som laddas ned
- Uppdateringen som installeras
- En väntande omstart av systemet
Det är bara ett exempel på hur tillståndsmeddelanden skickas till tillståndssystemet.
Dataflöde för tillståndsmeddelanden
Följande bild är ett faktiskt exempel på hur tillståndsmeddelandedata tar sig till hanteringsplatsen och bearbetas till databasen.
I det här exemplet används en testklient. Det börjar med att tvinga klienten att skrapa WMI för all information om tillståndsmeddelanden och skickar sedan informationen till hanteringsplatsen i nästa avsökningscykel.
I WMI lagras tillståndsmeddelanden i root\ccm\statemsg namnområdet. I det namnområdet finns det två intresseklasser: CCM_StateMsg_SerialNum och CCM_StateMsg.
Klassen CCM_StateMsg_SerialNum används för att registrera det sista serienumret som används för ett tillståndsmeddelande. Varje tillståndsmeddelande har ett unikt serienummer som liknar maskinvaruinventeringen. På så sätt kan platsservern hålla reda på om den saknar tillståndsmeddelanden från systemet. Det är viktigt eftersom saknade tillståndsmeddelanden kan orsaka ofullständig eller felaktig tillståndsrapportering.
Klassen CCM_StateMsg innehåller själva tillståndsmeddelandena. I klassinstansen hittar du alla tillståndsmeddelanden som registreras.
Om du öppnar ett av dessa meddelanden hittar du information om tillståndsmeddelandet och vissa data som vi tidigare har diskuterat, som du ser i följande exempel.
Vi kan skicka om data till hanteringsplatsen och spåra dess förlopp med hjälp av följande omsynkroniseringsskript.
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()
Det här skriptet finns på webben på olika platser. Den använder Configuration Manager SDK för att få klienten att skicka om sina data till hanteringsplatsen.
Vanligtvis körs ett Visual Basic-skript (VBScript) med hjälp cscriptav . Observera att skriptet kan misslyckas om du försöker köra det själv. Problemet är att Configuration Manager är ett 32-bitarsprogram som körs på en 64-bitars server. Standardversionen av cscript är 64-bitarsversionen och fungerar vanligtvis bra med alla VBScript. Men i det här fallet kräver anropet som görs den 32-bitarsversion av cscript som du måste köra ut från mappen syswow64.
När nästa avsökningscykel för tillståndsmeddelanden inträffar skickas alla tillståndsmeddelanden till hanteringsplatsen.
I filen Statemessage.log kan du se att statusmeddelandeinformationen hämtas, formateras till XML och sedan skickas till hanteringsplatsen. Informationen om tillståndsmeddelandet bör likna följande exempel:
<! [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</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[Vidarebefordrade tillståndsmeddelanden till hanteringsplatsen]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Kommentar
Det här exemplet trunkeras till ett enda tillståndsmeddelande på grund av XML-filens storlek.
Även om den Statemessage.log filen registrerar att meddelandena skickas till hanteringsplatsen, flyttar inte tillståndsmeddelandesystemet data till hanteringsplatsen. I följande exempel kan du se att CCMMessaging gör den här åtgärden. Det finns mer som pågår bakom kulisserna just nu. Det räcker dock att veta att CCMMessaging skickar data till hanteringsplatsen (i det här fallet komponenten MP_Relay ).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Levereras som värd för "host_name".]LOG]!>
När data tas emot för bearbetning på MP_Relaybearbetas och översätts de .smx till filformatet och placeras sedan i auth\statesys.box\incoming mappen.
Inv-Relay-uppgift: Bearbeta meddelandetext
Relay: FileType= SMX
Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Relay: Mottagna 0 bifogade filer
Relä: 0 av 0 bifogade filer har bearbetats
Inv-Relay: Uppgiften har slutförts
auth\statesys.box\incoming I mappen kan du se de .smx filer som bearbetas. Vanligtvis ser du dem inte här. Men om filerna finns kvar i den här mappen måste du undersöka vad meddelandena är och varför de inte bearbetas. Om du hittar en .smx fil kan du öppna den med hjälp av en textredigerare som Anteckningar för att se informationen. Formateringen av filen kan dock vara oläslig, som i följande exempel:
Om du byter .smx namn på filen genom att lägga till .xml tillägget så att filen heter file_name.smx.xml och sedan dubbelklickar på det nya filnamnet öppnas XML-filen i Internet Explorer och är mycket enklare att läsa.
Följande bild är ett exempel på en XML-fil som öppnas i Internet Explorer. Information om datorn och tillståndsmeddelandet är markerade. Den innehåller den information som vi tidigare har diskuterat, kombinerat med det unika värdet för tillståndsmeddelande-ID .
Kommentar
Om du byter namn på dessa filer kopierar du dem först till en annan mapp så att du inte påverkar mappen Statesys.box .
Slutligen måste tillståndsmeddelandena bearbetas till databasen. I filen Statesys.log kan du se sådana meddelanden som liknar följande exempel:
Hittade nya tillståndsmeddelanden att bearbeta och började bearbeta tråden
Tråden "State Message Processing Thread #0" id:5076 started
CMessageProcessor – Identifierad överordnad webbplats "site_name"
CMessageProcessor – Bearbetningsfil: mdlbp169. SMW
CMessageProcessor – Bearbetade 1 poster med 0 ogiltiga poster.
CMessageProcessor – replikerade filen "mdlbp169. SMW" till överordnad plats site_name.
CMessageProcessor – Bearbetade 1 meddelandefiler i den här batchen med 0 felaktiga filer.
Tråden "State Message Processing Thread #0" id:5076 avslutades normalt
Databasbearbetningskomponenten kan göras synlig genom att aktivera SQL-spårning, men det hjälper inte mycket. Vi måste använda SQL Profiler i stället. Profileraren ger oss en antydan om vad som händer i bakgrunden, men inte helt. Flera SQL-lagrade procedurer ansvarar för att bearbeta tillståndsmeddelanden. Dessutom lagrar flera tabeller i databasen tillståndsmeddelandedata. De lagrade procedurer som utför tillståndsbearbetning av meddelanden börjar vanligtvis med namnet spProcess. Det finns många sådana förfaranden.
Platsservern spårar tillståndsmeddelanden när de tas emot, så att den kan flagga eventuella meddelanden som saknas och regelbundet begära en omsynkronisering när det behövs. Tillståndsmeddelanden är viktiga. Du vill inte missa några.
När tillståndsmeddelanden anländer läss och lagras det unika ID:t i databasen. Allt eftersom bearbetningen fortsätter uppdateras data regelbundet. Om ett mellanrum identifieras flaggas dessa data och lagras som saknade tillståndsmeddelanden i SR_MissingMessageRanges tabellen. Helst är den här tabellen tom. I produktion kan du dock se data i tabellen. Den här tabellen hjälper dig att spåra tillståndsmeddelanden som kräver en omsynkronisering.
Platskontrollfilen finns i databasen. Om du vill hämta de specifika inställningarna för STATE_MESSAGE_SYSTEMkör du följande fråga på en primär plats eller CAS-plats:
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 inställningar
| Name | Värde 1 | Värde 2 | Värde 3 |
|---|---|---|---|
| Pulsslag msg intervall | 60 | ||
| Inkorgens avsökningsintervall | 900 | ||
| Segmentstorlek för inläsare | 256 | ||
| Inläsningstrådar | 4 | ||
| Maximalt antal hämtade segment | 100 | ||
| Minsta meddelandeålder som saknas | 2880 | ||
| Synkronisera om Incheckning terval | 15 | ||
| Försök konfigurera igen | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Kommentar
- Omsynkronisera Incheckning terval är inställt på 60 minuter. Det här är schemat för att kontrollera system som kräver omsynkronisering av tillståndsmeddelanden.
- Minsta meddelandeålder som saknas är inställd på 2880. Så här länge måste ett meddelande saknas innan en omsynkronisering begärs.