Opis komunikatów o stanie w programie Configuration Manager
W tym artykule opisano system obsługi komunikatów o stanie w programie Configuration Manager.
Oryginalna wersja produktu: Configuration Manager (current branch)
Oryginalny numer KB: 4459394
Opis komunikatów o stanie
Komunikaty o stanie w programie Configuration Manager to mechanizm, który odzwierciedla warunek klienta w określonym momencie. Natomiast komunikaty o stanie ułatwiają administratorom śledzenie przepływu pracy danych za pomocą różnych składników programu Configuration Manager.
Przeglądarka komunikatów o stanie jest wbudowana bezpośrednio w konsolę, dzięki czemu komunikaty o stanie mogą być wyświetlane i śledzone. Brak równoważnej przeglądarki komunikatów o stanie. Wynik komunikatów o stanie jest widoczny w:
- reports
- różne dane w konsoli programu, takie jak liczba systemów, które muszą zostać zaktualizowane
- dzienniki klienta
Komunikaty o stanie zawierają zwięzłe informacje o warunkach w miejscu na kliencie. System obsługi komunikatów stanu jest używany przez określone składniki programu Configuration Manager, w tym:
- aktualizacje oprogramowania
- żądane zarządzanie konfiguracją
- ochrona dostępu do sieci
Krytyczne dane aktualizacji oprogramowania opierają się na systemie obsługi komunikatów o stanie w programie Configuration Manager. Zrozumienie komunikatów o stanie stanie się jeszcze ważniejsze w przyszłych wersjach programu Configuration Manager, ponieważ coraz więcej składników z nich korzysta.
Na poniższym diagramie przedstawiono dobry opis działania systemu obsługi komunikatów stanu.
Zielone pole reprezentuje system obsługi komunikatów stanu. Składniki w polu to składniki, które zawierają informacje do systemu.
Po odebraniu komunikatów o stanie występują dwie rzeczy:
- Komunikaty o stanie są przechowywane w dostawcy instrumentacji zarządzania Windows (WMI).
- System stanu złomuje usługę WMI w 15-minutowym cyklu (wartość domyślna) dla wszystkich komunikatów o stanie, które nie zostały wysłane, a następnie przekazuje je do punktu zarządzania. Okres cyklu można zmienić.
Na diagramie fragment instalacji klienta jest pokazany oddzielnie w celu zapewnienia przejrzystości. Podczas instalacji klienta punkt zarządzania znajduje się i jest przeznaczony dla komunikatów o stanie. Komunikaty o stanie instalacji klienta są przekazywane do rezerwowego punktu stanu (FSP) (jeśli jest skonfigurowany) w jednym z następujących warunków:
- Punkt zarządzania nie jest osiągany.
- Z jakiegoś powodu punkt zarządzania nie działa.
W przypadku wszystkich innych elementów ruch przechodzi bezpośrednio do punktu zarządzania.
Komunikaty o stanie, które docierają do punktu zarządzania, są przetwarzane do .smx plików przez składnik MP Relay i umieszczane w auth\statesys.box\incoming folderze na serwerze lokacji. Następnie są one przetwarzane w bazie danych w celu ukończenia przepływu pracy.
Bliższe informacje
Musimy upewnić się, że pełne rejestrowanie jest włączone dla:
- klient
- punkt zarządzania
- składniki obsługi komunikatów stanu na serwerze lokacji
Aby ustawić pełne lub debugowanie rejestrowania na kliencie programu Configuration Manager lub w punkcie zarządzania, edytuj lub utwórz następujące wpisy rejestru:
| Podklucz rejestru | Nazwa DWORD | Dane wartości |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
PoziomRejestrowania | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Włączona | True |
Na serwerze lokacji zmodyfikuj następujący wpis rejestru, aby włączyć pełne rejestrowanie, a następnie uruchom ponownie usługę SMS_Executive (lub składnik systemu stanu):
| Podklucz rejestru | Nazwa DWORD | Dane wartości |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Pełne rejestrowanie | 1 |
Śledzenie poleceń SQL wymaga włączenia śledzenia SQL dla składników programu Configuration Manager. Jednak nie wiele przydatnych danych można uzyskać bezpośrednio ze śledzenia. To prawda, nawet jeśli profiler jest włączony. Przeanalizujemy więc pliki Updatesdeployment.log i Statemessage.log na kliencie. Interpretując komunikaty o stanie w tych dziennikach, możemy uzyskać jasny obraz tego, co dzieje się w różnych krokach procesu.
Zanim przeanalizujemy przykłady kodu dziennika, musimy zrozumieć format komunikatu o stanie. Sam komunikat o stanie składa się z kilku części, w tym typu tematu i identyfikatora komunikatu stanu. W niektórych lokalizacjach w dziennikach typ tematu wydaje się być już interpretowany.
Typ tematu i identyfikator komunikatu stanu nie zawsze będą widoczne razem w tym samym dzienniku. Jeden typ danych bez drugiego nie pomaga określić, co jest potrzebne. Jednak nawet jeśli masz zarówno typ tematu, jak i identyfikator komunikatu o stanie, informacje nie są przydatne, chyba że można je interpretować.
Poniższy wykres może pomóc w interpretowaniu kombinacji elementów i StateID uzyskiwaniu znaczących TopicType danych.
select * from v_StateNames
Uwaga 16.
Poniższy wykres zawiera kody typów tematów serii 300, 400 i 500.
Dane komunikatów o stanie
| Typ tematu | Identyfikator stanu | StateName |
|---|---|---|
| 300 | 0 | Nieznany stan zgodności |
| 300 | 1 | Zgodne |
| 300 | 2 | Niezgodne |
| 300 | 3 | Wykryto konflikt |
| 301 | 0 | Nieznany stan wymuszania |
| 301 | 1 | Instalowanie aktualizacji |
| 301 | 2 | Oczekiwanie na ponowne uruchomienie |
| 301 | 3 | Oczekiwanie na ukończenie kolejnej instalacji |
| 301 | 100 | Pomyślnie zainstalowano aktualizacje |
| 301 | 5 | Oczekiwanie na ponowne uruchomienie systemu |
| 301 | 6 | Nie można zainstalować aktualizacji |
| 301 | 7 | Pobieranie aktualizacji |
| 301 | 8 | Pobrane aktualizacje |
| 301 | 9 | Nie można pobrać aktualizacji |
| 301 | 10 | Oczekiwanie na okno obsługi przed zainstalowaniem |
| 301 | 11 | Oczekiwanie na zainicjowanie instalacji przez koordynatora innej firmy |
| 302 | 0 | Nieznany stan oceny |
| 302 | 1 | Aktywowano ocenę |
| 302 | 2 | Ocena powiodła się |
| 302 | 3 | Ocena nie powiodła się |
| 400 | 0 | Nieznany stan wykrywania |
| 400 | 1 | Niewymagane |
| 400 | 2 | Nie wykryto |
| 400 | 3 | Wykryte |
| 401 | 0 | Nieznany stan zgodności |
| 401 | 1 | Zgodne |
| 401 | 2 | Niezgodne |
| 401 | 3 | Wykryto konflikt |
| 401 | 100 | Błąd |
| 401 | 5 | Nie dotyczy |
| 401 | 6 | Nie wykryto |
| 401 | 7 | Wymuszone |
| 402 | 0 | Nieznany stan wymuszania |
| 402 | 1 | Wymuszanie rozpoczęte |
| 402 | 2 | Wymuszanie oczekiwania na zawartość |
| 402 | 3 | Oczekiwanie na ukończenie kolejnej instalacji |
| 402 | 100 | Oczekiwanie na okno obsługi przed zainstalowaniem |
| 402 | 5 | Przed zainstalowaniem wymagane jest ponowne uruchomienie |
| 402 | 6 | Błąd ogólny |
| 402 | 7 | Oczekująca instalacja |
| 402 | 8 | Instalowanie aktualizacji |
| 402 | 9 | Oczekiwanie na ponowne uruchomienie systemu |
| 402 | 10 | Pomyślnie zainstalowano aktualizację |
| 402 | 11 | Nie można zainstalować aktualizacji |
| 402 | 12 | Pobieranie aktualizacji |
| 402 | 13 | Pobrana aktualizacja |
| 402 | 14 | Nie można pobrać aktualizacji |
| 500 | 0 | Nieznany stan wykrywania |
| 500 | 1 | Aktualizacja nie jest wymagana |
| 500 | 2 | Aktualizacja jest wymagana |
| 500 | 3 | Aktualizacja jest zainstalowana |
| 501 | 0 | Nieznany stan skanowania |
| 501 | 1 | Skanowanie oczekuje na lokalizację katalogu |
| 501 | 2 | Skanowanie jest uruchomione |
| 501 | 3 | Ukończono skanowanie |
| 501 | 100 | Skanowanie oczekuje na ponowną próbę |
| 501 | 5 | Skanowanie nie powiodło się |
| 501 | 6 | Skanowanie ukończone z błędami |
Aby uzyskać więcej informacji, zobacz Komunikaty o stanie w programie Configuration Manager.
Poniższy przykład wyrównuje i porównuje pliki Updatesdeployment.log i Statemessage.log. Upewnij się, że dzienniki odwołują się do tego samego komunikatu o stanie, wyrównając ten sam TopicID (zielony tekst). Wyraźnie wskazuje, że dwa dzienniki odwołują się do tego samego komunikatu o stanie. Element TopicType jest wyświetlany w jasnoniebieskim tekście. Zwróć uwagę, że jeden dziennik może wyświetlać rzeczywistą liczbę, którą można interpretować na wykresie danych komunikatów stanu. Druga może pokazywać wartość ogólną (już zinterpretowana). Identyfikator komunikatu stanu (StateId) jest wyświetlany w fioletowym tekście.
Łącząc identyfikator komunikatu TopicType stanu i (StateId) z wykresu, możesz śledzić dokładnie to, co dzieje się w dziennikach. W tym przykładzie w poniższych przykładach kodu przedstawiono następujące informacje:
- Ocena aktualizacji
- Wynik oceny
- Pobierana aktualizacja
- Instalowana aktualizacja
- Oczekujące ponowne uruchomienie systemu
Jest to tylko jeden przykład sposobu wysyłania komunikatów o stanie do systemu stanu.
Przepływ danych komunikatów o stanie
Na poniższej ilustracji przedstawiono rzeczywisty przykład sposobu przetwarzania danych komunikatów o stanie do punktu zarządzania i przetwarzania ich w bazie danych.
W tym przykładzie użyto klienta testowego. Zaczyna się od wymuszenia klienta na złomowanie usługi WMI dla wszystkich informacji o komunikatach o stanie, a następnie wysyła te informacje do punktu zarządzania w następnym cyklu sondowania.
W usłudze WMI komunikaty o stanie są przechowywane w root\ccm\statemsg przestrzeni nazw. W tej przestrzeni nazw istnieją dwie interesujące klasy: CCM_StateMsg_SerialNum i CCM_StateMsg.
Klasa CCM_StateMsg_SerialNum służy do rejestrowania ostatniego numeru seryjnego używanego dla komunikatu o stanie. Każdy komunikat o stanie ma unikatowy numer seryjny podobny do spisu sprzętu. W ten sposób serwer lokacji może śledzić, czy w systemie brakuje komunikatów o stanie. Jest to ważne, ponieważ brakujące komunikaty o stanie mogą powodować niekompletne lub niedokładne raportowanie stanu.
Klasa CCM_StateMsg zawiera same komunikaty o stanie. W wystąpieniu klasy można znaleźć wszystkie zarejestrowane komunikaty o stanie.
Jeśli otworzysz jeden z tych komunikatów, znajdziesz szczegóły komunikatu o stanie i niektóre wcześniej omówione dane, jak pokazano w poniższym przykładzie.
Możemy ponownie wysłać dane do punktu zarządzania i śledzić jego postęp, używając poniższych skryptów ponownej synchronizacji.
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()
Ten skrypt można znaleźć w Internecie w różnych lokalizacjach. Używa zestawu SDK programu Configuration Manager, aby spowodować, że klient będzie ponownie wysłać dane do punktu zarządzania.
Zazwyczaj skrypt języka Visual Basic (VBScript) jest uruchamiany przy użyciu polecenia cscript. Zwróć uwagę, że skrypt może zakończyć się niepowodzeniem, jeśli spróbujesz uruchomić go samodzielnie. Problem polega na tym, że program Configuration Manager jest aplikacją 32-bitową działającą na serwerze 64-bitowym. Domyślną wersją programu jest wersja 64-bitowa cscript i ogólnie działa dobrze z dowolnym językiem VBScript. Jednak w tym przypadku wywołanie, które jest wykonywane, wymaga 32-bitowej wersji cscript , której należy uruchomić z folderu syswow64.
Po wystąpieniu następnego cyklu sondowania komunikatów o stanie wszystkie komunikaty o stanie są wysyłane do punktu zarządzania.
W pliku Statemessage.log widać, że informacje o komunikacie o stanie są ściągane, sformatowane w formacie XML, a następnie wysyłane do punktu zarządzania. Informacje o komunikacie o stanie powinny przypominać następujący przykład:
<! [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><>Nazwa NetBIOSName<>/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/ReportBody><>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[Pomyślnie przekazano komunikaty o stanie do punktu zarządzania]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Uwaga 16.
Ten przykład jest obcinany do pojedynczego komunikatu o stanie z powodu rozmiaru pliku XML.
Mimo że plik Statemessage.log rejestruje, że komunikaty są wysyłane do punktu zarządzania, system obsługi komunikatów stanu nie przenosi danych do punktu zarządzania. W poniższym przykładzie widać, że CCMMessaging wykonuje tę operację. Jest więcej, które idą za kulisami w tym momencie. Jednak wystarczy wiedzieć, że CCMMessaging wysyła dane do punktu zarządzania (w tym przypadku MP_Relay składnika).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Dostarczono pomyślnie do hosta "host_name".LOG]!>
Gdy dane docierają do przetwarzania w MP_Relayfolderze , są przetwarzane i tłumaczone na .smx format pliku, a następnie umieszczane w folderze auth\statesys.box\incoming .
Zadanie Inv-Relay: Przetwarzanie treści komunikatu
Przekaźnik: FileType= SMX
Przekaźnik: dir skrzynki nadawczej: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Przekaźnik: odebrano 0 załączników
Przekaźnik: pomyślnie przetworzyliśmy 0 z 0 załączników
Inv-Relay: Zadanie zostało ukończone pomyślnie
W folderze auth\statesys.box\incoming można zobaczyć .smx przetwarzane pliki. Zazwyczaj nie zobaczysz ich tutaj. Jeśli jednak pliki pozostaną w tym folderze, należy zbadać, czym są komunikaty i dlaczego nie są przetwarzane. Jeśli znajdziesz .smx plik, możesz go otworzyć przy użyciu edytora tekstów, takiego jak Notatnik, aby wyświetlić szczegóły. Jednak formatowanie pliku może być nieczytelne, jak w poniższym przykładzie:
W przypadku zmiany nazwy .smx pliku przez dodanie .xml rozszerzenia tak, aby plik został nazwany file_name.smx.xml, a następnie dwukrotnie klikniesz nową nazwę pliku, plik XML zostanie otwarty w programie Internet Explorer i jest znacznie łatwiejszy do odczytania.
Na poniższej ilustracji przedstawiono przykład pliku XML otwartego w programie Internet Explorer. Szczegóły komputera i komunikatu o stanie są wyróżnione. Zawiera on informacje, które zostały wcześniej omówione, w połączeniu z unikatową wartością identyfikatora komunikatu stanu.
Uwaga 16.
Jeśli zmienisz nazwę tych plików, najpierw skopiuj je do innego folderu, aby nie wpływać na folder Statesys.box .
Na koniec komunikaty o stanie muszą być przetwarzane w bazie danych. W pliku Statesys.log można zobaczyć takie komunikaty podobne do następującego przykładu:
Znaleziono nowe komunikaty o stanie do przetworzenia, rozpoczynając przetwarzanie wątku
Wątek "State Message Processing Thread #0" id:5076 started
CMessageProcessor — wykryta witryna nadrzędna "site_name"
CMessageProcessor — plik przetwarzania: mdlbp169. SMW
CMessageProcessor — przetworzone 1 rekordy z nieprawidłowymi rekordami 0.
CMessageProcessor — pomyślnie zreplikowany plik "mdlbp169. SITE_NAME lokacji nadrzędnej w programie SMW".
CMessageProcessor — przetworzone 1 pliki komunikatów w tej partii z 0 nieprawidłowymi plikami.
Wątek "State Message Processing Thread #0" id:5076 zakończył się normalnie
Składnik przetwarzania bazy danych może być widoczny przez włączenie śledzenia SQL, ale nie pomaga zbyt wiele. Zamiast tego musimy użyć profilera SQL. Profiler daje nam wskazówkę, co dzieje się za kulisami, ale nie całkowicie. Kilka procedur składowanych SQL jest odpowiedzialnych za przetwarzanie komunikatów o stanie. Poza tym kilka tabel w bazie danych przechowuje dane komunikatów o stanie. Procedury składowane, które wykonują przetwarzanie komunikatów o stanie, zwykle zaczynają się od nazwy spProcess. Istnieje wiele takich procedur.
Serwer lokacji śledzi komunikaty o stanie podczas ich nadejścia, dzięki czemu może flagować wszystkie brakujące komunikaty i okresowo żądać ponownej synchronizacji w razie potrzeby. Komunikaty o stanie są ważne. Nie chcesz przegapić żadnego.
Po nadejściu komunikatów o stanie unikatowy identyfikator jest odczytywany i przechowywany w bazie danych. W miarę kontynuowania przetwarzania dane są regularnie aktualizowane. Jeśli zostanie wykryta luka, dane te są oflagowane i przechowywane jako brakujące komunikaty o stanie w SR_MissingMessageRanges tabeli. W idealnym przypadku ta tabela będzie pusta. Jednak w środowisku produkcyjnym dane mogą być widoczne w tabeli. Ta tabela ułatwia śledzenie komunikatów o stanie, które wymagają ponownej synchronizacji.
Plik kontroli lokacji znajduje się w bazie danych. Aby uzyskać określone ustawienia programu STATE_MESSAGE_SYSTEM, uruchom następujące zapytanie w lokacji głównej lub 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))
ustawienia STATE_MESSAGE_SYSTEM
| Nazwisko | Wartość1 | Wartość2 | Wartość3 |
|---|---|---|---|
| Interwał pulsu msg | 60 | ||
| Interwał sondowania skrzynki odbiorczej | 900 | ||
| Rozmiar fragmentu modułu ładującego | 256 | ||
| Wątki modułu ładującego | 100 | ||
| Maksymalna liczba pobranych fragmentów | 100 | ||
| Minimalny brakujący wiek komunikatu | 2880 | ||
| Ponowne synchronizowanie Synchronizacja terval | 15 | ||
| Ponów próbę konfiguracji | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Uwaga 16.
- Ponowna synchronizacja Synchronizacja terval jest ustawiona na 60 minut. Jest to harmonogram sprawdzania systemów wymagających ponownej synchronizacji komunikatów stanu.
- Minimalny brakujący wiek komunikatu ma wartość 2880. Tak długo musi brakować komunikatu, zanim zażądano ponownej synchronizacji.