Monthly Archives: April 2013

SCOM ACS database full


scom-gsx-solutions

SCOM ACS database full

Acest articol este unul de genul ‘note to self’, bun de stiut pe viitor. M-am trezit ca baza de date pentru Audit Collections Services era full noroc ca am pus o limita odata pee a preventiv sa nu ocupe mai mult decat trebuie.

Pe scurt ACS este folosit sa trimita security events de pe orice host, in general servere, pentru a folosi la auditare. Altfel spus se pot tine centralizat evenimente ce sunt de interes companiei, cine ce a sters, ce a modificat, etc. ACS prezinta cateva avantaje in plus fata de alte ‘event forwarding solutions’ in sensul ca nu pot fi sterse ‘urmele’, se pot rula rapoarte complexe de corelare evenimente prin reporting services, etc.

Mai multe informatii aici: http://technet.microsoft.com/en-us/library/hh212908.aspx

Bun, am zis ca se intampla ca si la baza de date de data warehouse si trebuie sa aiba un ‘grooming period’ care il putem seta.

Si, am rulat pe baza de date OperationsManagerAC urmatorul query:

SELECT * FROM dtConfig

Si rezultatul a fost cel putin interesant pentru mine.

scomacs

In al 6-lea rand ‘number of partitions’ ar trebui sa afiseze numarul de zile de retinere de infromatii. By default sunt 14 zile din ce stiam eu.

Se pare ca era problema asta la 2007, si trebuia sa se fi rezolvat dar se pare ca si la 2012 persista. Exista si un hotfix la un moment dat, care il puteti gasi aici:

http://support.microsoft.com/kb/949969

Desi ma gandesc ca scenariul asta e posibil in cazul in care se face upgrade dela 2007 R3 la 2012.

Oricum, ca sa vedeti ce se afla exact in acele partition tables folositi urmatorul query:

SELECT * FROM dtPartition order by PartitionStartTime

La ‘Status’ valoarea ce trebuie sa o aiba partitia respective este 2, adica ca e gata de ‘grooming’ sau sters.

Daca au o valoare de 1, este mai ‘nasol’, pentru ca acele partitii nu vor fi sterse (groomed) niciodata si vor ajunge sa umple baza de ACS. Statusul de ‘1’ poate aparea de exemplu daca seara, cand se face by default mentenanta bazei de ACS, nu se reuseste indexarea acelor partition tables. Pentru cei mai curiosi exista urmatorul articol care explica cum functioneaza indexare partition tables-urilor:

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

Pentru a rezolva automat problema cu ‘status =1’  putem rula urmatorul query:

Use OperationsManagerAC

Update dtPartition

Set Status = 2

Where Status = 1

Dup ace s-a rulat query-ul restartati serviciul de Operations Manager Audit Collection Service (AdtServer).

acsdb

Acum baza de date va fi ‘curatata’ la urmatorul ‘scheduled maintenance’ de obicei pe timpul noptii cand numarul de evenimente generate este mai mic.

THE END…

Advertisements

SCOM Event ID 10830, Health Service Modules error


scom-gsx-solutions

SCOM Event ID 10830, Health Service Modules error

Acum câteva săptămâni m-am lovit de o problema care mi-a dat ceva de furca… O eroare care apare din minut in minut.

Poate au mai întâlnit-o si alții, dar din ce soluții am găsit pe net majoritatea ziceau sa refaci baza, restore, flush cache, etc,  si alte povesti de genul asta.

Abia acum scriu despre asta pentru ca am așteptat sa vad daca reapare problema dar totul este in regula acum.

Eroarea respectiva arata cam așa:

Error

Ok , deci avem un ID pentru regula de colectare, numele bazei afectate, tabelul, coloana si de la ce e conflictul, adică ‚FOREIGN KEY constraint’.

Prima data sa vedem ce este afectat. Trebuie sa identificam regula menționata in mesaj. Deschidem o consola de PS cu modulul de SCOM importat.

Get-SCOMRule -Id 4fc013b2-aa11-b2d2-ec51-b198640fae00 | fl name, id, displayname

ps

OK, deci acum știam ce este afectat de aceasta eroare.

Mai departe sa vedem in baza de date mai multe detalii. Navigam ‚bătrânește’ in baza operaționala  OperationsManager, tabelul dbo.BaseManagedEntity, coloana BaseManagedEntityId, asa cum scria in mesajul de eroare

PK

Facem click dreapta pe dbo.BaseManagedEntity si selectam Design. Apoi selectam Relationships.

relations

Apare fereastra de Foreign Key Relationships si verificam sa fie selectata rubrica care ne interesează, in acest caz FK_AlertBasedManagedEntity. Apoi deselectam FK constraint după care salvam.

