Blase 15 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Hallo, haben eine Domäne Firma.local an zwei Standorten. Standort A (192.168.100.0/24) ist sozusagen der Hauptstandort, wo fast alle Clients sich aufhalten. Dort stehen auch zwei DCs, DC1 und DC2, welche den Clients dort als primärer (DC1) und sekundärer (DC2) DNS zugewiesen sind. Standort B (192.168.200.0/24) ist in einer anderen Stadt und über VPN sind die beiden Netze Verbunden. Im Standort B steht DC3 und ist für die dortigen Clients der DNS Server. Die DCs sind alle mit Windows Server 2003 R2 SP2 ausgestattet. Im Bereich AD Standorte und Dienste sehe ich alle Drei Server im Bereich der Default-First-Site und die NTDS Settings sind alle automatisch übertragen. Alle drei sind GCs. Soweit sieht augenscheinlich alles gut aus. Ein Client aus Standort A meldet sich aber am DC3 aus Standort B an. Wenn ich in der CMD "set" eingebe, sehe ich, dass der "Logonserver" DC3 ist. Das ist natürlich alles grotten langsam! Die Frage ist, wie bringe ich diesem einen Client wieder bei, dass er sich wie gewohnt wieder an DC1 anmeldet? MfG Blase Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 (bearbeitet) ..... Im Bereich AD Standorte und Dienste sehe ich alle Drei Server im Bereich der Default-First-Site Hallo, ob das aber so richtig ist? Müsste nicht der Branch Office-Standort definiert sein mit dem DC3? bearbeitet 19. September 2013 von lefg Zitieren Link zu diesem Kommentar
Blase 15 Geschrieben 19. September 2013 Autor Melden Teilen Geschrieben 19. September 2013 Hmmm, keine Ahnung um ehrlich zu sein. Diese Konstellation läuft seit bestimmt.... 4 Jahren so und bisher absolut problemfrei. Nie hat sich ein Client dort angemeldet, wo er "nichts" zu suchen hatte. Heute scheint das das erste Mal so zu sein. So gesehen - MUSS das so eingestellt sein, wie Du sagst? Hatten wir bisher einfach Glück? MfG Blase Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 (bearbeitet) Ich schlage dir vor, warte auf weitere Meinungen dazu oder lese es nach! Interessehalber: Was ist aber das primäre Problem? Womit gibt es ein Problem? bearbeitet 19. September 2013 von lefg Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Die DCs sind alle mit Windows Server 2003 R2 SP2 ausgestattet. Im Bereich AD Standorte und Dienste sehe ich alle Drei Server im Bereich der Default-First-Site und die NTDS Settings Definiere einen neuen AD-Standort "Aussenstelle" und ordne ihm das Subnet 192.168.200.0/24 zu. Danach verschiebst du den DC3 in dieses Subnet und wartest ein paar Minuten-Stunden. ;) Soweit sieht augenscheinlich alles gut aus. Sehe ich anders. Ein Client aus Standort A meldet sich aber am DC3 aus Standort B an. Nein, er meldet sich an einem DC seines Standorts an. Wenn du die Standorte nicht ordnungsgemäß definierst, was soll der Client denn tun? Bye Norbert Hmmm, keine Ahnung um ehrlich zu sein. Diese Konstellation läuft seit bestimmt.... 4 Jahren so und bisher absolut problemfrei. soso, das wird kaum stimmen. ;) Denn deine Konfiguration tut nichts, dass es nicht auch schon vor 4 Jahren zu solchen Fällen gekommen sein kann. Nie hat sich ein Client dort angemeldet, wo er "nichts" zu suchen hatte. Soso. Und wieso sollte er dort "nichts" zu suchen haben? Ein wenig administrieren mußt du schon selbst. Bye Norbert Zitieren Link zu diesem Kommentar
Blase 15 Geschrieben 19. September 2013 Autor Melden Teilen Geschrieben 19. September 2013 Hallo Norbert, also lass es mich so formulieren: Da ich ja das "Ergebnis" aktuell sehe, was das grade für Auswirkungen hat und ich davon ausgehe, dass das das "normale" Anmeldeverhalten ist, wenn der "falsche" DC angesprochen wird, so hätte ich ganz sicher im laufe der letzten Jahre Feedback des einen oder anderen Benutzers bekommen, wenn es bei ihm auch so gelaufen wäre. Wir überwachen die Anmeldung nicht und ich weiß natürlich nicht, wo sich welcher Client tatsächlich anmeldet. Aber wie gesagt davon ausgehend, dass dieses elendig verzögerte Anmelden "normal" ist, wenn übers WAN der "falsche" DC angesprochen wird, hätte ich das schon von anderer Stelle erfahren. Also glaube es oder eben nicht - ich habe hier keinen Grund zu lügen - aber diese Auffälligkeit habe ich heute zum ersten Mal und wie ich sehen konnte, ist sein Logonserver halt der "falsche". MEIN (ganz persönlicher) Rückschluss ist halt, dass es direkt damit zu tun haben muss. Ich habe das Problem verstanden - es gibt, bezogen auf das AD, nur einen Standort bei uns und da kann jeder Server als Anmeldeserver fungieren. In meinem gefährlichen Halbwissen nahm ich bisher an, dass die Zuweisung des "richtigen" DNS Servers auf Clientseite diese Problematik umgeht - wie gesagt, hatte ja bisher auch keine Probleme damit. Durch die Zuweisung des IP Netzes von Standort B zum neuen AD Standort "Außenstelle" wissen alle Clients im Standort B automatisch, dass das "ihrer" ist? Und die Clients im Standort A fassen den nicht an, weil es eben nicht ihr IP Bereich ist? Anders gefragt, mehr muss ich nicht machen - außer warten? Hab vielen Dank für Deine Antwort. MfG Blase Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Durch die Zuweisung des IP Netzes von Standort B zum neuen AD Standort "Außenstelle" wissen alle Clients im Standort B automatisch, dass das "ihrer" ist? Und die Clients im Standort A fassen den nicht an, weil es eben nicht ihr IP Bereich ist? Anders gefragt, mehr muss ich nicht machen - außer warten? Du kannst dich zur mentalen Unterstützung natürlich auch noch 3mal gegen die aufgehende Sonne verbeugen. ;) Ansonsten hilft es, sich mit der Materie zu beschäftigen. http://technet.microsoft.com/en-us/library/cc782048(v=ws.10).aspx Bye Norbert Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Ich fragte in Beitrag '4, was denn das primäre Problem sei. Das Anmelden an sich einen entfernten DC muss überhaupt nicht das primäre Problem sein. Was sist also das primäre Problem, wie macht es sich bemerkbar? Ansonsten empfehle ich den Rat von Norbert. Zitieren Link zu diesem Kommentar
Blase 15 Geschrieben 19. September 2013 Autor Melden Teilen Geschrieben 19. September 2013 Ich fragte in Beitrag '4, was denn das primäre Problem sei. Ah, entschuldige. Das muss ich übersehen/-lesen haben. Das Problem war eine elendig lange Anmeldung eines AD Benutzers auf seiner Maschine. Mehrere Minuten für das Login, bis man unter Windows wirklich was machen kann. Dann der Outlook Start (Exchange im Standort A), welcher ebenfalls ewig dauert und auch bis der Internet Explorer "einsatzbereit" ist, vergeht massig Zeit. Gut, wahrscheinlich hat man einfach noch zu nah am Windows Start selbst die anderen Programme gestartet und das war einfach ein Nebeneffekt der ohnehin stark verzögerten AD-Windows-Anmeldung... Und als ich gesehen hatte, dass der LogonServer unser DC3 ist, welcher hier überhaut nicht steht, war mein "Schuldiger" gefunden... zumindest mein PC (sehen das über BGInfo an den Clients) hatte sich in den letzten Jahren noch nie an DC3 angemeldet... Du kannst dich zur mentalen Unterstützung natürlich auch noch 3mal gegen die aufgehende Sonne verbeugen. ;) Wenn ich mal Sonne hier hätte!!! :wink2: Ok, ich habe das so gemacht. ich habe jetzt eine zusätzliche Site unseres entfernten Standortes und im Bereich der Server unseren DC3 dort hinein getan. Zusätzlich habe ich, weil wir es vorher noch überhaupt nicht konfiguriert hatten, sowohl unseren Standort als Subnet eingetragen (192.168.100.0/24) und der Default-first-site zugewiesen, als auch 192.168.200.0/24 angelegt und dem entfernten Standort zugewiesen. Habe auf dem DC3 grade geschaut - die Informationen sind bisher nicht vollständig dort repliziert. Die neue Site steht dort und er ist da drinnen, aber bei den NTDS Settings taucht dort bisher unter "automatisch generiert" nur der DC2 auf, der DC1 fehlt noch. Aber Du sagtest ja, könnte ein wenig dauern.... Eine Frage hätte ich in diesem Zusammenhang noch - um meine Wissenslücken zu schließen ;) Nach welchen Kriterien "wählt" ein Client seinen Anmeldeserver? Wenn mehrere zur Verfügung stehen, woher weiß der Client, welchen er davon nimmt/nehmen soll? MfG Blase Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Eine Frage hätte ich in diesem Zusammenhang noch - um meine Wissenslücken zu schließen ;) Nach welchen Kriterien "wählt" ein Client seinen Anmeldeserver? Wenn mehrere zur Verfügung stehen, woher weiß der Client, welchen er davon nimmt/nehmen soll? http://blog.dikmenoglu.de/Dom%C3%A4nencontroller+Am+Standort.aspx Bye Norbert Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 (bearbeitet) ... Das Problem war eine elendig lange Anmeldung eines AD Benutzers auf seiner Maschine. Mehrere Minuten für das Login, bis man unter Windows wirklich was machen kann. Dann der Outlook Start (Exchange im Standort A), welcher ebenfalls ewig dauert und auch bis der Internet Explorer "einsatzbereit" ist, vergeht massig Zeit. Ist das möglicherweise nicht die Anmeldung selbst sondern ihr Nachfolgendes, wie das Laden der Benutzereinstellungen? bearbeitet 19. September 2013 von lefg Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Im Endeffekt ist das aber egal, denn das Problem tritt durch oben genannte und inzwischen beseitigte Fehlkonfiguration auf. ;) Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Im Endeffekt ist das aber egal, denn das Problem tritt durch oben genannte und inzwischen beseitigte Fehlkonfiguration auf. ;) Ja, scheint so. Könnte dahinter noch eine weitere Fehlkonfiguration stecken? Zitieren Link zu diesem Kommentar
Blase 15 Geschrieben 19. September 2013 Autor Melden Teilen Geschrieben 19. September 2013 http://blog.dikmenoglu.de/Dom%C3%A4nencontroller+Am+Standort.aspx Danke Dir für den Link. Ein, zwei Fragen hätte ich dazu noch, wenn ich darf :wink2: Yusuf schreibt, dass bei der Verschiebung eines DCs an einen anderen Standort eine Standortverknüpfung für die Replikation zu erstellen ist. Ich habe aber nun ohne mein Zutun bereits einen "DefaultIPSiteLink" im Bereich "Inter-Site Transport" unter "IP", wo auch beide Standorte bereits drinnen verknüpft sind. Ist das jetzt so, weil es neben der Default-First-Site mein erster weiterer Standort ist und er diese immer automatisch verknüpft? Also müsste ich das erst manuell machen, wenn ich noch weitere Standorte hinzufüge? Und eine andere Frage bezüglich des Zeitplans der Replikation. Wählt man sinnvollerweise ein Intervall, welches außerhalb der normalen Geschäftszeiten liegt, um die WAN Schnittstelle nicht zusätzlich zu belasten oder wählt man lieber grade ein eher durchgängiges Intervall, um Änderungen "sofort" zu Replizieren? Alles eine Frage der Bandbreite und Änderungsflut im AD? Letzteres dürfte sich ja, grade in kleineren Netzen, äußerst in Grenzen halten, weswegen der Zeitraum wiederum ziemlich egal ist, oder? Demnach ist auch das eigentliche Intervall von wegen "Replizieren alle X Minuten" (Standard 180 Minuten) ziemlich egal, oder? MfG Blase ps. bin wirklich dankbar und freue mich über Input! :thumb1: Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 19. September 2013 Melden Teilen Geschrieben 19. September 2013 Wie groß ist deine Umgebung? Das was da seit 2003 an Replikation drüber geht macht jede blöde ISDN Leitung im Hauptbetrieb mit. Also immer auf 15 Minuten stellen fertig. Bye Norbert Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.