Active Directory-Replikationsfehler 1753: Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar.

  • Artikel

In diesem Artikel wird ein Problem beschrieben, bei dem Active Directory-Replikationen mit Win32-Fehler 1753 fehlschlagen: "Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar."

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 2089874

Private Benutzer: Dieser Artikel richtet sich nur an Technische Supportmitarbeiter und IT-Experten. Wenn Sie Hilfe bei einem Problem benötigen, wenden Sie sich an die Microsoft Community.

Symptome

In diesem Artikel werden Symptome, Ursachen und Lösungsschritte für AD-Vorgänge beschrieben, die mit win32-Fehler 1753 fehlschlagen: "Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar."

  1. DCDIAG meldet, dass der Konnektivitätstest, der Active Directory-Replikationstest oder der KnowsOfRoleHolders-Test mit dem Fehler 1753 fehlgeschlagen ist: "Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar."

    Testserver: <Name des Standortdomänencontrollers><>
    Test wird gestartet: Konnektivität
    *Active Directory LDAP Services Check * Active Directory RPC Services Check
    [<DC-Name>] Fehler bei DsBindWithSpnEx() mit Fehler 1753,
    In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.
    Drucken der erweiterten Rpc-Fehlerinformationen:
    Fehlereintrag 1, ProcessID ist <Prozess-ID> (DcDiag)
    Systemzeit ist: <Datum><Uhrzeit>
    Generierende Komponente ist 2 (RPC-Runtime) Status 1753: Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar. Erkennungsort ist 500 NumberOfParameters ist 4
    Unicode-Zeichenfolge: ncacn_ip_tcp
    Unicode-Zeichenfolge: <QUELL-DC-Objekt-GUID>._msdcs.contoso.com
    Long val: -481213899
    Long Val: 65537
    Fehlereintrag 2, ProcessID ist 700 (DcDiag)
    Systemzeit ist: <Datum><Uhrzeit>
    Generierende Komponente ist 2 (RPC-Runtime)
    Status 1753: Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar.
    NumberOfParameters ist 1
    Unicode-Zeichenfolge: 1025

    [Replikationsprüfung,<DC-Name>] Fehler beim letzten Replikationsversuch:
    Vom <Quelldomänencontroller> zum <Zieldomänencontroller>
    Benennungskontext: <DN-Pfad der Verzeichnispartition>
    Bei der Replikation wurde ein Fehler (1753) generiert:
    Es sind keine weiteren Endpunkte über die Endpunktzuordnung verfügbar.
    Der Fehler ist zum Zeitpunkt des <Datums><> aufgetreten.
    Der letzte Erfolg ist zum <Zeitpunkt des Datums><> aufgetreten.
    Seit dem letzten Erfolg sind drei Fehler aufgetreten.
    Der Name> des Verzeichnisses auf dem <DC befindet sich im Prozess.
    des Startens oder Herunterfahrens, und ist nicht verfügbar.
    Vergewissern Sie sich, dass der Computer während des Startvorgangs nicht aufgehängt wird.

  2. REPADMIN.EXE meldet, dass der Replikationsversuch mit status 1753 fehlgeschlagen ist.

    REPADMIN-Befehle, die häufig die 1753-status enthalten, sind jedoch nicht auf Folgendes beschränkt:

    • REPADMIN /REPLSUM
    • REPADMIN /SHOWREPL
    • REPADMIN /SHOWREPS
    • REPADMIN /SYNCALL

    Die folgende Beispielausgabe von REPADMIN /SHOWREPS zeigt, dass bei der eingehenden Replikation von CONTOSO-DC2 nach CONTOSO-DC1 der Fehler "Replikationszugriff wurde verweigert" fehlschlägt:

    Default-First-Site-Name\CONTOSO-DC1
    DSA-Optionen: IS_GC
    Websiteoptionen: (keine)
    DSA-Objekt-GUID:
    DSA-Aufruf-ID:

    DC=contoso,DC=com
    Default-First-Site-Name\CONTOSO-DC2 über RPC
    DSA-Objekt-GUID:
    Fehler beim letzten Versuch @ <Datum></ Uhrzeit> , Ergebnis 1753 (0x6d9):
    Es sind keine weiteren Endpunkte über die Endpunktzuordnung verfügbar.
    <Anzahl> aufeinander folgender Fehler.
    Letzter Erfolg @ <Datum><uhrzeit>.

  3. Der Befehl "Replikationstopologie überprüfen" in Active Directory-Standorte und -Dienste gibt "es sind keine Endpunkte mehr über die Endpunktzuordnung verfügbar" zurück.

    Wenn Sie mit der rechten Maustaste auf das Verbindungsobjekt von einem Quelldomänencontroller klicken und "Replikationstopologie überprüfen" auswählen, tritt ein Fehler auf: "Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar. Die Fehlermeldung auf dem Bildschirm wird unten angezeigt:

    Dialogtiteltext: Überprüfen der Replikationstopologie
    Text der Dialognachricht:

    Der folgende Fehler ist beim Versuch, den Domänencontroller zu kontaktieren, aufgetreten: Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar.

    OK

  4. Der Befehl "Jetzt replizieren" in Active Directory-Standorte und -Dienste gibt "es sind keine Endpunkte mehr über die Endpunktzuordnung verfügbar" zurück.

    Wenn Sie mit der rechten Maustaste auf das Verbindungsobjekt von einem Quelldomänencontroller klicken und "Jetzt replizieren" auswählen, tritt ein Fehler auf: "Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar. Die Fehlermeldung auf dem Bildschirm wird unten angezeigt:

    Dialogtiteltext: Jetzt replizieren

    Dialogmeldungstext: Der folgende Fehler ist beim Versuch aufgetreten, den Namen der Namenskontextverzeichnispartition <> vom Domänencontroller-Quell-Domänencontroller><mit dem Domänencontroller-Zieldomänencontroller <>zu synchronisieren: Es sind keine weiteren Endpunkte in der Endpunktzuordnung verfügbar.

    Der Vorgang wird nicht fortgesetzt.

    Schaltflächen im Dialogfeld: OK

  5. NTDS Knowledge Consistency Checker (KCC), NTDS General oder Microsoft-Windows-ActiveDirectory_DomainService-Ereignisse mit dem 1753-status werden im Verzeichnisdienstereignisprotokoll protokolliert.

    Active Directory-Ereignisse, die häufig die 1753-status enthalten, sind jedoch nicht beschränkt auf:

    Ereignisquelle Ereignis-ID Ereigniszeichenfolge
    NTDS Allgemein 1655 Active Directory hat versucht, mit dem folgenden globalen Katalog zu kommunizieren, und die Versuche waren nicht erfolgreich.
    NTDS KCC 1925 Fehler beim Versuch, einen Replikationslink für die folgende beschreibbare Verzeichnispartition einzurichten.
    NTDS KCC 1265 Ein Versuch der Wissenskonsistenzprüfung (Knowledge Consistency Checker, KCC), eine Replikationsvereinbarung für die folgende Verzeichnispartition und den folgenden Quelldomänencontroller hinzuzufügen, ist fehlgeschlagen.

Ursache

Das folgende Diagramm zeigt den RPC-Workflow (Remote Procedure Call). Der Workflow beginnt mit der Registrierung der Serveranwendung beim RPC Endpoint Mapper (EPM) in Schritt 1. Sie endet mit der Übergabe von Daten vom RPC-Client an die Clientanwendung in Schritt 7.

Screenshot des RPC-Workflowdiagramms mit den Details von Schritt 1 bis Schritt 7

Die Schritte 1 bis 7 sind den folgenden Vorgängen zugeordnet:

  1. Die Server-App registriert ihre Endpunkte beim RPC Endpoint Mapper (EPM).
  2. Der Client führt einen RPC-Aufruf im Namen eines Benutzers, eines Betriebssystems oder eines von der Anwendung initiierten Vorgangs aus.
  3. Clientseitiger RPC kontaktiert den EPM der Zielcomputer und fordert den Endpunkt auf, um den Clientaufruf abzuschließen.
  4. Der EPM des Servercomputers antwortet mit einem Endpunkt.
  5. Clientseitige RPC-Kontakte mit der Server-App.
  6. Die Server-App führt den Aufruf aus und gibt das Ergebnis an den CLIENT-RPC zurück.
  7. Clientseitige RPC übergibt das Ergebnis zurück an die Client-App.

