Jump to content

domainshare nicht immer auf der richtigen site


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

Empfohlene Beiträge

hallo zusammen,

 

ein kleines problem. wenn ich mich anmelde und dabei das share \\domain.net\netlogon fuers logon nutze und durch das script danach dann auch noch ein dfs share mappe, dann komme ich nicht immer am richtigen standort raus.

die subnets auf den jeweiligen sites sind soweit richtig, die dc's etc auch.

wenn ich jetzt nur mal so aus spass an der freude nslookup auf das share mache komme ich nach jedem "ipconfig /flushdns" oder reboot an einem anderen standort raus komplett random...

 

jmd eine idee woran das liegen koennte ?

 

gruss

Link zu diesem Kommentar
  • 2 Wochen später...

das problem ist leider doch noch nicht behoben...

 

wir haben mittlerweile festgelegt wie sich die dc's zu replizieren haben, per site link bridges.

 

wir kommen allerdings immernoch an anderen standorten raus fuer die aufloesung "domain.net" wie kann man fuer einen bestimmten standort festlegen das er nur seinen dc dafuer nutzt ?

also 10.49.1.0 auch immer 10.49.1.50 (dc) --- 10.32.1.0 immer 10.32.1.50 etc...

Link zu diesem Kommentar

ich hab gerade noch ein wenig weiter gesucht und herrausgefunden, das round robin auf den dns servern eingeschaltet ist.

 

wenn ich das auf jedem dc auf allen sites austelle sollte das die clients auf ein netz zwingen,oder !?

 

die clients fragen dann aber auch einen anderen dc, von einer anderen site, falls der lokale mal nicht zur verfuegung stehen sollte ?

Link zu diesem Kommentar

Hallo,

 

das Round Robin solltest Du nicht ausschalten.

 

Grundsätzlich nutzt DFS die sogenannte "Site-Awareness" seit Windows 2000, die jedoch in jeder Version des Windows Servers danach erweitert / verbessert wurde. Wenn Ihr also die Standardeinstellungen nutzt, sollten sich die Clients auf einen Server Verbinden, der sich im lokalen Subnetz des Clients befindet.

Ist dort kein entsprechendes Ziel vorhanden, wird je nach Betriebssystem ein Ziel ausgewählt, welches am "billigsten" außerhalb der eigenen Site liegt.

 

Dementsprechend folgende Fragen:

- Sind die Clients den gleichen Sites zugeordnet wie die DCs derselben Site?

- Sind die Subnetze den korrekten Sites zugeordnet?

- Sind die DCs im DNS korrekt registriert?

- Wurden die standard DFS Einstellungen für die Targets von jemandem bearbeitet?

- Um welche Client- und Serverbetriebssysteme handelt es sich genau?

 

Ggf. solltest Du einmal einen Netzwerktrace vom Anmeldevorgang eines Clients ziehen bzw. dem Verbinden zu einem DFS-Namespace, nachdem Du per

dfsutil /pktflush

den Cache gelöscht hast.

 

Danach zeigt Dir ein

dfsutil /pktinfo

wohin der Client "geschickt" wurde bzw. mit welchem Server er verbunden ist.

 

Viele Grüße

olc

Link zu diesem Kommentar

also:

 

- die clients sind den gleichen subnetzen wie die dc's

- die subnetze sind den richtigen site zugeordnet

- die dc's sind alle korerkt im dns registriert

- die standart dfs einstellungen sind nicht veraendert worden

- wir haben windows server 2003 r2 sp2 mit xp sp2 im einsatz

 

der client meldet sich an dem korrekten dc's der site an. laut "dfsutil /pkginfo" und auch "set" (logonserver).

 

das problem was wir haben ist nur in den clientnetzen vorhanden:

 

bsp:

 

dc 10.49.1.50 + memberserver 10.49.1.123 -> hier ist immer der oder einer der dc's an dem standort fuer "domain.net" eingetragen

gleicher standort nur im client netz 10.49.2.0 -> hier kommt alle halbe stunde ein anderer dc als ergebnis raus. wenn round robin aktiviert ist mit jedem "ipconfig /flushdns".

