AD Replikation von subdomäne - Fehler 8442 / 8453

[soulseeker 13]

Hallo zusammen,

 

wir nutzen 3 child Domänen und bei einer (zum Glück wenig genutzten und mit wenigen Änderungen) ist mir kürzlich aufgefallen, dass der Exchange (der in der root Domäne liegt), Änderungen aus der child-Domäne nicht mitbekommt (wenn man z.B. einen User in eine andere OU verschiebt).

 

repadmin /syncall /force zeigt dann diesen Fehler auch an:

 

SyncAll hat folgenden Fehler ermittelt:
Fehler beim Ausstellen der Replikation: 8453 (0x2105):
    Der Replikationszugriff wurde verweigert.
    Von: af95bac4-95f0-4a88-aed1-c1014b5d14be._msdcs.mydomain.de
    An : 22b34a03-d5f3-49da-8544-6d5584134bde._msdcs.mydomain.de

 

 mit repadmin /replsum sehe ich dann

 

Quell-DSA          Größtes Delta    Fehler/gesamt %%  Fehler
mysubdc2                14m:03s    3 /  17   17  (8442) Im Replikationssystem ist ein interner Fehler aufgetreten.

 

Ursprünglich hatte ich zwei DCs in der child Domäne und nur einer davon hatte diesen Fehler angezeigt. Also habe ich die FSMO-Rollen  übergeben, diesen DC entfernt, Metadata gecleant und danach ist der Fehler auf den zweiten DC "vererbt" worden.

 

Alles, was ich dazu online finde hilft mir leider nicht wirklich weiter ... im eventlog des directory services finde ich auch sonst keine Fehler und alle Tricks mit dcdiag und repadmin helfen leider auch nicht (https://www.windowspro.de/marcel-kueppers/check-liste-tools-konsistenz-active-directory-pruefen).

 

Ich habe die Site-Links auch schon gelöscht und neu erstellt (auch manuell), DNS geprüft (alles bestens) und der AD Troubleshooter zeigt auch nur 8442 an und als Source meinen child-DC und als Ziel die jeweiligen Targets in der root und den anderen childs.

 

Was mir noch aufgefallen ist - ich kann in allen child-Domänen alle Site-Settings als jeweiliger lokaler Domadmin löschen und neu erstellen ... in der Subdomäne mit dem Fehler klappt das nur mit den eigenen Sitelinks, nicht aber mit den anderen "sie sind nicht dazu berechtigt oder das Objekt ist schreibgeschützt usw". Ich finde momentan aber noch nicht die fehlende Berechtigung (falls es eine ist).

 

8453 erscheint als Fehler ja auch, wenn ich den Befehl in einer cmd ohne "als administrator" ausführe ... aber das ist hier natürlich der Fall.

 

Hat jemand evtl. noch einen goldenen Tipp für mich? Vielen Dank vorab :)

 

VG

Marcel

 

 

 

 

bearbeitet 7. November 2019 von soulseeker

[NilsK 2.930]

Moin,

 

ein Tipp vorab: Vermutlich möchtest du die Angaben oben noch mal anonymisieren. Da steht ein Domänenname, der vermutlich Aufschluss über das Unternehmen gibt.

 

Den Rest müsste ich mir genauer ansehen, dazu fehlt mir gerade die Zeit. Da man solche Fehler nicht will und es anscheinend nicht um eine 5-Leute-Umgebung geht, würde ich an deiner Stelle umgehend den MS-Support einschalten.

 

Gruß, Nils

 

[soulseeker 13]

Hi Nils,

 

hatte ich übersehen, danke für den Hinweis.

 

Ich hätte wohl auch schon längst ein Ticket bei ms gezogen, aber das ist zum Glück eine subdomain, die keine große Rolle (mehr) spielt. Letztlich aber trotzdem unschön, einen Replikationsfehler in der Struktur zu haben, das stimmt. 

 

Die meisten Dinge aus diesem Artikel habe ich auch schon durch (DNS-Test, UAC, time, CheckSecurityError)

 

https://support.microsoft.com/en-us/help/2022387/active-directory-replication-error-8453-replication-access-was-denied

 

Viele Grüße

Marcel

 

[NilsK 2.930]

Moin,

 

na, wenn das so ist, löse die Subdomain auf ... das ist sowieso ein Konstrukt, das fast nie nützlich ist.

 

Gruß, Nils

 

[soulseeker 13]

Ein paar Versuche gebe ich mir noch ... ich betrachte das mal als Test für den Ernstfall, da wäre ich gerne vorbereitet :).

[daabm 1.348]

So als Wegweiser:

# for hex 0x2105 / decimal 8453 :
  ERROR_DS_DRA_ACCESS_DENIED                                    winerror.h     
# Replication access was denied.

Da hat entweder jemand gnadenlos mit den Rechten tief im AD gespielt, oder - mit viel Glück - es ist ein Problem mit den KDC-Kennwörtern oder dem Trust (bzw. dem Trust-Kennwort) Ich wüßte jetzt aber spontan nicht, wie man einen fehlerhaften Trust einer Child-Domain repariert - ich kann das nur bei Forest-Trusts

