Making DFS fault tolerant across child domains

[durx]

Hi,

We have a DFS root on an 2003 Enterprise SP1 server (which is the PDCE)
and on the same site, links on an Standard R2 server, with 1 other site
using Standard R2 and 3 on Standard 2003 SP1 making 5 in all.
The other sites are all child domains, which cannot find the DFS when
either the root server is down or the VPN to the site where the root
server is is down, making our DFS far from fault tolerant.

With the root server not being R2, is it still possible to make this
fault tolerant by creating a second root server, or by using the R2
server on a remote site?

We map our DFS as G:\domain\global

I started to build a second DFS root, but the root had a different path
due to it being a child domain, but stopped as it looked wrong.

Existing root is \\domain\globaldata and when i create a second root
at a remote site, \\child.domain\globaldata but i cannot see how it
could work due to the different domains.

I could move the root from the PDCE to the R2 server, and then create a
second namespace on the remote site using R2, but i still cannot see
how this could be fault tolerant across child domains as the path to
the root would still be different.

Please tell i am wrong...

Phil

[Ned Pyle (MSFT)]

Hi Durx,

Quick question - how many 2003 servers do you have in your forest root
domain (root meaning top level domain, nothing to with DFS:) )? Doesn't
matter if DC's or not, just that they are members - you can always add
another Root Target to any 2003 machine in that domain and have a more fault
tolerant configuration that withstand your PDCE going down.

Your instincts were right by the way - you cannot host another domain's
namespace in your child domains. Lots more info on all of the above at:
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx

Let me know if this does not answer your question.

Ned

Post by durx
Hi,
We have a DFS root on an 2003 Enterprise SP1 server (which is the PDCE)
and on the same site, links on an Standard R2 server, with 1 other site
using Standard R2 and 3 on Standard 2003 SP1 making 5 in all.
The other sites are all child domains, which cannot find the DFS when
either the root server is down or the VPN to the site where the root
server is is down, making our DFS far from fault tolerant.
With the root server not being R2, is it still possible to make this
fault tolerant by creating a second root server, or by using the R2
server on a remote site?
We map our DFS as G:\domain\global
I started to build a second DFS root, but the root had a different path
due to it being a child domain, but stopped as it looked wrong.
Existing root is \\domain\globaldata and when i create a second root
at a remote site, \\child.domain\globaldata but i cannot see how it
could work due to the different domains.
I could move the root from the PDCE to the R2 server, and then create a
second namespace on the remote site using R2, but i still cannot see
how this could be fault tolerant across child domains as the path to
the root would still be different.
Please tell i am wrong...
Phil

[durx]

Ned,

We have 5 2003 servers on the top level domain (HQ).

Yesterday i added a second root target at HQ, and brought a member
server on a remote site into the top level domain and added a root
target on that too, which all semed to work fine.

But, this has not created fault tolerance, as a short while ago our ISP
had a massive power outage, which caused our DFS to cease to function
on the remote sites. Even though our VPN is full mesh with the all
remotes using a seperate ISP VPN structure, so all remote site VPN's
are still up, its just the traffic into HQ is down.

I would have thought that so long as the remote sites can see a root
server in the same domain, that the DFS would be available.

Could this be that 1 of our root targets is still on the top level
domains PDC?

If i was to remove the root from the PDC (bearing in mind there is
another root target in the top level domain and 1 on a remote site),
would DFS wrap itself up in a pre-stage file again, or would it just
get on with it.

I read the FAQ on removing a root, but did notice that when i added a
new root yesterday, it did move all files to a pre-stag or pre-exist
folder.
after a while they reappeared again though, but not sure about doing it
live.

Cheers

Durx

[Ned Pyle (MSFT)]

Hi Durx,

It should have worked fine as you described (so no root targets up in hub,
but branch computers can all reach a root target elsewhere) as long as the
remote DC's had knowledge of the new root target for that domain. If the
DC's had not picked up the changes yet due to AD replication latency (maybe
it had not had a chance to replicate before the PDCE was no longer
available?), you'd still be in trouble.

Have you configured /INSITE on your root to prevent clients from leaving
their sites - it not only stops link referrals, but also root referals.

Ned

Post by durx
Ned,
We have 5 2003 servers on the top level domain (HQ).
Yesterday i added a second root target at HQ, and brought a member
server on a remote site into the top level domain and added a root
target on that too, which all semed to work fine.
But, this has not created fault tolerance, as a short while ago our ISP
had a massive power outage, which caused our DFS to cease to function
on the remote sites. Even though our VPN is full mesh with the all
remotes using a seperate ISP VPN structure, so all remote site VPN's
are still up, its just the traffic into HQ is down.
I would have thought that so long as the remote sites can see a root
server in the same domain, that the DFS would be available.
Could this be that 1 of our root targets is still on the top level
domains PDC?
If i was to remove the root from the PDC (bearing in mind there is
another root target in the top level domain and 1 on a remote site),
would DFS wrap itself up in a pre-stage file again, or would it just
get on with it.
I read the FAQ on removing a root, but did notice that when i added a
new root yesterday, it did move all files to a pre-stag or pre-exist
folder.
after a while they reappeared again though, but not sure about doing it
live.
Cheers
Durx

[durx]

I have just reset the /insite to allow sitecostings to be enabled,
didnt realise it stopped root referals too.

i will try it out during the evening.

Thanks Ned.

Durx

[Ned Pyle (MSFT)]

Right on, let me know how it goes Durx. :)

Post by durx
I have just reset the /insite to allow sitecostings to be enabled,
didnt realise it stopped root referals too.
i will try it out during the evening.
Thanks Ned.
Durx

[durx]

Ned,

Still not had to try it out yet, but soon as i do i will post the
results.

Thanks

Durx.

Post by Ned Pyle (MSFT)
Right on, let me know how it goes Durx. :)

Post by durx
I have just reset the /insite to allow sitecostings to be enabled,
didnt realise it stopped root referals too.
i will try it out during the evening.
Thanks Ned.
Durx

[durx]

At last found an opportunity to test out whether the insite command has
worked on our child sites.

This was forced on us as the VPN went down on the remote site, and when
that happened, the DFS failed;; error could not located
\\DFSrootname\global.

i checked the insite command "dfsutil /Root:\\DFSrootname\global
/Sitecosting /enable" and the query a few week ago, and it was enabled
for site costings.

The DFS root on the top level DC at the remote site seemed to be
configured correctly.

I have not had chance to try this on any of the other remotes, but i
suspect it will be the same.

Cheers

Post by durx
Ned,
Still not had to try it out yet, but soon as i do i will post the
results.
Thanks
Durx.

Post by Ned Pyle (MSFT)
Right on, let me know how it goes Durx. :)

Post by durx
I have just reset the /insite to allow sitecostings to be enabled,
didnt realise it stopped root referals too.
i will try it out during the evening.
Thanks Ned.
Durx