Discussion:
Accessing DFS Replica via \\servername\dfs$ gives randomly DFS roo
(too old to reply)
Jancsi
2006-08-14 10:57:02 UTC
Permalink
Hi,

we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to "distribute" the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can see this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?

kind regards
János Magoss
Jill Zoeller [MSFT]
2006-08-15 15:26:03 UTC
Permalink
There are a couple ways to do this, but these might or might not work for
you:

1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.

2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to "distribute" the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can see this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
Jancsi
2006-08-15 16:47:01 UTC
Permalink
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to "distribute" the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can see this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
Jill Zoeller [MSFT]
2006-08-15 17:52:54 UTC
Permalink
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.

Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?

Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
Jancsi
2006-08-15 18:29:02 UTC
Permalink
I will send you some "screenshots" tomorrow. It's not very hard to reproduce.
We have around 10 sites. One of the site has 4 DCs for one domain. For this
domain we have defined a DFS root called "DFS$" on a volume "D:" on each DC.
The other sites normally have 2 DCs for this domain. Normally we would access
the domain DFS with "\\domainname\DFS$" which will give us the the connection
to the server with the highest priority within the site (providing an exact
subnet definition for all sites). For the site with 4 DCs we want a kind of
load balancing. So we try to access the DFS using "\\servername1\DFS$",
"\\servername2\DFS$", "\\servername3\DFS$" or "\\servername4\DFS$" (depending
on the clients). First we thought that this worked because we saw and still
see the mappings with the stated servername. But when we do a "dir" on that
connected drive we see a different volume ID (e.g. "dir \\servername1\DFS$"
will show another volume id than "dir \\servername1\D$" even though they
reside physically on the same partition. If we compare the volume ID's
"\\servername1\DFS$" may show the volume ID of "\\servername2\D$"). We traced
it via ethereal and found that microsoft servers seem to "interpret" the
client request.
1. Client goes to the nearest DC and asks "can you give me the referral for
\\servername1\DFS$"
2. Server answers: "Sure! The referral is servername2!" (This may also
happen when the so asked DC itself is 'servername1' (funny)
3. Client connects to servername2 and gets the DFS root.

I would expect that particular behaviour, when we would address the DFS
using the domainname instead of the servername. So it really seems as if the
DCs would interpret the "\\servername1\DFS$" request, like "Hey you stupid
geek!! This is not a server based DFS! This is a domain based DFS!! If you
are too stupid to use it that way, I'll show you!"
OK. I admit: Sometimes or even often we do make mistakes and would
appreciate some help of the operating system. But in this case we do it by
purpose. ;-)
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
Dave Mills
2006-08-19 12:39:42 UTC
Permalink
Does your DRF$ contain only links to target shares or data. I ask as you do not
mention the targets shares.


