Category Archives: Active Directory

All things related to Active Directory

AD Initial Sync Requirement


Active-Directory-logo

AD Initial Sync Requirement

Am observat ca acest comportament nu este cunoscut de multi administratori, asa ca m-am gandit sa scriu ceva despre asta. Pentru cei ce stiu la ce se refera va fi doar un refresher.

Acest comportament este mai comun in mediile de testare deoarece DC-urile si topologia sunt modificate in mod frecvent. Intr-un mediu de productie unde un DC are mai multi parteneri de replicare de unde se poate replica, este mai putin probabil dar nu imposibil.

‘Initial Sync Requirement’ este o functionalitate utila, implementata pentru a se asigura functionalitatea rolurilor FSMO. Nu voi mai descrie ce face fiecare in parte, asta puteti afla aici: http://technet.microsoft.com/en-us/library/cc961939.aspx

Ce inseamna asta. Inseamna ca intr-un domeniu in care avem cel putin 2 domain controllere, in momentul cand porneste un DC care tine un rol FSMO, acel domain controller nu poate oferi serviciile specific rolurilor FSMO pana nu se replica naming contextul ce hosteaza acel rol FSMO.

De exemplu, sa presupunem ca rolul de PDC este tinut de DC1.

DC1 DC2 DC3  DC4

Atat timp cat nu se replica cu nici un partener, orice functionalitate legata de rolul de PDC nu va putea fi efectuata.

In versiunea originala de Windows Server 2003, dupa ce se restarta un DC, acesta incerca sa replice naming contextual de la un DC aflat in acelasi site cu el. Daca nu exista un DC care era in acel site, astepta pana se consuma intervalul de replicare specificat pe connection objectul cu site-ul respectiv (min 15 min), timp in care serviciile FSMO nu puteau fi utilizate.

In Windows Server 2003 SP1, s-a schimbat procesul, si atunci cand un DC porneste incearca sa replice de la orice partener de replicare disponibil, indifferent daca se afla in acelasi site sau nu.

Exista un override in registry care poate dezactiva ‘initial sync requirement’ pe care il puteti folosi daca stiti cu siguranta ca partenerii de replicare nu mai sunt disponibili. De exemplu DC-urile cu care se replica erau VM-uri si au fost inchise fara metadata cleanup, si acum am ramas cu un DC disponibil. Mai jos aveti cheia, valorile fiind 0 sau 1.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

“Repl Perform Initial Synchronizations”=dword:00000000

Referinte:

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

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

 

 

 

Advertisements

Removing Lingering Objects


Active-Directory-logo

Removing Lingering Objects

Lingering objects se produc atunci cand anumite DC-uri nu se replica intr-un interval de timp mai lung decat TSL (Tombstone Lifetime). Dupa ce replicarea este din nou functionala, acest domain controller poate avea obiecte care au fost sterse din Active Directory cat timp el nu s-a putut replica iar aceste obiecte se numesc lingering objects.

Atunci cand stergem un obiect din AD acesta nu este sters din database-ul din AD. In schimb este marcat ca si un Tombstone Object iar valoarea atributului isDeleted va fi TRUE, si mutat intr-un container special CN=Deleted Objects. Cand un obiect este marcat ca si tombstone, acesta nu va mai avea toate atributele pe care le avea inainte de a fi sters. Din nou nu este efectiv sters ci doar marcat ca sters. Va avea un set limitat de atribute si va fi pastrat in functie de cat este valoare TSL configurata in forest.

Atributele limitate de pe un tombstone object

attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
msDS-AdditionalSam­AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid

Atunci cand apar lingering objects in Active Directory exista doua posibilitati:

  1. Daca avem enabled Strict Replication Consistency DC-ul destinatie va primi un update notification pentru un obiect care nu exista din punctul lui de vedere. Avand optiunea SRC enabled va bloca replicarea inbound de la DC-ul care inca are acel obiect. SRC este un mecanism de protectie pentru a preveni inconsitenta obiectelor in AD.
  2. Daca Strict Replication Consistency este Disabled, atunci cand DC-ul destinatie primeste un notificare de tip update, acesta va cere toate informatiile despre acel obiect (Full Replica).

Daca obiectul existent de pe DC-ul sursa nu este updatat, fapt care face DC-ul sursa sa trimita update notifications la partenerii de replicare atunci nu se va intampla nimic care sa evidentieze existenta obiectelor lingering in AD.

