Opis komunikatów o stanie w Configuration Manager
W tym artykule opisano stan systemu obsługi komunikatów w Configuration Manager.
Oryginalna wersja produktu: Configuration Manager (bieżąca gałąź)
Oryginalny numer KB: 4459394
Omówienie komunikatów o stanie
Komunikaty stanu w Configuration Manager to mechanizm, który odzwierciedla warunek klienta w określonym momencie. Komunikaty o stanie pomagają natomiast administratorom śledzić przepływ pracy danych za pośrednictwem różnych składników Configuration Manager.
Przeglądarka komunikatów o stanie jest wbudowana bezpośrednio w konsolę, aby można było wyświetlać i śledzić komunikaty o stanie. Nie ma równorzędnej przeglądarki dla komunikatów o stanie. Wynik komunikatów o stanie jest widoczny w następujących elementach:
- Raporty
- różnych danych w konsoli, takich jak liczba systemów, które muszą zostać zaktualizowane
- dzienniki klienta
Komunikaty o stanie zawierają zwięzłe informacje o warunkach na kliencie. System komunikatów o stanie jest używany przez określone składniki Configuration Manager, w tym:
- aktualizacje oprogramowania
- żądane zarządzanie konfiguracją
- ochrona dostępu do sieci
Krytyczne dane aktualizacji oprogramowania opierają się na systemie komunikatów stanu w Configuration Manager. Zrozumienie komunikatów o stanie stanie stanie stanie się jeszcze ważniejsze w przyszłych wersjach Configuration Manager, ponieważ korzysta z niej więcej składników.
Na poniższym diagramie przedstawiono dobry opis działania systemu komunikatów o stanie.
Zielone pole reprezentuje system komunikatów o stanie. Składniki wewnątrz pola to składniki, które przesyłają 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 zgarnia usługę WMI w 15-minutowym cyklu (domyślnie) 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 element instalacji klienta jest wyświetlany oddzielnie, aby uzyskać przejrzystość. 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ągnięty.
- Z jakiegoś powodu punkt zarządzania nie działa.
W przypadku wszystkich innych elementów ruch trafia 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 folderze auth\statesys.box\incoming na serwerze lokacji. Następnie są one przetwarzane do bazy danych w celu ukończenia przepływu pracy.
Kopanie głębiej
Musimy upewnić się, że pełne rejestrowanie jest włączone dla:
- klient
- punkt zarządzania
- składniki komunikatów o stanie na serwerze lokacji
Aby ustawić pełne lub debugowanie rejestrowania w Configuration Manager klienta lub punktu 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 |
Loglevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Włączone | True |
Na serwerze lokacji edytuj 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 Configuration Manager. Ale niewiele przydatnych danych można uzyskać bezpośrednio z ś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 się dzieje 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 o stanie. W niektórych lokalizacjach dzienników typ tematu wydaje się już interpretowany.
W tym samym dzienniku nie zawsze będzie widoczny typ tematu i identyfikator komunikatu o stanie . Jeden typ danych bez drugiego tak naprawdę 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ą pomocne, chyba że można je zinterpretować.
Poniższy wykres może pomóc w interpretacji kombinacji i StateID uzyskaniu istotnych TopicType danych.
select * from v_StateNames
Uwaga
Poniższy wykres zawiera kody typów tematów serii 300, 400 i 500.
Dane komunikatów o stanie
| Typ tematu | StateID | StateName |
|---|---|---|
| 300 | 0 | Nieznany stan zgodności |
| 300 | 1 | Zgodny |
| 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 innej instalacji |
| 301 | 4 | 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 orkiestrator innej firmy |
| 302 | 0 | Nieznany stan oceny |
| 302 | 1 | Aktywowano ocenę |
| 302 | 2 | Ocena zakończyła się pomyślnie |
| 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 | Zgodny |
| 401 | 2 | Niezgodne |
| 401 | 3 | Wykryto konflikt |
| 401 | 4 | Error |
| 401 | 5 | Nie dotyczy |
| 401 | 6 | Nie wykryto |
| 401 | 7 | Wymuszane |
| 402 | 0 | Nieznany stan wymuszania |
| 402 | 1 | Rozpoczęto wymuszanie |
| 402 | 2 | Wymuszanie oczekujące na zawartość |
| 402 | 3 | Oczekiwanie na ukończenie innej instalacji |
| 402 | 4 | 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 czeka na lokalizację wykazu |
| 501 | 2 | Skanowanie jest uruchomione |
| 501 | 3 | Ukończono skanowanie |
| 501 | 4 | Skanowanie oczekuje na ponowienie próby |
| 501 | 5 | Skanowanie nie powiodło się |
| 501 | 6 | Skanowanie zostało zakończone z błędami |
Aby uzyskać więcej informacji, zobacz State messages in Configuration Manager (Komunikaty o stanie w 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ównują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 w jednym dzienniku może być wyświetlana rzeczywista liczba, którą można interpretować na wykresie danych komunikatów o stanie . Drugi może pokazywać wartość ogólną (już zinterpretowaną). Identyfikator komunikatu o stanie (StateId) jest wyświetlany w kolorze fioletowym.
TopicType Łącząc i State Message ID (StateId) z wykresu, można śledzić dokładnie, co się dzieje w dziennikach. W tym przykładzie te przykłady kodu zawierają następujące informacje:
- Ocena aktualizacji
- Wynik oceny
- Pobierana aktualizacja
- Instalowana aktualizacja
- Oczekujące ponowne uruchomienie systemu
To tylko jeden z przykładów 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, w jaki dane komunikatów stanu trafiają do punktu zarządzania i są przetwarzane do bazy danych.
W tym przykładzie użyto klienta testowego. Rozpoczyna się od wymuszenia na kliencie zeskrobania usługi WMI dla wszystkich informacji o komunikatach o stanie, a następnie wysłania tych informacji 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 brakuje żadnych komunikatów o stanie z systemu. 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 dane, które zostały wcześniej omówione, jak pokazano w poniższym przykładzie.
Możemy ponownie skierować dane do punktu zarządzania i śledzić ich postęp przy użyciu następujących 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 Configuration Manager, aby spowodować, że klient ponownie wysyła swoje 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 Configuration Manager to aplikacja 32-bitowa działająca na serwerze 64-bitowym. Domyślna wersja cscript to wersja 64-bitowa i ogólnie działa prawidłowo z dowolnym językiem VBScript. Jednak w tym przypadku wywołanie, które jest wykonywane, wymaga 32-bitowej cscript wersji, która musi zabraknąć folderu syswow64.
Po zakończeniu 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 komunikatach o stanie są ściągane, sformatowane w formacie XML, a następnie wysyłane do punktu zarządzania. Informacje o komunikatach o stanie powinny wyglądać podobnie do następującego przykładu:
<! [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><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number"><Topic ID="21e49ac6-a273-24a61-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[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
Ten przykład jest obcinany do pojedynczego komunikatu o stanie ze względu na rozmiar pliku XML.
Mimo że plik Statemessage.log rejestruje, że komunikaty są wysyłane do punktu zarządzania, system komunikatów stanu w rzeczywistości nie przenosi danych do punktu zarządzania. W poniższym przykładzie widać, że CCMMessaging wykonuje tę operację. W tym momencie za kulisami dzieje się więcej. Wystarczy jednak wiedzieć, że CCMMessaging dane są wysyłane do punktu zarządzania (w tym przypadku składnika MP_Relay ).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Pomyślnie dostarczono hosta "host_name".] DZIENNIK]!>
Po nadejściu danych do przetwarzania w programie MP_Relaysą 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
Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Przekaźnik: Odebrano 0 załączników
Przekaźnik: 0 z 0 załączników pomyślnie przetworzonych
Inv-Relay: zadanie zostało ukończone pomyślnie
W folderze auth\statesys.box\incoming można zobaczyć .smx przetwarzane pliki. Zazwyczaj nie będą one widoczne w tym miejscu. 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ć za pomocą edytora tekstów, takiego jak Notatnik, aby wyświetlić szczegóły. Jednak formatowanie pliku może być nieczytelne, jak w poniższym przykładzie:
Jeśli zmienisz nazwę .smx pliku, dodając .xml rozszerzenie tak, aby plik miał nazwę file_name.smx.xml, a następnie dwukrotnie klikniesz nową nazwę pliku, plik XML zostanie otwarty w programie Internet Explorer i będzie znacznie łatwiejszy do odczytania.
Poniższy obraz jest przykładem pliku XML otwartego w programie Internet Explorer. Szczegóły komputera i komunikat o stanie są wyróżnione. Zawiera informacje omówione wcześniej w połączeniu z unikatową wartością identyfikatora komunikatu o stanie .
Uwaga
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ą zostać przetworzone do bazy danych. W pliku Statesys.log takie komunikaty są podobne do następujących:
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 — przetworzono 1 rekordy z 0 nieprawidłowymi rekordami.
CMessageProcessor — pomyślnie zreplikowaliśmy plik "mdlbp169. SMW" do site_name lokacji nadrzędnej.
CMessageProcessor — przetworzono 1 pliki komunikatów w tej partii z 0 nieprawidłowymi plikami.
Wątek "Wątek przetwarzania komunikatów o stanie #0" o identyfikatorze:5076 został normalnie zakończony
Składnik przetwarzania bazy danych może być widoczny, włączając śledzenie SQL, ale nie pomaga to zbytnio. Zamiast tego należy użyć profilera SQL. Profiler daje nam wskazówkę, co dzieje się za kulisami, ale nie do końca. 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 w miarę ich pojawiania się, 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. W przypadku wykrycia luki te dane są oflagowane i przechowywane jako brakujące komunikaty o stanie w SR_MissingMessageRanges tabeli. Najlepiej, aby ta tabela była 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 dla STATE_MESSAGE_SYSTEMprogramu , uruchom następujące zapytanie w lokacji podstawowej 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
| Name (Nazwa) | Wartość1 | Wartość 2 | Wartość 3 |
|---|---|---|---|
| Interwał msg pulsu | 60 | ||
| Interwał sondowania skrzynki odbiorczej | 900 | ||
| Rozmiar fragmentu modułu ładującego | 256 | ||
| Wątki modułu ładującego | 4 | ||
| Maksymalna liczba pobranych fragmentów | 100 | ||
| Minimalny brakujący wiek komunikatu | 2880 | ||
| Interwał sprawdzania ponownej synchronizacji | 15 | ||
| Ponów próbę konfiguracji | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Uwaga
- Interwał sprawdzania ponownej synchronizacji jest ustawiony na 60 minut. Jest to harmonogram sprawdzania systemów, które wymagają ponownej synchronizacji komunikatów o stanie.
- Minimalna liczba brakujących czasów komunikatów jest ustawiona na wartość 2880. Tak długo musi brakować komunikatu przed żądaniem ponownej synchronizacji.