or On Tue, 15 Aug 2006 11:29:02 -0700, Jancsi
Post by Jancsi
I will send you some "screenshots" tomorrow. It's not very hard to reproduce.
We have around 10 sites. One of the site has 4 DCs for one domain. For this
domain we have defined a DFS root called "DFS$" on a volume "D:" on each DC.
The other sites normally have 2 DCs for this domain. Normally we would access
the domain DFS with "\\domainname\DFS$" which will give us the the connection
to the server with the highest priority within the site (providing an exact
subnet definition for all sites). For the site with 4 DCs we want a kind of
load balancing. So we try to access the DFS using "\\servername1\DFS$",
"\\servername2\DFS$", "\\servername3\DFS$" or "\\servername4\DFS$" (depending
on the clients). First we thought that this worked because we saw and still
see the mappings with the stated servername. But when we do a "dir" on that
connected drive we see a different volume ID (e.g. "dir \\servername1\DFS$"
will show another volume id than "dir \\servername1\D$" even though they
reside physically on the same partition. If we compare the volume ID's
"\\servername1\DFS$" may show the volume ID of "\\servername2\D$"). We traced
it via ethereal and found that microsoft servers seem to "interpret" the
client request.
1. Client goes to the nearest DC and asks "can you give me the referral for
\\servername1\DFS$"
2. Server answers: "Sure! The referral is servername2!" (This may also
happen when the so asked DC itself is 'servername1' (funny)
3. Client connects to servername2 and gets the DFS root.
I would expect that particular behaviour, when we would address the DFS
using the domainname instead of the servername. So it really seems as if the
DCs would interpret the "\\servername1\DFS$" request, like "Hey you stupid
geek!! This is not a server based DFS! This is a domain based DFS!! If you
are too stupid to use it that way, I'll show you!"
OK. I admit: Sometimes or even often we do make mistakes and would
appreciate some help of the operating system. But in this case we do it by
purpose. ;-)
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Jancsi
2006-08-19 17:49:02 UTC
Permalink
We onnly use it as DFS and not with FRS. That means we only use for target data
Post by Dave Mills
Does your DRF$ contain only links to target shares or data. I ask as you do not
mention the targets shares.
or On Tue, 15 Aug 2006 11:29:02 -0700, Jancsi
Post by Jancsi
I will send you some "screenshots" tomorrow. It's not very hard to reproduce.
We have around 10 sites. One of the site has 4 DCs for one domain. For this
domain we have defined a DFS root called "DFS$" on a volume "D:" on each DC.
The other sites normally have 2 DCs for this domain. Normally we would access
the domain DFS with "\\domainname\DFS$" which will give us the the connection
to the server with the highest priority within the site (providing an exact
subnet definition for all sites). For the site with 4 DCs we want a kind of
load balancing. So we try to access the DFS using "\\servername1\DFS$",
"\\servername2\DFS$", "\\servername3\DFS$" or "\\servername4\DFS$" (depending
on the clients). First we thought that this worked because we saw and still
see the mappings with the stated servername. But when we do a "dir" on that
connected drive we see a different volume ID (e.g. "dir \\servername1\DFS$"
will show another volume id than "dir \\servername1\D$" even though they
reside physically on the same partition. If we compare the volume ID's
"\\servername1\DFS$" may show the volume ID of "\\servername2\D$"). We traced
it via ethereal and found that microsoft servers seem to "interpret" the
client request.
1. Client goes to the nearest DC and asks "can you give me the referral for
\\servername1\DFS$"
2. Server answers: "Sure! The referral is servername2!" (This may also
happen when the so asked DC itself is 'servername1' (funny)
3. Client connects to servername2 and gets the DFS root.
I would expect that particular behaviour, when we would address the DFS
using the domainname instead of the servername. So it really seems as if the
DCs would interpret the "\\servername1\DFS$" request, like "Hey you stupid
geek!! This is not a server based DFS! This is a domain based DFS!! If you
are too stupid to use it that way, I'll show you!"
OK. I admit: Sometimes or even often we do make mistakes and would
appreciate some help of the operating system. But in this case we do it by
purpose. ;-)
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different
server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified
server
name?
kind regards
János Magoss
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Dave Mills
2006-08-28 07:48:35 UTC
Permalink
Sorry for the late reply. Been too busy to keep up.

I think from what you say that you are actually putting the data into the DFS$
folder instead of Links. It which case the client is asking for a referral for
\\servername1\DFS$ this is known to be a domain based dfs so the client gets
redirected to the DC to resolve a DFR Root server. I do not think it says "Ah
that's me" at this stage. It then connects to the DFR Root server that the DC
nominates, which could be any of them, and there it finds the data, not a link
to the target server so it returns the data.

To get the functionality you want you need to locate the data on a server and
share the folder. Then you need to create a Target within the DFS root that
points to the shared folder. Then you can either open the share on the server
(avoiding DFS) or use DFS to resolve the path to the share.

Something like