FK2

Pe scurt Foreign Key constraint asigura relaționarea intre tabele, coloane, grupuri de coloane etc.\

Mai multe detalii despre Foreign Key constraint :

http://msdn.microsoft.com/en-us/library/ms175464(v=sql.105).aspx

Atenție! Acest mod de funcționare nu este recomandat in producție pentru ca nu se mai asigura consistenta datelor, dar având in vedere ca știam despre ce date este vorba si ce presupunea modificarea respectiva am ales sa o configurez astfel.

După dezactivarea setării de foregin Key constraint normal ca datele (alertele) au putut f introduse baza de date.

După o perioada de aproximativ 15 minute am reactivat opțiunea de FK constraint si workflow-ul a revenit la normal.

Pana in prezent nu a mai apărut aceasta eroare.

THE END!

Eroare la importarea fisierului .adm ( Error 51 : Unexpected keyword )


scom-gsx-solutions

ADM import fail (The file cannot be loaded)

O chestie de care m-am lovit la un moment dat cu SCOM 2007 R3 speram sa se fi rezolvat pentru SCOM 2012/SP1. Se pare ca nu.

Ideea este ca dupa ce urmezi Wizard-ul de Configure Client Monitoring, adica ‘asta’…

options

..totul merge ok si iti configureaza share-ul unde sa tina rapoartele si informatiile cu erorile de pe clienti, si iti exporta un template de Group Policy adm (nu ADMX desi se poate converti folosind ADMX Migrator sau altceva…).

Acest template se importa pe domain controller pentru a configura setarile de ‘error reporting’ pe clienti prin Group Policy. Acest tip de configuratie se numeste AEM (‘agentless exception monitoring‘) deci nu foloseste agenti. Acest tip de configuratie consuma mai multe resurse decat ‘agent based’ monitoring.

Si iau frumos fisieru, intru pe DC, scriu gpedit.msc, click dreapta pe Administrative Templates si …..

Error

Urat …

Solutia:

Instalati un utilitar de genul Notepad++ , editati fisierul adm, mergeti la liniile respective, si veti gasi calea cate serverul de SCOM este scrisa pur si simplu, fara ghilimele. Sunt cam patru linii unde trebuie incadrata calea in ghilimele si asta este tot.

notepad

Apoi o sa gasiti setarile urmatoare in GPO pe orice domain controller dupa ce replicarea a ajuns la convergenta…

gpo

Iar in SCOM in tab-ul de Monitoring , Agentless Exception Monitoring…

scom

THE END….

Event ID 13562, ISTG, KCC, multiple site connection objects


Active-Directory-logo

Event ID 13562, ISTG, KCC, multiple site connection objects

Am constatat ca folosind SCOM pentru monitorizarea de Active Directory, si nu numai, s-a dovedit a fi o alegere buna in detectarea diverselor erori care in mod normal nu stiu daca le aflam timp util decat atunci cand era destul de tarziu.

Notificarea care o dadea acest „scom” (cand vorbesc cu cineva in engleza, de multe ori ma aud zicand „scum” si aproape ca ma bufneste si rasul) era ceva de genul „A domain controller has an unusually high number of replication partners” ca si subiect iar la descriere iti zice DC-ul in cauza si numarul  de “parteneri de replicare”. Sistemul asta de monitorizare ofera descrieri si link-uri utile pentru diverse probleme mai simple dar ceva mai complex….iti arunca eroarea asta “seaca” si te lasa sa iti bati capul cu ea. Initial ce am zis, “scomu” asta e nebun, nu stie ce zice…. De ceva timp incoace, mi-am schimbat parerea, si am ajuns la concluzia ca fiecare alerta “taNpita” are la baza o problema reala. Trebuie doar sa te concentrezi mai mult pe ea….

Ok, sa ne apucam de treaba, sa vedem de ce a luat-o razna si spune numai bazaconii…

M-am logat pe serverul cu pricina si m-am uitat prin loguri. Logurile din Operations Manager, un warning cu Event ID 81 zice ca am 45 de outbound replication connections „which is more than the recommended number 40”…si e Warning ca peste 50 deja e critical error…

Deschid dssite.msc si navighez pe serverul din site-ul respectiv si dau Proprietati pe NTDS Settings.

In enuntul erorii scria „outbound” deci m-am uitat la Connections, Replicate To….

Si acolo intradevar, 45 de connection objects asa cum zicea batranul scom….sa-i dea Dumnezeu sanatate! Foarte multe din connexiuni  faceau trimitere la acelasi server in acelasi site.

