Tag Archives: frs

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…

Advertisements

LepideAuditor for File Server


 LepideAuditor for File Server

Am avut recent ocazia de a lucra cu un tool excelent pentru audit de fișiere. Auditul accesului pe fisiere poate fi uneori dificil folosind instrumente implicite din Windows, trebuie configurate Group Policies, configurat audit pe foldere, configurare de event forwarding, atasarea taskurilor la evenimente pentru a trimite notificari pe email ( ce este interesant aici de mentionat este ca nu se poate configura inainte ca evenimenul sa se fi produs ceea ce inseamna bataie de cap aditionala), backup-ul acestor informatii, si pastrarea acestora pentru o perioada mai lunga de timp cum ar fi 6 luni de exemplu. Toate aceste activitati sunt consumatoare de timp mai ales daca nu aveti experienta in configurarea anterioara a acestor setari. LepideAuditor for File Server poate oferi toate aceste funcționalități și mai mult, principalul avantaj din punctul meu de vedere este timpul economisit in gasirea evenimentelor relevante situatiei. Nimanui nu ai place sa isi piarda timpul si sa parseze manual prin loguri … Configurarea acestui tool este foarte usoara, nimic special. Acesta folosește o instanță SQL, dar poate fi implementat foarte bine folosind SQL Express. Instrumentul are două console principale, consola de setări și Consola de raportare.

Consola de raportare, simpla si eficienta…

După cum puteți vedea in imagini am servere cu roluri diferite auditate, unele fiind chiar si DC-uri sau Exchange-uri. Puteți utiliza acest tool pentru diverse scopuri, si va voi arata un astfel de exemplu, folosind un DC mai târziu în acest document. Vom crea o regulă nouă în care putem defini politicile și setările pe care dorim să le pună în aplicare pentru audit. Aici incepe distracția. O altă caracteristică interesanta a acestui instrument este flexibilitatea cu care o puteți politici de audit. Atunci când implementati setările, puteti configura aplicatia pentru a lua în considerare politici individuale, politici de grup, sau puteti crea o nouă politică.

Creand astfel o nouă politică este destul de simplu, dar în cazul în care aveți probleme, vedeti documentatia Help a aplicatiei care explica clar utilitarul respectiv. Se poate seta un interval orar in care sa se aplice politica de audit, lucru foarte util de altfel pentru ca va permite oarecum sa controlati cantitatea de informatii generata de aplicatie.

Urmatoarele caracteristici va ofera o mai mare flexibilitate si anume va permite sa configurati politici pentru Drive Lists, Directories, File Names, File Types, Processes si Events. Fiecare din aceste setari se pot combina in finctie de scopul scontat si salvarea acestora intr-o politica. După cum puteți vedea diferite setări pot fi configurate intr-o singură politică.

Când vine vorba de setările de notificare aveți 3 opțiuni, e-mail, mesaje de retea si SMS-uri.

Puteți defini chiar și un query, folosind operatori si de a trimite notificări in cazul în care sunt îndeplinite anumite condiții.

O caracteristică interesantă care imi place, este gestionarea operațiunilor simple pe baza de date SQL direct din consola de setări prin intermediul unui wizard simplu. Nu este nevoie de a Management Studio sau alte instrumente pentru a face un database shrink.

Referitor la consola de raportare, vei putea vedea cine a modificat, accesat, sters, schimbat owner si alte evenimente care sunt utile atunci când faci un audit. De exemplu, atunci când un administrator sau un utilizator cu drepturi delegate a schimbat owner-ul unui fișier sau un folder, în scopul de a accesa acel conținut, in consola putem filtra doar acele evenimente care sunt relevante pentru căutarea noastră.

Sau putem folosi unul din filtrele builtin pentru rezultate rapide. Cum am spus si mai devreme, avantajul principal fiind rapiditatea cu care se pot accesa evenimentele dorite. Mai jos vom folosi filtrul Permission Changes filter (Folder).

La deschiderea evenimentului, putem vedea următoarele detalii:

Puteți crea rapoarte obisnuite, rapoarte personalizate și le puteți exporta în diferite tipuri, cum ar fi PDF, Word, HTML, CSV sau text simplu. Rapoartele sunt executate rapid și sunt bine formatate.

Am spus mai devreme că puteți utiliza acest instrument în diverse scenarii, de exemplu, pe un DC  sau Exchange Server. Desigur, Lepide are produse specializate separate pentru audit sau de gestionare a acestor sisteme, dar vreau doar sa demonstrez că se poate folosi si in alte moduri. Puteți configura, de exemplu, auditarea SYSVOL, containerul cu politicile de domeniu. Astfel veți putea monitoriza statusul GPO-urilor. Putem afla cine a modificat, sters, creat si cand referitor la politicile de grup. Intradevar nu este asa frumos fiind ca arata GUID-ul in loc de numele politicii (care se afla usor), dar funcționalitatea sa combinata cu funcția de alertare, va fi notifica imediat persoana in masura ca s-a modificat ceva și-ar putea sa ia niste masuri inainte ca acestea sa se propage sau ca utilizatorii sa primeasca setarile.

În imaginea de mai sus veți vedea, de exemplu, cum cineva a șters o politica de grup (în acest caz, dosarul a fost șters GPT.ini). Stiu, se vede GUID-ul politicii în loc de numele ei, dar totusi acesta este un auditor de file servere nu un auditor AD, pe langa asta oricine poate găsi GUID-ul prin căutarea în proprietățile obiectului. Același lucru se poate aplica pentru Loguri și alte fisiere din Exchange, depinde de cat de creativ esti …. Ca o concluzie despre acest instrument, bune si rele: Bune: • GUI Usor si instinctiv • Configurații foarte flexibile de politici de audit • Funcționează cu SQL Express • Consola de raportare genereaza rapoarte rapide, bine formatate • Notificări aproape in real time prin intermediul diferitelor medii. • Alerte personalizate cu ajutorul operatorilor (AND, OR) • Acces rapid la evenimente folosind filtre predefinite în Consola de raportare

Rele (primele două cred ca sunt inevitabile, deoarece cele mai multe Enterprise-uri folosesc software de monitorizare ce funcționează cu agenți și necesită macar o baze de date, dar în cazul în care se vrea a fi o soluție de tip enterprise poate că ar trebui să ofere mai multe feature-uri, iar unele sugerate mai jos ar putea fi utilizate pentru a îmbunătăți produsul): • Funcționează cu agenți • Necesită o bază de date SQL • Nici un mod de logging pentru troubleshooting-ul aplicatiei

• Necesită actualizarea de agenți frecventă pentru a împinge modificări catre acestia • Nu are user based authentication • Nu exista o consolă web • Ar putea utiliza datele din DB pentru a genera charturi/diagrame

Mai multe informații despre acest program puteți găsi la:

http://www.lepide.com/file-server-audit/?gclid=CM775_fp7bUCFfB3cAodhyIAqw

Demo Video:

http://www.lepide.com/file-server-audit/lfsa-overview-video.html

DcDiag Problem: Missing Expected Value


Active-Directory-logo

DcDiag Problem: Missing Expected Value

Am avut ocazia de curand sa intalnesc cateva “probleme” daca le putem numi asa, raportate de DCDIAG.  La un test obisnuit dcdiag totul parea ok, ceea ce ar fi linistit pe oricine vazand ca totul este in regula, insa la un test verbose folosind dcdiag /v /c /i /q pe orice DC din domeniu aparea urmatoarea eroare, enumerand missing expected value pe toate DC-urile din domeniul respectiv:

[1] Problem: Missing Expected Value
Base Object:
CN=DC1,OU=Domain Controllers,DC=child,DC=domain,DC=com
Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862

msDFSR-ComputerReferernceBL-edited

Cum spuneam, aceasta “problema” nu aparea ca si eroare in loguri sau in testele obisnuite din Active Directory, dar curioziatea de a intelege care este motivul generarii acestui mesaj este provocatoare.