\\domain\dfs$\data --> \\server1\data and --> \\server2\data
instead of putting the data in DFS$
Post by Jancsi
We onnly use it as DFS and not with FRS. That means we only use for target data
Post by Dave Mills
Does your DRF$ contain only links to target shares or data. I ask as you do not
mention the targets shares.
or On Tue, 15 Aug 2006 11:29:02 -0700, Jancsi
Post by Jancsi
I will send you some "screenshots" tomorrow. It's not very hard to reproduce.
We have around 10 sites. One of the site has 4 DCs for one domain. For this
domain we have defined a DFS root called "DFS$" on a volume "D:" on each DC.
The other sites normally have 2 DCs for this domain. Normally we would access
the domain DFS with "\\domainname\DFS$" which will give us the the connection
to the server with the highest priority within the site (providing an exact
subnet definition for all sites). For the site with 4 DCs we want a kind of
load balancing. So we try to access the DFS using "\\servername1\DFS$",
"\\servername2\DFS$", "\\servername3\DFS$" or "\\servername4\DFS$" (depending
on the clients). First we thought that this worked because we saw and still
see the mappings with the stated servername. But when we do a "dir" on that
connected drive we see a different volume ID (e.g. "dir \\servername1\DFS$"
will show another volume id than "dir \\servername1\D$" even though they
reside physically on the same partition. If we compare the volume ID's
"\\servername1\DFS$" may show the volume ID of "\\servername2\D$"). We traced
it via ethereal and found that microsoft servers seem to "interpret" the
client request.
1. Client goes to the nearest DC and asks "can you give me the referral for
\\servername1\DFS$"
2. Server answers: "Sure! The referral is servername2!" (This may also
happen when the so asked DC itself is 'servername1' (funny)
3. Client connects to servername2 and gets the DFS root.
I would expect that particular behaviour, when we would address the DFS
using the domainname instead of the servername. So it really seems as if the
DCs would interpret the "\\servername1\DFS$" request, like "Hey you stupid
geek!! This is not a server based DFS! This is a domain based DFS!! If you
are too stupid to use it that way, I'll show you!"
OK. I admit: Sometimes or even often we do make mistakes and would
appreciate some help of the operating system. But in this case we do it by
purpose. ;-)
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead
of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server
name
explicitly won't hinder DFS to connect the user to a totally different
server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified
server
name?
kind regards
János Magoss
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Jancsi
2006-08-28 11:27:02 UTC
Permalink
Definitly not: The data is mostly located on a SAN connected to a NetApp.
Some of the data is located on Microsoft Clusters as well. We only have the
links defined in DFS. There is not a single file in DFS$, only "directories".
Post by Dave Mills
Sorry for the late reply. Been too busy to keep up.
I think from what you say that you are actually putting the data into the DFS$
folder instead of Links. It which case the client is asking for a referral for
\\servername1\DFS$ this is known to be a domain based dfs so the client gets
redirected to the DC to resolve a DFR Root server. I do not think it says "Ah
that's me" at this stage. It then connects to the DFR Root server that the DC
nominates, which could be any of them, and there it finds the data, not a link
to the target server so it returns the data.
To get the functionality you want you need to locate the data on a server and
share the folder. Then you need to create a Target within the DFS root that
points to the shared folder. Then you can either open the share on the server
(avoiding DFS) or use DFS to resolve the path to the share.
Something like
\\domain\dfs$\data --> \\server1\data and --> \\server2\data
instead of putting the data in DFS$
Post by Jancsi
We onnly use it as DFS and not with FRS. That means we only use for target data
Post by Dave Mills
Does your DRF$ contain only links to target shares or data. I ask as you do not
mention the targets shares.
or On Tue, 15 Aug 2006 11:29:02 -0700, Jancsi
Post by Jancsi
I will send you some "screenshots" tomorrow. It's not very hard to reproduce.
We have around 10 sites. One of the site has 4 DCs for one domain. For this
domain we have defined a DFS root called "DFS$" on a volume "D:" on each DC.
The other sites normally have 2 DCs for this domain. Normally we would access
the domain DFS with "\\domainname\DFS$" which will give us the the connection
to the server with the highest priority within the site (providing an exact
subnet definition for all sites). For the site with 4 DCs we want a kind of
load balancing. So we try to access the DFS using "\\servername1\DFS$",
"\\servername2\DFS$", "\\servername3\DFS$" or "\\servername4\DFS$" (depending
on the clients). First we thought that this worked because we saw and still
see the mappings with the stated servername. But when we do a "dir" on that
connected drive we see a different volume ID (e.g. "dir \\servername1\DFS$"
will show another volume id than "dir \\servername1\D$" even though they
reside physically on the same partition. If we compare the volume ID's
"\\servername1\DFS$" may show the volume ID of "\\servername2\D$"). We traced
it via ethereal and found that microsoft servers seem to "interpret" the
client request.
1. Client goes to the nearest DC and asks "can you give me the referral for
\\servername1\DFS$"
2. Server answers: "Sure! The referral is servername2!" (This may also
happen when the so asked DC itself is 'servername1' (funny)
3. Client connects to servername2 and gets the DFS root.
I would expect that particular behaviour, when we would address the DFS
using the domainname instead of the servername. So it really seems as if the
DCs would interpret the "\\servername1\DFS$" request, like "Hey you stupid
geek!! This is not a server based DFS! This is a domain based DFS!! If you
are too stupid to use it that way, I'll show you!"
OK. I admit: Sometimes or even often we do make mistakes and would
appreciate some help of the operating system. But in this case we do it by
purpose. ;-)
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the
client
to connect to a specific server in its own site. And may be another client
in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets
are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires
that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead
of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server
name
explicitly won't hinder DFS to connect the user to a totally different
server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified
server
name?
kind regards
János Magoss
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Jancsi
2006-08-21 05:21:01 UTC
Permalink
Hi,

