July 30, 2014
0

Frissítések telepítve! Vagy mégsem?

A Configuration Manager-t használó vállalatok körében talán az egyik legelterjedtebben használt Site System szerepkör a Software Update Point, hiszen a Microsoft termékek frissítéseinek kezelése és automatizált terítése fontos részét képezi az üzemeltetési folyamatoknak.

Azon felül, hogy a szoftverekhez tartozó frissítéseket telepítjük a munkaállomásokra illetve szerverekre, ismernünk kell azok állapotát a frissítések telepítettségének szempontjából. Szerencsére a ConfigMgr beépített jelentéskészítő képességének segítségével igazán egyszerűen tudunk ilyen kimutatásokat készíteni.

Én is rendszeresen használom ezeket a kimutatásokat a számítógépek állapotának meghatározására és a közelmúltban éppen az Internet Explorer verzióról készítettem egy felmérést az infrastruktúrában, amikor is furcsa dolgot tapasztaltam.

Több kliensen is találtam telepítve Internet Explorer 8-at, miközben a jelentésekben hiányzó frissítésként szerepelt. A helyzet semmi esetre sem szerencsés, hiszen innentől kezdve az ember nem lehet biztos abban, hogy a jelentésekben szereplő adatok megfelelnek-e a valóságnak, illetve nem deríthető ki, mely kliensek jelzik jól az állapotukat és melyek nem.

Ennek okán keresgélni kezdtem az interneten és amint kiderült nagyon sokan küzdenek ezzel a problémával, sőt van rá megkerülő megoldás is. Persze ez nekem nem volt elég, magam kezdtem vizsgálódni a problémával kapcsolatban.

Mivel az jelentések a lekérdezés pillanatában nyerik ki az információkat a ConfigMgr adatbázisból, így azt biztosra vettem, hogy az adatbázisban szereplő információkat látom a riporting felületen is. Tehát a kliens nem méri fel megfelelően a saját állapotát, vagy nem küldi rendszeresen az állapotinformációit a Management Point felé. Ellenőriztem tehát az utolsó scan időpontját a problémás kliensek esetében.

Scan 4 – Clients of a site reporting a specific state

Úgy tűnt minden rendben van az Update Scan folyamattal. A biztonság kedvéért a kliensen manuálisan futtattam egy újbóli ellenőrzést, de ez sem hozott eredményt.

Mélyebbre kellett ásnom, ezért ellenőriztem, vajon a frissítésekről készülő State Message-ek továbbítódnak-e a kliensről a MP felé.

wsus2_1

Ezt az információt a statemessage.log tartalmazza a kliens oldalon, továbbá itt láthatjuk a keletkező State Message-eket is.

A szoftverfrissítések esetében a scan alkalmával minden egyes frissítéshez kapcsolódóan keletkezik egy 500-as kategóriájú State Message, amely tartalmazza annak állapotát.

http://technet.microsoft.com/en-us/library/bb932203.aspx

Ezek az üzenetek aztán a WMI-ben kerülnek tárolásra, innen pedig rendszeres időközönként továbbításra kerülnek a MP felé.

Az üzeneteket megnézhetjük a wbemtest eszköz segítségével, ha csatlakozunk a root\ccm\statemsg névtérhez és megnyitjuk a CCM_StateMsg osztályt. Ennek az osztálynak a példányai maguk a keresett üzenetek.

wsus2_2

Természetesen itt nem csak a frissítésekre vonatkozó üzeneteket láthatjuk, hanem az összes többit is, de az 500-as kategóriával jelzettek, mind egy-egy frissítéshez tartoznak. Észrevehetjük azt is, hogy az ID nem más mint a frissítés egyedi azonosítója.

instance of CCM_StateMsg
{
    Criticality = 0;
    MessageSent = TRUE;
    MessageTime = "20120126160725.401000+000";
    ParamCount = 1;
    StateDetails = "";
    StateDetailsType = 0;
    StateID = 3;
    TopicID = "fbd8316c-68b4-47c3-8059-b826cc72efc6";
    TopicIDType = 3;
    TopicType = 500;
    UserFlags = 0;
    UserParameters = {"100"};
};

Az egyes példányokat tüzetesebben megvizsgálva találhatunk számunkra érdekes információkat. A példában látható üzenet az attribútumai alapján már elküldésre került a MP felé, továbbá egy már telepített frissítésről van szó a 3-as StateID és 500-as kategória alapján.

http://catalog.update.microsoft.com/v7/site/ScopedViewInline.aspx?updateid=fbd8316c-68b4-47c3-8059-b826cc72efc6

Ráadásul ez pont az Internet Explorer 8 a Windows Server 2003-hoz.

Ezen információk alapján az update scan jól működik, sőt jól is kerül rögzítésre a WMI-ben a frissítés állapota. A naplófájlok alapján a kliens elküldi ezeket az információkat a MP felé. Aztán persze itt a statesys.log-ban látható is ezeknek az üzeneteknek a feldolgozása.

Tehát minden tökéletesen jónak tűnik, azonban mégsem ez a helyzet.

Úgy tűnik a megoldás kulcsa a kliens speciális viselkedése, miszerint az információknak csak egy különbségi állapotát küldi a MP irányába, azaz egy frissítésre vonatkozó állapotinformáció csak akkor kerül újra elküldésre, ha az ténylegesen megváltozott a kliensen. Persze jogos a kérdés, vajon miért nem került elküldésre a frissítés telepítését követően, de erre nincs igazán magyarázat. Szerencsére létezik egy olyan eljárás a ConfigMgr SDK-ban aminek a manuális futtatása rákényszeríti a kliens oldali komponenseket a teljes állapotinformáció újraküldésére.

http://msdn.microsoft.com/en-us/library/cc302775.aspx

RefreshServerComplianceState()

Sub RefreshServerComplianceState()
    dim newCCMUpdatesStore
    set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
    newCCMUpdatesStore.RefreshServerComplianceState
    wscript.echo "Ran RefreshServerComplianceState."
End Sub

64 bites operációs rendszerek esetében a futtatáshoz 32 bites cscript szükséges, tehát a SYSWOW64 könyvtárból futtassuk azt.

Mivel bármelyik kliensen bármikor előfordulhat hasonló anomália, érdemes lehet akár havonta ütemezetten futtatni a fenti scriptet.

Share this:

del.icio.us DiGG Google Buzz Microsoft Live RSS PDF

Leave a Reply

*

  • Tabber

Comments

MVP_Horizontal_FullColor