Problem mit servergesp. Profilen & mehreren Filialen

[stifler 10]

Hallo!

 

Ich betreu ein Unternehmen was aus 4 Filialen besteht und pro Filiale jeweils einen Standortserver besitzt welche via VPN mit der Zentrale verbunden sind.

 

Der AD-Abgleich usw. klappt wunderbar, leider hab ich ein Problem mit "Springern" also Usern die mal in Filiale A, dann Filiale B sind usw., da ich servergespeicherte Profile verwende und wenn der User also für den Standortserver der Filiale A den Profilpfad \\mt-srv-01\profiles\hans.mustermann hat und sich in Filiale B anmelden will, wo der Anmeldeserver ak-srv-01 heisst, entsteht das Problem, dass ganz einfach das Profil mit all seinen Daten nicht verfügbar ist.

 

Gibt's einen Trick wie man die Profile auf jedem Rechner verfügbar machen kann und sich auch von jedem Standort anmelden kann??

 

so far

stif

[zuschauer 10]

Hi stifler !

Eine einfache Variante wäre die Angabe %logonserver% bei der Festlegung des Profilpfades der Springer. Dann wird immer das auf dem jeweiligen Logonserver liegende Profil benutzt.

Du müßtest dann allerdings über einen Copy-Job (Backupprogramm oder z.B. mit Robocopy ) die Profile in den einzelnen Standorten abgleichen.

[stifler 10]

Hab mir heut Abend bisschen Campari in den Kopf gegossen :D und bin auf die Idee gekommen ob man nicht evtl. das ganze über Distributed File System lösen könnte??

 

D.h. Der Profilpfad wäre (in meinem Fall) z.Bsp.

 

\\RBW\dfsroot\home\%username%

 

... aber?! wie ist das ganze mit Windows NT 4.0 WS Clients verträglich, klappt das auf denen auch oder muss ich irgendeinen Client von MS nachinstallieren??

[grizzly999 11]

Ich vermute, das hat weniger was mit dem Nicht-Finden des Profils zu tun, als vielmehr mit der "langsamen Verbindung" zwischen den Standorten. Bei Erkennen einer solchen, wird das Serverbasierte Benutzerprofil nicht geladen. Man kann dieses Verhalten abschalten, bzw. den Wert für die langsame Verbindung hochsetzen: http://support.microsoft.com/default.aspx?scid=kb;de;227260&Product=WWin2000Ger

Man bedenke aber die Netzwerklast, die dann beim Laden des Profils auf der WAN-Leitung entsteht, vor allem bei großen Profilen.

 

grizzly999

[zuschauer 10]

@grizzly:

Das ist aber kein Spaß, wenn er dann mal eben 15 Minuten das Profil über die WAN-Strecke kopiert - und zum Feierabend dasselbe dann zurück !

 

@stifler: Solche standortübergreifenden Problem mit DFS zu erschlagen - daran haben wir auch schon gedacht, aber in der Praxis noch nicht getestet. Theoretisch geht das natürlich (auch für NT4 Clients - ohne Zusätze auf den Clients- das ist dann ein reines Server"Problem").

 

Das Problem, was wir da sehen und testen wollen, wie aktuell ist das DFS bei lahmen WAN-Strecken und was passiert, wenn die WAN-Verbindung ganz wegbricht ?

[dubbel 10]

he - endlich mal einer der das selb Problem hat wie ich.

 

Bei uns sind es auch 5 Neiderlassungen mit 60 User und darunter mehrere Springer. Eigentlich nichts besonderes.

Selbst wenn man die Ordner-Umleitung aktiviert sind die Profile noch recht groß.

 

Ich frage mich wie das andere Unternehemen realsieren?? Über das wir hier reden ist doch bestimmt kein Einzellfall - oder??

 

Es muss doch eine sinnvolle Lösung geben das jeder User sich an jedem Standort anmelden kann und sein Servergespeichertes Profil vorfindet.

 

Da muss sich Microsoft irgendwas dabei überlegt haben.

 

Hat denn noch jemand eine Idee??

 

 

MfG

DuBBeL

[stifler 10]

Also ich hab das DFS gerade auf den 3 Standortserver und dem Zentralserver mit der Hub-and-Spoke Replikationstopologie eingerichtet und zum Test ein paar MB in einen Testordner eingestellt - ich muss dazu sagen, dass die Profile nicht besonders groß sind (das wichtigste für die User sind die Outlook-Einstellungen) - und die Replikation ist überraschend flott.

 

Von der Anbindung her haben wir in der Zentrale eine 2 MBit Standleitung an die die anderen 3 STO-Server mit DSL-Business also 1,5MBit angebunden sind. Da die STO-Server nicht mit einander DFS-Daten austauschen - da Hub-and-Spoke - entlastet das das Nadelöhr von T-DSL zu T-DSL aufgrund des geringen Upstreams, da alles vom Zentralserver über SDSL 2MBit weiterverteilt wird.

 

Und jetzt muss ich noch die Funktionsfähigkeit und Interoperabilität mit den Userprofilen testen ;)

 

so far

stif

[zuschauer 10]

@stifler: Bin ehrlich gespannt auf Deinen Erfahrungsbericht ! :)

[stifler 10]

Nun, habe jetzt ca. 10 Profile auf den DFS-Stamm migriert und kann bisher sagen dass es prima funktioniert. Auch in einem kritischen Zustand nimmt das DFS bei Leitungsausfall danach wieder seine Arbeit auf und vervollständigt alles tadellos. So hab ich eine T-DSL 24h Zwangstrennung simuliert während ein ca. 40 MB großes Profil kopiert wurde. Die Verbinundgsaufnahme von STO-Server zu Master-Server zwecks AD-Replikation dauert hier immer ca. 5 Minuten, da zum einen der DynDNS-Hostname ca. 5 Minuten zum updaten braucht und danach noch die Router eine VPN-Connection herstellen.

 

Danach fing das DFS dort an wo es wieder aufgehört hatte und replizierte noch nicht verteilte Ordner & Dateien.

 

Wie es sich nun im Langzeitbetrieb bewährt? Schaun 'mer mal - hat der Kaiser schon gesagt.

 

Ich lass' euch sicher dran teilhaben :D