Replikation 2 DCs 2 Subnetze gestört

[Jim di Griz 13]

Hallo,

 

ich habe 2 DCs in 2 Subnetzen, dazwischen ist ein ISA 2004.

ping usw. funktionieren, joindom ebenfalls.

alles wunderbar, leider laesst sich der 2te dc nicht mehr aus der domain entfernen, fehler "1722, der rpc-server ist nicht verfügbar".

nachdem ich nun seit 2 wochen irgendwelche hinweise zu diesem fehler suche die anfrage ans forum:

was bedeutet diese fehlermeldung? und wie werd ich die wieder los ohne die ganze verdammte domaene abzureissen und neuaufzubauen?

[Daim 12]

Moin,

 

ich habe 2 DCs in 2 Subnetzen, dazwischen ist ein ISA 2004.

 

gibt es für diese Konstellation auch einen trifftigen Grund?

 

alles wunderbar

 

... scheinbar doch nicht.

 

leider laesst sich der 2te dc nicht mehr aus der domain entfernen

 

Dann könntest du den DC immer noch "mit Gewalt" entfernen. Dazu führst du das DCPROMO /FORCEREMOVAL aus und entfernst LOKAL die AD-Daten von dem Server. Anschließend musst du aber aber noch mit NTDSUTIL den DC aus dem AD entfernen.

 

Yusuf`s Directory - Blog - Das Active Directory gewaltsam vom DC entfernen

 

 

fehler "1722, der rpc-server ist nicht verfügbar".

 

Das kann leider an vieles liegen, ich nehme aber stark an, dass es mit dem ISA zusammenhängt.

Die DCs können sich eben nicht 100%ig erreichen. Gerade die dynamischen RPC-Ports stellen oftmals ein Problem dar.

 

http://support.microsoft.com/kb/839880/en-us

 

Du könntest die zu verwenden RPC-Ports fest vorgeben...

Lies den folgenden samt weiterführende Artikel dazu durch:

 

Yusuf`s Directory - Blog - Active Directory Replikation durch eine Firewall

 

und wie werd ich die wieder los ohne die ganze verdammte domaene abzureissen und neuaufzubauen?

 

Die Domäne neu aufsetzen musst du deswegen noch lange nicht.

Wenn nichts hilft, bringt dich das gewaltsame entfernen weiter.

Trotzdem sollte das Konzept - wenn es keinen plausiblen Grund dazu gibt - mit dem ISA dazwischen überdacht werden.

[Jim di Griz 13]

Hallo,

 

danke für die Antwort.

den triftigen Grund gibt es: Abbilden meiner alten physikalischen Domäne in einer

reinen VMWare-Umgebung.

 

Funktionieren bedeutet, das Zugriffe auf Daten ueber username/Passwort funktionieren. Das jedoch domänen so aussehen als seien sie in Ordnung bis es dann doch mal hakt ist ja nichts neues.

 

Warum abreissen? weil ich seit 2 Wochen immer dieselben Artikel zu RPC-Problemen lese ohne das sich an der Situation etwas aendern liesse.

 

Die Firewall ist inzwischen zwischen den 2 DCs völlig offen, keine Aenderung.

Auch wenn die beiden DCs im selben Subnetz sind gibt es keine erfolgreiche replikation.

 

und was soll an dem konzept mit dem isa dazwischen so anrüchig sein, ein altes physikalisches Netz das vom neuen virtuellen netz durch eine firewall getrennt ist..... wirklich nichts dolles. joindom funktionierte auch ueber die firewall.

und bitte, das ist alles mikrosoft. man sollte erwarten koennen das eine ms-firewall netzverkehr zwischen 2 ms-dcs transportieren kann OHNE das ein doktortitel noetig ist

 

Das problem ist eher einer der vielen wunderbaren reg und dns-eintraege die beim promoten angelegt werden, irgendetwas fehlt.

 

ich les die artikel einfach nochmal, teste alles nochmal, poste mal die errorausgaben so vorhanden, vielen dank soweit

[Jim di Griz 13]

DNS Problem w2k3 - Seite 3 - Forum Fachinformatiker.de

 

ist exakt mein Stand in dieser Sache:

 

die Datei NETLOGON.DNS kann nicht gelesen werden und es gibt keine NETBT-Eintraege (die Datei existiert und hat vernünftig aussehende Einträge, wurde beim Systemstart geändert)

Auch den obigen Beitrag hab ich komplett abgearbeitet, alle Fehlerbilder sind 1 zu 1 wie bei mir.

die DCs können sich pingen und gegenseitig auf ihre netzlaufwerke zugreifen.

AD-Administrationstools Zugriffe sind problemlos nach allen Seiten möglich.

 

 

Nur repliziert wird zwischen beiden nicht.

Eventid 13508 "the file replication service is having trouble......using the DNS"

[Daim 12]

den triftigen Grund gibt es: Abbilden meiner alten physikalischen Domäne in einer reinen VMWare-Umgebung.

 

Ohne auf den Rest einzugehen... was genau bedeutet das?

Hast du einen bestehenden DC mit dem VMWare Converter virtualisiert und möchtest nun das beide DCs miteinander replizieren?

Bitte genau erklären.

[Jim di Griz 13]

Ich habe einen bestehenden und seit Jahren funktionierenden DC.

 

Aus Gründen der Redundanz gibt es einen neuen 2ten DC in derselben Domäne.

Der 2te neue DC ist ein "virtueller" DC auf einem anderen Rechner (Server) in derselben Domäne. Das Netzwerk ist Host-Only (so soll es mal sein) oder eben direkt bridged im physikalischen Netz.

 

Der Fehler wie oben beschrieben tritt nur auf dem neuen DC auf, dieser hat Probleme beim Erkennen der DNS-Settings der Domäne.

Diese Probleme existieren nicht auf dem ersten, älteren DC.

 

Kurz: Die Datei netlogon.dns wird nicht in den dns-server des neuen DC integriert (sie wird nicht abgearbeitet). DNS startet zwar auf dem neuen Server und zeigt auch alle eintraege der domäne korrekt an.

Leider ist der neue Server dann nicht in der Lage, sich selbst als DC in diesen DNS-Eintraegen wiederzufinden, es ist eher ein logisches Problem als ein Netzproblem (es sei denn die Netlogon.dns datei kann nicht vom ersten älteren DC gelesen werden wenn der neue DC startet).

Die Gruppenrichtlinien werden z.B. ohne Probleme korrekt auf beiden DCs angewendet.

 

und der fehler macht mich langsam jeck weil ich seit mehreren Tagen Boardbeitraege wälze die mir zwar sagen wie der fehler aussehen kann aber leider nicht den kleinsten hinweis wie man ihn wieder loswird.

Klar ist Neuaufsetzen da kürzer, allerdings hab ich schon ein bisschen ehrgeiz inzwischen rauszufinden was da stört

[phoenixcp 10]

Nur repliziert wird zwischen beiden nicht.

Eventid 13508 "the file replication service is having trouble......using the DNS"

 

Hier schonmal geschaut? EventID.Net

 

Spricht zwar auch wieder nur alles darauf, das du die Ports auf der Firewall freischalten musst oder freie Ports für die Replikation benutzen musst. Aber da hast du ja von Daim die entsprechenden Links.

[Jim di Griz 13]

ja, eventid.net kenne ich.

was mir fehlt ist die uebersetzung der offenen ports in ms-firewall-sysntax.

da bleibt ja dann eigentlich nur DC-DC alle ports oeffnen und so sieht die firewall gerade auch aus. keine Aenderung am fehler.

 

erklaert doch alles nicht, warum das problem existiert selbst wenn beide DCs sich im selben subnetz befinden und wieso die datei netlogon.dns nicht lesbar ist (obwohl sie beim systemstart jeweils modifiziert wird)

[Daim 12]

keine Aenderung am fehler.

 

100%ig kannst du das nur behaupten, wenn beide DCs miteinander kommunizieren können, ohne einen ISA dazwischen zu haben.

Erst dann kann man sich sicher sein, dass es nichts mit dem ISA zu tun hat.

 

Du könntest dich auch mal mit diesen beiden Tools auseinandersetzen um zu kontrollieren, ob nicht doch etwas geblockt wird.

 

Download details: Port Reporter (PortRptr.exe)

New features and functionality in PortQry version 2.0

 

erklaert doch alles nicht, warum das problem existiert selbst wenn beide DCs sich im selben subnetz befinden und wieso die datei netlogon.dns nicht lesbar ist (obwohl sie beim systemstart jeweils modifiziert wird)

 

Nö, dass mit Sicherheit nicht. Deinstalliere doch mal den Virenscanner auf dem DC (deaktivieren reicht nicht und führe anschließend in der Kommandozeile ein "net stop netlogon & net start netlogn" durch und kontrolleire was passiert.

[Jim di Griz 13]

ajo, danke für die tools, mit denen ich mich dann in den nexten tagen auseinandersetze.

sehr schoenes portlogging bisher, es gibt immer mal wieder verbindungen auf allen möglichen ports zwischen den DCs (auch auf port 135 z.B.)

 

 

ich setz denn alles mal aufs selbe subnetz

und les mich satt an den kruden portbeschreibungen von ms

[Velius 10]

Versteh das Problem nicht - ISA 2004 bringt schon einen respektablen Monitor mit, warum nicht den Benutzen? Oder liegt es da am Verständnis?

 

Ausserdem, RPC-Call == Request auf Port 135 und Ausshandeln der entsprechenden Caller Funktion entsprechend seiner GUID auf einem Port > 1024. Aber das sollte ja kein Problem sein 'wenn' alles offen ist zwischen den beiden. Fehlkonfigurationen sind aber nicht ausgeschlossen.

 

 

cheers

Velius

 

 

P.S.: Wie sieht die DNS Reiehnfolge deines DCs in den Eigenschaften der NIC aus? Sich selbst zuerst, anderen zuerst oder was? More details please...

[Jim di Griz 13]

lol, nein es liegt nicht am verstaendnis... und ja, schoenes monitoring, wie geschrieben lief der joindom auch ueber die isa2004-firewall, mir ist nicht ganz klar warum die replikatiuon dann scheitern sollte

oder doch, ich verstehe z.b. nicht, warum rpc-verkehr von dc1 auf dc2 als rpc erkannt wird und analog der regel durchgeroutet wird waehrend der verkehr von dc2 zu dc1 auf port 135 als "unidentifizierter traffic" geblockt wird.

 

mir ist ganz grundsaetzlich nicht klar, warum alle naselang die alten netbios-ports mit den lustigsten verrenkungen benoetigt werden obwohl doch alles im schoenen neuen windows ldap und tcp/ip-basiert ist.

 

ich weiss jedoch imzwischen warum ich nen 2ten dc wollte, der alte ist grad heut mit der meldung ausgefallen das windows die activierung nicht ueberprüfen koenne....nach 1 jahr problemlosem betrieb.

und wie schoen, das dann nicht mal mehr ein reparaturlogin moeglich ist (im abgesicherten modus ...lol)

 

interessant war auch, das das tolle porttool mit dem einen dc im anderen subnetz feststellt, das der port 135 gefiltert wird. als beide im selben subnetz waren lief die replikation plötzlich, obwohl der portreporter meldete, das kein rpc-port auf keinem servern offen sei. ohne firewall und virenscanner.

 

aber gut, aktuell habe ich einen halben dc der neu aufgesetzt werden muss dank einer ueberraschend fehlenden aktivierung und der daher noetigen emergency-reparatur und einen 2ten dc der so nuetzlich ist wie ein kropf.

 

was bin ich froh das ich so einen haufen muell nicht produktiv im einsatz habe, danke für die hilfe soweit, neu aufsetzen den dreck ist wirklich um laengen schneller als sich um sowas noch lange gedanken zu machen

[Velius 10]

oder doch, ich verstehe z.b. nicht, warum rpc-verkehr von dc1 auf dc2 als rpc erkannt wird und analog der regel durchgeroutet wird waehrend der verkehr von dc2 zu dc1 auf port 135 als "unidentifizierter traffic" geblockt wird.

 

Scheint grundsätzlich ne Macke mit DC2 zu sein - neu machen scheint mir da nicht unsinnig.

 

mir ist ganz grundsaetzlich nicht klar, warum alle naselang die alten netbios-ports mit den lustigsten verrenkungen benoetigt werden obwohl doch alles im schoenen neuen windows ldap und tcp/ip-basiert ist.

 

Yup, das sieht man. Diese 'Netbios-Ports' sind NetBios over TCPIP oder kurz NBT. Scheinbar bist du dem leider immer noch vorliegenden Mythos auf den Leim gegangen, NetBUI hätte auch nur entfernt was mit NBT zu tun. Wie auch immer, los wirst du die definitv nur dann, wenn NBT auf der Netzwerkkarte deaktiviert wird, ansonsten wird es zur abwärtskompatibilität weiter verwendet.

[Jim di Griz 13]

ich weiss nicht ob ich da nem mythos auf den leim gegangen bin.

vernünftig monitoren laesst sich das ganze nur wenn von vornherein alles was mit netbios beginnt (session name service und datagram) geblockt wird, da die drei selbst ohne effektiven datenaustausch jedes log zuspammen.

 

ich sehs eher so, das die altlasten eigentlich schon laengst weg sein sollten, komischerweise kann jedoch windows ohne netbios plötzlich nicht mehr richtig.

 

anyway, vielen dank für die hilfe, das mit der fehlenden aktivierung war wirklich gestern das sahnehäubchen.... für so einen Mist zahl ich natürlich gern die lizenzgebühren würg

[Jim di Griz 13]

hm, ok, also portqry bringt mir inzwischen von jedem server die am rpc-locator anliegenden eintraege.

Im selben Subnetz kommt es zu spontaner replikation.

 

am dynamischen Zuordnen knusper ich noch ein wenig rum, die feste zuordnung einzelner ports funktioniert schon einmal, die empfehlung ueber VPN zu tunneln find ich sehr ernuechternd.

ehrlich gesagt so wahnsinnig ungewöhnlich finde ich das ganze Konstrukt (Firewall zwischen Internem Netz und Perimeternetz) nun auch nicht, ich quäl mich mal weiter durch die recht umfangreiche Doku für die ich mich nochmals bedanken möchte.

 

hätte nur noch die Frage ob ich korrekt verstanden habe das sich nur fest vergebne Ports ueber die Firewall erreichen lassen und ob es notwendig ist die Server im ISA zu publishen?