accessing the same root target every time with multiple root targets in the same site

Discussion:

(too old to reply)

chad

2006-07-19 21:38:01 UTC

Our DFS Root and all of the targets are running 2003 Server Standard
R1. We are using FRS for replication.

We have 1 server at corporate that is acting as DFS Root, and I've
setup 69 root targets throughout our WAN, which are located at our
Plants. Our Branches (approximately 70) do not have servers on site,
but are authenticating to AD at our Plants. I've enabled the Insite
parameter on our DFS Share so that each workstation only accesses the
DFS Share at the server in their LAN at a Plant, or the local Plant
server for a Branch.

We push software installation packages using GPOs and DFS. I point
each package to the DFS Share, "\\domain.com\dfsshare". I do this
with computer policies. When the computer boots, it finds
"\\domain.com\dfsshare" in it's local site and install the
package from there.

The problem with this is the 256Kb WAN connection at a Branch. When
they try to install a software package through DFS they access their
local plant server to do this, and it takes quite a long time. We
would like to add a DFS root target at the Branches also.

We would like to accomplish this by setting up a NAS device running
2003 Storage Server at the Branch, and have the users there pull their
software installations from this device. I am worried that with our
Active Directory setup, it may still pull from either a Plant Root
Target or Branch Root Target, and I only want it to pull from the
Branch Root Target. With the Insite Parameter, it is my understanding
that the workstation will pull from whatever DFS Root Target is in its
AD Site.

Since the Branch workstation will be in the same subnet as the Branch
Root Target, will the workstation pull from the Branch Root Target
every time, or will it pull from random Root Targets in it's AD Site?
If the pull is random, can we specify the Branch Root Target for that
Branch's workstations?

It's been recommended to me to just create another site for the branch
subnet. The problem is, there is no DC in that subnet, so how will the
workstations authenticate?

Thanks in advance for any assistance.

Jill Zoeller [MSFT]

2006-07-20 15:37:02 UTC

Permalink

Hi Chad,

You definitely have an interesting scenario! Are you using root scalabilty
mode? It's something we recommend when you have more than 16 root targets.

As for your situation, you are correct that if there are multiple targets in
a client's site, the client will pick one at random. For servers running
SP1, we do have a new feature called target priority, which lets you specify
whether a target should always be first/last within a referral, or
first/last among same-site targets in the referral. The new DFS Management
snap-in in R2 lets you configure this via the UI, but you can also do this
using Dfsutil (downloadable from www.microsoft.com/dfs). The Dfsutil option
has more granularity for this configuration. (We have a webcast on
configuring target priority available from the above link as well.)

Here is something to keep in mind--since you're using root targets, not link
targets, you'll need to install SP1 on all DCs in the domain hosting the
namespace. The DCs are what hand out domain-based root referrals, so you
need to install SP1 on them to enable this functionality.

Also, I believe there is a way to have DC-less sites--but I'm not an AD
expert so you might want to pose this question to an AD newsgroup. Using
sites is definitely the way to go as far as DFS is concerned.
--
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 chad
Our DFS Root and all of the targets are running 2003 Server Standard
R1. We are using FRS for replication.
We have 1 server at corporate that is acting as DFS Root, and I've
setup 69 root targets throughout our WAN, which are located at our
Plants. Our Branches (approximately 70) do not have servers on site,
but are authenticating to AD at our Plants. I've enabled the Insite
parameter on our DFS Share so that each workstation only accesses the
DFS Share at the server in their LAN at a Plant, or the local Plant
server for a Branch.
We push software installation packages using GPOs and DFS. I point
each package to the DFS Share, "\\domain.com\dfsshare". I do this
with computer policies. When the computer boots, it finds
"\\domain.com\dfsshare" in it's local site and install the
package from there.
The problem with this is the 256Kb WAN connection at a Branch. When
they try to install a software package through DFS they access their
local plant server to do this, and it takes quite a long time. We
would like to add a DFS root target at the Branches also.
We would like to accomplish this by setting up a NAS device running
2003 Storage Server at the Branch, and have the users there pull their
software installations from this device. I am worried that with our
Active Directory setup, it may still pull from either a Plant Root
Target or Branch Root Target, and I only want it to pull from the
Branch Root Target. With the Insite Parameter, it is my understanding
that the workstation will pull from whatever DFS Root Target is in its
AD Site.
Since the Branch workstation will be in the same subnet as the Branch
Root Target, will the workstation pull from the Branch Root Target
every time, or will it pull from random Root Targets in it's AD Site?
If the pull is random, can we specify the Branch Root Target for that
Branch's workstations?
It's been recommended to me to just create another site for the branch
subnet. The problem is, there is no DC in that subnet, so how will the
workstations authenticate?
Thanks in advance for any assistance.