In site-ul respectiv aveam 2 DC-uri unul cu „database errors” (sa-i zicem DC1) , alta poveste, deci unu mai bolnav…in fine urma sa fie scos. Dar nu era acesta serverul care aparea in loguri ci celalat care nu dadea nici un semn ca ar fi ceva in neregula…Nu foloseam „manual connection objects” si lasam KCC-ul sa isi faca treaba…dar cum sa greseasca KCC-ul care stia cel mai bine care e treaba…Un articol in teresant de citit „ You are not smarter then the KCC

Stiam ca serverul DC1 are probleme dar nu intelegeam de ce partenerul lui din acelasi site afisa problemele…

Daca nimeni nu a creat acele legaturi clar KCC-ul le-a creat. Si erau intre site-uri deci serverul care avea si rol de ISTG. Am verificat si DC1 era si ISTG pentru site-ul respectiv…

And then came the breakthrough…

Am citit un articol pe technet care avea cateva randuri foarte interesante:

„When there are two domain controllers in the site that appear to own the intersite topology generator role, there might be a temporary state of inbound replication connection objects being created by both computers. However, after replication occurs and all domain controllers receive the change that identifies the new intersite topology generator, the KCC on the intersite topology generator adjusts the topology.

Deci daca ambele servere din acel site se credeau „owner” de ISTG ambele DC-uri creau obiecte automat si fiindca replicarea era „busita” pentru unul din DC’uri obiectele respective nu mai erau sterse cand se ajungea la convergenta.

Dar ambele servere afisau acelasi ISTG adica DC1 (cel cu probleme). Ce mai puteam sa incerc…

Initial am sters pur si simplu obiectele care, normal au reaparut…

M-am gandit sa mut rolul de ISTG de pe DC1 pe DC2 sa vedem cum se comporta.

Dupa ce am facut modificarea am verificat si acele connection objects au disparut…puff!

Si-am incalecat pe o sha shi v-am spus povestea mea….

Cateva detalii despre KCC, ISTG, Bridgeheads si Preferred Bridgeheads

  • Se poate porni logging pentru KCC pentru a afla mai multe detalii modificand valoarea inregistrarii Replication Events in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
  • Fiecare KCC de pe fiecare DC ruleaza un algoritm care determina topologia din site-ul (intersite topology)din care face parte. Fiecare DC din acel site va avea aceeasi informative asa ca fiecare DC va deduce aceeasi topologie.
  • KCC creaza obiectele de la DC-urile sursa.
  • KCC creeaza in topologia intersite legaturi intre DC-uri redundante si care sa nu fie la o distanta mai mare de 3 hopuri pentru a reduce latenta.
  • Pentru a forta generarea topologiei se poate da click dreapta pe obiectul NTDS, All tasks, Check Replication Topology sau folosind repadmin /kcc <DSA>.
  • Un DC per Site isi asuma rolul de ISTG, este responsabil de creearea de “connection objects” intre DC-uri din site-uri diferite (intrasite topology).
  • Pentru a Identifica ce DC este si ISTG exista mai multe metode. Va zic doua:
  1. Repadmin /istg <DSA>
  2. Dssite.msc , navigati la site-ul respectiv, in panoul din dreapta, proprietati pe NTDS Object, Attribute Editor si cautati InterSiteTopologyGenerator….

istg

  • Cand ISTG trebuie sa modifice obiectul de pe un bridgehead din alt site, va face modificarea in copia locala din AD si replicarea normal isi va lua cursul.
  • In timp ce KCC genereaza topologia intersite, evalueaza fiecare DC ca si posibil candidat pentru bridgehead. Daca sunt configurati Preferred Bridgeheads acestia sunt candidati la selectie.
  • Daca am configurat mai multi Preferred BH si acestia din diverse motive nu mai sunt disponibili, nu se va face failover la alte DC-uri chiar daca sint eligibili.
  • Schimbarea ISTG-ului se face modificand atributul din imaginea de mai sus.
  • Ca sa ne asiguram ca modificarile facute unui connection object nu sunt suprascrise de KCC (care se pune owner pe acel obiect) este nevoie sa facem modificarile pe serverul care tine rolul de ISTG.

Daca imi mai amintesc alte chestii utile le mai adaug eu sau mai imi spuneti voi. Am scris cam repejor articolol asa ca imi cer scuze de eventualele greseli, dar le corectam daca e cazul…

A, si mai erau un articol pe technet:

http://support.microsoft.com/kb/251250

…care spune ca solutie sa stergeti pur si simplu obiectele duplicate. Pare o solutie temporara daca la urmatoarea replicare te pomenesti din nou cu ele…