Usb rollback, mare și teribil, mvvrus

Ce este USN Rollback

Realizarea testelor primare

Server de testare: Implicit-Prim-Site-Nume \ DC2
Începutul testului: Publicitate
Avertisment: DsGetDcName a returnat informații pentru \\ DC1.domain.loc, când






încercam să ajungem la DC2.
SERVER NU RESPONDEAZĂ SAU NU ESTE CONSIDERAT ADEVĂRAT.
......................... DC2 nu a reușit publicarea testului
...........................................................................

cu ID-ul evenimentului 2095

Usb rollback, mare și teribil, mvvrus

și cu ID-ul evenimentului 2103

Usb rollback, mare și teribil, mvvrus

Primul dintre aceste evenimente este fixat o singură dată, la prima dată după apariția problemei, al doilea va apărea și la fiecare repornire ulterioară a controlerului de domeniu.

Active Directory este proiectat astfel încât sincronizarea (replicare) pot fi transmise CD-ul țintă nu este întreaga bază de date, dar numai acele modificări care nu au primit încă CD-ul țintă. În acest scop, fiecare schimbare (inclusiv nou Souza) în atributul obiect bază de date AD sau obiect este marcat în CD-ul lor identificator de metadate (Invocation ID), în cazul în care a fost făcută inițial schimbarea, și numărul de ordine (USN) modificării acestui CD-ul original (a se vedea metadatele pentru orice obiect și toate atributele sale pot repadmin echipa / showmeta). La fiecare schimbare, produsă inițial de pe acest CD, acest număr crește. În plus, fiecare CD magazine au o listă a numerelor maxim de modificări ale replicate pentru fiecare dintre cunoscute la sursele de CD-actualizare (identificate prin ID-ul de invocare) pentru fiecare partiție director - up-to-actualității vectorul (vă puteți vedea repadmin / echipa showutdvec). Și cu cereri de replicare CD-uri numai modificările, numărul USN care este mai mare decât numărul maxim deja produs modificări.

Din această descriere este clar că în cazul în care cel mai mare număr de curent USN pentru un motiv oarecare redus, modificările marcate cu numere USN în spațiul dintre noul curent numărul maxim USN și stocate pe alte CD-ul maxim replicată modificări nu sunt reproduse la celălalt CD-ul de exemplu, baza de date AD va fi în stare inconsistentă - conținutul său pe diferite controlere de domeniu vor fi întotdeauna diferite.

Din moment ce toți algoritmii AD funcționează pe baza faptului că conținutul bazelor de date pe CD-uri diferite (sau destul de repede devine) același, situația descrisă mai sus este inadmisibilă. Pentru a evita aceasta, în mecanismul de replicare AD s-a adăugat un element de control, verificare la momentul primei de replicare CD, curent numărul cel mai mare USN pe controlerul de domeniu nu este mai mic decât numărul maxim de modificări ale replicate, cunoscute pentru partenerii săi de replicare. Dacă această condiție nu este îndeplinită, atunci blocurile AD intrare și de ieșire de replicare, precum și mărcile (în registru) o copie a bazei de date ca fiind indisponibil pentru înregistrarea datorită numărului USN a reveni la o valoare mai mică - care tocmai cauzeaza chiar simptomele care sunt descrise la începutul articol.

Detectarea USN Rollback funcționează, din păcate, nu întotdeauna. În cazul în care controlerul de domeniu de recuperare după a imaginii nu este datorată pentru o lungă perioadă de timp, cu alte CD-ul, și pe ea în acea perioadă există o mulțime de schimbări, după comunicarea este restaurat poate fi faptul că, la momentul primei replicare după restabilirea numărului maxim de curent USN este mai mult decât numărul maxim de modificări ale replicate starea rollback absenta USN va cunoscut în mod oficial, de fapt, a avut loc retroactivitate modificărilor detectate și numerele vor face parte din modificările și nu vor fi reproduse. Această opțiune este destul de fezabilă în CD-ul de recuperare după eșecul catastrofal undeva în biroul ramură, în cazul în care, din cauza eșecului suferit și de comunicare. Deci, găsirea citat mai devreme în acest articol simptome, vă puteți bucura chiar și - lucrurile ar putea fi mai rău.

