Stopping use of a dfsroot replica during replication

  • Thread starter Thread starter newsgroup2
  • Start date Start date
N

newsgroup2

We have a single dfsroot - say \\domain1\dfsroot, which until now has
just had a single share in it - say \\server1\dfsroot. This dfsroot
contains mainly user profiles and home directories, and exists on a
domain controller. This contains about 800MB in 90,000 files.

We now want to create another dfsroot replica on another domain
controller - say \\server2\dfsroot, for resilience. We have got the
replication working, but this takes several hours to replicate - can
be up to 18 hours.

The problem is that while the initial replication is in progress, if
users access thier profiles etc, they may get to use the dfsroot on
the server which is not "ready" yet, and therefore thier profile may
not yet exist. They then get a temporary profile. If they later log
off, this overwrites thier real profile.

My question is, How do you prevent the second dfsroot from being used
until the replication is finished ?
 
newsgroup2 said:
We have a single dfsroot - say \\domain1\dfsroot, which until now has
just had a single share in it - say \\server1\dfsroot. This dfsroot
contains mainly user profiles and home directories, and exists on a
domain controller. This contains about 800MB in 90,000 files.

We now want to create another dfsroot replica on another domain
controller - say \\server2\dfsroot, for resilience. We have got the
replication working, but this takes several hours to replicate - can
be up to 18 hours.

The problem is that while the initial replication is in progress, if
users access thier profiles etc, they may get to use the dfsroot on
the server which is not "ready" yet, and therefore thier profile may
not yet exist. They then get a temporary profile. If they later log
off, this overwrites thier real profile.
Click to expand...
My question is, How do you prevent the second dfsroot from being used
until the replication is finished ?
Click to expand...

If this is the only problem tries these ideas: kill the
(general) routing on the unfinished server by giving
it (first) a good route to the OTHER (ready) server;
then by sending all addresses on the local subnet to
some bogus place. No client will ever get an answer
from this server to they MUST fail over to the working
one.

Another idea (may not work but it isn't as ugly):
Change the permissions on the unfinished server
share so that it denies EVERYONE access -- this
may not fail over (haven't tested) but no one will
get their files there.

Note: This should never be done for a production
server -- the shares in a replication set should always
have the same permissions -- NTFS is taken care of
by replication but you can muck with the SHARE.

You could also hide it behind a router and ONLY
teach the ready server to find it (but that is just the
more complex version of the first idea.)
 
If you were storing your profiles in a link target (as opposed to a root
target), you would be able to disable referrals on the second link target
until the files had replicated in. Currently there is no way to disable
referrals to a root target.

Also, we recommend against replicating root targets for reasons described in
the DFS FAQ at
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx.

The question you want is called:

Q. If I use multiple root targets in a domain-based DFS namespace, do I need
to enable replication on the root?
 
Back
Top