Mennyire aktuális a kliens lista, amit látok a Configuration Manager-ben?

Gyakran felmerül kérdésként, hogy mennyire aktuális az a kliens szám, amit a Configuration Manager-ben látunk. Ennek megértéséhez nézzük át, hogy hogyan kerülnek be és hogyan kerülnek ki a kliens objektumok a Configuration Manager adatbázisba/ból.

Hogyan kerülnek be az adatok a Configuration Manager-be?

A Configuration Manager 2012-be az adatok a feltérképezések (discovery) révén kerülnek be. Számítógép objektumok az alábbi módokon kerülhetnek feltérképezés révén az adatbázisba:

• Active Directory System Discovery: Az AD-ben a megadott LDAP elérési út(ak) alatt levo computer objektum-ok beolvasása az ConfigMgr adatbázisba. Bovítheto hogy milyen AD objektum attribútumokat olvassunk be az adatbázisba.
• Network Discovery: Alapértelmezetten kikapcsolt és nem javasoljuk csak bizonyos esetekben, pl a vPRO támogatás használata esetén bekacsolni. Ennek során a DHCP scope-k és router táblák adatai alapján nézi az elérheto IP alhálózatokat és minden egyes lehetséges végponthoz megpróbál csatlakozni a teljes hálózaton. Mivel ez rettenetesen sok próbálkozást jelent ez nagyon sok idot vehet (akár napokat is) igénybe, ezért nem javasoljuk.
• Heartbeat Discovery: Amikor a telepített Configuration Manager kliens küld magáról élet jelet és ez alapján jön létre a megfelelo computer objektum az adatbázisban. Erre lehet példa egy workgroup gép-re manuálisan feltelepített Confiiguration Manager kliens által bejelentkezo munkaállomás

A fentieken felül további feltérképezések vannak, amelyek a felhasználó és csoport objektumokat olvasnak be a Configuration Manager adatbázisba, hogy azokat tudjuk kezelni, mint pl: szoftver terítési cél. Ez egy fontos alapeleme a felhasználó központú felügyeletnek.

A Configuration Manager a klienseket két azonosító alapján követi:

• Hardware ID: amely a hardver egyedi paraméterei alapján a hardver konfigurációt azonosítja (hasonlóan mint amit a Windows aktiválás is használ)

• Configuration Manager Unique Identifier GUID: Egy egyedi azonosító, amit a Configuration Manager kliens a kliens ügynök telepítésekor generálódik

Ez a két azonosító alapján tudja detektálni a Configuration Manager hogy volt-e változás a kliens környezetben:

• Ha ugyan azon a hardver azonosítón megjelenik egy új ConfigMgr GUID akkor az azt jelenti hogy azon a hardver-en újra telepítették az OS-t vagy legalábbis a ConfigMgr klienst. Ekkor lesz a korábbi állapothoz tartozó objektum Obsolete.
• Ha ugyan az a GUID jelenik meg akkor a más hardver azonosítón, akkor a gép változott, hardver konfiguráció változás az OS-t és a COnfigMgr klienst változatlanul hagyta. Ha ugyan az a GUID több különbözo hardver azonosítóról érkezik meg akkor az a jele a rosszul image-lt operációs rendszer telepítésnek, amely nem muködo ConfigMgr klienseket eredményez és mindenképp elkerülendo.

Tehát az alábbi oszlopok a következoket jelentik:

• Obsolete: Egy ilyen elem azt jelenti hogy a hardver azonos maradt de a ConfigMgr GUID nem, tehát valószínuleg az OS vagy legalábbis a ConfigMgr kliens azonos maradt.Az obsolete elemet a ConfigMgr kliens több okból is megtartja, pl: a hardver leltár adatok, amik a korábbi objektumhoz tartoznak, illetve a Collection tagságok, stb. A Configuration Manager alapértelmezetten képes rá hogy „összeolvassza” a régi és az új Computer objektumot ilyen esetben.
• Active: A kliens különbözo aktivitásai alapján a Configuration manager kiszolgáló azt állapítja meg hogy élo kliensrol van szó (lelkesen küldi-e a hardver leltár adatokat, heartbeat discovery-t, stb.) Ezen határidoket a Configuration Manager 2012 esetében a Monitoring fül Client Activity pontja alatt konfigurálhatjuk:

Szóval mostanáig áttekintettük, hogy az életciklusuk alatt milyen alap állapotaik lehetnek a Computer objektumoknak.

Hogyan kerülnek ki az objektumok az adatbázisból?