Link zu diesem Kommentar

Hallo,

 

entschuldige - aber irgendwie ist mir das Problem immer noch nicht ganz klar: Du schreibst zwar, daß die DCs und die Clients im gleichen Subnetz sind, relativierst diese Aussage jedoch wenig später wieder. Scheinbar liegen die Clients also doch in einem anderen Subnetz als die DCs? Sind beide Subnetze (Clients und DCs) der selben Site zugewiesen?

 

Weiterhin schreibst Du, daß sich die Clients immer auf verschiedene DCs verbinden - aber sicherlich doch nur auf verschiedene DCs der lokalen Site, nicht in der gesamten Domäne oder? Das ist das korrekte Verhalten.

 

Der Logonserver hat im übrigen nichts damit zu tun - das DFS-Referral kann auf einen anderen DC verweisen als auf den Logonserver.

 

Sollte es also so sein, daß sich die Clients auf verschiedene DCs des gleichen Subnetzes verbinden: Wo liegt das Problem dabei? Das Netlogon Verzeichnis ist doch Teil der FRS Replikation und somit auf allen DCs der Domäne (und damit auch der Site) vorhanden.

 

Viele Grüße

olc

Link zu diesem Kommentar

die dc's der sites sind in einem anderen subnetz als die clients, beide subnetze sind allerdings der gleichen site zugeordnet. dfs-referral und logonserver sind bei den clients immer der dc oder einer der dc's der site, das laeuft soweit auch wunderbar.

 

das problem liegt hier:

wenn die clients zb. das logonscript bekommen (von dem korrekten dc der site) und dadurch dann das dfs-share gemappt bekommen, sie auf "\\domain.net\share" gemappt werden. hierbei entsteht das problem das man fuer domain.net _nicht_ den lokalen dc als partner zurueckbekommen sondern irgendeinen anderen dc auf einer anderen site.

 

da fuer domain.net alle dc's mit ihrer ip eingetragen sind, verhaelt es sich wie round robin im dns. es sollte allerdings auch fuer die dfs-share der lokale dc gelten, tut er aber nicht.

 

bsp.:

server und client sind ueber die subnets der gleichen site zugeordnet!

 

ping von einem member server (10.1.0.10) im gleichen subnet:

 

ping domain.net -> 10.1.0.50

30 mins spaeter

ping domain.net -> 10.1.0.50

 

ping von einem client (10.1.1.123) in einem anderen subnet:

 

ping domain.net -> 10.52.0.50

30 mins spaeter

ping domain.net -> 10.43.0.50

 

usw.

 

gruss flip

Link zu diesem Kommentar

Hallo,

 

ich muß ehrlich sagen, daß Deine ganzen Beschreibungen ein wenig "konfus" wirken - ist nicht böse gemeint. Du solltest jedoch nicht unterschiedliche Baustellen miteinander verwechseln:

 

DFS hat rein gar nichts mit dem Logonserver oder auch mit Pings zu tun. Pings wiederum haben nichts mit dem Logonserver zu tun. Du vermengst hier also verschiedene Dinge, die unter Umständen nur in der Wirkung gleich sind, nicht jedoch in der Ursache.

 

1. Der jeweilige Logonserver wird also nach Deiner Aussage korrekt aus der Client-Site gewählt. Das ist soweit auch erst einmal sehr gut.

 

2. Nachdem der Cache Timeout bezüglich des DNS-Cachings auf dem Client abgelaufen ist, wird er bei einem Ping auf den Domänennamen das DNS befragen. Da hier bei einem Ping auf den Domänennamen tatsächlich Round Robin stattfindet, ist es verständlich, daß der Client unterschiedliche IP-Adressen von beliebigen DCs erhält. Soweit also auch kein Problem.

 

3. Greifst Du mit einem Client auf den Domain Namespace der Domäne zu (z.B. SYSVOL / NETLOGON), bekommst Du ein Referral auf einen DC der Domäne zurück. Da auf allen DCs das SYSVOL vorhanden ist, könnte das grundsätzlich erst einmal jeder sein. Da es jedoch die "site awareness" der Server und Clients gibt, sollte das Referral im Normalfall an einen Server der gleichen Site gegeben werden. Hier liegt also ein Problem.

 

Die Frage nach der DFS-Konfiguration sollte also noch einmal geprüft werden. Auch wenn Du die Antwort schon gegeben hast: Ist hier unter Umständen etwas verändert worden (siehe Disabling site awareness for Windows Server 2003 or for Windows 2000 DFS in a Windows NT 4.0 domain )?

 

Was sagt ein

dfsutil /sitename:<computer>

für einen betroffenen Client und einen nicht gewünschten DC?

 

Sind die "lokalen" DCs im DNS korrekt in der Client-Site registriert (siehe unterhalb von <site_name>._sites.dc._msdcs.domain.tld)? Findest Du dort unterhalb der entsprechenden Site unter Umständen DCs anderer Sites? Ich denke nich, daß es so ist - denn würdest Du auch nicht immer die lokalen Logonserver bekommen. Aber prüfen solltest Du es in jedem Fall.

 

Schau Dir zusätzlich auch einmal folgenden Link an: You may receive DFS referrals that contain a list of random DFS targets, random SYSVOL or NETLOGON referrals, or experience slow performance when you access a shared folder in a DFS namespace on a Windows Server 2003-based computer

Interessant ist hierbei (neben dem Hotfix) der Registry Key - standardmäßig ist jedoch die site awareness aktiv.

 

Viele Grüße

olc

Link zu diesem Kommentar

hi

 

dank dir erstmal fuer die weiteren ansaetze! und sry fuer das "konfuse geschreibsel" ;)

 

das dfs nicht zwingend was mit dem logonserver zutun hat bzw. die "pings" auch eine andere ursache haben koennen, war mir klar. Die sichtbaren auswirkungen haben mich nur ein wenig verwirrt, deshalb hab ich in verschiedenen bereichen angefangen zu gucken.

 

ich hab auf einigen der betroffenen sites round robin ausgeschaltet und das problem der verschieden aufgeloesten ip's ist geblieben. bzw hat sich dadurch dem chache-timeout angepasst (vorher ist bei jedem "ipconfig /flushdns"

die ip anders aufgeloest worden).

das problem, das die dfs-shares teilweise nicht gemappt werden konnten, ist uns allerdings erst aufgefallen, als wir versucht haben dfs fuer die fileservices

einzufuehren und dadurch fuer die user sichtbare konsequenzen erfolgt sind (vorher haben die user ja nicht gemerkt von welchem dc sie das logonscript erhalten)

 

fuer die siteawareness ist kein wert gesetzt bzw. der schluessel existiert nicht. daher sollte hier das problem nicht liegen.

 

der befehl dfsutil /sitename:<computername> funktioniert nicht. mit den eckigen klammern sagt er die syntax sei falsch, wenn ich sie weglasse gibt er mir die tooltips welche commands ich eingeben kann.

 

im dns auf den dc's sind die server soweit alle richtig den sites zugeordnet.

_ldap

_kerberos

_gc

 

der ansatz mit dem hotfix scheint mir am plausibelsten da wir einige dc's haben die leider nicht auf dem aktuellen stand sind.

 

danke und gruss flip

Link zu diesem Kommentar

Guten Abend,

 

das dfs nicht zwingend was mit dem logonserver zutun hat bzw. die "pings" auch eine andere ursache haben koennen, war mir klar. Die sichtbaren auswirkungen haben mich nur ein wenig verwirrt, deshalb hab ich in verschiedenen bereichen angefangen zu gucken.

 

Ok, alles klar. :)

Ist halt nur wichtig die einzelnen Themen genau auseinander zu dividieren, da man sich sonst verzettelt bei der Fehlersuche.

 

der befehl dfsutil /sitename:<computername> funktioniert nicht. mit den eckigen klammern sagt er die syntax sei falsch, wenn ich sie weglasse gibt er mir die tooltips welche commands ich eingeben kann.

 