chad

2006-07-20 18:31:39 UTC

Permalink

Great, thanks for the reply. Targetpriority is exactly what I've been
looking for. To answer your questions first, No we are not set up in
root scalability mode, but I read about the 16 target or more
recommendation before, and will be implementing this. I just have to
read up on exactly how to do that. Hopefully I won't have to recreate
all my root targets!

Yes, all of our servers are running 2003 server sp1. Yes, I have also
posted this in the AD group, but I believe your answer with
/targetpriority using dfsutil is exactly what I've been looking for.

I did try to execute this command with dfsutil, and I am getting an
error

System error 124 has occurred.
The system call level is not correct.

Done processing this command.

Any ideas??

Post by Jill Zoeller [MSFT]
Hi Chad,
You definitely have an interesting scenario! Are you using root scalabilty
mode? It's something we recommend when you have more than 16 root targets.
As for your situation, you are correct that if there are multiple targets in
a client's site, the client will pick one at random. For servers running
SP1, we do have a new feature called target priority, which lets you specify
whether a target should always be first/last within a referral, or
first/last among same-site targets in the referral. The new DFS Management
snap-in in R2 lets you configure this via the UI, but you can also do this
using Dfsutil (downloadable from www.microsoft.com/dfs). The Dfsutil option
has more granularity for this configuration. (We have a webcast on
configuring target priority available from the above link as well.)
Here is something to keep in mind--since you're using root targets, not link
targets, you'll need to install SP1 on all DCs in the domain hosting the
namespace. The DCs are what hand out domain-based root referrals, so you
need to install SP1 on them to enable this functionality.
Also, I believe there is a way to have DC-less sites--but I'm not an AD
expert so you might want to pose this question to an AD newsgroup. Using
sites is definitely the way to go as far as DFS is concerned.
--
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.

Jill Zoeller [MSFT]

2006-07-20 18:49:35 UTC

Permalink

I did a search of support cases and did not see any for the error you
describe. Can you provide the exact syntax you are using? Feel free to
change the server names for privacy if you want.

Also, root scalability mode doesn't require any changes to root targets. It
just changes how namespace servers obtain updated information about the
namespace.
--
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 chad
Great, thanks for the reply. Targetpriority is exactly what I've been
looking for. To answer your questions first, No we are not set up in
root scalability mode, but I read about the 16 target or more
recommendation before, and will be implementing this. I just have to
read up on exactly how to do that. Hopefully I won't have to recreate
all my root targets!
Yes, all of our servers are running 2003 server sp1. Yes, I have also
posted this in the AD group, but I believe your answer with
/targetpriority using dfsutil is exactly what I've been looking for.
I did try to execute this command with dfsutil, and I am getting an
error
System error 124 has occurred.
The system call level is not correct.
Done processing this command.
Any ideas??

chad

2006-07-20 19:26:05 UTC

Permalink

I did get it to work now, by loading the support tools on the server
that is the DFS root.

The command(s) I tried on my workstation were with the UNC Path and by
Netbios name, and they always displayed the same error, here.

C:\Program Files\Support Tools>dfsutil /TargetPriority
/Path:\\domain.com\share /Server:targetsvr /Share:share /Display

Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.

System error 124 has occurred.
The system call level is not correct.

When I tried this same command on the DFS Root Server, it gave me this
error

C:\Program Files\Support Tools>dfsutil /TargetPriority
/Path:\\domain.com\share /Server:target /Share:share /Display

Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.

System error 1783 has occurred.
The stub received bad data.

How I got it to work was replacing the UNC \\domain.com with the
netbios name of the domain, \\domain

TargetPriority for path \\domain\share:
Target <target, share>:
PriorityClass = SiteCostNormal, PriorityRank = 0