[soulseeker 13]

Mit den Rechten hat niemand herumgemacht (zumindest soweit mir bekannt) ... der Trust scheint laut diverser Tests auch ok zu sein.

Was mir nur noch einfällt - vor längerer Zeit gab es mal einen Storage-Ausfall und ich erinnere mich, dass dabei ein kaputter DC aus einem Snapshot-Backup wiederhergestellt wurde. Das hat natürlich zu Problemen geführt, daher hat man diesen DC danach entsorgt und einen neuen erstellt. Ich meine aber, dass danach augenscheinlich erst einmal alles ok zu sein schien.

 

Wie gesagt, in dieser Domäne passiert nicht viel ... Objekte werden dort nur ganz selten angelegt und wenn ich nicht einen User in eine andere OU verschoben und ein paar Eigenschaften angepasst hätte - wäre mir wohl noch länger nicht aufgefallen. 

[NilsK 2.930]

Moin,

 

entweder man braucht die Domäne nicht. Dann weg damit, bevor noch Fehler in anderen Teilen der Umgebung entstehen. Oder man braucht sie - dann würde ich 300 Euro für einen MS-Call ausgeben, statt abzuwarten und in Foren zu stochern.

 

Nur meine 0,02 EUR,

Nils

 

[soulseeker 13]

Ich brauche sie noch bis nächste Woche, danach mache ich sie platt ... immerhin habe ich trotzdem einiges dadurch über AD-Troubleshooting auffrischen können ... aber leider auch gemerkt, dass es bis zu einem gewissen Punkt zu riskant ist, ohne MS weiterzufummeln. Ich hoffe nur, dass ich das sobald nicht in einer wichtigen Domäne erleben darf.

 

Marcel

[testperson 1.674]

vor 18 Minuten schrieb soulseeker:

Ich hoffe nur, dass ich das sobald nicht in einer wichtigen Domäne erleben darf.

Dafür wäre es ein sehr guter Ansatz, dass sich

vor einer Stunde schrieb soulseeker:

dass dabei ein kaputter DC aus einem Snapshot-Backup wiederhergestellt wurde.

das nicht in einer wichtigen Domäne wiederholt. :P

[soulseeker 13]

Ich wollte mal meine Erlebnisse zum besten geben ... 

 

Zunächst mal hat mich der MS-Support erst Tage nach Erstellung des Tickets angerufen und hat defacto nichts gemacht, außer erfolglos versucht, ein Kommando zum FSMO-rollen bestimmen einzugeben und "winver". Ereignisse hat er sich kaum angeschaut und Logs auch nicht gezogen. Nach Tagen kam dann nach "Rücksprache mit dem Exchange"-Team der Tipp, ich soll die Subdomain einfach löschen, das hat keinen Einfluss auf Exchange.

 

Ich habe in der Zwischenzeit mal eine ungenutzte Mailbox aus dem Exchange entfernt, das hat natürlich zu dem erwarteten Ergebnis geführt - die Mailbox und der AD-User sind weg, der Eintrag steht aber noch in der EMC mit der Meldung "Objekt mit der GUID xyz wurde nicht gefunden".

 

Ich bin begeistert, vor allem weil der Support jetzt nicht mehr reagiert. Das kenne ich eigentlich anders.

 

Ich habe jetzt mal versucht, "lingering objects" zu finden, bin aber nicht sicher, ob ich repadmin richtig verwende:

 

REPADMIN /removelingeringobjects <DNS-Name des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten
Objekte befinden> /Advisory_Mode.

 

<DNS-Name des veralteten DCs>= der DC in der child-dom

<GUID eines aktuellen DCs> = einer in der root

<NC> - hier hatte ich gedacht, das wäre der DN des Users-container in der child-Domäne wo sich der Eintrag befand, das führt aber zu:

 

DsReplicaVerifyObjectsW() ist fehlgeschlagen mit Status 8440 (0x20f8):
    Der für diesen Replikationsvorgang angegebene Namenskontext ist ungültig.

[NilsK 2.930]

Moin,

 

der Namenskontext ist hier der LDAP-Name der Domäne. Siehe das letzte Beispiel von "repadmin /removelingeringobjects /?".

 

Gruß, Niös

 

[soulseeker 13]

Hmm, keine lingering objects ... aber trotzdem ein Geisterpostfach in der EMC. 

 

Gruß

Marcel

[NorbertFe 2.027]

vor 28 Minuten schrieb soulseeker:

aber trotzdem ein Geisterpostfach in der EMC

Das muss ja kein lingering object sein.

[soulseeker 13]

War halt nur meine erste Vermutung, aber es ist ja so, dass die Subdomäne nicht mehr in den GC repliziert ... d.h. alles an Änderungen in der Childdomäne kommt hier nicht mehr an. Ich lösche nun ein Postfach der Childdomäne im Exchange, der User wird in der Childdomäne gelöscht, aber diese Änderung bekommt der Exchange nicht mit. 

 

Das gleiche wird vermutlich im größeren Maßstab passieren, wenn ich die Childdomäne ganz entferne.