Cum de a trata răsturnarea USN

Cel mai bun tratament este, după cum știți, prevenirea. După cum se aplică la subiectul acestui articol, aceasta înseamnă: să faceți în mod regulat copii de rezervă ale bazei de date AD (este inclusă în starea sistemului pentru CD-uri) și să le faceți un program care să știe să copieze și, cel mai important, să restaureze baza de date AD. Cel mai simplu dintre aceste programe este built-in Windows Server Backup. Utilizarea programelor potrivite elimină majoritatea posibilelor apariții ale USN Rollback și dacă se produce un astfel de dezastru (de exemplu, din cauza unei defecțiuni a controlerului RAID care reflectă discul de sistem), este ușor să restabiliți baza de date AD fără probleme.







Dar iată ce să facem dacă dezastrul sa întâmplat deja și nu există o copie de rezervă a bazei de date AD? Recomandările producătorului - Microsoft - sunt simple și simple: reduceți cu forța controlerul de domeniu, eliminați metadatele sale din AD și măriți-le înapoi. Procedurile sunt simple și descrise de multe ori, aici nu mă voi concentra asupra lor. În cele mai multe cazuri, acest lucru se poate face destul de nedureros și, de fapt, dacă este posibil, merită făcut.

O altă întrebare este mai interesantă: ce se întâmplă dacă coborârea forțată cu o scădere ulterioară nu este o opțiune? De exemplu, dacă pe CD există un program care, cu un grad rezonabil de probabilitate, nu va transfera astfel de manipulări. Sau USN Rollback a provenit de la un singur controler al domeniului nou creat, în care au fost deja create noi conturi de utilizator. Sau, de exemplu, a fost cazul în forumul Technet rus, atunci când administratorul de sistem a reușit să conducă în stare de USN Retroactivitatea toate controlerele din domeniul rădăcină de pădure - cum să salveze pădurea? În astfel de cazuri, metoda recomandată de producător pentru rezolvarea problemei nu este adecvată. Dar ieșire cu toate acestea, est.Chtoby înțeleg cum funcționează, ar trebui să ia în considerare două lucruri: atât în ​​reconstrucția corectă a bazei de date AD este evitată USN revocați și ce schimbări sunt făcute la configurația CD-ului atunci când detectează această condiție.

Pentru a asigura corectitudinea programului de recuperare a bazei de date restaurat face un lucru simplu: este după recuperarea este finalizată (și se produce atunci când încărcarea director modul de asistență) înregistrat în registrul de noua valoare pentru ID-ul de invocare în HKEY_LOCAL_MACHINE \ System \ parametrul «CurrentControlSet \ Services \ NTDS \ bază de date Parametrii \ New GUID », cauzand AD la pornire în timpul următoarea inițializare a sistemului în modul normal pentru a schimba ID-ul de invocare - care este, face uite (din punct de vedere al replicare a datelor de baze de date mecanism AD) restaurat controler de domeniu ak un nou complet diferit CD-uri,, modificările în care sunt înregistrate, indiferent de trecut, care a făcut la recuperarea.

În ceea ce privește răspunsul la USN Rollback include două lucruri: în primul rând, pentru subiectul CD ei este oprit (prin setarea unor steaguri DISABLE_INBOUND_REPL și DISABLE_OUTBOUND_REPL atribut Opțiuni obiect «NTDS Setări», în legătură cu subiectul CD-ului în secțiunea de configurare) de intrare și replicare de ieșire, și în al doilea rând, în registrul CD-ului în parametrul «HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NTDS \ Parameters \ DSA nu inscriptibil» (tip REG_DWORD) este fixat, ca baza de date AD nu este permisă din cauza apariției USN Rollback (valoare este setat egal cu 4). Atunci când detectează că ultimul parametru este o înregistrare în jurnal ID-ul evenimentului 2103, dar serviciul Netlogon este pus într-o stare suspendată.