I promised to send you screenshots. What I did: I wrote a batch job that
makes a directory listing. First of \\domainname\dfs$ (with domain name =
"dz") and then to "\\logonserver\dfs$" followed by directory listings of each
servers "D$" where DFS$ is located. I deleted the directory entries.
Important are the volume serial numbers:

C:\TEMP>dir \\dz\dfs$
Volume in drive \\dz\dfs$ is Data
Volume Serial Number is FCAA-FE48

Directory of \\dz\dfs$

05/20/2006 16:47 <DIR> .
05/20/2006 16:47 <DIR> ..
0 File(s) 0 bytes
9 Dir(s) 25.136.701.440 bytes free

C:\TEMP>dir \\dfhidca4\dfs$
Volume in drive \\dfhidca4\dfs$ is Data
Volume Serial Number is FCAA-FE48

Directory of \\dfhidca4\dfs$

05/20/2006 16:47 <DIR> .
05/20/2006 16:47 <DIR> ..
0 File(s) 0 bytes
9 Dir(s) 25.136.701.440 bytes free

C:\TEMP>dir \\dfhidca4\d$
Volume in drive \\dfhidca4\d$ is DATA
Volume Serial Number is 5063-E3AE

Directory of \\dfhidca4\d$

0 File(s) 0 bytes
5 Dir(s) 25.878.241.280 bytes free

C:\TEMP>dir \\dfhidca1\d$
Volume in drive \\dfhidca1\d$ is DATA
Volume Serial Number is C80F-2399

Directory of \\dfhidca1\d$

0 File(s) 0 bytes
6 Dir(s) 25.624.428.544 bytes free

C:\TEMP>dir \\dfridca2\d$
Volume in drive \\dfridca2\d$ is Data
Volume Serial Number is FCAA-FE48

Directory of \\dfridca2\d$

1 File(s) 149.192 bytes
7 Dir(s) 25.136.701.440 bytes free

C:\TEMP>dir \\dfridca3\d$
Volume in drive \\dfridca3\d$ is Data
Volume Serial Number is 2CCC-0BB5

Directory of \\dfridca3\d$

0 File(s) 0 bytes
8 Dir(s) 25.545.515.008 bytes free

kind regards
János
Post by Jill Zoeller [MSFT]
You're right--target priority isn't going to give you exactly what you want.
I don't think that DFS is going to give you the kind of control you're
looking for, unfortunately. This just wasn't how DFS was designed.
Also, the reason why DFS is "intercepting" the \\servername\DFS$ is that the
share is being used by DFS and therefore the client requires the DFS
redirector (as opposed to the SMB redirector) to receive referrals from any
links under the root. If the client (incorrectly) interprets
\\servername\DFS$ as a non-DFS share, the links under the root won't work.
What I can't explain is why you're seeing another server name in the network
connection--this is the second report I've seen on this. I'd be interested
in seeing a better illustration of this--would you mind emailing me some
screenshots and steps to reproduce the problem?
Have you tried installing Dfsutil on your clients to view the referrals the
client receives? This is more for an educational perspective rather than
troubleshooting. It's interesting to see the referrals to understand what's
going on beneath the covers so to speak.
--
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 Jancsi
Thanks for the explanation. The problem is, that we want to force the client
to connect to a specific server in its own site. And may be another client in
the same site to another server. That can't be done using the target
priority, if I understood that correctly. May be I didn't find the right
words for my question.
Is it possible to connect within a domain based DFS to a specific server in
a site that may be different for other clients in the same site?
And the second question is: Why does a client a using "\\servername\dfs$"
get a connection and the DFS-replica of another server as stated in the
command even though it still shows the correct servername when I list the
network connection?
Post by Jill Zoeller [MSFT]
There are a couple ways to do this, but these might or might not work for
1. Force a client to connect to a server in its own site by setting the
insite parameter on the root. This assumes that your sites and subnets are
all set up correctly in AD.
2. Set target priority on a server to specify that it's always first in a
referral, or first among same-site targets in a referral. This requires that
the DCs run W2K3 SP1 because target priority was new in SP1.
--
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 Jancsi
Hi,
we got a problem here. We have a DFS tree with 10 root targets. Instead of
using "\\domain_name\dfs$" we use "\\%logonserver%\dfs$" to
"distribute"
the
DFS access onto different servers. But we found that using the server name
explicitly won't hinder DFS to connect the user to a totally different server
even though the network connection shows "\\servername\dfs$". We can
see
this
when we compare the volume ID's that are shown during the dir command.
Is it possible to force Microsoft DFS to use explicitly the specified server
name?
kind regards
János Magoss
Loading...