In mesaj se face referire la un KBQ312862 in care se descrie metode de recuperearea a obiectelor si attributelor din Active Directory, cum sa detectam si sa reparam atrubute cu valoarea nula, etc…Oricum nu era cazul nostrum pentru ca daca aveam missing objects in AD era destul de grav, si nu mai alerta dcdiag doar in modul verbose ci in orice mod :)).

Explicatia acestor “erori” este mai simpla decat pare.

La o verificare a atributului mentionat msDFSR-ComputerReferenceBL am vazut ca valoarea acestuia nu este populata. Dar ce ar fi trebuit sa contina mai exact?

Am verificat un DC 2008 R2 intr-un mediu virtual si valoarea populata in acel atribut este:

CN=DCServerName,CN=Topology,CN=Domain System Volume,CN=DFSR -GlobalSettings,CN=System,DC=Domain,DC=Com

Atunci a fost clar care este problema…Acel atribut trebuia populat cu un backlink catre un DC care tine o replica Sysvol.

M-am conectat la Default Naming Context si am vazut ca in CN=DFSR -GlobalSettings,CN=System,DC=Domain,DC=Com nu exista Domain System Volume (SysVol), si verificarea in containerul File Replication Services a confirmat faptul ca replicarea inca se face prin FRS.Desi recent fusese ridicat nivelul de functionare al domeniului si forestului la 2008 R2, replicarea inca se face prin FRS de aceea nu avea cum sa fie populat acel atribut!

FRS

Aceasta era de fapt problema alertata de dcdiag, care nu era chiar o “problema”…

Urmartoul pas este migrarea replicarii Sysvol de la FRS la DFSR, proces documentat in urmatorul articol Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=4843

USN Journal_Wrap


USN Journal_Wrap

Erorile de tipul journal_wrap apar de obicei cand folosim replicare FRS si este foarte improbabil sa gasim o astfel de eroare in cazul replicarii DFSR. Acest lucru se intampla deoarece FRS a fost conceput fara un sistem de auto-remediere in cazul coruperii bazei de date, journal wraps, si morphed folders.

USN Journal este un fisier care are o dimensiune stabilita care inregistreaza toate schimbarile ce au loc intr-o partitie formatata NTFS.

NTFRS monitorizeaza acest fisier (USN journal) atat timp cat serviciul FRS functioneaza.

Aceste erori apar atunci cand serviciul de replicare FRS a fost oprit (deci nu a mai putut monitoriza modificarile din USN Journal) iar ultima schimbare inregistrata de serviciul FRS inainte ca acesta sa fie oprit, nu se mai regaseste in fisierul USN journal. Frs poate fi oprit pentru o perioada mai lunga de timp de catre administrator pentru a efectua operatiuni de mentenanta pe masinile respective fara sa se gandeasca la impactul acestei actiuni.

In acest caz, exista modificari fisirelor/datelor replicate de care FRS nu stie si astfel intra intr-un journal_warp state. Una din simptomele vizibile acestui scenariu ar fi de exemplu acela ca share-urile SYSVOL si NETLOGON nu mai sunt vizibile. Acesta este un mechanism pentru a se proteja de inconsistenta informatiilor.

Cum se rezolva?

Trebuie aflata conditia care a generat starea de journal warp. In procesul ce urmeaza noi nu facem decat sa repornim sau sa reinitializam replicarea corespunzator dar daca nu se stie cauza care adeterminat acest lucru este posibil ca in scurt timp sa reapara problema.

Membrul afectat trebuie reinitializat cu un restore non-autoritative (D2), iar acesta isi va sincroniza datele de la un partener de replicare. Mai exact trebuie modificat folosind BurFlags.

BurFlags sunt chei in registrii care folosesc la efectuarea restore-urilor (authoritative si/sau non autoritative). Cheia BurFlags se gaseste in urmatoarea locatie:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs \Parameters\Backup/Restore\Process at Startup