Și în lumina tuturor celor de mai sus, devine clar ce trebuie să faceți pentru a aduce controlerul de domeniu din starea USN Rollback:

De fapt reteta.

Avertizare. Următoarele acțiuni nu se bazează pe recomandările oficiale ale Microsoft (deși au fost verificate personal de mine). Acestea pot cauza copii necorespunzătoare ale bazei de date Active Directory pe controlere de domeniu diferite (vedeți mai jos). Prin urmare, folosiți-le pe propria răspundere și numai ca o ultimă soluție.

2. În cazul în care un avertisment pe controlerul de domeniu afectat în baza de date AD au fost efectuate modificări după apariția stării de USN Rollback, aceste modificări vor probabil nu fi replicat la alte controlere de domeniu, chiar și după restaurarea procedurii de mai jos (au fost luate în considerare motivele în secțiunea anterioară). Din acest motiv, va exista o aliniere necorespunzătoare a copiilor bazei de date. Și apoi poate duce la un comportament ciudat (de exemplu, conturi de parole nepotrivite) sau prin încălcarea de replicare (bug 8606). Dacă a fost depistată imediat recuperarea USN și controlerul de domeniu a fost blocat în timp, probabilitatea unor astfel de erori este mică. Dar, dacă a fost, de exemplu, controlerul restaurat din imaginea discului undeva în ramură, consecințele pot fi destul de neplăcute. Sper să ia în considerare modul în care puteți calcula astfel de modificări în avans și le puteți pune la dispoziție pentru replicare într-unul din următoarele articole.

1. A face o schimbare AD Invocation ID. Deși puteți face acest lucru în mod direct prin scris o valoare corespunzătoare pentru registru, mi se pare preferabil să se facă acest lucru cu ajutorul unui backup regulat / Restore - aceasta este, în același timp, să elimine și posibila nealinierea copii ale SYSVOL pe controlerul de domeniu afectat, și alte CD-uri și pentru a permite izbedat posibile probleme cu replicarea acestuia (aceasta un alt subiect care sunt aici nu este afectat). Secvența de acțiuni, cum ar fi următoarele (nu am vopsea detaliu toate etapele în care acestea sunt reflectate în multe manuale):

1a. Acțiuni pregătitoare. Instalați, dacă nu este încă instalat, componenta de rezervă și pregătiți locul în care va fi scris rezervarea (fie un disc curat local sau detașabil, fie un dosar de rețea partajat gol). De asemenea, vă recomandăm să reparați (prin repadmin / showrepl) actualul ID de invocare al controlerului de domeniu.

1c. Introduceți în modul de recuperare a serviciului director și restaurați starea sistemului. Vă recomand să faceți în numele Serviciilor de contabilitate Directory locale Restore cont de administrator Mod (l-am văzut cazuri în care o încercare de a restabili starea de sistem în înregistrarea sub administratorii domeniului au dus la eșecuri inexplicabile).

1d. Descărcați controlerul de domeniu în modul normal.

2. Permiteți replicarea de intrare și ieșire pentru controlerul de domeniu. Înainte de a permite replicarea ca măsură de precauție, vă recomandăm să verificați dacă valoarea ID-ului de invocare afișată de comanda repadmin / showrepl a fost modificată de cea veche fixată în pasul 1a

Activarea replicării se face prin comenzi

repadmin / opțiuni CD_name -DISABLE_INBOUND_REPL

repadmin / opțiuni CD_name -DISABLE_OUTBOUND_REPL

4. Rulați din starea suspendată (dacă nu a început încă) serviciul Netlogon

După finalizarea acestor pași, am recomandăm (dar nu neapărat) din nou pentru a reporni controlerul de domeniu, și de a efectua diagnosticul folosind comanda DCDIAG: după lichidarea se poate produce USN revocați și alte erori (a se vedea, de exemplu, în cazul menționat deja în forumul TechNet Rusă - nu a trebuit să fie eliminate. și probleme cu SYSVOL, și nu de la distanță în timp ( „blocat“), din cauza unor obiecte de replicare rupte).

Recuperare de succes pentru tine. Și nu mai faceți asta.







Trimiteți-le prietenilor: