[W2K] DFS-Root Replication UITDAGING!

[NetWorker]

Aangezien we een probleem hebben waar we niet 1-2-3 uitkomen het volgende:

Binnen ons Windows 2000 domein maken we gebruik van een 'DFS-Root' (Distributed File System). Dit domein is weer opgesplitst in een aantal 'Sites' (in dit voorbeeld Site A en Site .

Tegen welk probleem lopen we nu aan? -> Wanneer de DFS-Root in Site A er uit ligt, proberen de clients naar de DFS-Root van Site B te connecten en vica versa. Aangezien het hier een 'slow-link netwerk' betreft tussen deze twee sites is dit niet wenselijk.

Wat willen we dus? -> We proberen clients te stoppen een connectie te maken naar een DFS-Root replica buiten hun eigen site.

Oplossing? -> DFSUTIL.EXE (Microsoft): Deze util is ons bekend en heeft een 'undocumented' feature, namelijk /INSITE. Microsoft zegt zelf: [quote] 'will NOT get ANY referal for a replica outside their own side' [/end quote].

Dit zou dus moeten werken maar werkt niet bij ons ...


Test Opstelling:
We hebben als test-opstelling twee DC's, gescheiden door routers (dus 3 segmenten). De twee DC's hosten een 'Domain based DFS', waardoor ik dus twee Root-replica's heb. Wanneer ik een van beide DC's afsluit (Site A), alle caching opschoon (netbios, pkt, spc, dns) op alle machines, en een connectie probeer te maken naar de DFS-Root replica (buiten de eigen site welke dus nog wel actief is) vanaf de client, krijg ik na 40 a 50 seconden toch nog een connectie naar de andere site (Site . Dit zou dus niet mogelijk moeten zijn ...

WAT MIS IK HIER

[Han]

--> [forum=24]

[RedRose]

Dit is een beetje een wild guess, maar: gebruikersrechten? Volgens mij kan je heel site B dichtgooien voor gebruikers die naar site A zouden moeten gaan. Of alleen server A laten connecten naar server B en je clients in subnet A helemaal geen toegang laten geven tot subnet B Maar ik begrijp dat je dat niet wilt. Dan toch maar gebruikersrechten.

[NetWorker]

Nee helaas. Ik vind dit geen mogelijke optie. Denk aan de enorme administratie die er zou moeten plaatsvinden om dit voor elkaar te krijgen.

Ter info: In het voorbeeld ga ik uit van twee sites (A en . De werkelijkheid is iets complexer, namelijk: meer dan 10 sites en zo ongeveer 1750 gebruikers over het domein verspreid. Je kunt waarschijnlijk wel inzien dat dit niet echt een werkbare oplossing oplevert...

In ieder geval bedankt voor het meedenken ... Iemand anders misschien (of heb je zelf nog andere werkbare ideeen?)

[RedRose]

Even voor mijn beeld: wat mogen ze wel en wat mogen ze niet?

[Verwijderd]

Je DFS bestaat uit 2 machines?

In dat geval bij elke site een extra machine plaatsen die meedoet aan de DFS, zodat als je root eruit knalt, hij nog altijd bij een andere machine op dezelfde site kan kijken naar de bestanden.

En anders aan clustering denken zodat het altijd up blijft?

[joop3]

Volgens mij idd maakt ie standaard gebruik van de backup faciliteit door als site A eruit ligt ie automatisch naar site B gaat.

[RedRose]

Op vrijdag 03 mei 2002 12:46 schreef jeanpaultje het volgende:
Je DFS bestaat uit 2 machines?

In dat geval bij elke site een extra machine plaatsen die meedoet aan de DFS, zodat als je root eruit knalt, hij nog altijd bij een andere machine op dezelfde site kan kijken naar de bestanden.

En anders aan clustering denken zodat het altijd up blijft?

Daar heb je gelijk in, alleen heeft ie straks 10 servers en 1750 gebruikers... forse investering dan?

[NetWorker]

Misschien wederom ter aanvulling: Investering is niet ter sprake ... infrastructuur ligt er al, alsmede de servers etc. Waarom we DFS (willen) gebruiken is als volgt:

DFS geeft ons een middel om een eenduidige structuur aan de gebruiker aan te bieden... daarnaast is de replicatie van DFS erg goed en betrouwbaar. Maw: het maakt niet uit waar de gebruiker zich bevind. In elke Site is namelijk de DFS hetzelfde genaamd bijvoorbeeld \\DFSROOT\SHARE . Hieronder zouden we bijvoorbeeld installatie-software kunnen plaatsen voor alle gebruikers. Het principe is dan als volgt: wanneer er iets geinstalleerd moet worden op Site A dan kan dat aangeroepen worden als \\DFSROOT\SHARE (fysiek heet de server dan bijvoorbeeld \\SERVERSITEA). Wanneer hetzelfde op Site B, of C etc gedaan wordt dan geld ook installatie vanaf \\DFSROOT\SHARE (fysiek heet de server misschien dan \\SERVERSITEB of SERVERSITEC etc, etc).

Misschien was dit wat verhelderend?

Je kunt begrijpen dat installaties niet vanaf een andere server mogen komen als er een slow-link is (128kb/sec) ofzo... en je een installatie hebt van een paar honderd Mb.

[Predator]

Ik vond dit op technet:

How to Give Out Referrals to Client Site Servers Only
In DFS, if you are an administrator, you can force access to only those servers that are in the same site as the client, and not to any other servers. To do so, enable the following control on the entire DFS namespace (the DFS root and all its links) or on individual DFS links:

dfsutil /insite DFS_name_of_Root_Or_Link /set

dfsutil /insite DFS_name_of_Root_Or_Link /reset

When this behavior is set on the DFS root, the behavior is inherited by all the links under that root.

If you make changes to set or reset the in-site behavior, these changes do not go in to effect immediately. The DFS root replicas periodically synchronize with changes made to the DFS metadata, and the change goes in to effect when all root replicas have read the newly made changes.

NOTE : Use extreme caution when you set this change on a DFS root or link. If this change is set on a DFS link that does not have any replicas in a certain site, clients in that site are not able to access the data using the DFS namespace.

Het gebeurt wel maar na replicatie.

Dit is wel tegen de natuur van DFS maar dit zou moeten doen wat jij vraagt toch

Veel alternatieven kan ik niet bedenken,
ACL worden ook gesynced dus daar kan je niets mee doen.
Als je de 2 sites ook subnets kan scheiden misschien firewall connectie op de die DFS shares van andere clients uit andere site blocken ?

[NetWorker]

Dit artikel is mij bekend ... hieruit blijkt nou eenmaal dat het zou moeten werken maar helaas ... niet bij ons ... nu is dus de vraag: waarom niet? Wat hebben we over het hoofd gezien?

Zelfs na replicatie gebeurt het nog steeds ... (en dit hebben we echt een aantal malen getest hoor).

Een firewall is ook al bedacht maar welk verkeer ga je dan tegenhouden? Je wilt wel dat replicatie plaatsvindt van de DFS en dat clients natuurlijk nog wel andere servers kunnen benaderen in andere Sites... (Als het zo makkelijk zou zijn had ik dit natuurlijk al gedaan maar ik wil enkel en alleen in deze situatie = DFS, de toegang weigeren). Daarnaast zijn Firewall licentie's (vooral als je echte gebruikt) erg duur voor deze oplossing ... (laat staan de Hardware).

[Verwijderd]

Ik heb niet al te veel ervaring met DSF maar als blijkt dat na de replica nog steeds connecties plaats vinden. Misschien zou het handig zijn om de shares, in de sites met een slow link, anders te noemen.

Bijv.
\\dfsroot\share (voor compleet domijn)
\\dfsroot\sharesl (sl = slow link, voor slow link sites)

sharesl shares zullen dan niet gevonden worden buiten de slow site en zal er ook geen grove data transfer plaats vinden over de router.

[NetWorker]

Zo werkt het niet helemaal helaas. De \\DFSROOT\SHARE zoals de client deze ziet is opgebouwd uit de volgende servers/shares:
\\SERVER1\SHARE1
\\SERVER2\SHARE2
\\SERVER3\SHARE1

Waarbij dus niet de shares bepalend zijn van de server zelf maar de \\DFSROOT\SHARE... snap je Kijk anders eens op http://www.microsoft.com/windows2000/techinfo/planning/fileandprint/dfssteps.asp voor meer info hieromtrent.

Daarnaast zou je dan geen eenduidige benaming hebben en dat is nu juist waar het hier om gaat. Anders hadden we wel gewone shares per server kunnen vertellen aan de gebruikers. Dan hadden we geen DFS nodig gehad.

[NetWorker]

JOEPIEEE WERKEND!!!

Wat was/is nu het probleem: een aanpassing in de DNS structuur binnen het domein. Wat gebeurt er namelijk:

een client heeft de beschikking over een aantal dns-servers, bijvoorbeeld dns3 (dns server op de site A), dns1 en dns2 (site . Dns1 is primairy DNS server met de W2K server records en is tevens DC. Op een site staat ook een DC met een eigen DNS server (replica van dns1) genaamd Dns3. Wanneer de client echter de DFS aanspreekt op de site (dus via dns3) zal hij de dfs-root krijgen die dns3 aangeeft namelijk die in zijn eigen site (dfs3). Wanneer de dfs3 er uit ligt (bijv: problemen met server) en deze tevens op de dns3 server staat (waardoor dns het ook niet doet) gaat de client naar de 2e dns server in zijn lijst namelijk dns1 of dns2. Deze servers weten dat de dfsroot binnen die Sites dfs1 en dfs2 zijn en stuurt de client daar naar toe. (dat was dus het probleem van de 40-50 seconden en dan toch nog dfs krijgen).

Om dit te omzeilen hebben we de client een andere dns volgorde gegeven en andere dns servers, namelijk: dns3 (nog steeds) maar als tweede dns server een nieuwe dns server welke geen server records heeft van het domein (dnsX). Hierdoor kan de client nooit een verwijzing krijgen buiten zijn domein wanneer de dns server er uit ligt.

Is dit duidelijk of niet?

[Predator]

Op vrijdag 03 mei 2002 14:38 schreef NetWorker het volgende:
Dit artikel is mij bekend ... hieruit blijkt nou eenmaal dat het zou moeten werken maar helaas ... niet bij ons ... nu is dus de vraag: waarom niet? Wat hebben we over het hoofd gezien?

Zelfs na replicatie gebeurt het nog steeds ... (en dit hebben we echt een aantal malen getest hoor).

Een firewall is ook al bedacht maar welk verkeer ga je dan tegenhouden? Je wilt wel dat replicatie plaatsvindt van de DFS en dat clients natuurlijk nog wel andere servers kunnen benaderen in andere Sites... (Als het zo makkelijk zou zijn had ik dit natuurlijk al gedaan maar ik wil enkel en alleen in deze situatie = DFS, de toegang weigeren). Daarnaast zijn Firewall licentie's (vooral als je echte gebruikt) erg duur voor deze oplossing ... (laat staan de Hardware).

Dat verkeer kan je toch wel uit elkaar houden.
Je moet dan ook niet alles gaan blocken.
Gerichte block rules voor de clients uit die 2 sites en die TCP connecties naar de andere share(s) op de andere DFS server.
DFS servers zelf exclude je.

Maar dat kost dan weer geld indd en voor zo een beperkt doel is da ook niet echt gerechtvaardigd.

Ik heb nog eens zitten lezen maar ik vind weinig waarmee je jouw probleem op een andere manier met DFS/FRS kan oplossen.

Er zijn precies 2 manieren om /insite te gebruiken,
zonder args op de DFS root:
DFSutil /insite /Set
of
Dfsutil /insite:\\domain.com\dfsroot /SET

Heb je ze alle 2 al eens getest ?

Due /INSITE is op meer dan 1 pagina van MS te vinden dus dat zou toch wel moeten werken.
------------------edit-------------------------------

Op vrijdag 03 mei 2002 15:22 schreef NetWorker dat hij blij was dat het werkt:

Tis al in orde dus

[NetWorker]

Bedankt jongens (of meiden) voor het meedenken !!!

Sluiten maar aub.