Post by Jill Zoeller [MSFT]
I did a search of support cases and did not see any for the error you
describe. Can you provide the exact syntax you are using? Feel free to
change the server names for privacy if you want.
Also, root scalability mode doesn't require any changes to root targets. It
just changes how namespace servers obtain updated information about the
namespace.
--
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.

chad

2006-07-26 19:06:18 UTC

Permalink

I'm not sure about this solution now, the more I think about it. If we
have 2 root targets in the same site, and I want our Branch to get from
one root target, and our Plant to get from another and I set the
targetpriority to high on the 1 at the Branch, then our Plant
workstations will pull their DFS information from the target at the
Branch also.

That is bad, now I'm just reversing the problem! Any other
suggestions? I still think the solution is creating a site for the
Branch, but I'm not sure how to specify authentication to a server that
doesn't live on the subnet specified for that site.

Post by chad
I did get it to work now, by loading the support tools on the server
that is the DFS root.
The command(s) I tried on my workstation were with the UNC Path and by
Netbios name, and they always displayed the same error, here.
C:\Program Files\Support Tools>dfsutil /TargetPriority
/Path:\\domain.com\share /Server:targetsvr /Share:share /Display
Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.
System error 124 has occurred.
The system call level is not correct.
When I tried this same command on the DFS Root Server, it gave me this
error
C:\Program Files\Support Tools>dfsutil /TargetPriority
/Path:\\domain.com\share /Server:target /Share:share /Display
Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.
System error 1783 has occurred.
The stub received bad data.
How I got it to work was replacing the UNC \\domain.com with the
netbios name of the domain, \\domain
PriorityClass = SiteCostNormal, PriorityRank = 0

Jill Zoeller [MSFT]

2006-07-26 20:11:10 UTC

Permalink

DFS is all about sites. That's how it decides which targets to put at the
top of the referrals to give to clients. With geographically distributed
targets in the same AD site, then you're right--it's hard to direct clients
to the low-cost site because DFS thinks they all cost the same. If you do
get your branch target in a separate site, then you wouldn't need to use
target priority. The branch clients will automatically choose the branch
server because servers in the same site as the client are always listed
first. If you had, say, two branch servers in the branch site, then you
could assign priority to one of them and branch clients would go there
first.
--
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 chad
I'm not sure about this solution now, the more I think about it. If we
have 2 root targets in the same site, and I want our Branch to get from
one root target, and our Plant to get from another and I set the
targetpriority to high on the 1 at the Branch, then our Plant
workstations will pull their DFS information from the target at the
Branch also.
That is bad, now I'm just reversing the problem! Any other
suggestions? I still think the solution is creating a site for the
Branch, but I'm not sure how to specify authentication to a server that
doesn't live on the subnet specified for that site.

Post by Jill Zoeller [MSFT]
Hi Chad,
You definitely have an interesting scenario! Are you using root scalabilty
mode? It's something we recommend when you have more than 16 root targets.
As for your situation, you are correct that if there are multiple
targets
in
a client's site, the client will pick one at random. For servers running
SP1, we do have a new feature called target priority, which lets you specify
whether a target should always be first/last within a referral, or
first/last among same-site targets in the referral. The new DFS Management
snap-in in R2 lets you configure this via the UI, but you can also
do
this
using Dfsutil (downloadable from www.microsoft.com/dfs). The Dfsutil option
has more granularity for this configuration. (We have a webcast on
configuring target priority available from the above link as well.)
Here is something to keep in mind--since you're using root targets,
not
link
targets, you'll need to install SP1 on all DCs in the domain hosting the
namespace. The DCs are what hand out domain-based root referrals, so you
need to install SP1 on them to enable this functionality.
Also, I believe there is a way to have DC-less sites--but I'm not an AD
expert so you might want to pose this question to an AD newsgroup. Using
sites is definitely the way to go as far as DFS is concerned.
--
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 chad
Our DFS Root and all of the targets are running 2003 Server Standard
R1. We are using FRS for replication.
We have 1 server at corporate that is acting as DFS Root, and I've
setup 69 root targets throughout our WAN, which are located at our
Plants. Our Branches (approximately 70) do not have servers on site,
but are authenticating to AD at our Plants. I've enabled the Insite
parameter on our DFS Share so that each workstation only accesses the
DFS Share at the server in their LAN at a Plant, or the local Plant
server for a Branch.
We push software installation packages using GPOs and DFS. I point
each package to the DFS Share, "\\domain.com\dfsshare". I do this
with computer policies. When the computer boots, it finds
"\\domain.com\dfsshare" in it's local site and install the
package from there.
The problem with this is the 256Kb WAN connection at a Branch.
When
they try to install a software package through DFS they access their
local plant server to do this, and it takes quite a long time. We
would like to add a DFS root target at the Branches also.
We would like to accomplish this by setting up a NAS device running
2003 Storage Server at the Branch, and have the users there pull their
software installations from this device. I am worried that with our
Active Directory setup, it may still pull from either a Plant Root
Target or Branch Root Target, and I only want it to pull from the
Branch Root Target. With the Insite Parameter, it is my understanding
that the workstation will pull from whatever DFS Root Target is in its
AD Site.
Since the Branch workstation will be in the same subnet as the Branch
Root Target, will the workstation pull from the Branch Root Target
every time, or will it pull from random Root Targets in it's AD Site?
If the pull is random, can we specify the Branch Root Target for that
Branch's workstations?
It's been recommended to me to just create another site for the branch
subnet. The problem is, there is no DC in that subnet, so how will the
workstations authenticate?
Thanks in advance for any assistance.

