robotroonie

Wie

schon wieder

Der Replikationsfehler ist permanent seit ein paar Wochen da.

Win-Installation läuft etwa seit einem halben Jahr.

dcpromo mir Herunter-/Heraufstufen und ggf. Herausnehmen aus der Domain wären meine vorherigen Versuche. Hat aber nichts mehr mit minimalinvasiv zu tun.

Hmm; irgendwie immer rätselhafter.

Replikationsfehler 13508 vom DC W-B zu allen anderen Replikationspartnern finden sich weiter im Log.

Replmon sagt aber an allen Stellen: The last replication attempt was successful.

Gebe ich dem Client im Netz W-B manuelle IP-Kfg, mit lediglich DC W-B als DNS und Wins, funktioniert beides nicht (Wins-Forward- und Reverse-Lookup gemäss Microsoft Corporation )

Nur die Abdeckung ist bescheiden

Wenn umts vorhanden, ist dies schon aufgrund der Geschwindigkeit die bessere Wahl.

Abgesehen davon könnte die Hälfte ja schon vorhanden sein (Flat+Router Haupthaus). Router aber ev. ohne ISDN-Option.

Das Szenario wurde früher auch immer für LCRs vorgeschlagen (vom handy daheim anrufen; dort über LCR raus). Damit sich das lohnt, muss man schon viel telefonieren (umStromkosten lcr-pc rauszuholen). Außerdem sind die Tarife ja inzwischen sehr niedrig.

Im obigen Szenario dürfte es mit geringeren Stromkosten funzen (2* Router).

Erforderlich: Router ISDN WE-Haus, Router Haupthaus (DSL, ISDN), DSL-Flat Haupthaus, Festnetzflat WE-Haus

Das dürfte nicht funktionieren.

Vor rund 10 Jahren gab es noch vereinzelt Provider, die eine normale Festnetznummer zur Einwahl nutzten. Gibt es jetzt vermutlich nicht mehr.

Habe damals über Modem Aktions-Wochenenden genutzt (600mb-Download am WE; auch Telefonate über hottelephone.com mit Ausland - alles gratis über Call-by-Call-Vorwahl).

Bei Lancom kann ich nur sagen, dass der Support vor llem in Bezug auf Firmware recht gut ist. Gibt oft neue Releases; häufig mit zusätzlichen Funktionen.

Vielleicht nicht unbedingt für den 800, aber z.B. beim 1721.

die anderen Dienste laufen

wie im Eingangspost erwähnt, gab es Probleme mit DHCP, die aber behoben sind

Die ipconfig /all-Daten sind schon realitätsnah.

Der Netzaufbau ist nun mal etwas komplexer - ich hatte versucht, den im Eingangspost hinreichend zu erläutern.

Tatsache ist: der DNS W-B funktioniert nur, wenn man diesen auf sich selbst abfragt. Von allen Clients aus nicht.

Nur dieser Satz bezieht sich auf Auflösung über DNS W-B (deswegen steht das ja auch im Satz).

Versuch, dies etwas verständlicher zu machen

Mit dem FQDN geht nslookup auch.

bezieht sich auf nslookup vom Client (Server I als DNS)

dies bezog sich auf dies in Post 11

Wie zu vermuten: ist der Server am Standort I eingetragen, funktioniert es korrekt (sonst läuft es ja auch über ihn, wobei er aber als sekundärer DNS zum Zug kommt).

Gibt man den DNS W-B bei nslookup vor, erscheint Fehlermeldung wie gehabt.

Das wurde am Client getan als Reaktion auf Post 10, der den Vorgang auf dem Client anfragte (nur nicht noch einmal in Post 11 erwähnt, dass dies vom Client gemeint ist):

Setze auf einem Client auch mal bitte den DNS-Server der Hauptstelle als bevorzugten DNS-Server, führe den Nslookup-Befehl aus und poste das Ergebnis. Und zum zweiten wieder den ursprünglichen DNS-Server eintragen und wieder die Nslookup-Ausgabe posten ...

Aus Post 13 der letzte Teil

Au dem DC W-B selbst funktioniert nslookup ja auch mit diesem selbst als DNS. Nur von keinem Client aus.

bezieht sich auf den selben Vorgang (nslookup), jedoch auf Server W-B ausgeführt. Steht aber doch da?

Alles verständlich soweit?

Das bezog sich aber auf die Namensauflösung über den Server I

Wo die Schlussfolgerung mit dem FQDN herkommt, kann ich nicht schlussfolgern.

Gebe ich nslookup dc-w-b.abc-defg.local dc-w-b ein, funktioniert es nicht

Gebe ich für den DNS auch den FQDN an, ändert das nichts:

nslookup dc-w-b.abc-defg.local dc-w-b.abc-defg.local

PTR-Einträge gehen doch nur in der jeweiligen Zone? Ein Pointer Eintrag eines anderen Subnets geht doch nicht? Oder sind die NameServer-Einträge gemeint? Die sind in allen 3 Reverse-Zonen vorhanden (je 5 Stk).

Was auffiel: nur das Subnet W-B hat einen Eintrag für Wins-Reverse-Lookup (abc-defg.local)

Führe ich jetzt einen nslookup vom Server W-B aus, wird standardmässig Server I genommen (ist ja heute zum primären gemacht worden). Gebe ich den Server w-b als DNS vor, erfolgt die Auflösung wie gehabt.

Machbar ist das. Haben z.B. VPN-Kopplung der Standorte nur zum internen Datentausch. Fällt aber an einem Standort DSL aus, kann man nach Umkonfiguration der Router auch über den anderen ins Netz. Sind aber Business-Geräte (Lancom 1721).

nslookup tut es aber (war zumindest bei bisherigen Tests von anderen Clients diese Woche so).

Gegentest heute aus Netz I mit Angabe des DC W-B als Zwangs-DNS hat natürlich auch nichts aufgelöst

Habe gute Erfahrungen mit Lancom 800 gemacht (auch mit anderen Lancom-Modellen im Lan- und UMTS-Bereich). Gibts schon seit Jahren; aktuelle Modelle sind etwas modifiziert (wenn ich mich recht entsinne, ohne Com-Port).

Wird aber bei uns in anderen Szenarien eingesetzt.

Falls die Abdeckung da ist, würde ich UMTS in Betracht ziehen. Flats gibts da auch schon unter 30 Euro.

keine Server-Firewall

die x32-Clients sind ebenso betroffen

Änderungen an der NW-Kfg erst am Montag vor Ort (wohl auf einem anderen Client).

@Necron

Das Posting von 21:33 Uhr enthält andere IP-Angaben als zuvor (Servernamen gleich)

Also:

Netz 1

192.168.81.0

Server I: 192.168.81.102 (DNS, Wins, DHCP)

Server A (Exchange): 192.168.81.100 (DNS, WINS)

Server G: 192.168.81.105 (DNS)

Gateway/Router 192.168.81.42

Netz II

192.168.82.0

Server W-B: 192.168.82.101 (DNS, WINS, DHCP)

Gateway/Router 192.168.82.42

Netz III (über Slow Link angebunden)

192.168.83.0

Server B: 192.168.83.101 (DNS, WINS, DHCP)

Gateway/Router 192.168.83.42

Aktiviert ist

- Primäre und verbindungsspezifische DNS-Suffixe anhängen

- übergeordnete Suffixe..anhängen

- Adressen dieser Verbindung in DNS registrieren

Dies müsste der Standard-Einstellung entsprechen.

Ist übrigens der einzige Client mit Win XP x64 (sonst x32)

Richtlinien sollten keine Relevanz haben (z.B. Windows Update über Default Domain Policy).

Name der Reverse-Zonen? Ist doch die jeweilige Subnet-Bezeichnung (in umgekehrter Reihenfolge)

DNS-Suffix wird bei ipconfig am Client ausgegeben (steht auch ganz oben).

IP-Adresse. . . . . . . . . . . . : ? wird genau so ausgegeben. Hat mich auch stutzig gemacht. Werde am Montag mit einem anderen Client testen (vermutlich kommt dieser Eintrag da nicht).

Ping vom Client an DC W-B wird korrekt beantwortet.

Arbeiten ist in der Form ja auch nicht eineschränkt. Ich vermute aber unnötige Verzögerungen bei Arbeiten über Netz.

Ändern der NW-Kfg mache ich auch erst am Montag vor Ort.

Die obige Kfg hat auch den sekundären Wins veraltet. Dürfte aber inzwischen aktualisiert und mit einem neuen Lease erledigt sein. Will mich aber nicht mit ipconfig /release aussperren.

Die unverfälschten Ausgaben kann ich gern per PN senden.

so, hab mich mal über vpn auf einen Client verbunden, der durchläuft und auf diesem getestet: nslookup scheitert hier (sekundärer DC ist eingetragen, wird aber nicht verwendet). Gebe ich bei nslookup den DNS-Server vor, funktioniert es mit dem Server I, aber nicht mit dem Server W-B (also wie gehabt).

ipconfig:

Ethernet-Adapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix: abc-defg.local

Beschreibung . . . . . . . . . . : NVIDIA nForce Networking Controller

Physikalische Adresse . . . . . . : 00-11-22-2F-A5-A1

DHCP aktiviert . . . . . . . . . : Ja

Autokonfiguration aktiviert . . . : Ja

IP-Adresse. . . . . . . . . . . . : 192.168.82.240

Subnetzmaske . . . . . . . . . . : 255.255.255.0

IP-Adresse. . . . . . . . . . . . : ?

Standardgateway . . . . . . . . . : 192.168.82.42

DHCP-Server . . . . . . . . . . . : 192.168.82.101

DNS-Server . . . . . . . . . . . : 192.168.82.101

192.168.81.102

192.168.81.100

192.168.81.105

192.168.83.101

?

?

?

Primärer WINS-Server . . . . . . : 192.168.82.101

Sekundärer WINS-Server . . . . . : 192.168.81.101

192.168.81.100

Lease erhalten . . . . . . . . . : Dienstag, 7. Oktober 2008 21:26:03

Lease läuft ab . . . . . . . . . : Mittwoch, 15. Oktober 2008 21:26:03

nslookup dc-w-b

DNS request timed out.

timeout was 2 seconds.

Server: UnKnown

Address: 192.168.82.101

DNS request timed out.

timeout was 2 seconds.

nslookup dc-w-b dc-I

Server: dc-I.abc-defg.local

Address: 192.168.81.102

Name: dcwb.abc-defg.local

Address: 192.168.82.101

Aliases: dc-w-b.abc-defg.local

Interessant ist, dass sich die Ausschrift unterscheidet. Schreibt man die Ausgabe in eine Datei, kommt das obige. Ohne Schreiben in eine Datei kommt die Ausgabe

nslookup ServerW-B

DNS request timed out.

timeout was 2 seconds.

***Der Servername für die Adresse 192.168.82.101 konnte nicht gefunden werden:

Timed out

Server: UnKnown

Address: 192.168.82.101

DNS request timed out.

timeout was 2 seconds

***Zeitüberschreitung bei Anforderung an Unknown

Eigentlich gibts für den Server W-B noch einen Alias (der nicht ausgegeben wird) - sollte aber keine Relevanz haben.

nö, war gekürzt.

server.abc-defg.local

Mit dem FQDN geht nslookup auch.

Zoneninhalte sind gleich - weichen maximal um eine Revisionsnummer voneinander ab.

Au dem DC W-B selbst funktioniert nslookup ja auch mit diesem selbst als DNS. Nur von keinem Client aus.

Wie zu vermuten: ist der Server am Standort I eingetragen, funktioniert es korrekt (sonst läuft es ja auch über ihn, wobei er aber als sekundärer DNS zum Zug kommt).

Gibt man den DNS W-B bei nslookup vor, erscheint Fehlermeldung wie gehabt.

Also:

Server I als prim. DNS

nslookup ServerW-B

Server: I.local

Address: 1.1.1.1.

Name: ServerWB.local (alias-Name)

Address: 1.2.3.4

Aliases: ServerW-B.local

Nach Rückstellen der Kfg (Server W-B ist primärer DNS; Server I sekundärer):

nslookup ServerW-B

DNS request timed out.

timeout was 2 seconds.

***Der Servername für die Adresse 1.2.3.4 konnte nicht gefunden werden:

Timed out

~~~danach die Ausgabe wie oben (korrekte Auflösung über Server I)

netdiag (auf DC W-B) selbst zeigt keinen Fehler (auch gestern schon mal probiert)

auf DC W-B jetzt den anderen Server vom Hauptstandort als primären DNS eingetragen

netdiag /fix ausgeführt

nslookup vom Client ist unverändert

wenn das einfach wäre, hätte ich die DNS-Funktion auf dem betroffenen DC ja schon mal erneuert.

dies geht aber doch nur nach dcpromo? ist mir zu riskant im laufenden Betrieb

Szenario soweit korrekt.

Die 4 primären Zonen sind die 1 FW und 3 Reverse Zonen?

Clients am Hauptstandort haben als sekundären Server andere Server des gleichen Standortes.

DNS-Servereinträge über Kreuz? Auf jedem Server sind alle Server als DNS-Nameserver eingetragen.

Kann man auf einem AD-DC einen anderen Server als diesen selbst als primären DNS-Server eintragen? Noch nie probiert.

Den Rest teste ich morgen.

Wie gesagt AD-integriertes DNS. Da gibts keinen primären/sekundären.

Der Ausdruck bezog sich auf den DNS-Eintrag der Clients (primär=lokaler DNS; sekundär=Remote-DNS).

Firewalls nach außen

Kein NAT, ACL, keine Subdomains usw.

IPs per DHCP verteilt (wie schon gesagt).

Zur Zeit sitze ich an folgendem Problem - vielleicht kann mir jemand einen Tip geben?

Netz:

5 Server (4*2003, 1*2000), an 3 Standorten (Standort I mit 3 Servern ist mit Standort W-B über Funkstrecke gekoppelt; Standort B mit beiden über VPN-Tunnel per DSL.

Am Standort W-B sagt mir ntslookup, dass die Namensauflösung über den sekundären DNS erfolgt (vom Standort I). Vorangestellt die Meldung: DNS request timed out. timeout was 2 seconds. ***Der Servername für die Adresse 1.2.3.4 {IP Server W-B} konnte nicht gefunden werden."

Führe ich ntdsutil direkt auf dem Server W-B aus, löst er alle Namen über seinen eigenen DNS auf.

Gebe ich bei nslookup den Server W-B zur Auflösung vor, erhalte ich

***Der Servername für die Adresse 1.2.3.4 {IP Server W-B} konnte nicht gefunden werden:

Timed out

*** Zeitüberschreitung bei Anforderung an Unknown

DNS request timed out.

timeout was 2 seconds.

Server: UnKnown

Address: 1.2.3.4

DNS request timed out.

timeout was 2 seconds.

Auf dem Server selbst funktioniert dies.

IP-Kfg Clients ist natürlich korrekt.

Die IP und auch der Name des Servers W-B lassen sich vom Client erreichen (auch die beiden Aliase). Mit ping -a wird der Name zurückgegeben.

In den Reverse-Zonen sind die Einträge natürlich vorhanden. Zonen werden auch repliziert (SOA-Versionsnummern stimmen). Server W-B ist sowohl in Reverse- als auch in Forward-Zone als NS und SOA vorhanden (AD-integrierte Zonen).

Ereignisanzeige enthält Fehler 13508 bezüglich gescheiterter Replikation aller entspr. Server zum Server W-B.

Neustart DNS-Dienste und Dateireplikationsdienst auf Server W-B ohne Ergebnis.

FRSDiag bringt mir nur Fehler aus dem Event-Log (Fehler 1865, 1311, 1566 bis 30.09. An dem Tag wurde die Verbindung B zu W-B wiederhergestellt und der Eintrag tauchte nicht mehr auf > also kein Fehler

Dcdiag und ntfrsutil bringen mir auch keine Fehler (außer eventlog).

Bin etwas ratlos.

Zumal sich am Standort W-B im letzten Monat einige merkwürdige Fehler ereigneten:

- DHCP funktionierte nicht mehr (vergab keine Adressen mehr). Entfernen, Neuaufsetzen (sowohl mit Import als auch mit manuellem Erstellen der Attribute) wurde mehrfach durchgeführt ohne Veränderung. Provisorisch den Router zum DHCP gemacht; auf dem Server den DHCP de-autorisiert. Ncah etwa 5-6 Wochen Router-DHCP deaktiviert; Server-DHCP autorisiert: funktioniert wieder (ohne Veränderung in Kfg)

- VPN-Tunnel W-B nach B funktionierte nicht mehr. Auf beiden Routern gelöscht und identisch neu erstellt: funktioniert wieder

- dyndns-Aktualisierung vom Router aus funktioniert nicht mehr (Eintrag mehrfach neu geschrieben; 1:1 mit anderem Router (bei dem es funktioniert) verglichen; schließlich Tool auf Server installiert (zur Aktualisierung)