Jump to content

Client meldet sich am falschen "Logonserver" an


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

 

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

... 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 von lefg
Link zu diesem Kommentar

 

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:

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...