chad

2006-07-27 14:21:19 UTC

Permalink

I will research how to assign a server to a site for authentication,
and try to get the branch in its own site.

Back to /targetpriority. Weirdest thing, after I set a high priority
on my NAS device in another site, I had clients accessing this share
from seperate sites.

Was is the command line to set rank and class back to default for a
target?

Post by Jill Zoeller [MSFT]
DFS is all about sites. That's how it decides which targets to put at the
top of the referrals to give to clients. With geographically distributed
targets in the same AD site, then you're right--it's hard to direct clients
to the low-cost site because DFS thinks they all cost the same. If you do
get your branch target in a separate site, then you wouldn't need to use
target priority. The branch clients will automatically choose the branch
server because servers in the same site as the client are always listed
first. If you had, say, two branch servers in the branch site, then you
could assign priority to one of them and branch clients would go there
first.
--
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]
Hi Chad,
You definitely have an interesting scenario! Are you using root scalabilty
mode? It's something we recommend when you have more than 16 root targets.
As for your situation, you are correct that if there are multiple
targets
in
a client's site, the client will pick one at random. For servers running
SP1, we do have a new feature called target priority, which lets you
specify
whether a target should always be first/last within a referral, or
first/last among same-site targets in the referral. The new DFS Management
snap-in in R2 lets you configure this via the UI, but you can also
do
this
using Dfsutil (downloadable from www.microsoft.com/dfs). The Dfsutil option
has more granularity for this configuration. (We have a webcast on
configuring target priority available from the above link as well.)
Here is something to keep in mind--since you're using root targets,
not
link
targets, you'll need to install SP1 on all DCs in the domain hosting the
namespace. The DCs are what hand out domain-based root referrals, so you
need to install SP1 on them to enable this functionality.
Also, I believe there is a way to have DC-less sites--but I'm not an AD
expert so you might want to pose this question to an AD newsgroup. Using
sites is definitely the way to go as far as DFS is concerned.
--
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 chad
Our DFS Root and all of the targets are running 2003 Server Standard
R1. We are using FRS for replication.
We have 1 server at corporate that is acting as DFS Root, and I've
setup 69 root targets throughout our WAN, which are located at our
Plants. Our Branches (approximately 70) do not have servers on site,
but are authenticating to AD at our Plants. I've enabled the Insite
parameter on our DFS Share so that each workstation only accesses the
DFS Share at the server in their LAN at a Plant, or the local Plant
server for a Branch.
We push software installation packages using GPOs and DFS. I point
each package to the DFS Share, "\\domain.com\dfsshare". I do this
with computer policies. When the computer boots, it finds
"\\domain.com\dfsshare" in it's local site and install the
package from there.
The problem with this is the 256Kb WAN connection at a Branch.
When
they try to install a software package through DFS they access their
local plant server to do this, and it takes quite a long time. We
would like to add a DFS root target at the Branches also.
We would like to accomplish this by setting up a NAS device running
2003 Storage Server at the Branch, and have the users there pull their
software installations from this device. I am worried that with our
Active Directory setup, it may still pull from either a Plant Root
Target or Branch Root Target, and I only want it to pull from the
Branch Root Target. With the Insite Parameter, it is my understanding
that the workstation will pull from whatever DFS Root Target is in its
AD Site.
Since the Branch workstation will be in the same subnet as the Branch
Root Target, will the workstation pull from the Branch Root Target
every time, or will it pull from random Root Targets in it's AD Site?
If the pull is random, can we specify the Branch Root Target for that
Branch's workstations?
It's been recommended to me to just create another site for the branch
subnet. The problem is, there is no DC in that subnet, so how will the
workstations authenticate?
Thanks in advance for any assistance.