Az adatbázis karbantartására ütemezett feladatok vannak, amelyeket az Administration fülön a Site Configuration alatti Site pontot kiválasztva egy egyes site-okra külön-külön állíthatunk a Site maintanance beállításokat.

Ezek között a Delete Aged Discovery Data az amely a nem használt feltérképezési adatokat és objektumokat távolítják el az adatbázisból.

Látható hogy ez alapértelmezetten a 90-napnál régebben nem frissülo adatokat törli ki. Ezzel kapcsolatban viszont azt fontos kiemelni hogy ez az alapján értelmezendo hogy utoljára valamelyik discovery mód alapján az adott objektum élonek lett megjelölve. Az egyes objektumokról azt hogy mely feltérképezések és mikor találták meg utoljára azt az objektum tulajdonságai között láthatjuk:

Látható hogy az alábbi teszt gépet utoljára az AD System Discovery találta meg 2012. február 20-án délben.

Fontos!

Tehát ha egy gép valamilyen feltérképezés által folyamatosan frissül az adatbázisban, akkor azt a „Delete Aged Discovery Data” Site Maintanence task nem fogja kitörölni! Tehát ha egy már nem egyébként fizikailag leselejtezett számítógép Computer objektuma továbbra is benne van az AD-ben egy olyan OU-ban amit a Configuration Manager 2012 feltérképez, és a hozzátartozó DNS "A" rekord létezik (tehát a DNS scavenging nem takarítja ki) akkor az soha nem fog kikerülni az adatbázisból (hiszen az AD discovery mindig frissíteni fogja). Ezért Configuration Manager 2012 esetében az AD Discovery-t egy nagyon hasznos funkcióval bovítettük:

Vagyis most már ez a korábbi probléma megszüntetheto és beállítható, hogy az AD-bol csak a valóban élo gépek kerüljenek feltérképezésre ahol az élo gép alatt azt értjük, hogy legalább 90 napja (az alapértelmezés szernti beállításokkal) változtatott jelszót. Ugyan úgy ahogy az „Delete Aged Discovery Data” esetében ez az érték is természetesen az egyéni környezet igények szerint finom hangolható. Ehhez nem árt ha tudjuk, hogy a Computer Account-ok az AD-ben alapértelmezettne 30 naponta változtatnak jelszót.

Tehát ha az alapbeállításokat vesszük a Configuration Manager 2012 esetében is az után hogy egy gép fizikailag kivonásra kerül az infrastruktúrából akkor még legrosszabb esetben 90 napig frissül az adatbázisban (utolsó jelszó változtatás, plusz az AD discovery által kezelt türelmi ido). Ez után még újabb 90 nap míg az utolsó discovery utántól számítva a site maintanence task törli az adatbázisból az objektumot. Ezen lehet valamelyest gyorsítani a „Delete Inactive Client Discovery Data” opcióval, amely törli az inaktiv állapotba kerüléstol számolt megadott (alapértelmezetten 90) napnyi ido múlva a rekordot (ez ugyebár párhuzamosan megy a discovery 90 napos várakozásával).

Összefoglalva

Láthatjuk hogy arra a kérdésre hogy hány felügyelt gépem van a Configuration Manager-bol csak közelíto számot tudunk mondani (a 2012-esetében jól konfigurálva egész jó közelítést, a 2007 esetében egy rosszul konfigurált és nem karban tartott AD esetében pedig kifejezetten rossz közelítést.

Ez alapvetoen nem termék, hanem feladatkör probléma, a kiszolgáló környezethez képest a munkaállomás környezet ahonnan a Configuration Manager eredete indul egy sokkal komplexebb környezet elég, ha csak arra gondolunk hogy a gépek jönnek mennek a hálózatról ki-be, újra telepítik, szabadság alatt kikapcsolják, stb.. Így sokkal nehezebb egy adott pillanatban megmondani, hogy hány gép van (hiszen pl.: nem tudjuk, hogy egy gépet azért nem látunk, már mert megszunt vagy csak szabadságra ment a tulajdonosa). Ha túl rövid idot hagyunk, hogy mennyi ido után töröljük azokat a gépeket, amiket nem láttunk egy ideje akkor könnyen valós adatokat veszthetünk (collection tagságok, hirdetmények, stb.), ha túl ritkán akkor nagyon sok szemét marad az adatbázisban. Egy jól konfigurált címtár környezet és Configuration Manager esetében azonban elég jó közelítést tudunk adni, ehhez persze ismerni kell az adott környezet sajátosságait.