flooo

Hi, danke erstmal für deine Antworten und deine Bemühungen! Wenn ich die Einstellung setze, ändert sich in der Tat etwas. Erst kommt diese Antwort: Und dann nach nochmal probieren (eine Minute später): Wenn ich den Haken dann wieder setze, erscheint wieder das alte Bild: C:\Users\<Benutzername>>nslookup 192.168.19.23 Server: <domaincontroller>.<domain>.eu Address: 10.51.64.2 Name: localhost Address: 192.168.19.23

Hallo, weitergeleitet wird an unseren ISA Server, der wiederum als Weiterleitungen die DNS Server unseres Providers eingetragen hat.

Für diesen Bereich bekomme ich auch die erwartete Antwort, eine Reverse-Lookup-Zone existiert. Für diesen Bereich bekomme ich "localhost" zurück, es existiert im DNS KEINE Reverse-Lookup-Zone.

Hallo, wenn ich wirklich eine nicht vergebene IP aus einem Bereich anpinge, in dem auch Geräte vorhanden sind, d.h. ein Bereich der auch genutzt wird, bekomme ich die Antwort "Unbekannt" zurück. Nehme ich z.B. 192.168.29.x oder 10.51.49.x (beide werden nicht genutzt, d.h. sind auch nirgends definiert), bekomme ich "Localhost" zurück. Alle DNS Server sind Active Directory 2003 Domain Controller.

Hier die Konfiguration. Es handelt sich aber nicht um das Problem eines einzelnen Rechners, von Windows und Linux besteht zum Beispiel das gleiche Problem und es trat erst seit dem 3. Dezember auf. Wenn ich NSLOOKUP auf eine unbekannte bzw nicht vergebene IP in einem bekannten IP Bereich mache, dann bekomme ich die entsprechende Antwort zurück, also "Unknown". Wenn ich jedoch eine IP aus einem undefinierten lokalen (z.B. 192.168.191.123) Addressbereich benutze, bekomme ich als Antwort "localhost".

Hallo, normalerweise würde man ja "Unknown" als Antwort auf eine Abfrage nach einer unbekannten IP Adresse (z.B. nicht vergebene IP) vom DNS Server erhalten, wenn diese nicht als Eintrag gefunden wird. Wir erhalten seit kurzem immer "localhost" (getestet von verschiedenen Rechnern) zurück. Hat jemand eine Idee woran das liegen könnte?

Hallo, wir setzen ISA2006 ein und bei einem User gibt es ein kleines Problem, seitdem dieser durch die Kennwortrichtlinien des AD gezwungen wurde, sein Passwort zu ändern. Jedesmal wenn er ins Internet will (Proxy über ISA) wird er aufgefordert sein Benutzername und Kennwort einzugeben. Auf interne Seite kann er problemlos drauf und wird dort auch über seinen Windows Logon erkannt (z.B. im Sharepoint). Er meldet sich am Windows mit seinem neuen Kennwort an und auch wenn er bei der Aufforderung des IE Domänenuser und Kennwort (auch das neue) angibt, kann er surfen. Kann es sein, dass der PC hier irgendwo noch etwas gecacht hat ? Komisch war auch, dass der User selbst nicht auf das bevorstehende Ablaufen des Kennworts hingewiesen worden ist, sondern irgendwann anrief, dass er sich nicht mehr einloggen kann. Das Problem hat auch nur dieser eine User und einer aus einem anderen Standort. Bei allen anderen Usern scheint es normal zu laufen (sie verwenden auch dieselbe Konfiguration). Achso vielleicht noch nicht unwichtige Angaben: WinXP, IE6, letzte Updates installiert (genau wie beim ISA selbst auch).

Vielleicht noch eine Frage zu der Verteilung der Rollen. Sollten die Rollen wirklich alle auf einem Server lagern oder besser auf 2-3 verteilt werden, um z.B. einem Totalausfall zu entgehen, wenn dieser eine Server ausfällt? (Es läuft hier ja neben den 4 AD Rollen auch noch IAS und Sub-CA). Zum Glück lässt man uns in Europa da recht viel eigenen Freiraum und will auch gar nicht mit den Problemen einer Migration konfrontiert werden, von daher müsste die Initiative dann wohl von uns ausgehen und logischerweise würde unser Domäne dann auch in die der Muttergesellschaft integriert werden, da es einfacher ist 800 Maschinen und User zu migrieren als >20000 :-) Wir wollen jedoch erstmal in die Richtung einer einzigen europäischen Domäne, da wir auch die einzigen sind, die überhaupt Child Domains nutzen und das in der Vergangenheit schon immer Nachteile mit sich gebracht hat. Danke erstmal an alle für die sehr aufschlussreiche Diskussion!

An den Standorten innerhalb der Hauptdomäne ca 300 Workstations und Server, wobei wahrscheinlich in absehbarer Zeit zwei Standorte integriert werden, d.h. wir sind bei ca. 450-500. Die dann zwei übrig bleibenden Child Domains haben nochmal jeweils 150. Das wäre sicher ein denkbarer Schritt, ich bezweifle aber, dass das aus organisatorischer Sicht überhaupt möglich ist (technisch sicherlich). Wir haben in Europa nur ca. 800 Maschinen, die im AD vorhanden sind, im asiatischen Raum sind es dann aber schon über 20.000. In Amerika dürfte es ähnlich wie in Europa sein. In Europa ist eine Konsolidierung wahrscheinlich sinnvoll und auch in den nächsten Jahren machbar, weltweit würde es technisch auch gehen, aber es würde eine immensen organisatorischen Aufwand bedeuten, der wahrscheinlich den Benefit übersteigt. DNS ist auf jedem Domain Controller installiert, nur einen GC gibt es nur einmal pro Standort. Das werde ich dann ändern, eigentlich sollte das ja auch dann das Logon Problem lösen, da der Client ja nicht einen DC in einem anderen Standort dafür kontaktieren muss, wenn ich das richtig verstanden habe?

Hallo, erstmal Danke für die schnellen Reaktionen und die Links. Das der Standort des IMs unwichtig ist, wenn alle DCs auch GC sind, war mir bewusst, die Frage ist nur, ob das nicht zuviel Traffic erzeugt. Im Moment sind alle Standorte mit dem HQ über 2mbit Standleitung verbunden. Das HQ selbst ist mit 6mbit an den Backbone angeschlossen, da die anderen Standorte auf das HQ zugreifen. Welche Überlegungen sollte ich in dieser Richtung noch anstellen? Wir streben mittlerweile auch eine Konsolidierung zumindestens auf Kontinentebene an, d.h. in Europa sollten alle Standorte in eine Domain. Das ist allerdings ein Prozess der sich nicht mal eben umsetzen lässt und daher werden wir wahrschein noch mindestens 1-2 Jahre mit der momentanten Struktur leben müssen. Die Standorte und IP-Adressbereich sind übrigens unter "Sites and Services" vollständig konfiguriert. Anhand der Reaktionen und der Artikel kann ich sehen, dass es zwar nicht Default, aber durchaus verbreitet ist, alle DCs auch zu GCs zu machen. Das heisst wiederum, dass es von Haus aus normal ist, dass wenn der GC in einem Standort ausfällt, die Clients und auch andere Applikationen ewig lange für einen Anmeldevorgang benötigen. Ich frage, da ich es von meinem vorherigen Unternehmen eigentlich nicht so kenne und mir fast sicher bin, dass wir nur einen GC hatten. Zum DNS: Die Zonen unserer Domain und der Child Domains sind AD integriert. Die Kopie der Zone für den asiatischen und amerikanischen Raum, zu deren Domains wir Trusts haben, werden im Moment aber nur von einem DNS Server repliziert.

Domain example.com --> Standort 1 --> Standort 2 --> Standort 3 --> Standort 4 -> Child Domain country1.example.com -> Child Domain country2.example.com -> Child Domain country3.example.com -> Child Domain country4.example.com example.com selbst ist über 4 Standorte in DE verteilt. Die Child Domains werden in anderen Ländern betrieben. Jeder Standort hat seinen eigenen IP-Adressbereich im selben Subnetz. An jedem Standort existieren mindestens zwei Domain Controller. An Standort 1, dem HQ, steht der Windows 2k3 Enterprise Server und ein 2k3 Standard Server. Server 1 (2K3 Enterprise) hält bis auf den Infrastruktur-Master alle anderen 4 AD Rollen und ist gleichzeitig GC für den HQ Standort, ausserdem ist er Sub-CA und stellt die TRUSTs zu anderen Domains (Mutterfirma) her und hält im DNS eine Kopie der Zoneneinträge dieser anderen Domains. Server 2 (2K3 Standard) ist Infrastruktur-Master. Beide Server sind zusätzlich DNS und IAS Server. An den anderen Standorten sind jeweils 2 2k3 Domain Controller, die auch gleichzeitig DNS für den Standort bereitstellen. Einer von diesen ist immer der GC für den jeweiligen Standort. Die Frage ist jetzt, ob man im HQ nicht noch einen dritten Domain Controller zur Verfügung stellen sollte, der nur GC (und vielleicht dritter DNS) Server ist und praktisch nur für die lokale Clientanmeldung verantwortlich ist? Ausserdem beobachten wir immer wieder, dass wenn der GC Domain Controller in einem Standort ausfällt, alle Clients in diesem Standort manchmal bis zu 10 Minuten warten müssen bis sie sich anmelden können und auch alle anderen Vorgänge, die den GC erfordern unglaublich träge, wenn nicht sogar unmöglich sind. Hat irgendjemand eine Idee, woran das liegen könnte bzw. wie man die Struktur optimieren könnte ?

Hallo, leider kam es gestern zu einem kleinen Zwischenfall, der uns zwang auf einem Printserver alle (im Active Directory veröffentlichten) Drucker wieder neu zu installieren. Problem ist jetzt dass a) die Treiberversionen nicht mehr mit denen der Clients übereinstimmen und b) die Drucker aufgrund der neuen Active Directory-Veröffentlichung auch nicht mehr vom Client angesprochen werden können (trotz gleichem Freigabenamens). Deshalb besteht jetzt folgende Überlegung: 1. Alle Drucker existierenden Netzwerkdrucker auf den Clients via Logon Script entfernen (lokale Drucker sollten aber eigentlich unberührt bleiben, wegen z.B. PDF Drucker oder z.B. Drucker @ Home) 2. Da im Moment schwer zu entscheiden ist welcher User, welchen Drucker braucht, erstmal alle existierenden Drucker jedem Client zur Verfügung zu stellen Wobei Punkt 1. erstmal am wichtigsten ist, da sich im Moment der Effekt abspielt, dass der Client abstürzt, wenn er versucht die nicht mehr vorhanden Drucker anzusprechen. Hat jemand eventuell ein entsprechendes VBS Script, was das erledigen könnte ?

Hallo, existiert für das Problem kein Lösungsansatz, d.h. ist es wirklich erforderlich in der entsprechenden Subdomain sich einen eigenen Account anzulegen ? (So habe ich es im Moment gelöst)

Hallo, wir haben diverse Subdomänen für unsere Geschäftsstellen. Wir (also die Admins im HQ und damit auch Admins der Hauptdomäne und des Forests) müssen gelegentlich auf Mitgliedsservern der Subdomänen bei Problemen administrativ aktiv werden. Wir haben in den Geschäftsstellen/Subdomänen auch Admins, die auch in der "Domain Admins-Gruppe" der Subdomänen sind und sich dort eigentlich um die Server kümmern. Nur haben wir im HQ keinen administrativen Rechte auf den Mitgliedsservern (aber auch Workstations) der Subdomänen. Das ist auch schon das Problem. Ich könnte mir vorstellen, dass das mit der Erstellung von ein paar Universal Groups/Global Groups eventuell zu lösen wäre, nur wie ?

Hallo Nils, gibt es irgendeine andere Möglichkeit das Problem zu lösen ?