Come rimuovere correttamente gli oggetti persistenti quando -strict è stato impostato su un numero elevato di controller di dominio per lungo tempo?

Di recente mi trovavo in un ambiente in cui c'erano 120 controller di dominio in oltre 100 siti in tutto il mondo. Questo dominio è iniziato nell'era di Windows 2000 ed è stato aggiornato nel tempo, quindi la coerenza della replica rigorosa non è mai stata impostata come predefinita per i nuovi controller di dominio e non è mai stata abilitata su alcun controller di dominio. Ci sono oggetti persistenti nella directory e si vede regolarmente un numero decente di oggetti in conflitto a causa di ciò.

L'utilizzo repadmin /removelingeringobjectsrichiede la conoscenza di due cose:

1. Quali DC hanno oggetti persistenti nel database

2. Un controller di dominio che non contiene oggetti persistenti da utilizzare come controller di riferimento.

Ovviamente, in futuro, questo ambiente dovrebbe essere impostato in modo tale che tutti i nuovi controller di dominio dispongano di una rigorosa coerenza di replica e repadmin /options * +strictvengano eseguiti per fare in modo che tutti i controller di dominio correnti utilizzino una coerenza di replica rigorosa, ma ciò interromperà la replica ora senza pulire gli oggetti .

Quindi, la mia domanda è questa: in un ambiente così vasto in cui non avrei idea di quali controller di dominio abbiano oggetti persistenti e quali no, come posso identificare un controller di riferimento valido repadmin /removelingeringobjectsda utilizzare e come posso garantire che tutti i 120+ I controller di dominio sono puliti dagli oggetti persistenti prima di applicare una coerenza di replica rigorosa e interrompere la replica? Oppure è solo più facile attivare la modalità rigorosa e guardare repadmin /replsumper vedere cosa si rompe e gestirla?

Ci vorrà del tempo per risolvere.

Per interrompere tutta la replica, eseguire:

repadmin /options +DISABLE_OUTBOUND_REPL

Su tutti i controller di dominio. Ricorda che l'impostazione sopra non impedisce azioni di replica manuale come un amministratore (tu) in esecuzione repadmin /syncall /APed, ecc. Ma è una buona cosa perché ti consente di ripristinare completamente la sincronizzazione di tutti i controller di dominio prima di riattivare la replica regolare.

Repadmin determina che è un oggetto persistente se l'oggetto esiste su ServerA ma non su ServerB, dove ServerB è il controller di dominio di riferimento. La differenza tra replicare oggetti appena creati e replicare gli aggiornamenti su oggetti già esistenti è la chiave. Replica di oggetti appena creati = buono. Replica degli aggiornamenti su oggetti già esistenti = buono. Replica degli aggiornamenti agli oggetti che non esistono sul controller di dominio di destinazione = non valido.

Hai solo bisogno di schiuma, risciacquo, ripetizione fino a quando tutte le DC corrispondono allo stesso DC di riferimento valido. Quindi attivare la coerenza rigorosa ovunque, quindi riattivare la replica. Sì, si corre il rischio di eliminare oggetti legittimi creati su altri controller di dominio remoti che non si sono replicati nel controller di riferimento.

Dal fantastico articolo " Come funziona il modello di replica di Active Directory ":

Impostazione della coerenza della replica

Se gli attributi di un oggetto persistente non cambiano mai, l'oggetto non viene mai considerato per la replica. Tuttavia, se un attributo cambia, l'attributo viene considerato per la replica in uscita. Poiché il controller di dominio di destinazione non contiene l'oggetto per l'attributo che viene replicato, non è possibile eseguire un aggiornamento. La modalità di risoluzione di questa condizione dipende dall'impostazione della coerenza della replica sul controller di dominio.

Un'impostazione del Registro di sistema sui controller di dominio che eseguono Windows Server 2003 o Windows 2000 Server con SP3 fornisce un valore di coerenza che determina se un controller di dominio replica e rianima un oggetto aggiornato che è stato eliminato da tutte le altre repliche o se la replica di tali oggetti è bloccata. Le impostazioni predefinite sono diverse nei controller di dominio che eseguono Windows 2000 Server con SP3 e Windows Server 2003.

Coerenza rigorosa della replica

Per evitare problemi con la rianimazione degli oggetti che sono stati eliminati, un controller di dominio che esegue Windows Server 2003 in una foresta Windows Server 2003 appena creata (non aggiornata) blocca la replica in entrata per impostazione predefinita quando riceve un aggiornamento di un oggetto che non ha .

Nota • La replica di Active Directory utilizza il rilevamento degli aggiornamenti per distinguere tra la replica di un oggetto appena creato e l'aggiornamento di un attributo per un oggetto esistente. La replica di un oggetto persistente è un tentativo di aggiornare uno o più attributi di un oggetto che il controller di dominio di destinazione non può aggiornare perché l'oggetto non esiste.

La replica viene interrotta nella partizione di directory per l'oggetto fino a quando l'oggetto persistente viene rimosso dal controller di dominio di origine o l'impostazione di coerenza della replica rigorosa viene disabilitata.

Quando ServerB dice a ServerA: "Ehi, sono stati apportati alcuni aggiornamenti all'oggetto A esistente". Quindi ServerA dice: "Aspetta cosa? Non ho nemmeno un oggetto A. Inviami l'intero oggetto!" Se nessuna coerenza rigorosa. Se rigorosamente coerente, ServerA dice: "Aspetta cosa? Come ti aspetti che aggiorni un oggetto che non esiste? Vai piegato!"

Per sapere se hai oggetti persistenti su un controller di dominio:

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode 

ServerGUID è il DC di riferimento valido noto. So che lo sai già ... e come scrivere la riga sopra per eseguirla su tutti i controller di dominio ... ( foreach ($DC In $(Get-ADDomain).ReplicaDirectoryServers) { }) ...

È necessario un buon DC di origine per confrontare, linea di fondo. Se non disponi di un controller DC noto o non lo sai, devi solo sceglierne uno. Dovrebbe essere un GC scrivibile, ovviamente. È relativo: se tutti i controller di dominio concordano sull'esistenza di un oggetto e sugli attributi di quell'oggetto ... non è un oggetto persistente.

foreach($GC In $(Get-ADForest).GlobalCatalogs) { repadmin /removelingeringobjects $_.name 85d158d2-a006-4fff-b1e5-f9b6eaabab2b '$directoryPartition'

Questo sta risincronizzando quella partizione di directory di ogni GC nella foresta con l'origine valida nota che è necessario specificare come GUID.

Quindi dopo aver ottenuto tutti i controller di dominio ancora una volta tutti d'accordo, e la replica è felice ... allora vai e inizi a lanciare una coerenza rigorosa su tutti loro.

Modifica: questa è la linea di partito di Microsoft sul problema e ciò che probabilmente ti faranno conoscere se li chiamassi.

Infine, questo potrebbe essere più un problema da risolvere di quanto valga la pena a meno che non ti causi problemi. Odio dirlo, ma AD può ancora funzionare normalmente con oggetti persistenti al suo interno.

Il principio generale in un caso in cui non è possibile identificare un DC pulito è il seguente:

for each $sourceDC in $allDCs
    for each $targetDC in $allDCs
        if ($targetDC <> $sourceDC) then
            run repadmin with $sourceDC and $targetDC
        end if
    next
next

Questo processo è descritto qui: http://blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx

Tuttavia, dai un'occhiata a ReplDiag . Automatizza il processo eseguendo repadminper te tutte le combinazioni di controller di dominio di origine e destinazione. Segue quindi il /advisory_onlycontrollo di eventuali oggetti persistenti.