Fehler 1753 wird durch einen Fehler zwischen den Schritten 3 und 4 generiert. Insbesondere bedeutet Fehler 1753, dass der RPC-Client (Ziel-DC) den RPC-Server (Quell-DC) über Port 135 kontaktieren konnte, aber der EPM auf dem RPC-Server (Quell-DC) konnte die interessante RPC-Anwendung nicht finden und hat den serverseitigen Fehler 1753 zurückgegeben. Der Fehler gibt an, dass der RPC-Client (Ziel-DC) die serverseitige Fehlerantwort vom RPC-Server (AD-Replikationsquell-DC) über das Netzwerk empfangen hat.

Zu den spezifischen Grundursachen für den Fehler 1753 gehören:

  1. Die Server-App wurde nie gestartet. Das heißt, Schritt 1 im Diagramm "Weitere Informationen" wurde nie versucht.
  2. Die Server-App wurde gestartet, aber während der Initialisierung ist ein Fehler aufgetreten. Durch den Fehler wurde verhindert, dass die Registrierung beim RPC-Endpunktzuordnungsserver erfolgen kann. Das heißt, Schritt 1 im Diagramm "Weitere Informationen" wurde versucht, aber fehlgeschlagen.
  3. Die Server-App wurde gestartet, ist aber später gestorben. Das heißt, Schritt 1 im Diagramm "Weitere Informationen" wurde erfolgreich abgeschlossen. Dies wurde später rückgängig machen, weil der Server gestorben ist.
  4. Die Registrierung ihrer Endpunkte wurde von der Server-App manuell aufgehoben (ähnlich wie 3, aber absichtlich. Nicht wahrscheinlich, aber aus Gründen der Vollständigkeit enthalten.)
  5. Der RPC-Client (Ziel-DC) hat einen anderen RPC-Server als den vorgesehenen kontaktiert. Dies liegt an einem Name-to-IP-Zuordnungsfehler in der DNS-, WINS- oder host/lmhosts-Datei.

Fehler 1753 wird NICHT verursacht durch:

  • fehlende Netzwerkkonnektivität zwischen dem RPC-Client (Ziel-DC) und dem RPC-Server (Quell-DC) über Port 135.
  • fehlende Netzwerkkonnektivität zwischen dem RPC-Server (Quell-DC) über Port 135 und dem RPC-Client (Ziel-DC) über den kurzlebigen Port.
  • ein Kennwortkonflikt oder die Unfähigkeit des Quelldomänencontrollers, ein kerberos-verschlüsseltes Paket zu entschlüsseln.

Lösung

Vergewissern Sie sich, dass der Dienst, der seinen Dienst bei der Endpunktzuordnung registriert, gestartet wurde.

  • Für Windows 2000- und Windows Server 2003-DCs: Stellen Sie sicher, dass der Quelldomänencontroller im normalen Modus gestartet wird.
  • Für Windows Server 2008 oder Windows Server 2008 R2: Starten Sie in der Konsole des Quelldomänencontrollers den Dienst-Manager (services.msc). Vergewissern Sie sich, dass der Active Directory-Dienst ausgeführt wird. Active Directory wird als "Active Directory Domain Services" angezeigt.

Überprüfen Sie, ob der RPC-Client (Ziel-DC) mit dem vorgesehenen RPC-Server (Quell-DC) verbunden ist.

Alle DCs in einer allgemeinen Active Directory-Gesamtstruktur registrieren einen GUIDED DC CNAME-Eintrag im _msdcs.<DNS-Zone der Gesamtstrukturstammdomäne> , unabhängig davon, in welcher Domäne sie sich innerhalb der Gesamtstruktur befinden. Der geführte DC-CNAME-Eintrag wird von der objectGUID jedes DCs NTDS Settings-Objekts abgeleitet.

Bei replikationsbasierten Vorgängen fragt ein Zieldomänencontroller DNS für den GEFÜHRTen CNAME-Eintrag der Quell-DCs ab. Der CNAME-Eintrag enthält den vollqualifizierten Computernamen des Quelldomänencontrollers. Dieser Name wird verwendet, um die IP-Adresse der Quell-DCs wie folgt abzuleiten:

  • DNS-Clientcachesuche
  • Host-/LMHost-Dateisuche
  • Host A/AAAA-Eintrag in DNS oder WINS

Veraltete NTDS-Einstellungsobjekte und ungültige Namen zu IP-Zuordnungen in DNS-, WINS-, Host- und LMHOST-Dateien können dazu führen, dass der RPC-Client (Ziel-DC) eine Verbindung mit dem falschen RPC-Server (Quell-DC) herstellt. Darüber hinaus kann der fehlerhafte Name zur IP-Zuordnung dazu führen, dass der RPC-Client (Ziel-DC) eine Verbindung mit einem Computer herstellt, auf dem nicht einmal die interessante RPC-Serveranwendung (in diesem Fall die Active Directory-Rolle) installiert ist. Beispielsweise enthält ein veralteter Hostdatensatz für DC2 die IP-Adresse von DC3 oder eines Mitgliedscomputers.

Stellen Sie sicher, dass die folgenden GUIDs übereinstimmen:

  • Die Objekt-GUID für den Quelldomänencontroller, der in der Kopie des Zieldomänencontrollers von Active Directory vorhanden ist
  • die GUID des Quelldomänencontrollerobjekts, die in der Kopie des Quelldomänencontrollers von Active Directory gespeichert ist.

Wenn eine Diskrepanz vorliegt, verwenden Sie repadmin /showobjmeta für das NTDS-Einstellungsobjekt, um zu sehen, welches objekt der letzten Heraufstufung des Quell-DC entspricht. Vergleichen Sie die folgenden Datumsstempel:

  • Das NTDS-Einstellungsobjekt erstellt das Datum aus /showobjmeta.
  • Das Datum der letzten Heraufstufung in den Quell-DCs dcpromo.log Datei.

Möglicherweise müssen Sie das Datum der letzten Änderung/Erstellung des DCPROMO verwenden. LOG-Datei selbst. Wenn die Objekt-GUIDs nicht identisch sind, verfügt der Ziel-DC möglicherweise über ein veraltetes NTDS-Einstellungsobjekt für den Quelldomänencontroller, dessen CNAME-Eintrag auf einen Hostdatensatz mit einem ungültigen Namen zu IP-Zuordnung verweist.

Führen Sie auf dem Zieldomänencontroller aus IPCONFIG /ALL , um zu ermitteln, welche DNS-Server der Zieldomänencontroller für die Namensauflösung verwendet:

c:\>ipconfig /all

Führen Sie NSLOOKUP auf dem Zieldomänencontroller für den vollqualifizierten DOMÄNENCONTROLLER-DOMÄNENCONTROLLER-CNAME-Eintrag aus:

c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination DCs primary DNS Server IP >
c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination DCs secondary DNS Server IP>

Vergewissern Sie sich, dass die von NSLOOKUP "besitzt" zurückgegebene IP-Adresse den Hostnamen/die Sicherheitsidentität des Quelldomänencontrollers besitzt.

a) C:\\>NBTSTAT -A \\<IP address _returned_ by NSLOOKUP in the step above>

ODER

b) Melden Sie sich bei der Konsole des Quelldomänencontrollers an, führen Sie IPCONFIG an der CMD-Eingabeaufforderung aus, und überprüfen Sie, ob der Quelldomänencontroller die IP-Adresse besitzt, die vom obigen NSLOOKUP-Befehl zurückgegeben wurde.

Überprüfen Sie im DNS auf veraltete/doppelte Host-zu-IP-Zuordnungen.

NSLOOKUP -type=hostname \<single label hostname of source DC> \<primary DNS Server IP on destination DC>
NSLOOKUP -type=hostname \<single label hostname of source DC> \<secondary DNS Server IP on destination DC>

NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \<primary DNS Server IP on destination DC>
NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \<secondary DNS Server IP on dest. DC>

Wenn in Hosteinträgen ungültige IP-Adressen vorhanden sind, untersuchen Sie, ob dns scavenging aktiviert und ordnungsgemäß konfiguriert ist.

Wenn die obigen Tests oder eine Netzwerkablaufverfolgung keine Namensabfrage anzeigen, die eine ungültige IP-Adresse zurückgibt, sollten Sie veraltete Einträge in HOST-Dateien, LMHOSTS-Dateien und WINS-Servern berücksichtigen. DNS-Server können auch für die Wins-Fallbacknamenauflösung konfiguriert werden.

Vergewissern Sie sich, dass die Serveranwendung (Active Directory usw.) bei der Endpunktzuordnung auf dem RPC-Server (Quell-DC) registriert wurde.

Active Directory verwendet eine Mischung aus bekannten und dynamisch registrierten Ports. Zu den bekannten Ports und Protokollen, die von Active Directory-Domänencontrollern verwendet werden, gehören:

RPC-Serveranwendung Port TCP UDP Kommentare
DNS-Server 53 √ √
Kerberos 88 √ √
LDAP-Server 389 √ √
Microsoft-DS 445 √ √
LDAP SSL 636 √ √
Globaler Katalogserver 3268 √
Globaler Katalogserver 3269 √

Bekannte Ports sind NICHT bei der Endpunktzuordnung registriert.

Active Directory und andere Anwendungen registrieren auch Dienste, die dynamisch zugewiesene Ports im rpc-Kurzportbereich empfangen. Solchen RPC-Serveranwendungen werden dynamisch TCP-Ports zwischen 1024 und 5000 auf Windows 2000- und Windows Server 2003-Computern zugewiesen. Ihnen werden dynamisch TCP-Ports zwischen 49152 und 65535 auf Windows Server 2008- und Windows Server 2008 R2-Computern zugewiesen. Der von der Replikation verwendete RPC-Port kann in der Registrierung hartcodiert werden, indem die schritte unter MSKB 224196 dokumentiert sind. Active Directory registriert sich weiterhin beim EPM, wenn es für die Verwendung eines hartcodierten Ports konfiguriert ist.

Vergewissern Sie sich, dass sich die interessante RPC-Serveranwendung bei der RPC-Endpunktzuordnung auf dem RPC-Server registriert hat (im Fall der AD-Replikation der Quelldomänencontroller).

Es gibt viele Möglichkeiten, diese Aufgabe zu erledigen. Eine besteht darin, PORTQRY über eine privilegierte Administratoreingabeaufforderung auf der Konsole des Quelldomänencontrollers zu installieren und auszuführen:

c:\>portquery -n \<source DC> -e 135 >file.txt

Notieren Sie sich in der portqry Ausgabe die Portnummern, die dynamisch von der "MS NT Directory DRS Interface" (UUID = 351...) für das ncacn_ip_tcp-Protokoll registriert wurden. Der folgende Codeausschnitt zeigt eine Beispielausgabe eines Windows Server 2008 R2-DC und das von Active Directory verwendete UUID/Protokollpaar fett hervorgehoben:

UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_np:CONTOSO-DC01[\pipe\lsass]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_np:CONTOSO-DC01[\PIPE\protected_storage]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_ip_tcp:CONTOSO-DC01[49156]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_http:CONTOSO-DC01[49157]
UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_http:CONTOSO-DC01[6004]