Jill Zoeller [MSFT]

2006-07-31 16:20:16 UTC

Permalink

I don't know if there's a command to set back to the defaults. You could try
assigning the same rank/class to all targets, thus making them equal. You
could also try just viewing the rank/class on a target that you haven't set
priority on. This should tell you the default.
--
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 chad
I will research how to assign a server to a site for authentication,
and try to get the branch in its own site.
Back to /targetpriority. Weirdest thing, after I set a high priority
on my NAS device in another site, I had clients accessing this share
from seperate sites.
Was is the command line to set rank and class back to default for a
target?

Post by Jill Zoeller [MSFT]
I did a search of support cases and did not see any for the error you
describe. Can you provide the exact syntax you are using? Feel free to
change the server names for privacy if you want.
Also, root scalability mode doesn't require any changes to root targets. It
just changes how namespace servers obtain updated information about the
namespace.
--
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]
Hi Chad,
You definitely have an interesting scenario! Are you using root
scalabilty
mode? It's something we recommend when you have more than 16 root
targets.
As for your situation, you are correct that if there are multiple
targets
in
a client's site, the client will pick one at random. For servers running
SP1, we do have a new feature called target priority, which lets you
specify
whether a target should always be first/last within a referral, or
first/last among same-site targets in the referral. The new DFS
Management
snap-in in R2 lets you configure this via the UI, but you can also
do
this
using Dfsutil (downloadable from www.microsoft.com/dfs). The
Dfsutil
option
has more granularity for this configuration. (We have a webcast on
configuring target priority available from the above link as well.)
Here is something to keep in mind--since you're using root targets,
not
link
targets, you'll need to install SP1 on all DCs in the domain
hosting
the
namespace. The DCs are what hand out domain-based root referrals,
so
you
need to install SP1 on them to enable this functionality.
Also, I believe there is a way to have DC-less sites--but I'm not
an
AD
expert so you might want to pose this question to an AD
newsgroup.
Using
sites is definitely the way to go as far as DFS is concerned.
--
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 chad
Our DFS Root and all of the targets are running 2003 Server Standard
R1. We are using FRS for replication.
We have 1 server at corporate that is acting as DFS Root, and I've
setup 69 root targets throughout our WAN, which are located at our
Plants. Our Branches (approximately 70) do not have servers on site,
but are authenticating to AD at our Plants. I've enabled the Insite
parameter on our DFS Share so that each workstation only
accesses
the
DFS Share at the server in their LAN at a Plant, or the local Plant
server for a Branch.
We push software installation packages using GPOs and DFS. I point
each package to the DFS Share, "\\domain.com\dfsshare". I do this
with computer policies. When the computer boots, it finds
"\\domain.com\dfsshare" in it's local site and install the
package from there.
The problem with this is the 256Kb WAN connection at a Branch.
When
they try to install a software package through DFS they access their
local plant server to do this, and it takes quite a long time.
We
would like to add a DFS root target at the Branches also.
We would like to accomplish this by setting up a NAS device running
2003 Storage Server at the Branch, and have the users there
pull
their
software installations from this device. I am worried that
with
our
Active Directory setup, it may still pull from either a Plant Root
Target or Branch Root Target, and I only want it to pull from the
Branch Root Target. With the Insite Parameter, it is my
understanding
that the workstation will pull from whatever DFS Root Target is
in
its
AD Site.
Since the Branch workstation will be in the same subnet as the Branch
Root Target, will the workstation pull from the Branch Root Target
every time, or will it pull from random Root Targets in it's AD Site?
If the pull is random, can we specify the Branch Root Target
for
that
Branch's workstations?
It's been recommended to me to just create another site for the
branch
subnet. The problem is, there is no DC in that subnet, so how
will the
workstations authenticate?
Thanks in advance for any assistance.