Discussion:
Use DFS root servers for non-FRS shares?
(too old to reply)
Thomas H
2006-10-04 15:03:03 UTC
Permalink
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and company
financial data).

Physically, these DFS servers have a large amount of free disk space, so I'd
like to put some "regular" shares onto their drives. However, these shares
shouldn't be replicated (such as roaming profiles for mobile users).

Should I just create the shares on the server as \\siteAdfs\profiles?

Or should I link them into the namespace too, even though they won't be
replicated with DFSR?

And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?

Thanks in advance!

-TH
Jill Zoeller [MSFT]
2006-10-05 20:18:09 UTC
Permalink
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes sense for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add it there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users don't know
about.

For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs (these hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk space, so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as \\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Thomas H
2006-10-06 00:28:02 UTC
Permalink
Jill, thanks for the reply! Its good to know that I can put normal shares on
the drives. And I'll have to look into upgrading those root shares to EE (to
add another unpublished namespace).

This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you can help me
clear all this up?

Originally, I wanted to set up DFSR to create a namespace for all the users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage and very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up offline files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.

However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I read your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx about offline
files and DFS. (But now that you mentioned an additional namespace, maybe I
could make a namespace "just" for users' redirected folders?)

But then I'll find pages like this:
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx ... both
of which make it seem like yes, what I want /is/ possible.

So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.

Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR documentation/best
practices?

Thanks for your time!

-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes sense for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add it there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users don't know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs (these hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk space, so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as \\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Jill Zoeller [MSFT]
2006-10-06 17:27:58 UTC
Permalink
Hi Thomas,

What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.

What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.


Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
download: http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal shares on
the drives. And I'll have to look into upgrading those root shares to EE (to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you can help me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all the users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage and very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up offline files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I read your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx about offline
files and DFS. (But now that you mentioned an additional namespace, maybe I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx ... both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes sense for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add it there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users don't know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs (these hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk space, so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as \\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Thomas H
2006-10-06 17:53:02 UTC
Permalink
Jill, thanks for looking into this for me. And honestly, if we can't use
DFS/FRS for roaming profiles, I don't mind that much.

I'm thinking of a new namespace design now.

I'll dedicate one just for redirected folders + offline files, which will
avoid the issue that the blog discussed. Whats nice is I can have a much
more simple group policy at the domain level to say "put all redirected
folders into \\mycompany.internal\users\%username%" and let DFSR handle the
user/folder/etc creation! The users could sit at any desk at any site they
choose and still get to their own data.

Then I'll put one namespace out there, hidden from the users, for software
deployment and *maybe* roaming profiles (the population that will use roaming
profiles is small)

The last namespace will be visible to the the users, and will link to all
the collaborative file share areas (Accounting, HR, etc). And this one won't
have offline files enabled either.

If I take the roaming profiles out of the mix, does that sound like a decent
plan?

Thanks again!
Post by Jill Zoeller [MSFT]
Hi Thomas,
What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.
What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.
Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
download: http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal shares on
the drives. And I'll have to look into upgrading those root shares to EE (to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you can help me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all the users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage and very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up offline files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I read your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx about offline
files and DFS. (But now that you mentioned an additional namespace, maybe I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx ... both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes sense for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add it there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users don't know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs (these hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk space, so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as \\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Thomas H
2006-10-10 04:12:01 UTC
Permalink
Hi Jill, any luck? What if we "cancel" the roaming profiles; will my
three-namespace-design below be OK? Thanks!

-TH
Post by Thomas H
Jill, thanks for looking into this for me. And honestly, if we can't use
DFS/FRS for roaming profiles, I don't mind that much.
I'm thinking of a new namespace design now.
I'll dedicate one just for redirected folders + offline files, which will
avoid the issue that the blog discussed. Whats nice is I can have a much
more simple group policy at the domain level to say "put all redirected
folders into \\mycompany.internal\users\%username%" and let DFSR handle the
user/folder/etc creation! The users could sit at any desk at any site they
choose and still get to their own data.
Then I'll put one namespace out there, hidden from the users, for software
deployment and *maybe* roaming profiles (the population that will use roaming
profiles is small)
The last namespace will be visible to the the users, and will link to all
the collaborative file share areas (Accounting, HR, etc). And this one won't
have offline files enabled either.
If I take the roaming profiles out of the mix, does that sound like a decent
plan?
Thanks again!
Post by Jill Zoeller [MSFT]
Hi Thomas,
What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.
What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.
Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
download: http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal shares on
the drives. And I'll have to look into upgrading those root shares to EE (to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you can help me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all the users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage and very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up offline files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I read your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx about offline
files and DFS. (But now that you mentioned an additional namespace, maybe I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx ... both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes sense for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add it there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users don't know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs (these hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD sites in a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root targets, and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk space, so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as \\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best for a true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Jill Zoeller [MSFT]
2006-10-10 14:47:57 UTC
Permalink
Sorry--was a bit swamped yesterday and today. I still want to have another
co-worker review this before I comment.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hi Jill, any luck? What if we "cancel" the roaming profiles; will my
three-namespace-design below be OK? Thanks!
-TH
Post by Thomas H
Jill, thanks for looking into this for me. And honestly, if we can't use
DFS/FRS for roaming profiles, I don't mind that much.
I'm thinking of a new namespace design now.
I'll dedicate one just for redirected folders + offline files, which will
avoid the issue that the blog discussed. Whats nice is I can have a much
more simple group policy at the domain level to say "put all redirected
folders into \\mycompany.internal\users\%username%" and let DFSR handle the
user/folder/etc creation! The users could sit at any desk at any site they
choose and still get to their own data.
Then I'll put one namespace out there, hidden from the users, for software
deployment and *maybe* roaming profiles (the population that will use roaming
profiles is small)
The last namespace will be visible to the the users, and will link to all
the collaborative file share areas (Accounting, HR, etc). And this one won't
have offline files enabled either.
If I take the roaming profiles out of the mix, does that sound like a decent
plan?
Thanks again!
Post by Jill Zoeller [MSFT]
Hi Thomas,
What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.
What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.
Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal
shares
on
the drives. And I'll have to look into upgrading those root shares
to EE
(to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you can
help
me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all the users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage
and
very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up offline files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I
read
your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx about offline
files and DFS. (But now that you mentioned an additional namespace,
maybe
I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx
...
both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR
documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes
sense
for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add
it
there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users
don't
know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs
(these
hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two folder targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage
technologies?
Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD
sites in
a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root
targets,
and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk
space,
so
I'd like to put some "regular" shares onto their drives. However, these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as
\\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best
for a
true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Jill Zoeller [MSFT]
2006-10-11 16:35:34 UTC
Permalink
Here is Ned's response to your planned namespace design:

His plan for simply rooting redirected folders at the users target is pretty
close, but not quite complete. What should work best is:

1. Create a new namespace of: \\fabrikam\users.

2. Create a folder target of 'Redirected' (which should be shared on all
DFSR servers and replicated; be careful with permissions - share should be
everyone FC, users should be users CHANGE, and the redirection extension
will take care of making the individual security for each user).

3. Configure Group Policy for the users to redirect my documents, with
'BASIC' and 'Create a folder for each user under the root path'; set the
root path to '\\fabrikam\users\redirected'.

4. Replicate policy, refresh policy, usual stuff.

Once all this is done, the RF client-side extension will take care of
creating the user's folders, moving the data up (which can take a LONG time,
depending on how out of control their my docs is currently - sometimes that
first logon takes HOURS due to the many GB of data users had in there).
Obviously, this isn't going to be perfect since DFSR is going to run into
some sharing violations, so if users actually have more than one computer
and tend to roam around without logging off, there are going to be issues
with stale or 'lost' data...

*****
I also asked Ned about how to fit roaming profiles into the mix. He says
that those settings (roaming profiles) changes would be made in the account
properties of the users. You'd create yet another replicated folder target
for that piece. Just like RF's, it may not operate all that great on DFSR
due to locks and latency.


Hope this helps!
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Jill Zoeller [MSFT]
Sorry--was a bit swamped yesterday and today. I still want to have another
co-worker review this before I comment.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies?
Visit our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hi Jill, any luck? What if we "cancel" the roaming profiles; will my
three-namespace-design below be OK? Thanks!
-TH
Post by Thomas H
Jill, thanks for looking into this for me. And honestly, if we can't use
DFS/FRS for roaming profiles, I don't mind that much.
I'm thinking of a new namespace design now.
I'll dedicate one just for redirected folders + offline files, which will
avoid the issue that the blog discussed. Whats nice is I can have a much
more simple group policy at the domain level to say "put all redirected
folders into \\mycompany.internal\users\%username%" and let DFSR handle the
user/folder/etc creation! The users could sit at any desk at any site they
choose and still get to their own data.
Then I'll put one namespace out there, hidden from the users, for software
deployment and *maybe* roaming profiles (the population that will use roaming
profiles is small)
The last namespace will be visible to the the users, and will link to all
the collaborative file share areas (Accounting, HR, etc). And this one won't
have offline files enabled either.
If I take the roaming profiles out of the mix, does that sound like a decent
plan?
Thanks again!
Post by Jill Zoeller [MSFT]
Hi Thomas,
What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.
What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.
Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal
shares
on
the drives. And I'll have to look into upgrading those root shares
to EE
(to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you
can help
me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all
the
users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders would've
gone to \\mycompany.internal\users. It would've been easy to manage
and
very
redundant. Every user "local" to their site would've used the local target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up
offline
files
in case we had a switch failure and a floor couldn't reach either datacenter-
their "My Documents" and etc would still be there for them while our network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I
read
your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx
about
offline
files and DFS. (But now that you mentioned an additional namespace,
maybe
I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx
...
both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR
documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not replicated.
And it's fine to put shares on your root server. Do whatever makes
sense
for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add
it
there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users
don't
know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs
(these
hand
out referrals to the domain-based namespace itself), two namespace servers
(to hand out referrals to your folders with targets), and two
folder
targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage
technologies?
Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD
sites in
a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root
targets,
and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk
space,
so
I'd like to put some "regular" shares onto their drives.
However,
these
shares shouldn't be replicated (such as roaming profiles for mobile
users).
Should I just create the shares on the server as
\\siteAdfs\profiles?
Or should I link them into the namespace too, even though they won't be
replicated with DFSR?
And which way (normal shares, or non-replicated in DFS) is best
for a
true
loss-of-site disaster-recovery scenario?
Thanks in advance!
-TH
Thomas H
2006-10-16 03:15:02 UTC
Permalink
Jill & Ned, yes, it does help! Thanks!! Glad to know I can give DFSR "back"
its central role in our plan!

I've already got the software deployment namespace up and the redirected
folders namespace/shares, and ran a test (using myself in a "lone" OU)- yep
that initial login took a while, but maybe we can s-l-o-w-l-y push the GPO
onto a section of users at a time, and just have them log in at night.

Now I've got to create some test users and throw some test pc's up at both
sites (probably use remote desktop so I can "pretend" I'm in both sites at
once) and see what scenarios will cause things to get dropped into the
conflict folders.

Thanks again for your help!

-Thomas H
Post by Jill Zoeller [MSFT]
His plan for simply rooting redirected folders at the users target is pretty
1. Create a new namespace of: \\fabrikam\users.
2. Create a folder target of 'Redirected' (which should be shared on all
DFSR servers and replicated; be careful with permissions - share should be
everyone FC, users should be users CHANGE, and the redirection extension
will take care of making the individual security for each user).
3. Configure Group Policy for the users to redirect my documents, with
'BASIC' and 'Create a folder for each user under the root path'; set the
root path to '\\fabrikam\users\redirected'.
4. Replicate policy, refresh policy, usual stuff.
Once all this is done, the RF client-side extension will take care of
creating the user's folders, moving the data up (which can take a LONG time,
depending on how out of control their my docs is currently - sometimes that
first logon takes HOURS due to the many GB of data users had in there).
Obviously, this isn't going to be perfect since DFSR is going to run into
some sharing violations, so if users actually have more than one computer
and tend to roam around without logging off, there are going to be issues
with stale or 'lost' data...
*****
I also asked Ned about how to fit roaming profiles into the mix. He says
that those settings (roaming profiles) changes would be made in the account
properties of the users. You'd create yet another replicated folder target
for that piece. Just like RF's, it may not operate all that great on DFSR
due to locks and latency.
Hope this helps!
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Jill Zoeller [MSFT]
Sorry--was a bit swamped yesterday and today. I still want to have another
co-worker review this before I comment.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies?
Visit our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hi Jill, any luck? What if we "cancel" the roaming profiles; will my
three-namespace-design below be OK? Thanks!
-TH
Post by Thomas H
Jill, thanks for looking into this for me. And honestly, if we can't use
DFS/FRS for roaming profiles, I don't mind that much.
I'm thinking of a new namespace design now.
I'll dedicate one just for redirected folders + offline files, which will
avoid the issue that the blog discussed. Whats nice is I can have a much
more simple group policy at the domain level to say "put all redirected
folders into \\mycompany.internal\users\%username%" and let DFSR handle the
user/folder/etc creation! The users could sit at any desk at any site they
choose and still get to their own data.
Then I'll put one namespace out there, hidden from the users, for software
deployment and *maybe* roaming profiles (the population that will use roaming
profiles is small)
The last namespace will be visible to the the users, and will link to all
the collaborative file share areas (Accounting, HR, etc). And this one won't
have offline files enabled either.
If I take the roaming profiles out of the mix, does that sound like a decent
plan?
Thanks again!
Post by Jill Zoeller [MSFT]
Hi Thomas,
What might be confusing are the various considerations for Offline Files,
folder redirection, and roaming profiles. Each has its own interop issues to
consider, and these are compounded when you combine the technologies with
DFS and replication. As you've read in the blog there are drawbacks to using
Offline Files in domain-based namespaces, and you've read about the
drawbacks to using replication in this scenario. The FAQ states that DFS and
Offline Files can be combined (with the noted drawback) but that adding FRS
(or DFS Replication) to the mix is not recommended.
What I'm not an expert in are roaming profiles. From the FAQ I gather that
these require careful placement so that they don't conflict with redirected
mydocs. Let me see if I can find someone more knowledgable about this to
respond here.
Also, I should mention that there is a hotfix that allows you to have
multiple domain-based namespaces on a Standard server. Here is a link to the
http://support.microsoft.com/default.aspx?scid=kb;en-us;903651.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Jill, thanks for the reply! Its good to know that I can put normal
shares
on
the drives. And I'll have to look into upgrading those root shares
to EE
(to
add another unpublished namespace).
This post originated mainly from the conflicting information I've been
reading on the Microsoft website and in Microsoft docs- maybe you
can help
me
clear all this up?
Originally, I wanted to set up DFSR to create a namespace for all
the
users
in both of my sites. (Single AD domain, two sites, 2 DCs at each site) I
was going to make a GPO for Folder Redirection so everyone's folders
would've
gone to \\mycompany.internal\users. It would've been easy to manage
and
very
redundant. Every user "local" to their site would've used the local
target.
If one datacenter went down (say, cooling issues), then the users would've
gone over the WAN to the other site. I also wanted to set up
offline
files
in case we had a switch failure and a floor couldn't reach either
datacenter-
their "My Documents" and etc would still be there for them while our
network
guys fixed the problem.
However, a few Microsoft pages seemed to say this setup wasn't recommended
for redirected folders. It came down to the files being constantly
open/edited which would lead to synchronization conflicts. And I
read
your
team's blog entry at
http://blogs.technet.com/filecab/archive/2006/01/19/417761.aspx
about
offline
files and DFS. (But now that you mentioned an additional namespace,
maybe
I
could make a namespace "just" for users' redirected folders?)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
(Question 68, under "Managing DFS: Can I use DFS with Offline Files and
redirected My Documents folder) and the demo at
http://www.microsoft.com/winme/0512/25905/Branch_Server_demo_mbr.asx
...
both
of which make it seem like yes, what I want /is/ possible.
So based on the conflicting information (sorry this is so long), I figured
that I had to keep users' redirected folders, roaming profiles, and
collaborative-file-share-areas as normal, non-DFSR shares. With that
assumption, I thought that I could still leverage a bit of DFS by
integrating
profiles and collaboration areas into one namespace /without/ DFSR replica
sets. The idea was if we lost a site (due to flood/fire/etc), I could
restore the lost data from offsite tape onto the surviving-site's servers.
Then I'd go to the surviving DFS root server, delete the "failed" link
targets, and replace them with the new "restored data" targets.
Can you point me in the right direction here? Could it be that I've just
been reading a mix of Win2k/2k3 FRS and Win2k3 DFSR
documentation/best
practices?
Thanks for your time!
-Thomas
Post by Jill Zoeller [MSFT]
For a given namespace, it's fine if the folder targets for a given folder
are replicated (say \\domain\root\users where users has multiple targets)
and other folders, perhaps those with a single target, are not
replicated.
And it's fine to put shares on your root server. Do whatever makes
sense
for
your organization. For example, if you don't mind the fact that your
profiles share will appear in the namespace, then it's fine to add
it
there.
However, if you don't want to expose this folder to your users via normal
browsing of the namespace, then create a new namespace that users
don't
know
about.
For the best disaster recovery, you need to eliminate single points of
failure for your namespace and target data. This means two DCs
(these
hand
out referrals to the domain-based namespace itself), two namespace
servers
(to hand out referrals to your folders with targets), and two
folder
targets
for each folder--or store the single folder target on a server cluster.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Want to learn more about Windows Server file and storage technologies?
Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.
Post by Thomas H
Hello everyone! At my medium-sized business, we've got two AD
sites in
a
single domain. Each site has a Win2k3 SE R2 root server with a
domain-integrated namespace. The namespace has multiple root
targets,
and
does use DFSR for some shares (examples= GPO software deployment and
company financial data).
Physically, these DFS servers have a large amount of free disk
Continue reading on narkive:
Loading...