SCCM este un instrument extrem de misterios. Cât de mult lucrează cu el, dar el nu încetă să mă uimească. Recent am avut din nou o neînțelegere completă în dorințele și posibilitățile mele.
Vreau doar să-ți mulțumesc lui Alexander Petlevoy pentru sprijinul său moral și câteva link-uri utile.
Așa că am procedat la un studiu nervos al bustenilor. Primul lucru pe care l-am verificat a fost atunci când agenții s-au prezentat ultima dată prin Heartbeat Discovery. Pentru a face acest lucru, deschideți orice computer din orice colecție, deschideți proprietățile sale și găsiți intrarea corespunzătoare a Agentului în funcție de numele agentului.
În cazul meu, analiza "zborurilor" a avut loc pe 28, iar data ultimei Heartbeat Discovery a fost datată pe 14. Asigurându-vă că setarea Clear Insatall Flag este de 10 zile (acest lucru poate fi realizat aici: Baza de date a site-ului -> Gestionarea site ->% SITE_CODE% -> Setări site -> Site ÎNTREȚINEREA -> Sarcini -> Clear Instal Flag -> Properties), motiv eliminați de pavilion IsClient a devenit clar: bătăile inimii nu a venit, task clar pavilion Instal a făcut onest datoria. A rămas "mic" - pentru a găsi motivul pentru care agenții nu au raportat starea lor.
După o inspecție sumară de bușteni, a devenit clar că funcționalitatea completă a SCCM lucrări curat - cu o zi înainte pe mai multe zeci de calculatoare a fost implementat cu succes Office, OSD a lucrat în mod normal, toate celelalte Discovery, de asemenea, a lucrat în mod normal. Ie Doar Heartbeat Discovery a fost spart.
1. Conform programului, agentul generează un fișier XML. Fișierul este salvat în această formă aproximativ:% windir% \ system32 \ CCM \ stocuri \ Temp \ d0c06056-6363-41ce-9a2e-5409e7702cbe.xml
2. După formare, fișierul este trimis folosind BITS către serverul SCCM (Point Management). În nord toate fișierele XML se încadrează în folderul% SCCM_DIR% \ inboxes \ auth \ ddm.box \
3. După aceea, serverul procesează fișierele recepționate și scrie datele primite în baza de date.
Toate procesele legate de Heartbeat Discovery, puteți vizualiza fișierele jurnal de pe agentul Stronie este% windir% \ system32 \ CCM \ Logs \ InventoryAgent.log, pe partea de server este% SCCM_CCM% \ Logs \ MP) Ddr.log.
După examinarea jurnalelor, tocmai am căzut într-o stupoare - atât pe agenți cât și pe server în jurnalele au existat doar înregistrări despre procesarea cu succes a fișierelor. Nu s-au făcut greșeli în ele. Ideea a venit să vedem ce se află în fișierul inboxes \ auth \ ddm.box \. Și aici așteptam o surpriză - în acest dosar erau aproximativ 140.000 de dosare. Fișierul cel mai timpuriu a fost datat de momentul ultimului mesaj al agenților despre el însuși. În acest caz, nimic nu se găsește în dosarul inboxes \ auth \ ddm.box \ BAD_DDRS, unde cad pachetele rău. O căutare rapidă în Google nu a furnizat informații specifice.
Cauza aparentă a problemei a fost o încălcare a DDR de pachete de prelucrare, astfel încât ideea de a elimina unele dintre cele mai vechi fișiere din foldere cutiile poștale \ AUT \ ddm.box \. După îndepărtarea de aproximativ 100 de fișiere și servicii de repornire SMS_EXECUTE pe un server, un miracol sa întâmplat - fișier de procesare DDR a început să lucreze din nou, iar numărul de dosare în cutiile poștale \ AUT \ ddm.box \ redus rapid la zero. Versiunea că procesul a fost spart din cauza unor fișiere DDR rău a confirmat apariția a aproximativ 1500 de fișiere în folderul inboxes \ auth \ ddm.box \ BAD_DDRS.
Trimiteți-le prietenilor: