robotroonie

mW: Ja

Alle angesprochenen PCs sind Mitglied der 2000er Domain. Versuche wurden von 3 XP Pro SP2-Clients gemacht; 2 davon x32 / 1 x64-Edition

Bin immer noch nicht weiter. Im Richtlinienergebnissatz wird mir gesagt, dass die Reg-Einstellungen nicht mit einer ADM-Vorlage übereinstimmen und ggf durch ein zusätzliches Snap-In definiert wurden. Im Gruppenrichtlinienergebnissatz steht wieder der Pfad der Default Domain Policy (Computerkonfiguration, Administrative Vorlagen, Netzwerk, Netzwerkverbindungen und dann Windows-Firewall). Da ist aber kein Eintrag, den man konfigurieren könnte (gar kein Unterordner in NW- und DFÜ-Verbindungen; alle Einstellungen in diesem Ordner sind auf "nicht konfiguriert". Das Merkwürdige: in den "Richtlinien für lokaler Computer" sowie 2 weiteren, erstellten RL gibt es die gesuchten Einträge (hier aber nicht konfiguriert); nicht jedoch in Default Domain und Default DC Policy. Das Recht Bearbeiten/Löschen/Sicherheit verändern hat der Admin-Account, mit dem ich das Ganze probiere.

Ist alles irgendwie schon zu lange her. Woher weiß ich, wo der Eintrag KeyName: Software\Policies\Microsoft\WindowsFirewall\DomainProfile steht? (so zeigt das ja nur auf einen Registry-Key)

Bin noch auf der Suche, wo diese festgelegt ist. In Default Domain Policy wirds wohl sein. Aber nicht in Computerkonfiguration, Administrative Vorlagen, Netzwerk, Netzwerkverbindungen und dann Windows-Firewall.

Habe mal protokollieren verworfener Pakete aktiviert: #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path 2006-08-17 11:28:00 DROP ICMP 192.168.2.254 192.168.2.116 - - 56 - - - - 5 1 - RECEIVE zahllose dieser Einträge (immer gleiche IP-Einträge)

Die nForce-FW ist deaktiviert. Trotzdem ein guter Tip. Die lokale FW wird von einer GRL gesteuert. Schau ich mal nach.

Das ist doch mal eine Auskunft! So wie ich das verstehe, gibts den Hotfix nicht zum freien Download, sondern nur per Anfrage an den MS-Support? Merkwürdig.

Hier ein Ipconfig/all eines beteiligten Client-PCs (Netz W): Habe festgestellt, dass die IP des 3. DNS-Servers noch die alte war und diese geändert (192.168.1.206 wird zu 192.168.2.201). Dürfte im Netz W noch auf allen Clients so stehen (insofern mehrere DNS eingetragen sind). Auf den Servern stimmt die Eintragung. Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : IT-W-211 Primäres DNS-Suffix . . . . . . . : bau-medien.local Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert. . . . . . . : Ja WINS-Proxy aktiviert. . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : bau-medien.local Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Intel® PRO/100 VE-Netzwerkverbindung Physikalische Adresse . . . . . . : 00-01-80-10-59-15 DHCP aktiviert. . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.1.211 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.254 DNS-Server. . . . . . . . . . . . : 192.168.1.200 192.168.1.201 192.168.1.206

Hier ein Ipconfig/all eines beteiligten Client-PCs (Netz K). Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : ibk-w-116 Primäres DNS-Suffix . . . . . . . : bau-medien.local Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : bau-medien.local Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : NVIDIA nForce Networking Controller Physikalische Adresse . . . . . . : 00-16-17-8E-A5-C8 DHCP aktiviert . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse (Autom. Konfiguration) : 192.168.2.116 Subnetzmaske . . . . . . . . . . : 255.255.255.0 IP-Adresse. . . . . . . . . . . . : ? Standardgateway . . . . . . . . . : 192.168.2.254 DNS-Server . . . . . . . . . . . : 192.168.2.201 192.168.1.201 ? ? ? Ethernet-Adapter LAN-Verbindung 2: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : Windows Mobile-based Device Physikalische Adresse . . . . . . : 80-00-60-0F-E8-00 DHCP aktiviert . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 169.254.2.2 Subnetzmaske . . . . . . . . . . : 255.255.255.0 IP-Adresse. . . . . . . . . . . . : ? Standardgateway . . . . . . . . . : DHCP-Server . . . . . . . . . . . : 169.254.2.1 DNS-Server . . . . . . . . . . . : ? ? ? Lease erhalten . . . . . . . . . : Montag, 14. August 2006 17:02:30 Lease läuft ab . . . . . . . . . : Mittwoch, 13. September 2006 17:02:30 Tunneladapter Teredo Tunneling Pseudo-Interface: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : FF-FF-FF-FF-FF-FF-FF-FF DHCP aktiviert . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : ? Standardgateway . . . . . . . . . : NetBIOS über TCP/IP . . . . . . . : Deaktiviert

Jedes Netz hat einen DSL-Router, über den es ins Netz geht (separate DSL-Flats). Dieser ist Std-Gateway im entspr. Netz und verweist für andere Subnetze auf die entspr. Router. @ITHome lässt sich das vielleicht noch eingrenzen, da der Zugriff auf die Server ja funktioniert (bzw. kann man dann überhaupt von Filtern als Ursache ausgehen)?

Nur das nehme ich (mit Name geht aber auch net)

Info Query failed Status=9553 ... Command failed DNS_ERROR_INVALID_PROPERTY ...

Es kommt der Fehler "Der Netzwerkpfad wurde nicht gefunden" Manuell habe ich keine Routen eingetragen. Normalerweise sollte ja der Standard-Gateway reichen ?! Es wäre ja mühsam, auf jedem Client die Routen zu jedem anderen Client eintragen zu müssen. Zudem geht das Pingen ja. Veraltete Routen sind keine am Client vorhanden. Ständige Routen sind nicht definiert. Ein versuchsweiser Eintrag einer Route auf dem Client bringt kein anderes Resultat. Geroutet wird über 2 Funkstrecken-Router, die von einer externen Firma betreut werden (PW liegt nicht vor; wurde so von der GF beschlossen). Gateway ist der DSL-Router zum Internet; dieser routet die entspr. Pakete auf den Funkstreckenrouter. Welche Pakete/Ports/Protokolle könnten es denn sein, die unnötig geblockt werden???

Quelle DNS Zahllose Einträge: Ereignis-ID 7063 vereinzelte Einträge: 5504 (z.T. von "fremder" IP, z.T. von einem DC - konnte auf diesem den Fehler aber nicht finden)

Welche Einschränkungen gibt es genau? Das mit den 10 maximal gleichzeitigen Verbindungen ist mir bekannt. Nun habe ich aber folgendes Problem: Netz hat 3 DCs und zahllose Clients; speziell auf einem ist eine Freigabe, die von überall aus erreichbar sein muss. Das Netz wurde nun in 2 geroutete Subnetze getrennt; der Zugriff auf Server (gegenseitig), Internet, Exchange usw. funktioniert alles. Den betreffenden Client-PC kann ich auch pingen. Allerdings kann ich mich aus dem anderen Subnetz nicht direkt darauf verbinden. Dies scheint jeweils für alle Clients im anderen Subnetz zu gelten (also auch vom Server Netz A auf Client Netz B). Zwischen beiden Netzen funktioniert nur der Zugriff auf die Server uneingeschränkt. Innerhalb eines Subnetzes ist der Zugriff auf alle Clients möglich. Ursprünglich hielt ich das für ein Authentifizierungssproblem - es sind aber keine Fehler im Protokoll. Muss ich vielleicht noch irgendetwas anpassen/einstellen? Clients stehen alle mit aktuell gültigen Namen im DNS und die Namensauflösung klappt genauso wie das Pingen. Bin ratlos.

Da das in dem anderen Thread etwas untergegangen ist: habe zahllose Fehler im DNS-Protokoll, weil nicht erreichbare/ungültige Weiterleitungsadressen vorhanden sein sollen. Es wird aber keine davon angezeigt (nur die eine korrekte); hatte auch mit dnscmd ... /resetforwarders gelöscht, hat aber auch nichts gebracht > gibt es eine Möglichkeit, sich diese "versteckten" Weiterleitungen anzuzeigen (werden mit GUI nicht angezeigt)? 3 DCs, W2k, AD-integrierte Zonen (1 Forward/2Reverse), 1 Domain, 2-3 geroutete Subnetze

So ähnlich hatte ich vermutet. Nur das erste Reply besagte ja das Gegenteil (Frage war ja explizit auf AD-integrierte Zonen gemünzt). Kann mir noch jemand bezüglich der 2. Frage helfen?

Komisch. Aktuell ist jeder sein eigener SOA und die Daten sind konsistent. Habe das geändert; dann den SOA in allen 3 Zonen (1 Forward; 2 Reverse) um ein Inkrement erhöht; bei den anderen 2 Servern manuell auf "Aktualisieren" - und: Der SOA-Eintrag dieser Server wird automatisch wieder geändert (jeder ist sein eigener SOA) - ist das bei AD-integrierten Zonen nun doch so, oder liegt es an einem Fehler im DNS???

Habe mal eine prinzipielle Frage dazu. Dei AD-integrierten Zonen handelt es sich doch um ein Multimastermodell (jeder DNS-Server ist autorisierend). Was sollte man als SOA eintragen - bzw. spielt das dann überhaupt eine Rolle? Es gäbe da 3 Varianten: 1.) Jeder DNS-Server ist sein eigener SOA 2.) "im Kreis" - jeder DNS-Server hat den vorherigen /oder nächsten) als SOA eingetragen 3.) alle verweisen auf einen (ist das sinnvoll bei einem gerouteten Netz?) Habe leider keine Info dazu gefunden. Noch eine andere Frage: habe zahllose Fehler im Protokoll, weil nicht erreichbare/ungültige Weiterleitungsadressen vorhanden sein sollen. Es wird aber keine davon angezeigt (nur die eine korrekte); habe nun mit dnscmd ... /resetforwarders gelöscht und hoffe, dass die Fehler nicht mehr kommen > gibt es eine Möglichkeit, sich diese "versteckten" Weiterleitungen anzuzeigen (werden mit GUI nicht angezeigt)?

Folgendes hat zu einem Teilerfolg geführt: Ändern der Forward-Zonen auf beiden Servern im Netz W auf Sekundär; mit Master und SOA Server Netz K. Replikation klappt. Will ich diese Zonen allerdings wieder auf AD-integriert stellen, kommt die Meldung, dass der Zonentyp ungültig sei (Das Setzen der Daten auf der Primärzone ist fehlgeschlagen). Was meine Vermutung bestätigt, dass das Problem AD-verursacht ist. Versuche ich die Zone auf Server Netz K von AD auf primär zu ändern, kommt die gleiche Meldung. Nach einigen Versuchen ist der Stand folgender: alle Zonen sind AD-integriert und auf dem gleichen Szand. Ob die Replikation untereinander korrekt funktioniert, werde ich in den nächsten Tagen beobachten. Mich stört aber, dass am Server Netz K immer noch ein gelbes Ausrufezeichen am DNS-Symbol gezeigt wird. Und die Zugriffsprobleme (Client Netz K auf Client Netz K) immer noch bestehen.

Standorte sind noch nicht eingerichtet (wurden aber in Erwägung für zukünftiges Netzwerkdesign mit in Betracht gezogen). Einen Teilerfolg habe ich erreicht: Die Reverse-Zonen wurden erfolgreich repliziert nach folgendem Eingriff: Seriennummer der manuell geänderten erhöht; SOA überall auf Server Netz K gestellt (Neue) Zone 192.168.2.x geändert von primäre Zone auf AD-integrierte; diese Zone auf Server Netz W erstellt. Direkt nach dem Erstellen der Zone hat er sich alle Einträge geholt. Das Merkwürdige daran: normalerweise muss man die Zone doch kein 2. Mal erstellen, da diese ja repliziert (und zwar nicht nur den Inhalt an sich (wie geschehen), sondern auch die Zone selbst). Beim Versuch, auf Server 2 Netz W die Zone zu erstellen, kam die Meldung, dass es nicht gehe, weil die Zone schon vorhanden sei. Nach manuell gestarteter Replikation war diese dann auch da (alle 3 Versionen der Reverse-Zonen haben nun den gleichen Stand); die Vermutung liegt aber nahe, dass der Datenaustausch zwischen Netz W und K immer noch in irgendeiner Form eingeschränkt ist Was immer noch nicht geht (trotz erhöhter Snr) ist die Replikation der Forward-Lookup-Zone.

Vorher: alles im 192.168.1.x-Netz Netz W und K durch Funkstrecke im Bridging Modus verbunden Umstellung auf 192.168.2.x im Netz K; Funkstrecke in den Routing Mode Außerdem (irrelevant:) am Netz W hängt über einen Router Netz E (192.168.30.x) usw. Umstellung wurde in erster Linie vorgenommen, um bei Ausfall der Funkstrecke eine Fallback-Lösung per VPN realisieren zu können (Vorraussetzung unterschiedliche Subnetze) DNS-Server wie gesagt: insgesamt 3; davon steht einer jetzt im neuen Subnetz. Das Problem ist, dass dieser (manuell aktualisierte) DNS nicht auf die anderen repliziert.

Die Trennung eines Netzes in 2 Subnetze ist erfolgt. Die Funktionalität ist weitgehend wiederhergestellt; folgende Probleme bestehen noch: Zugriff von Netz K zu Netz W: auf Server kpl. möglich; auf Clients Ping OK, aber kein Verbinden möglich (Authentifizierungsproblem?). Namensauflösung für Test-Client ist OK; Zugriff von Netz W zu Netz K: auf Server kpl. möglich; auf Clients nicht /nicht einmal Ping Ich gehe davon aus, dass die noch bestehenden Probleme (manche Prozesse sind auch sehr langsam) ursächlich am DNS liegen. Theoretisch sollten sich die Clients mit geänderter IP ja selbst neu registrieren; das funktioniert aber nicht wirklich (nur bei einem Client). Netz hat 1 Server im Netz K; 2 im Netz W (einer davon Exchange); alle sind W2k und haben AD-integrierte Zonen (eine Forward und 1 Reverse-Lookup). Zuerst habe ich den Eintrag Server Netz K geändert (SOA usw.), da sich dessen IP geändert hat. Dann eine neue Reverse-Lookup-Zone hinzugefügt. Veraltete Einträge rausgeworfen und für die relevanten Clients (Netz K) neue Einträge (Forward und Reverse) erstellt. Mir ist noch aufgefallen, dass auf den beiden Servern im Netz W jeweils eine Weiterleitung auf eine ungültige IP eingestellt war. Mein Problem ist nun: ich habe auf dem Server Netz K die Einträge geändert, es wird aber nix repliziert. Physische Netzverbindung ist da (Zugriff in beide Richtungen funktioniert). Sicher habe ich noch etwas vergessen? Muss mich erst wieder in die Thematik einarbeiten. Forward-Zone braucht es keine 2. (bei 2 Subnetzen)? Netze sind ja durch Router gegenseitig erreichbar. Oder sollten die einen Teil des Traffic blocken? (Halte ich für unwahrscheinlich, da hier im Wesentlichen nur Routingeinträge und IPs geändert wurden) Was noch auffällt: auf dem Server Netz K hat das DNS-Server-Symbol ein gelbes Ausrufezeichen; im DNS-Log sind Einträge, die sich auf den Zugriff eines Servers auf Server K beziehen (Ungültiger Domänenname). Die Ursache dafür muss ich noch ergründen. Ein Ändern des DNS auf Sekundäre Zone auf Server 1/W mit Angabe IP Server K führt auch nicht zur Replikation

Wenn es wirklich ursächlich an der Sprachbarriere liegt, vielleicht mal die Gruppe umbenennen? Ist auch bei mir schon nötig gewesen, jedoch nicht iV mit Migration (Name Nutzer/Gruppen, Name Arbeitsgruppe,..)