Momentan sunteți offline, așteptați să vă reconectați la internet

Restaurarea unui controler de domeniu poate provoca inconsistențe între controlerele de domeniu

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 316829
Simptome
Restaurarea unui controler de domeniu poate provoca o Event ID: 1587, indicând inconsistențe între controlerii de domeniu. Dacă se întâmplă acest lucru, unele obiecte persistente pot fi prezente pe controlerul de domeniu restaurat. De asemenea, obiecte noi pe controlerul de domeniu restaurate nu se reproduce.
Cauză
Această problemă se produce deoarece controlerul de domeniu atribuie un ID de invocarea nou, dar utilizează marca highwater originală.
Rezoluţie
Pentru a rezolva această problemă, obțineți cel mai recent pachet pachet Service Pack pentru Windows 2000. Pentru informații suplimentare, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:
260910 Cum se obține cel mai recent Windows 2000 pachet Service Pack
Pentru a rezolva această problemă, obțineți remedierea rapidă descrisă în următorul articol din baza de cunoștințe Microsoft:
299687 MS01-036: Function expus utilizând LDAP prin SSL ar putea activa parolele pentru a fi modificate
Remediere
Pentru a rezolva această problemă, se retrogradează și apoi promova controlerul de domeniu restaurat. Înainte să retrogradați serverului în cauză, impune o reproducere completă a serverului în cauză către un alt controler de domeniu. (Sincronizare completă poate fi resurse io pentru domenii mai mari). Efectuați sincronizarea completă pe partiția de domeniu și pe partiția de configurare. Linia următoare Arată sintaxa comenzii Repadmin pe care le utilizați pentru a efectua sincronizarea:
Repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">force/Force [/full]</Source> </Dest> </Naming>
Următoarea linia Către este un exemplu de utilizare a acestei comenzi:
Repadmin /sync DC = domeniu, DC = rădăcină good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 Force/complet
În comanda de exemplu,
  • "DC = domeniu, DC = rădăcină" este nominalizare context de domeniu.
  • "good_DC" este destinație DC. Acest lucru este bun partener care vor primi actualizări.
  • DSA GUID este reproducerea GUID pentru DC restaurat. Puteţi obţine acest lucru prin executarea Repadmin /showreps pe serverul de restaurat. GUID-ul este listat în partea de sus sub "DC obiect Guid".
Dacă sincronizarea are succes, primiți următorul mesaj:
Sincroniza din 122a5239-36b3-488a-b24c-971ed0ca8a46 Good_DC terminat cu succes.


Repetați procesul pentru nominalizare context de configurare utilizând o comandă similar cu următorul:
Repadmin /sync cn = configuration, DC = domeniu, DC = rădăcină good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 Force/complet
Problema nu este probabil să fi rezolvat după aceasta. După aceasta, instalați remedierea rapidă sau retrogradează și apoi promova controlerul de domeniu pentru a rezolva problema.
Stare
Microsoft a confirmat că aceasta este o problemă în produsele Microsoft care sunt listate la începutul acestui articol. Această problemă a fost corectată prima dată în Windows 2000 pachet Service Pack 3.
Informaţii suplimentare
Atunci când restabiliți un controler de domeniu, USN angajează mai mare este revenea la punctul când copierea de rezervă a fost creat. ID de invocarea controlerul de domeniu este retras și se atribuie o nouă. Când un partener încearcă să se reproducă prima dată după restaurarea, urmaţi mesajul este înregistrată:

Tip eveniment: informații
Sursă eveniment: Reproducere NTDS
Categorie eveniment: (5)
ID eveniment: 1587
Data: 3/16/2001
Ora: 10:52:35 AM
Utilizator: CONTOSO\CO-NA-DC-01$
Computer: CO-DC-02
Descriere:
Directory Service Agent (DSA) corespund objectGuid d0a6a575-9702-4f4e-bf68-bb2a9f875188 a cerut pentru modificările de la un marcaj de selectare anterioare local DSA restaurare cea mai recentă de copiere de rezervă la USN 94727614. marcaj de selectare se ajustează după cum urmează: anterioare invocarea ID: bc546028-fae7-4978-abe0-d294694da32b
Actualizarea anterioară obiect USN: 95853579
Actualizare proprietate anterioare USN: 95853579
Noi invocarea ID: ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Noua actualizare de obiect USN: 94727614
Noua actualizare de proprietate USN: 94727614


Acest eveniment este tipic pentru un controler de domeniu restaurat. În sine, acest lucru indică o problemă. Aceasta este o problemă dacă obiectele care sunt create pe controlerul de domeniu restaurate "tăcere" nu se reproduc absent.

În scenariul problema, USN cea mai mare este revenea. Cu toate acestea, în timpul marcaj de selectare în document (sau "actualitate" vector Reinițializare), controlerul de domeniu sursă furnizează cea mai mare valoare USN care a fost prezent înainte de restaurare. Obiectele care au valori USNchanged între valoarea atributului sus şi de jos highestCommittedUSN sunt considerate niciodată pentru reproducere.

De exemplu: să presupunem că controler de domeniu 1 are o USN mai mare de 100. Partenerul său de reproducere, controlerul de domeniu 2, are o "actualitate" vector de 100 pentru controlerul de domeniu 1.

Restaurați 1 controler de domeniu dintr-o copiere de rezervă pe care este USN mai mare de 50. După următorul reproducere cu controlerul de domeniu 2, controlerul de domeniu 1 reinițializează marcaj de selectare la 100 (ar trebui să fie 50). controler de domeniu 1 provine modificările 51, 52 și 53. În cazul în care controlerul de domeniu 2 negociază reproducerea, niciodată consideră modificările, deoarece se consideră că are modificări la 100. controler de domeniu 1 Urmărire să efectuați modificări și ajunge 101. Modificarea 101 se reproduce, dar nu sunt modificări 51 până la 100.

În unele cazuri, să detecteze această stare. Utilizați Ldp sau ADSI Edit să citească atributul highestCommittedUSN curentă pe obiectul rootDSE pe controlerul de domeniu restaurat. Apoi, care compara datele de ieșire din repadmin /showreps / verbose unul din partenerii săi. În rezultatele Repadmin, căutați "USN ### /OU" valoarea pentru controlerul de domeniu restaurate pentru fiecare nominalizare context. Dacă valoarea din Repadmin este mai mare decât atributul highestCommittedUSN , controlerul de domeniu restaurat are problema.

Reţineţi că, în cazul în care controlerul de domeniu restaurat are originea suficient actualizări care sa atribut highestCommittedUSN a atins sau depășit "actualitate" vector care este înregistrat pe alte controlere de domeniu (ca în exemplul din acest articol), unele modificări nu vor fi considerate pentru reproducere. Cu toate acestea, noile modificări se reproduce absent. Modificările unreplicated sunt denumite "obiecte persistente."
Referinţe
Pentru informații suplimentare despre obiecte persistente, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:

317097 Obiecte persistente împiedica reproducerea Active Directory la care apar

3125191 Event ID 1587 este generat pe un controler de domeniu, atunci când există mai mult de două controlere de domeniu în același site ca Lync server
kbDirServices

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 316829 - Ultima examinare: 01/25/2016 22:06:00 - Revizie: 1.0

  • kbbug kbdirservices kbfix kbwin2000presp3fix kbwin2000sp3fix kbmt KB316829 KbMtro
Feedback