Die "Klammern" sollten natürlich nur Platzhalter darstellen. ;)

Was genau hast Du denn eingegeben? Wenn beispielsweise der Client "Client1", ein Problem-DC (also den Du nicht haben willst) "DC1" heißt und die Domäne "domain.tld", lauten die beiden Kommandos:

 

dfsutil /sitename:Client1.domain.tld
dfsutil /sitename:DC1.domain.tld

 

der ansatz mit dem hotfix scheint mir am plausibelsten da wir einige dc's haben die leider nicht auf dem aktuellen stand sind.

 

Na mal schauen, dann verfolge doch einmal den Ansatz. :)

 

Wäre klasse, wenn Du Dich melden könntest, falls das Problem durch den Hotfix gelöst wird - interessiert mich. ;)

 

Viele Grüße

olc

Link zu diesem Kommentar

ahh ok den fqdn hab ich natuerlich nicht ausprobiert ;) und die klammern nur mal versucht als es nich ging..man weiss ja nie *g

 

aber leider kommt, auch wenn ich den fqdn nehme nur folgendes raus:

 

C:\Documents and Settings\xxx>dfsutil /xxx:xxx-dc1.domain.net

Unrecognized option "xxx:xxx-dc1.domain.net"

 

Microsoft® Windows Dfs Utility Version 2.1

Copyright © Microsoft Corporation 1991-2000. All Rights Reserved.

 

Dfsutil is an administrative tool to check the functionality of DFS.

 

Usage: dfsutil [/OPTIONS]

 

/? - Usage information

/ADDSTDROOT:<DfsName> /SERVER:<ServerName> /SHARE:<ShareName>

/ADDDOMROOT:<DfsName> /SERVER:<ServerName> /SHARE:<ShareName>

/REMROOT:<DfsName> /SERVER:<ServerName> /SHARE:<ShareName>

 

-----------The following are client-side only----------------

/PKTFLUSH - Flush the local DFS cached information

/SPCFLUSH - Flush the local DFS cached information

/PKTINFO [/LEVEL:<Level>] - show DFS internal information.

/SPCINFO - Show DFS internal information.

Done processing this command.

 

ich hab gerade mal geguckt ob es eine neuere version gibt...bei den xp support tools sollte die version 5.1.2600.0 dabei sein das util gibt aber eine version 2.1 aus...

 

die hotfixe bzw leider auch sp's einzuspielen wird noch ein etwas groesseres unterfangen (55dc's auf unterschiedlichen patchleveln) kann also noch ein wenig dauern bis ich hier ein ergebnis habe.

 

danke und gruss flip

Link zu diesem Kommentar

Hallo,

 

die Option "sitename" hatte ich nicht in Klammern geschrieben - also sollte dabei auch nichts eingesetzt werden. ;)

Das heißt: "/sitename:" ist die Option, die Du setzen mußt. Die einzige Variable ist also der FQDN der entsprechenden Maschine. Rückgabe des Kommandos ist die Site, in der die Maschine liegt. ;)

 

Aber das Kommando ist auch nicht unglaublich wichtig - es wäre halt nur interessant zu sehen, ob die "falschen" DCs in der korrekten Site angezeigt werden.

 

Vielleicht hilft der Hotfix ja.

 

Viele Grüße

olc

Link zu diesem Kommentar

Hi,

 

ja diese Option ist deaktiviert worden. Allerdings ist dies erst nachdem wir das Problem bemerkt haben passiert, sollte also nichts damit zutun haben.

 

Ich gehe zzt. davon aus das das Problem im DNS liegt. In "DomainDnsZones" habe ich insg. 5 IP-Adressen geloescht die keinem DC bzw. DNS Server zuzuordnen ist. Jetzt haben sich allerdings zwei der IP's wieder automatisch eingetragen...

 

Hast du ne Idee wie ich nachvollziehen kann wer diese hier eingetragen hat ? (MS hat zzt jedenfalls keine...)

 

Gruss Philipp

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...