Valorile acestei chei pot fi:

  • D2 (non-authoritative restore)
  • D4 (authoritative restore)

Pentru a efectua un non-authoritative restore, trebuie oprit serrviciul FRS, configurata cheia BurFlags si apoi repornit serviciul.

1.Click pe Start, apoi faceți clic pe Run.

2.Tastați cmd, apoi apăsați ENTER.

3.In caseta de comandă, scrieti ntfrs net stop.

4.Click Start, apoi faceți clic pe Run.

5.Tastați regedit și apoi apăsați ENTER.

6.Navigati la:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NtFrs \ Parameters \ Backup / Restore \ Process at Startup

7.In panoul din dreapta, faceți dublu clic pe BurFlags.

8.In Edit DWORD Value scrieti D2 și apoi faceți clic pe OK.

9.Quit Registry Editor.

10.In cmd, scrie ntfrs net start.

11.Quit CMD.

Cand serviciul FRS reporneste urmatoarele action se vor intampla:

•Valoarea cheii BurFlag revine la 0.

•Fisierele reinitializate sunt mutate in containerul Pre-existing.

• Apare Event 13565 (non-authoritative restore has started).

•Baza FRS este reconstruita.

•Membrul face join in replica set folosind cheia Replica Set Partner care desemneaza parent-ul de replicare.

•Membrul respectiv porneste o replicare complete cu ceilalti membri.

•La sfarsitul procesului se inregistreaza event 13516 (FRS is operational). Daca nu se inregistreaza evnt-ul atunci sunt problem de replicare frs.

Pe langa restaurarea non-autoritativa mi poate fi folosita si restaurarea autoritativa dar aceasta este de obicai lasata ca ultima solutie.

Ce trebuie stiut inainte de a face o restaurare autoritativa:

  • -Se foloseste pentru reconstruirea intregului replica set de la 0.
  • -Serviciul FRS trebuie oprit pe toti membrii.
  • -Exista evenimente 13553 si 13516 in FRS event log. Acestea demonstraza ca a fost stabilita apartenenta la replica set.
  • Computerul folosit trebuie configurat ca autoritativ (D4) iar ceilalti membri din replication set ca si non-autoritativi (D2)

Procedura este la fel ca la cea de non-autoritative restore doar ca in loc de D2 ca valoare vom specifica D4 (authoritative)

Cum prevenim erorile journal warp?

-Localizarea continutului replicat pe partitii mai putin ‘busy’

-Asigurarea ca serviciul functioneaza

-Nu aducem modificari continutului FRS atat timp cat serviciul este oprit

-Crestem dimensiunea fisierului USN journal. (acest lucru se face prin setarea urmatoarei chei in registrii HKLM\System\CCS\Services\NTFRS\Parameters\”Ntfs Journal size in MB” (REG_DWORD)) . Range-ul variaza intre 8MB si 128MB avand default 32MB. Daca marim dimensiunea fisierului trebuie oprit/pornit serviciul NTFRS pentru a se aplica modificarea, dar daca micsoram dimensiunea trebuiesc reformatate partitiile ce contin date replicate prin FRS…)

Additional info

In exemplele anterioare folosim cheia global BurFlags ceea ce reinitializeaza toate replica sets pe care serverul respectiv le are. Daca vrem sa resetam doar un replica set trebuie mai intai sa identificam GUID-ul acestuia:

  • Oprim serviciul NTFRS, navigam la KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
  • Sub cheia Replica Sets, există una sau mai multe subchei care sunt identificate printr-un GUID. In panoul din stânga, faceți clic pe GUID, apoi, în panoul din dreapta nota Data care sunt listate pentru valoarea Root Replica Set. Această cale va indica care replica set este reprezentat de GUID.
  • Navigam la KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets
  • Sub cheia Cumulative Replica Sets identifica GUID-ul de mai devreme. In pane-ul drept editeaza BurFlags cu valoarea D2 sau D4.

Alte link-uri utile