Discussion:
Adventures in DFS over DSL and questions
(too old to reply)
Gordon Fecyk
2004-08-25 02:25:54 UTC
Permalink
This a repost from win2000.active_directory. My problems no longer appear
to stem from anything AD-related, as AD replication is working fine.

So I've been able to set up a self-replicating DFS root between two sites,
where each site has its own domain controller and they're linked through a
VPN connection over DSL. This seems to allow me to have roving profiles and
roving home directories between the two sites, which so far is working fine.

My first problem is there are old DFS roots in the Active Directory that's
causing warnings to appear in both DCs' event logs, and I've already tried
hunting for and removing them, to no avail. The warnings don't seem to
affect the working DFS root. These roots were there from first attempts to
get DFS working right, one of which resulted in me reinstalling a DC. I
would like to remove the old entries for these but am not sure how to go
about it safely.

I guess the old roots are in the NTFRS settings somewhere. I did a dfsutil
/clean on both DCs before building the current DFS root, so the errant
settings shouldn't be in DFS.

The DCs are: 1 x SBS2000 with Win2K Server SP4, and 1 x Win2K Server SP4.
I'll be adding a third DC at a new site in September. I'm using a single
domain but have established two sites in AD Sites and Services to ensure
workstations use their local DC. The DFS is set up with a single root and
folders inside for users and profiles, and they're mapped like this:

\\example.com\dfs\users\%username%
\\example.com\dfs\profiles\%username%

My second and last problem is how to go about setting up the third new site
and DC. Inital replication took over 24 hours to complete (DSL, 320 kbps,
with about 4 GB of user folders to replciate).

I'd rather not do that after installing the third server, instead installing
the third server at the main site first, replicating the DFS, and then
delivering the server to the new site. However, the server build and
installation would be separated by as many as five days (!). I have 7 GB of
staging space set and I set the journal size to 512 MB per MS
recommendations (128 MB/100,000 files) to avoid journal wraps and running
out of staging space - will this be enough to keep DFS happy until the third
DC comes back online at its new location?