DC-ul destinatie va inregistra evenimentul cu ID 1988 in care se va afisa obiectul si DC-ul sursa care il contine.

zLingering 1988

Urmatoarele evenimete arata ca ar putea exista obiecte de tip lingering in AD:

1862 The local domain controller has not recently received replication information from several domain controllers (intersite).

1863 The local domain controller has not recently received replication information from several domain controllers (intersite).

1864 The local domain controller has not recently received replication information from several domain controllers (summary).

1311 The Knowledge Consistency Checker (KCC) was not able to build a spanning tree topology.

2042 It has been too long since this server last replicated with the named source server. 

1084 There is no such object on the server.

1388 This destination system received an update for an object that should have been present locally but was not.

1311 Another domain controller replicated an object not present on this domain controller.

 Odata identificat obiectul sau obiectele, naming contextul care contine obiectele si pe ce domain controller se afla acestea, se va folosi comanda repadmin cu parametrul removelingeringobjects. In exemplul anterior dubdc03.contoso.com contine obiectele care incearca sa fie replicate in AD.

repadmin /removelingeringobjects dubdc03.contoso.com 667f7037-8198-4357-8f15-8f709f04b6e2 DC=europe,DC=contoso,DC=com /advisory_mode

In exemplul anterior dubdc03.contoso.com contine obiectele care incearca sa fie replicate in AD.

667f7037-8198-4357-8f15-8f709f04b6e2 reprezinta GUID-ul DSA. Sunt multe metode de a gasi guidul. De exemplu ruland repadmin /showreps

DC=europe,DC=contoso,DC=com – este naming contextul unde se afla obiectul

advisory_mode – obiectele nu vor fi sterse si vor fi afisate in event log. Pentru a se sterge se omite acest parametru.

zLingering 1946

Rulam comanda fara advisory_mode si vedem urmatoarele evenimente:

zLingering 1945

Din acest moment replicarea isi va relua cursul daca a fost oprita de SRC la DC-urile destinatie.

AdminSDholder, SDProp si “Protected Groups”


Active-Directory-logo

AdminSDholder, SDProp si “Protected Groups”

De cele mai multe ori ne lovim sau aflam de AdminSDHolder atunci cand permisiunile delegate unui obiect dispar.

Cateva exemple care ne atrag atentia in acest sens ar fi pierderea delegarilor facute in Active Direcctory, device-uri BlackBerry/ActiveSync care nu se sincronizeaza cu serverele de Exchange, sau permisiuni insuficiente in administrarea serverelor de Lync. Posibil sa fie si alte scenarii acestea sunt doar cateva.

Ce este AdminSDHolder?

Un mecanism de protectie al permisiunilor membrilor unor grupuri ‘administrative’.

Pe scurt, fiecare domeniu din forest are un obiect AdminSDHolder care se gaseste in containerul System.

adminSDHolder

Acesta tine permisiunile default pentru anumite grupuri protejate. Grupurile protejate difera in functie de vesiunea de Windows Server dar se poate ‘edita’ lista de grupuri ‘Protected Groups’.

Acestea sunt grupurile protejate implicite per versiune de server:

Windows 2000 Server RTM Windows 2000 Server with SP1 Windows 2000 Server with SP2 Windows 2000 Server with SP3 Windows 2000 Server with SP4 Windows Server 2003 RTM Windows Server 2003 with SP1 Windows Server 2003 with SP2 Windows Server 2008 RTM Windows Server 2008 R2
Administrators Account Operators Account Operators Account Operators
Domain Admins Administrator Administrator Administrator
Enterprise Admins Administrators Administrators Administrators
Schema Admins Backup Operators Backup Operators Backup Operators
Cert Publishers Domain Admins Domain Admins
Domain Admins Domain Controllers Domain Controllers
Domain Controllers Enterprise Admins Enterprise Admins
Enterprise Admins Krbtgt Krbtgt
Krbtgt Print Operators Print Operators
Print Operators Replicator Read-only Domain Controllers
Replicator Schema Admins Replicator
Schema Admins Server Operators Schema Admins
Server Operators Server Operators

Cum functioneaza AdminSDHolder?

Pe domain controller-ul ce tine rolul de PDC emulator ruleaza by default la un interval de 60 de minute un proces numit SDPprop (Security Descriptor Propagator) ce compara permisiunile ACL pentru membrii grupurilor protejate cu acelea de pe AdminSDHolder. (Acest process se poate initializa si manual, vezi aici.)

