robotroonie

OK. Nun besteht die Domäne aber aus 4 Subnetzen. Da bei allen eine Anmeldung an der Domäne (inkl. Verbindung zum DC) erfolgt, wird das Domänenprofil immer angewendet - auch wenn ein Notebook zwischen Subnetzen wandert? Wie verhält es sich mit der Default Domain Policy? Wird diese auch angewendet, wenn die Anmeldung getrennt vom Netz (mit cached credentials) erfolgt? Geplante Kfg wäre: an Notebook-OUs Domänenprofil auf FW deaktiviert und Standardprofil auf nicht konfiguriert (wird dann von der kfg. FW der DDP überlagert).

Folgende Problemstellung: Im Netz gibt es diverse PCs und Notebooks; die Notebooks sind natürlich auch immer mal unterwegs. Diese sind in separaten OUs erfasst. Der bisherige Stand war folgender: Windows-Firewall wurde für alle per Default Domain Policy (DDP) vorgegeben. Da diese aber eventuell beschädigt ist (?) lässt sich die Firewall nicht mehr anpassen/deaktivieren (auch vom XP SP2-Client aus, von dem aus diese erstellt wurde; trotz Einspielen der entsprechenden Templates auch vom 2k-Server aus nicht / per Richtlinienergebnissatz wird mir die Anwendung der FW-RL Aber angezeigt). Der komplette Untereintrag fehlt einfach. Da in der DDP auch andere angepasste Einstellungen vorhanden sind, möchte ich diese nicht zurücksetzen. Da aber zusätzliche Clients ins Netz kamen sowie neue Software - die in der FW als Ausnahme definiert werden muss, habe ich die normalen Clients in entsprechende OUs verschoben und an diesen jeweils neue RL festgemacht - bei denen die FW deaktiviert ist (Domänenprofil) - bei diesen RL wurde der zu konfigurierende Eintrag auch wieder angezeigt (im Gegensatz zur DDP). Da das Netz durch Router und Antivirenlösung geschützt ist, ist die Client-Firewall sicher obsolet. Nun würde ich aber die Notebooks gern so konfigurieren, dass sie im Netz keine FW aktiv haben; außerhalb aber schon. Meines Wissens entspricht das der Einstellung: FW im Domänenprofil deaktiviert / FW im Standardprofil aktiviert. Ist das so weit korrekt? Oder wird beim Anmelden mit lokal zwischengespeicherten Credentials der Domäne dann doch das Domänenprofil verwendet? Gemäß Netzwerkbestimmungsverhalten sollte das laut MS nicht so sein: TechNet - The Cable Guy - May 2004: Network Determination Behavior for Network-Related Group Policy Settings Wenn das (Standard)Profil nicht konfiguriert wird, wird es ja von der DDP überlagert. Trifft das auch beim Betrieb jenseits des Domänennetzes auf (wird die DDP dann angewendet)?

Hi, ich suche ein Tool, das mir von einer großen Ordnerstruktur einfach und übersichtlich die aktuelle Ordnertiefe (Anzahl der Ebenen) anzeigt. Da die Pfadtiefe ja beschränkt ist und diese Grenze in der Struktur hin und wieder erreicht wird, möchte ich von vornherein wissen, in welchen Bereichen die Struktur am tiefsten ist (also z.B. Suche nach allen Ordnern, die tiefer als 8 oder 10 Ebenen liegen). Habe leider nichts Adäquates gefunden.

Denke nun, dass es primär ein DNS-Problem ist. Internet läuft über 1und1 mit Lancom-Router. DNS auf dem Router ist deaktiviert - soll ja der Win-Server machen (3 Stück 2k mit AD-integriertem DNS).

Habe ein geroutetes Netz mit 3 Subnetzen. Alle Mails laufen über 1und1 über einen Exchange 2000 (soweit ohne Probleme). Nun wurde letzte Woche das 3. Subnetz auf den Exchange umgestellt. pop3-Abruf läuft über popconnect; Versand über Exchange. Das Problem: Empfang (ausschließlich der Strato-Adressen) funktioniert oft nicht; Versand dito. Ändert man den Standardgateway am Exchange-Server in einen ungültigen und dann wieder zurück, hat es jeweils eine Weile funktioniert. Die Auflösung der Startseite strato.de sowie post.strato.de war im Fehlerfall auch nicht möglich. Habe dann festgestellt, dass der Server eine 2. IP (217....) an die NW-Karte gebunden hat (die auch immer automatisch im DNS eingetragen wurde. 2. IP entfernt; im DNS autorisierend gelöscht sowie einen connector für den strato-smtp-traffic erstellt: scheinbar OK; neu verschickte Mails kommen an. Die, die bereits (z.T. seit Tagen) in der Warteschleife hängen, aber nicht > daher diese gelöscht. Nun, nach ein paar Stunden, das Ganze noch einmal kontrolliert: Fehler wie zuvor. So einige Mails hängen in der Warteschleife (ping auf strato-smtp aber OK; popconnect-test auf strato nicht). Noch eimal flushdns gemacht; Testmails verschickt: OK (alte Mails hängen weiter in der Warteschleife). Habe post.strato.de für smtp verwendet (woanders wird aber auch von post.webmailer.de gesprochen). Im Übrigen kommt es auch ab und zu vor, dass Websites falsch aufgelöst werden - und im Subnetz, in dem der Exchange steht, können keine https-Seiten mehr dargestellt werden. Feste IP gibt es nicht (aber dyndns für vpn).

Danke. Hatte es mit IE und Firefox von 2 Clients aus getestet. Werde das nun mal im Auge behalten. Eigentlich sind die Befehle im Router abgelegt; der Zugriff scheiterte jedoch (lag aber auch am geänderten PW). Werde nun mal beobachten, ob die IP morgen automatisch aktualisiert wird.

Zum Thema Firewall: mit einem Client, der nicht Mitglied der Domain ist und die Win-Firewall ausgeschaltet hat, ist auch kein Zugriff auf den Client des anderen Subnets möglich (Pingen auf IP und Name schon). Steht nach wie vor die Frage: liegt es am fehlenden WINS (obwohl Zugriff auf \\IP versucht wird) oder ev. an blockierten Ports in den WLAN-Routern???

Habe folgendes Problem: das Update des dyndns-Eintrages sollte eigentlich über das Aufrufen einer bestimmten url ( http://username: password@members.dyndns.org/nic/update? system=dyndns& hostname=yourhost.ourdomain.ext,yourhost2.dyndns.org& myip=ipaddress& wildcard=OFF& mx=mail.exchanger.ext& backmx=NO& offline=NO ) möglich sein. Tatsache ist, dass es auf diese Art hier nicht funktioniert - speziell mit http://(user):(password)@members.dyndns.org/nic/update?system=dyndns&hostname=(xyz)&wildcard=NOCHG&mx=(xyz)&backmx=NO Das Problem scheint die Übergabe der Authentifizierungsinformationen zu sein. Gebe ich http://members.dyndns.org/nic/update?system=dyndns&hostname=(xyz) ein, kommt ein Fenster zur Eingabe der Accountdaten und danach wird das Update erfolgreich durchgeführt. Nun habe ich versucht, das mit dyndnsupdater durchzuführen (erfolgreich) und die Pakete mit Ethereal mitgeschnitten. Dort taucht aber nicht der gesuchte GET-Befehl über http auf, sondern Traffic über SSL. Mit einem extra installierten 2. Updater (3DWatch!) ist es das gleiche. Die Versuche mit der URL wurden sowohl aus dem Firmennetz (mit Router) als auch von einem Heim-Notebook (direkt am DSL über Fritzbox) durchgeführt - mit gleichem Ergebnis. Wo liegt der Fehler?

Soweit ist auch mein Kenntnisstand. Wurde alles oben schon diskutiert. WINS läuft nicht; die meisten Clients haben keinen Netbios-Namen. Wäre also aufwändig zu implementieren (zumal nur für einige Wochen Übergangszeit benötigt). Ping geht komplett (auf Namen und IP), Verbinden überhaupt nicht (auch auf IP nicht) - das ist ja der Punkt: Verbinden auf IP sollte auch ohne WINS gehen! Der Zugriff erfolgte zwar über den Explorer, aber eben über gemappte Laufwerke (nicht über Browsing-Funktion in Netzwerkumgebung).

richtig; Zugriff für normale User über gemappte Laufwerke (Explorer) Zugriff aus eigenem Teilnetz funktioniert uneingeschränkt Es handelt sich um NTFS-Partitionen mit detaillierter Rechtevergabe (Freigaberechte: Jeder-alles; NTFS-Rechte genau konfiguriert). Firewall s.o. (aktiv über default domain policy; momentan nicht abstellbar; Möglichkeit mit Umgehen der dd-policy wird als nächstes getestet.)

Korrekt. Keine kritischen Fehler; Replikation funktioniert. Eventuell kritisch wäre höchstens Fehler 5504, wie hier geschildert: http://www.mcseboard.de/windows-forum-ms-backoffice-31/dns-weiterleitungsfehler-96309.html Sollte aber iV mit dieser Problemstellung nicht relevant sein.

Es gibt momentan 3 Server (in Kürze 4). 2 im Netz W und 1 im Netz K. Alle sind DCs und DNS-Server (AD-integrierte Zonen). Server hat nur ein Interface ins jeweilige Subnet (Zugriff aufs andere Subnet via Funk-Router). 1 Server im Netz W agiert als Exchange-Server; die anderen 2 primär als Fileserver. Alle relevanten Clients sind Domänenmitglieder. Clients XP Pro SP2; Server W2k

Dumm erscheint mir die Frage nicht; waren die Router doch noch vor 15 Tagen (vor der Trennnung in 2 Subnets) im Bridging mode konfiguriert.

Die Funkrouter routen nur ins andere Subnet; für Internet gibts jeweils einen anderen (DSL-)Router. Dieser ist jeweils Standard-Gateway und hat entspr. Routen eingetragen (bereits oben geschildert). Netz ist jeweils DSL6000-Flat. Anbindung Server kA (Verbindung ist vorhanden - aber in welcher Form? - ich nehme an, nur über einen Switch).

Es gibt 2 dedizierte Clients, auf denen Daten gespeichert sind, die von überall aus zugänglich sein sollen (Archiv alter Projekte und IT-Archiv mit SW). Die vorhandenen Server bieten leider nicht genug Kapazität. Da diese Daten nicht SO wichtig sind, ist es auch nicht so kritisch, dass sie nicht gesichert werden (zumal alte Projekte auf CD-R/DVD gesichert werden). Diese Clients fungieren nicht als Workstations / an diesen arbeiten keine User. Seit heute ist eine Archiv-HD im gleichen PC wie das SW-Archiv (da der Archiv-PC Netz W Probleme machte; dieser hatte noch NT Server laufen; Archiv ohne Sicherung). Somit also nur noch 2 Clients mit Freigaben für alle. Dauerzustand ist das Ganze nicht, aber mindestens 6 Wochen sollte es noch so funktionieren (es kommen neue Server; der erste ist bereits fertig und der 2. wird ca 09/06 getauscht; diese enthalten dann auch das kpl. SW-Archiv). Zudem ist genaugenommen kein Zugriff Netz W auf Clients Netz K erforderlich, sondern nur umgedreht (für Projektarchiv reicht Subnet-interner/standortinterner Zugriff; nur das SW-Archiv muss auch vom anderen Subnet erreichbar sein). Die normalen Clients sind nicht als Datenablage bestimmt und werden auch nicht dafür verwendet. Was aber so auch wegfällt, aber gebraucht wird: Remotedesktop-Zugriff auf Clients im anderen Subnet (sollte von jedem zu jedem möglich sein).

Das deckt sich soweit mit meinem Wissen. Trotzdem schien das heute mit den Credentials auf dem einen Client anders zu sein.

Das Systemhaus weiß nicht wirklich Bescheid, da es auch erst seit Kurzem involviert ist Selbst bin ich auch erst wenige Wochen für das Netz zuständig und die Dokumentation lässt an manchen Punkten zu wünschen übrig. So weiß ich z.B. fast nichts über die phys. Verkabelung (direkt am Server,...). @lefg Die Funkrouter sind als Router konfiguriert Ist für den Direktzugriff (\\IP oder \\Name) definitiv WINS erforderlich, sobald das Subnet-übergreifend erfolgt? Der Zugriff auf die Server erfolgt dann auf andere Weise (da dies ja funktioniert)? Wenn dem so ist, führt wohl kein Weg daran vorbei - Wins-Server zu installieren und - auf zahllosen Clients Netbios-Namen einzurichten Gibt es vielleicht eine Möglichkeit zum Umgehen des Problems (ideal wäre es, wenn man auf den Servern eingerichtete Netz-Laufwerke (die auf die entsprechenden Clients weisen) freigeben könnte - mit Bordmitteln geht dies aber nicht.

Noch keine Zeit. Hatte ein anderes Problem zu lösen: User-LW eines Users auf 1 PC werden nicht gemappt. Login-Script fragt nach PW, akzeptiert das vom User aber nicht. Habe festgestellt, dass (u.a.) das Script merkwürdigerweise unter anderem Kontext ausgeführt wurde (alter Admin-Account). Da dieser seit 10 Tagen deaktiviert ist, kam beim Verbinden die Fehlermeldung "Konto ist deaktiviert". Komischerweise ging es mit dem gleichen Nutzerkonto auf anderen Clients; andere User gingen auf dem betroffenen; Konten zurückgesetzt, Computer-Konto gelöscht+neu Dom beigetreten, lokales Userkonto gelöscht/neu erstellt; letzte Win-Updates zurückgerollt > alles erfolglos. Verbinden auf Name hat schließlich funktioniert / auf IP aber nicht (Pingen auf beides aber OK). Zudem festgestellt, dass unter ihrem Konto kein Lesezugriff auf ihr Login-Script bestand (trotz Lesefreigabe für "Jeder"). Ihr Konto separat hinzugefügt > OK; funktioniert soweit alles wieder. Der Verdacht liegt nahe, dass für bestimmte Aufgaben (wenn kein Zugriff/Ausführen möglich ist), automatisch Credentials eines zweiten Accounts (Admin alt), die lokal zwischnegspeichert wurden, verwendet werden - wo kann man diese einsehen/löschen? Mit dem lokal gespeicherten Profil des Admin-Accounts sollte es ja nichts zu tun haben? Soweit funktioniert das jetzt wieder (auch nach Neustart; vorher wurden trotz Ab-/Anmelden wohl die Zweitaccount-Credentials genommen, da der Fehler dann nicht, aber nach dem Neustart auftrat).

jeweils beide

WINS wurde mir vom Systemhaus als Ursache benannt. Habe gerade festgestellt, dass der Zugriff DC > Client anderes Subnet auch nicht geht. Wie bereits geschildert, ist die Win-Firewall per Default Domain Policy definiert - mit diversen Ausnahmen für so einige Anwendungen. Ich kann mir per gpmc und Richtlinienergebnissatz anzeigen lassen, dass die RL aktiv ist, aus welcher Policy sie kommt und wo sie eigentlich zu finden sein müsste. Allerdings fehlt der Unterpunkt zum Kfg der Firewall komplett (da, wo er eigentlich sein müsste). Bei anderen RL (z.B. lokale RL) wird er genau dort angezeigt. Tests wurden mit DCs W2k (importierte Templates von XPSP2 und danach W2k3) sowie von 4 XPSP2-Clients durchgeführt (einer x64, 3 x32); Rechner stehen in beiden Subnets; Ergebnis ist immer das Gleiche (obengenannte). Am Freitag habe ich die Domain noch in 2 Standorte (sites) aufgeteilt mit den entsprechenden Einstellungen. Das ist zwar nicht unbedingt nötig, kann aber die Replikation optimieren. Auf das geschilderte Problem sollte das keinen Einfluss haben. Noch mal: wie kann ich testen, ob die Ports an den Routern frei oder gesperrt sind? Habe ich mit telnet etwas falsch gemacht, oder gibt es noch weitere/bessere Tools? Mit netstat -na werden mir die freien ports des Client-PCs angezeigt - aber nicht vom Router. Eine Liste der meiner Meinung nach freizugebenden Ports: 21 TCP FTP 25 TCP SMTP 53 TCP+UDP DNS 80 TCP HTTP 88 TCP+UDP Kerberos Secure Authentication 123 TCP NTP Time 135 TCP MS Networking 137 UDP MS Networking >>> auch TCP?? 138 UDP MS Networking 139 TCP MS Networking 389 TCP LDAP >>> auch UCP?? 443 TCP SSL 445 TCP NetBIOS over TCP/IP >>> auch UDP?? 464 TCP UDP Kerberos Password 1025 oder 1026 TCP AD logon + directory replication 3268 TCP MS Global Catalog 3269 TCP MS Global Catalog w/ LDAP/SSL 3389 TCP RDP 4125 TCP connect to server desktop

Auf den Servern läuft keine Firewall, da diese ja nur W2k haben. In Verdacht ist jetzt WINS: dieses ist nicht implementiert (keine Wins-Server und 98% der Clients ohne Netbios-Name). Zu öffnende Ports wären 389 und 4125 Das Testen offener Ports sollte doch mit telnet auf den betr. Router und Angabe des Ports möglich sein? Bekomme da immer "Connect failed/Verbindung fehlgeschlagen" (auch vom DC aus - ohne Firewall). Sollte bei geschlossenem Port nicht "connection refused" kommen?

Der Patch von MS kam Freitag mittag und wurde auf allen 3 DCs eingespielt. Der eine Fehler hat sich damit erledigt (Weiterleitung an...). Der andere taucht aber auf 2 PCs immer noch ständig im Protokoll auf - Fehler 5504 ungültiger Domänenname im Paket von ... (nun immer von "fremder" IP)

Auf die Anforderung des Hotfixes gabs noch keine Antwort. Hier wird noch eine andere Vermutung genannt: Windows 2000 DNS - Event ID: 5504 I researched it and found, as Kevin said, that this is primarily caused by an illegal character in a host name. Illegal character such as a space or underscore. I found two Mac machines with those characters in their names, and guess what, I changed the names and the error disappeared. Abgesehen von Bindestrichen dürfte es in der Umgebung aber keine Sonderzeichen in Hostnamen geben (und Bindestriche haben alle Clients im Namen).

ADM-Template von XP SP2 auf 2k eingebunden. Die relevante Setting sollte ja in der system.adm sein. Alles ist korrekt eingebunden; der entspr. Eintrag wird aber trotzdem nicht angezeigt. Habe nun nach einem Gespräch mit einem Systemhäusler noch einen heißen Tipp bekommen: es könnte an einem Dienst auf dem Server liegen, der deaktiviert werden muss. Das Problem wäre bekannt. Welcher Dienst das sei, soll mir in den nächsten Stunden mitgeteilt werden (Ansprechpartner dafür außer Haus).

Dem ist aber nicht so - habe ja schon alles mögliche probiert. Um die andere Fragestellung noch einmal zu präzisieren: kann es überhaupt ein geblockter Port sein, wenn der Zugriff DC > DC und Client > DC zwischen beiden Netzen funktioniert? Oder anders: was ist beim Traffic Client > Client anders als beim Traffic zum DC?? Werden wirklich andere Ports/Protokolle verwendet???