Andere Ursachen

  1. Vergewissern Sie sich, dass der Quelldomänencontroller im normalen Modus gestartet wird. Überprüfen Sie außerdem, ob die Betriebssystem- und DC-Rolle auf dem Quelldomänencontroller vollständig gestartet wurden.

  2. Vergewissern Sie sich, dass der Active Directory-Domäne-Dienst ausgeführt wird. Wenn der Dienst derzeit beendet oder nicht mit Standardstartwerten konfiguriert wurde, setzen Sie die Standardstartwerte zurück. Starten Sie den geänderten Domänencontroller neu, und wiederholen Sie den Vorgang.

  3. Überprüfen Sie, ob der Startwert und der Dienst status für DEN RPC-Dienst und RPC-Locator für die Betriebssystemversion des RPC-Clients (Ziel-DC) und des RPC-Servers (Quell-DC) korrekt sind. Wenn der Dienst derzeit beendet oder nicht mit Standardstartwerten konfiguriert wurde, setzen Sie die Standardstartwerte zurück. Starten Sie den geänderten Domänencontroller neu, und wiederholen Sie den Vorgang.

    Stellen Sie außerdem sicher, dass der Dienstkontext den Standardeinstellungen entspricht.

    Windows 2000 Startwert Dienststatus
    Remoteprozeduraufruf (Remote Procedure Call, RPC) Automatisch Begann
    RPC-Locator Automatisch Begann
    Windows Server 2003, Server 2008, Server 2008 R2 Startwert Dienststatus
    Remoteprozeduraufruf (Remote Procedure Call, RPC) Automatisch Begann
    RPC-Locator Manuell NULL oder Beendet

  4. Stellen Sie sicher, dass die Größe des dynamischen Portbereichs nicht eingeschränkt wurde. Die Windows Server 2008- und Windows Server 2008 R2 NETSH-Syntax zum Aufzählen des RPC-Portbereichs ist unten dargestellt:

    >netsh int ipv4 show dynamicport tcp
>netsh int ipv4 show dynamicport udp
>netsh int ipv6 show dynamicport tcp
>netsh int ipv6 show dynamicport udp

  5. Lesen Sie die KB-224196. Stellen Sie sicher, dass der hartcodierte Port innerhalb des kurzlebigen Portbereichs für die Betriebssystemversion des Quelldomänencontrollers liegt.

  6. Vergewissern Sie sich, dass der Schlüssel ClientProtocols unter HKLM\Software\Microsoft\Rpc vorhanden ist und die folgenden fünf Standardwerte enthält:

    ncacn_http REG_SZ rpcrt4.dll
ncacn_ip_tcp REG_SZ rpcrt4.dll
ncacn_nb_tcp REG_SZ rpcrt4.dll
ncacn_np REG_SZ rpcrt4.dll
ncacn_ip_udp REG_SZ rpcrt4.dll

Weitere Informationen

Beispiel für einen fehlerhaften Namen zur IP-Zuordnung, der den RPC-Fehler 1753 im Vergleich zu -2146893022 verursacht: Der Zielprinzipalname ist falsch.

Die contoso.com Domäne besteht aus \\DC1 und \\DC2 mit den IP-Adressen x.x.1.1 und x.x.1.2. Die Hosteinträge "A" / "AAAA" für \\DC2 werden ordnungsgemäß auf allen DNS-Servern registriert, die für \\DC1 konfiguriert sind. Darüber hinaus enthält die HOSTS-Datei auf \\DC1 den vollqualifizierten Hostnamen von DC2 zur IP-Adresse x.x.1.2. Später ändert sich die IP-Adresse von DC2 von X.X.1.2 in X.X.1.3, und ein neuer Mitgliedscomputer wird der Domäne mit der IP-Adresse x.x.1.2 hinzugefügt. Ad-Replikationsversuche, die durch den Befehl "Jetzt replizieren" im Snap-In "Active Directory-Standorte und -Dienste" ausgelöst werden, schlägt mit dem Fehler 1753 fehl. Die Ablaufverfolgung ist unten dargestellt:

F# SRC DEST-Vorgang
1 x.x.1.1 x.x.1.2 ARP:Request, x.x.1.1 fragt nach x.x.1.2
2 x.x.1.2 x.x.1.1 ARP:Response, x.x.1.2 bei 00-13-72-28-C8-5E
3 x.x.x.1.1 x.1.2 TCP:Flags=...... S., SrcPort=50206, DstPort=DCE-Endpunktauflösung(135)
4 x.x.x.1.2 x.x.1.1 ARP:Request, x.x.1.2 fragt nach x.x.x.1.1
5 x.x.1.1 x.x.1.2 ARP:Response, x.x.1.1 bei 00-15-5D-42-2E-00
6 x.x.x.1.2 x.x.1.1 TCP:Flags=... Eine.. S., SrcPort=DCE-Endpunktauflösung(135)
7 x.x.x.1.1 x.1.2 TCP:Flags=... A...., SrcPort=50206, DstPort=DCE-Endpunktauflösung(135)
8 x.x.1.1 x.x.1.2 MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
9 x.x.x.1.2 x.x.1.1 MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0x5E68 Xmit=0x16D0 Recv=0x16D0
10 x.x.1.1 x.x.1.2 EPM:Anforderung: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2} [DCE-Endpunktauflösung(135)]
11 x.x.x.1.2 x.x.1.1 EPM:Response: ept_map: 0x16C9A0D6 - EP_S_NOT_REGISTERED

Bei Frame 10 fragt der Ziel-DC die Endpunktzuordnung der Quell-DCs über Port 135 für die Active Directory-Replikationsdienstklasse UUID {E351...} ab.

In Frame 11 hostt der Quell-DC, in diesem Fall ein Mitgliedscomputer, die DC-Rolle noch nicht. Daher wurde das {E351...} nicht registriert. UUID für den Replikationsdienst mit seinem lokalen EPM. Der Quelldomänencontroller antwortet mit einem symbolischen Fehler EP_S_NOT_REGISTERED. Dieser Fehler wird dem Dezimalfehler 1753, dem Hexadezimalfehler 0x6d9 und dem benutzerfreundlichen Fehler "es sind keine endpunkten mehr in der Endpunktzuordnung verfügbar" zugeordnet.

Später wird der Mitgliedscomputer mit der IP-Adresse x.x.1.2 als "MayberryDC"-Replikat in der contoso.com Domäne heraufgestuft. Auch hier wird der Befehl "jetzt replizieren" verwendet, um die Replikation auszulösen, aber dieses Mal schlägt ein Fehler mit dem Fehler "Der Zielprinzipalname ist falsch" fehl. Der Computer, dessen NIC die IP-Adresse x.x.1.2 besitzt, ist ein Domänencontroller. Er wird derzeit im normalen Modus gestartet und hat die {E351...}-Replikationsdienst-UUID beim lokalen EPM registriert. Es besitzt jedoch nicht den Namen/die Sicherheitsidentität von DC2 und kann die Kerberos-Anforderung nicht von DC1 entschlüsseln. Daher schlägt die Anforderung mit dem Fehler "Der Zielprinzipalname ist falsch." fehl. Dieser Fehler wird dem Dezimalfehler -2146893022 zugeordnet, hexadezimaler Fehler 0x80090322.

Solche ungültigen Host-to-IP-Zuordnungen können durch veraltete Einträge in Host-/lmhost-Dateien, Host A/AAAA-Registrierungen in DNS oder WINS verursacht werden.

Zusammenfassung:

  • Beispiel 1 ist aufgrund einer ungültigen Host-zu-IP-Zuordnung fehlgeschlagen (in diesem Fall in der HOST-Datei). Dadurch wurde der Zieldomänencontroller in einen "Quelldomänencontroller" aufgelöst, auf dem der AD-Dienst nicht ausgeführt (oder sogar installiert wurde). Der Replikations-SPN war also noch nicht registriert, und der Quell-Domänencontroller hat den Fehler 1753 zurückgegeben.
  • Im zweiten Fall hat eine ungültige Host-zu-IP-Zuordnung (wiederum in der HOST-Datei) dazu geführt, dass der Zieldomänencontroller eine Verbindung mit einem Domänencontroller herstellt, der den {E351...}-Replikations-SPN registriert hatte. Diese Quelle hatte jedoch einen anderen Hostnamen und eine andere Sicherheitsidentität als der beabsichtigte Quelldomänencontroller, sodass die Versuche mit dem Fehler -2146893022 fehlgeschlagen sind: Der Zielprinzipalname ist falsch.

Datensammlung

Wenn Sie Unterstützung vom Microsoft-Support benötigen, empfehlen wir Ihnen, die Informationen zu sammeln, indem Sie die unter Sammeln von Informationen mithilfe von TSS für Active Directory-Replikationsprobleme beschriebenen Schritte ausführen.

Verwandte Inhalte