Se mai poate modifica intervalul folosind urmatoarea cheie pana la max 2 ore dar nu este recomandat datorita overheadului generat de procesul LSASS.

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600

Microsoft recomanda ca ‘best practice’ sa avem un set de 2 conturi in Active Directory. Un cont obisnuit pentru rutinele de zi cu zi si un alt cont cu drepturi administrative pe care s ail folosim atunci cand trebuie sa efectuam operatiuni cu drepturi elevate. Nu intotdeauna se respecta aceasta situatie.

De exemplu, daca un user cu drepturi normale (cu casuta de email, device mobil cu activesync) face parte din unul din grupurile de mai sus, poate a fost adaugat in Print Operators sa administreze cine stie ce print server, la un moment dat acel user se poate trezi ca nu se mai sincronizeaza device-ul mobil cu activesync sau daca avea ceva delegari mai speciale acestea nu mai sunt in efect.

Deasemenea, daca face parte dintr-un grup de securitate sau distributie. Asa ca group nesting este valabil in acest caz.

Daca se prezinta astfel de simptome, primele lucruri care trebuiesc verificate sunt urmatoarele:

AdminSDHolder2

  1. Lipseste bifa pentru ACL inheritance.

AdminSDHolder4

  1. Valoarea atributului adminCount este 1.

Daca valoarea este 1 sau >1, atunci acest obiect face parte din unul din acele grupuri protejate sau a fost membru. Daca acel user a facut parte din unul din grupuri dar a fost scos ulterior, atunci valoarea atributului ramane neschimbata. By default valoarea este <not set>. Atata timp cat valoarea este 1 inheritancce-ul de ACL-uri va ramane neselectat. Pentru fiecare user trebuie modificat acest atribut, fie la <not set>, fie 0. Daca punem 0 putem sa avem un istoric cu obiectele afectate.

Cum o rezolvam?

  1. Pentru test, putem pune bifa manual de “Inherit permissions” doar ca sa vedem daca problemele se rezolva in acest mod. Tineti cont ca dupa acel interval de timp inheritance-ul va fi din nou scos de SDProp.
  2. RECOMANDAT – Folositi 2 conturi asa cum se recomanda si de catre Microsoft, si scoate-ti conturile din grupurile respective.
  3. Modificati lista de Protected Groups.

Acest lucru se face modificand flagul dsHeuristics; Ca sa ajungeti acolo deschideti ADSIEDIT, deschideti naming contextual de Configuration, apoi mergeti la Services, WindowsNT, Directory Service.

AdminSDHolder3

Acest flag accepta valori hexazecimal. De exemplu:

Bit

Grupuri Excluse

Valoare in binar

Valoare in   hexazecimal

0

Account Operators

0001

1

1

Server Operators

0010

2

2

Print Operators

0100

4

3

Backup Operators

1000

8

Lucrurile se complica in cazul in care vrem sa excludem mai multe grupuri. In acest caz se aduna valoare lor in binar si se transforma apoi in hexazecimal.

Grupuri   Excluse

Valoare   in binar

Valoare   in hexazecimal

None   (Default)

0000

0

Account   Operators

0001

1

Server   Operators

0010

2

Account   Operators Server Operators

0001   + 0010 = 0011

3

Print   Operators

0100

4

Account   Operators Print Operators

0001   + 0100 = 0101

5

Server   Operators Print Operators

0010   + 0100 = 0110

6

Account   Operators Server Operators Print Operators

0001   + 0010 + 0100 = 0111

7

Backup   Operators

1000

8

Account   Operators Backup Operators

0001   + 1000 = 1001

9

Server   Operators Backup Operators

0010   + 1000 = 1010

a

Account   Operators Server Operators Backup Operators

0001   + 0010 + 1000 = 1011

b

Print   Operators Backup Operators

0100   + 1000 = 1100

c

Account   Operators Print Operators Backup Operators

0001   + 0100 + 1000 = 1101

d

Server   Operators Print Operators Backup Operators

0010   + 0100 + 1000 = 1110

e

Account   Operators Server Operators Print Operators Backup Operators

0001   + 0010 + 0100 + 1000 = 1111

f

Alte linkuri utile:

  1. Description and Update of the Active Directory AdminSDHolder Object
  2. Manually initializing the SD propagator thread to evaluate inherited permissions for objects in Active Directory
  3. AdminSDHolder Thread Affects Transitive Members of Distribution Groups
  4. Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue

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…

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