And speaking of staging space, I notice that files appear in C:\frs-staging
but the amount of free disk space on C doesn't decrease. By chance does FRS
/ DFS use hard or symbolic links instead of copies of the files in this
staging space? Pretty clever if so.
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/***@pan-am.ca.asc>
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>
Jill Zoeller [MSFT]
2004-08-27 16:39:58 UTC
Permalink
To get rid of the old roots, try the following KB article:
HOW TO: Force Deletion of DFS Configuration Information 224384 at
http://support.microsoft.com/?id=224384

We have an article on prestaging replica sets at
http://support.microsoft.com/?id=266679. Essentially you take a backup (not
a copy) of the existing replica set and restore it onto the third member.
You can do this at the local site or the remote site. Any changes that occur
between the time you take the backup and restore the backup on the new
member will be replicated across the network.

If you do plan to add the new member to DFS in your local site and then want
to move it to the remote site, you'll need to update the static site
information as described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;260857.

If you'd like to read more about how prestaging works, see the FRS Technical
Reference "How FRS Works" document at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_frs_how.asp.
Some sections of interest include "How the Vvjoin Process Works" and "How
Prestaging Works."

You might also be interested in "How Files and Folders Are Replicated,"
which explains how we create staging files. Here's the snippet (it's a
little out of context here):
"ServerA uses backup APIs to create a backup of the changed file or folder
in ServerA's staging folder. These backup files, known as staging files,
encapsulate the data and attributes associated with a replicated file or
folder. By creating the staging file in the staging folder, FRS ensures that
file data can be supplied to partners regardless of any activity that might
prevent access to the original file. All staging files in the staging folder
are compressed to save disk space and network bandwidth during replication."
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by Gordon Fecyk
This a repost from win2000.active_directory. My problems no longer appear
to stem from anything AD-related, as AD replication is working fine.
So I've been able to set up a self-replicating DFS root between two sites,
where each site has its own domain controller and they're linked through a
VPN connection over DSL. This seems to allow me to have roving profiles and
roving home directories between the two sites, which so far is working fine.
My first problem is there are old DFS roots in the Active Directory that's
causing warnings to appear in both DCs' event logs, and I've already tried
hunting for and removing them, to no avail. The warnings don't seem to
affect the working DFS root. These roots were there from first attempts to
get DFS working right, one of which resulted in me reinstalling a DC. I
would like to remove the old entries for these but am not sure how to go
about it safely.
I guess the old roots are in the NTFRS settings somewhere. I did a dfsutil
/clean on both DCs before building the current DFS root, so the errant
settings shouldn't be in DFS.
The DCs are: 1 x SBS2000 with Win2K Server SP4, and 1 x Win2K Server SP4.
I'll be adding a third DC at a new site in September. I'm using a single
domain but have established two sites in AD Sites and Services to ensure
workstations use their local DC. The DFS is set up with a single root and
\\example.com\dfs\users\%username%
\\example.com\dfs\profiles\%username%
My second and last problem is how to go about setting up the third new site
and DC. Inital replication took over 24 hours to complete (DSL, 320 kbps,
with about 4 GB of user folders to replciate).
I'd rather not do that after installing the third server, instead installing
the third server at the main site first, replicating the DFS, and then
delivering the server to the new site. However, the server build and
installation would be separated by as many as five days (!). I have 7 GB of
staging space set and I set the journal size to 512 MB per MS
recommendations (128 MB/100,000 files) to avoid journal wraps and running
out of staging space - will this be enough to keep DFS happy until the third
DC comes back online at its new location?
And speaking of staging space, I notice that files appear in
C:\frs-staging
Post by Gordon Fecyk
but the amount of free disk space on C doesn't decrease. By chance does FRS
/ DFS use hard or symbolic links instead of copies of the files in this
staging space? Pretty clever if so.
--
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET.
<http://vmyths.com/rant.cfm?id=401&page=4>
Gordon Fecyk
2004-08-28 04:37:18 UTC
Permalink
Post by Jill Zoeller [MSFT]
We have an article on prestaging replica sets at
http://support.microsoft.com/?id=266679. Essentially you take a backup (not
a copy) of the existing replica set and restore it onto the third member.
You can do this at the local site or the remote site. Any changes that occur
between the time you take the backup and restore the backup on the new
member will be replicated across the network.
That's sweet.

I already have two functioning DFS root replicas and I'll be installing the
third some time in a week and a half. The DCs are all Win2K Server SP4. If
I read KB266679 corectly, I am to:

1) Make a backup of \\[server1]\dfs using ntbackup to some media (a .bkf
file for instance),
2) Bring the backup media with me to the new site,
3) Deploy the new server at the new site (already defined in AD Sites &
Services), adding it to the AD, and ensuring AD replication, SYSVOL
replication, etc is working (SYSVOL on my domain is just a few KB),
4) Restore the above backup to \\[server3]\dfs by specifying an "alternate
location",
5) Add the new server to the DFS root replica set, and enable replication
for the new server,
6) The new server will move the newly restored files to
\dfs\ntfrs_preexisting_etc-etc and then move files back to \dfs as
replication orders come in, restoring unchanged files and replicating
changed ones.

A little complicated but, when I think about it, makes more sense than
prebuilding the new DC and DFS replica and moving it.
Post by Jill Zoeller [MSFT]
If you do plan to add the new member to DFS in your local site and then want
to move it to the remote site, you'll need to update the static site
information as described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;260857.
A-hah, that says DFS isn't updated when I move a DC with a DFS replica to a
new site. Lovely, so what I did today was a waste of time (installed a new
DC at same site where \\[server1] was, and made a DFS root replica). I can
update it manually as you suggested, but it sounds easier just to deploy the
new DC on site and follow KB266679 instead. And I don't run into the
possiblity of running out of journal or staging space during my travel to
the new site.
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/***@pan-am.ca.asc>
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>
Jill Zoeller [MSFT]
2004-08-30 16:36:48 UTC
Permalink
Your plan sounds correct, though I recommend testing this in a lab
environment first (if possible), just to make sure you work out any kinks
before you travel.

Also, are you familiar with our monitoring and troubleshooting tools?
They're described in the URL below. I highly recommend Ultrasound as a way
of monitoring replication.


http://www.microsoft.com/windowsserver2003/technologies/fileandprint/file/dfs/tshootfrs.mspx
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by Gordon Fecyk
Post by Jill Zoeller [MSFT]
We have an article on prestaging replica sets at
http://support.microsoft.com/?id=266679. Essentially you take a backup
(not
Post by Jill Zoeller [MSFT]
a copy) of the existing replica set and restore it onto the third member.
You can do this at the local site or the remote site. Any changes that
occur
Post by Jill Zoeller [MSFT]
between the time you take the backup and restore the backup on the new
member will be replicated across the network.
That's sweet.
I already have two functioning DFS root replicas and I'll be installing the
third some time in a week and a half. The DCs are all Win2K Server SP4.
If
Post by Gordon Fecyk
1) Make a backup of \\[server1]\dfs using ntbackup to some media (a .bkf
file for instance),
2) Bring the backup media with me to the new site,
3) Deploy the new server at the new site (already defined in AD Sites &
Services), adding it to the AD, and ensuring AD replication, SYSVOL
replication, etc is working (SYSVOL on my domain is just a few KB),
4) Restore the above backup to \\[server3]\dfs by specifying an "alternate
location",
5) Add the new server to the DFS root replica set, and enable replication
for the new server,
6) The new server will move the newly restored files to
\dfs\ntfrs_preexisting_etc-etc and then move files back to \dfs as
replication orders come in, restoring unchanged files and replicating
changed ones.
A little complicated but, when I think about it, makes more sense than
prebuilding the new DC and DFS replica and moving it.
Post by Jill Zoeller [MSFT]
If you do plan to add the new member to DFS in your local site and then
want
Post by Jill Zoeller [MSFT]
to move it to the remote site, you'll need to update the static site
information as described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;260857.
A-hah, that says DFS isn't updated when I move a DC with a DFS replica to a
new site. Lovely, so what I did today was a waste of time (installed a new
DC at same site where \\[server1] was, and made a DFS root replica). I can
update it manually as you suggested, but it sounds easier just to deploy the
new DC on site and follow KB266679 instead. And I don't run into the
possiblity of running out of journal or staging space during my travel to
the new site.
--
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET.
<http://vmyths.com/rant.cfm?id=401&page=4>
Jill Zoeller [MSFT]
2004-08-30 16:48:35 UTC
Permalink
One more point to consider--there is an extra step you need to do (before
prestaging) if your existing replica set is less than 7 days old. Please let
me know if this is the case and I'll send you the additional steps.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by Gordon Fecyk
Post by Jill Zoeller [MSFT]
We have an article on prestaging replica sets at
http://support.microsoft.com/?id=266679. Essentially you take a backup
(not
Post by Jill Zoeller [MSFT]
a copy) of the existing replica set and restore it onto the third member.
You can do this at the local site or the remote site. Any changes that
occur
Post by Jill Zoeller [MSFT]
between the time you take the backup and restore the backup on the new
member will be replicated across the network.
That's sweet.
I already have two functioning DFS root replicas and I'll be installing the
third some time in a week and a half. The DCs are all Win2K Server SP4.
If
Post by Gordon Fecyk
1) Make a backup of \\[server1]\dfs using ntbackup to some media (a .bkf
file for instance),
2) Bring the backup media with me to the new site,
3) Deploy the new server at the new site (already defined in AD Sites &
Services), adding it to the AD, and ensuring AD replication, SYSVOL
replication, etc is working (SYSVOL on my domain is just a few KB),
4) Restore the above backup to \\[server3]\dfs by specifying an "alternate
location",
5) Add the new server to the DFS root replica set, and enable replication
for the new server,
6) The new server will move the newly restored files to
\dfs\ntfrs_preexisting_etc-etc and then move files back to \dfs as
replication orders come in, restoring unchanged files and replicating
changed ones.
A little complicated but, when I think about it, makes more sense than
prebuilding the new DC and DFS replica and moving it.
Post by Jill Zoeller [MSFT]
If you do plan to add the new member to DFS in your local site and then
want
Post by Jill Zoeller [MSFT]
to move it to the remote site, you'll need to update the static site
information as described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;260857.
A-hah, that says DFS isn't updated when I move a DC with a DFS replica to a
new site. Lovely, so what I did today was a waste of time (installed a new
DC at same site where \\[server1] was, and made a DFS root replica). I can
update it manually as you suggested, but it sounds easier just to deploy the
new DC on site and follow KB266679 instead. And I don't run into the
possiblity of running out of journal or staging space during my travel to
the new site.
--
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET.
<http://vmyths.com/rant.cfm?id=401&page=4>
Gordon Fecyk
2004-08-28 19:26:32 UTC
Permalink
Post by Jill Zoeller [MSFT]
HOW TO: Force Deletion of DFS Configuration Information 224384 at
http://support.microsoft.com/?id=224384
The old DFS roots don't appear to be visible in the Registry under
dfsdriver. But the working root is visible.

In the ntfrs keys, however, I found the old roots under the Replica Sets
key. The old roots have "Replica Set Tombstoned = 1" which I assume means
it's inactive. If it's inactive, I wonder why I'm still getting event log
entries with ID 13562:

The nTFRSSubscriber object
cn=dfsroot,cn=dfsroot,cn=085f3c31-284a-4e4d-aeb4-ceec728bbad3,cn=dfs
volumes\
cnf:a46561d5-ef24-43b5-beb8-90c3eebfd62f,cn=ntfrs
subscriptions,cn=[server1],ou=domain controllers,dc=[example],dc=com has a
invalid value for the attribute frsMemberReference.

The nTFRSSubscriber object
cn=dfsroot,cn=dfsroot,cn=085f3c31-284a-4e4d-aeb4-ceec728bbad3,cn=dfs
volumes\
cnf:00bb78bc-9bfd-4763-99d2-787a6e7dcc3d,cn=ntfrs
subscriptions,cn=[server1],ou=domain controllers,dc=[example],dc=com has a
invalid value for the attribute frsMemberReference.

[Actual server and domain names censored but [server1] represents the actual
first server.]

Do I need to hunt for and delete these objects from the AD? "dfsroot" is
the name of the old DFS root, and there are two instances of it because I
tried it twice but used a different folder name "dsfroot" by mistake the
first time.
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/***@pan-am.ca.asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>
Jill Zoeller [MSFT]
2004-08-30 16:32:35 UTC
Permalink
Looks like you have lingering FRS objects. We have a KB on recovering these
objects but not one for removing them. We do describe the location in the
registry and AD of these objects, but you'll want to use great care in
deleting them.

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_frs_how.asp
see "Hierarchy of FRS Objects in Active Directory for DFS Replica Sets"

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_dfs_how.asp
see "DFS Object in Active Directory"
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by Gordon Fecyk
Post by Jill Zoeller [MSFT]
HOW TO: Force Deletion of DFS Configuration Information 224384 at
http://support.microsoft.com/?id=224384
The old DFS roots don't appear to be visible in the Registry under
dfsdriver. But the working root is visible.
In the ntfrs keys, however, I found the old roots under the Replica Sets
key. The old roots have "Replica Set Tombstoned = 1" which I assume means
it's inactive. If it's inactive, I wonder why I'm still getting event log
The nTFRSSubscriber object
cn=dfsroot,cn=dfsroot,cn=085f3c31-284a-4e4d-aeb4-ceec728bbad3,cn=dfs
volumes\
cnf:a46561d5-ef24-43b5-beb8-90c3eebfd62f,cn=ntfrs
subscriptions,cn=[server1],ou=domain controllers,dc=[example],dc=com has a
invalid value for the attribute frsMemberReference.
The nTFRSSubscriber object
cn=dfsroot,cn=dfsroot,cn=085f3c31-284a-4e4d-aeb4-ceec728bbad3,cn=dfs
volumes\
cnf:00bb78bc-9bfd-4763-99d2-787a6e7dcc3d,cn=ntfrs
subscriptions,cn=[server1],ou=domain controllers,dc=[example],dc=com has a
invalid value for the attribute frsMemberReference.
[Actual server and domain names censored but [server1] represents the actual
first server.]
Do I need to hunt for and delete these objects from the AD? "dfsroot" is
the name of the old DFS root, and there are two instances of it because I
tried it twice but used a different folder name "dsfroot" by mistake the
first time.
--
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>
Loading...