dfs over vpn

[RW]

I have setup 2 x 2008 files server and DFS name space, each server is in its
own phisical loction connected site-to-site vpn, replication works as
expected problem we are facing is that some people have problem with
accessing shared drives over vpn connection when connecting with vpn client
from home. locally on both sites all works. What is interseting those who do
have this problem can access \\domain\netlogon but cannot access
\\domain\namespace they can in second case path not found and because of that
any share in format \\domain\namespace\share cannot be map
any idea? there is nothing unique about those user AD profiles, laptops are
built base on same image

[RW]

ok so now I have experiance this myself where I used never had problem with
this, when I try to access shares at \\domain\share I get this error message:
"<drive>:\ is not accessible. Configuration Information could not be read
from the domain controller, either because the machine is unavailable, or
access has been denied"

this message is totally missleading because neither one is true, DCs are
avaliable and I have access to them at the same time I cannot access shared
drives on dfs.

access to is set exactly the same on all shares and roots for all files
servers in DFS name space in addition I'm domain admin so this cannot be
that, and I can access it no problem while in the office.

what I found is that if I do "net stop dfs" & "net start dfs" on dfs file
server I should be connected to no problem I get access with out even
restarting PC or reopening windows explorer. What I have to mention is also
that at the time this happens DFS namespace service is still running, no
hangs, crashes, not a single indication in event log that there is a problem
with service.... and if I connect remote desktop to workstation located in
LAN and try to access same share drive I have no problem accessing it without
restarting dfs service. So what ever this stop/start dfs does it is allowing
vpn client to connect to shares. WHY?!

Post by RW
I have setup 2 x 2008 files server and DFS name space, each server is in its
own phisical loction connected site-to-site vpn, replication works as
expected problem we are facing is that some people have problem with
accessing shared drives over vpn connection when connecting with vpn client
from home. locally on both sites all works. What is interseting those who do
have this problem can access \\domain\netlogon but cannot access
\\domain\namespace they can in second case path not found and because of that
any share in format \\domain\namespace\share cannot be map
any idea? there is nothing unique about those user AD profiles, laptops are
built base on same image

[ciscokid03]

Post by RW
ok so now I have experiance this myself where I used never had problem with
"<drive>:\ is not accessible. Configuration Information could not be read
from the domain controller, either because the machine is unavailable, or
access has been denied"
this message is totally missleading because neither one is true, DCs are
avaliable and I have access to them at the same time I cannot access shared
drives on dfs.
access to is set exactly the same on all shares and roots for all files
servers in DFS name space in addition I'm domain admin so this cannot be
that, and I can access it no problem while in the office.
what I found is that if I do "net stop dfs" & "net start dfs" on dfs file
server I should be connected to no problem I get access with out even
restarting PC or reopening windows explorer. What I have to mention is also
that at the time this happens DFS namespace service is still running, no
hangs, crashes, not a single indication in event log that there is a problem
with service.... and if I connect remote desktop to workstation located in
LAN and try to access same share drive I have no problem accessing it without
restarting dfs service. So what ever this stop/start dfs does it is allowing
vpn client to connect to shares. WHY?!

Post by RW
I have setup 2 x 2008 files server and DFS name space, each server is in its
own phisical loction connected site-to-site vpn, replication works as
expected problem we are facing is that some people have problem with
accessing shared drives over vpn connection when connecting with vpn client
from home. locally on both sites all works. What is interseting those who do
have this problem can access \\domain\netlogon but cannot access
\\domain\namespace they can in second case path not found and because of that
any share in format \\domain\namespace\share cannot be map
any idea? there is nothing unique about those user AD profiles, laptops are
built base on same image

[ciscokid03]

ok...i hear you...i have the same problem. however, i think my problem has
to do with DNS. specifically, my domain name is technical.com
(internal)...when my vpn users try to resolve the dfs root by that name they
actually end up resolving a public technical.com domain that obviously is not
our network...confusing?!

i think i can resolve my issue if i can tell my vpn clients to never try to
resolve dns names OUTSIDE of our internal dns servers...any way to do that.

wondering if you have the same case scenario...

Post by RW
ok so now I have experiance this myself where I used never had problem with
"<drive>:\ is not accessible. Configuration Information could not be read
from the domain controller, either because the machine is unavailable, or
access has been denied"
this message is totally missleading because neither one is true, DCs are
avaliable and I have access to them at the same time I cannot access shared
drives on dfs.
access to is set exactly the same on all shares and roots for all files
servers in DFS name space in addition I'm domain admin so this cannot be
that, and I can access it no problem while in the office.
what I found is that if I do "net stop dfs" & "net start dfs" on dfs file
server I should be connected to no problem I get access with out even
restarting PC or reopening windows explorer. What I have to mention is also
that at the time this happens DFS namespace service is still running, no
hangs, crashes, not a single indication in event log that there is a problem
with service.... and if I connect remote desktop to workstation located in
LAN and try to access same share drive I have no problem accessing it without
restarting dfs service. So what ever this stop/start dfs does it is allowing
vpn client to connect to shares. WHY?!

Post by RW
I have setup 2 x 2008 files server and DFS name space, each server is in its
own phisical loction connected site-to-site vpn, replication works as
expected problem we are facing is that some people have problem with
accessing shared drives over vpn connection when connecting with vpn client
from home. locally on both sites all works. What is interseting those who do
have this problem can access \\domain\netlogon but cannot access
\\domain\namespace they can in second case path not found and because of that
any share in format \\domain\namespace\share cannot be map
any idea? there is nothing unique about those user AD profiles, laptops are
built base on same image

[DaveMills]

On Thu, 22 Oct 2009 12:54:02 -0700, ciscokid03

Post by ciscokid03
ok...i hear you...i have the same problem. however, i think my problem has
to do with DNS. specifically, my domain name is technical.com
(internal)...when my vpn users try to resolve the dfs root by that name they
actually end up resolving a public technical.com domain that obviously is not
our network...confusing?!

This would cause you much bigger issues since no internal server names would
resolve either so that could not connect to \\fileserver\uncpath either.

If your issue is just not being able to resolve the DNS root then are the VPN
client computers members of the domain. If not then they cannot know about the
DCs needed to find the DFS server supporting the domain based DFS root. They
could however use \\DFSServer\DFSRoot.

Normally VPN clients use the internal DNS servers when connected but this does
not always happen. I have yet to work out why some computers (XP) get this wrong
though.

Post by ciscokid03
i think i can resolve my issue if i can tell my vpn clients to never try to
resolve dns names OUTSIDE of our internal dns servers...any way to do that.
wondering if you have the same case scenario...

Post by RW
ok so now I have experiance this myself where I used never had problem with
"<drive>:\ is not accessible. Configuration Information could not be read
from the domain controller, either because the machine is unavailable, or
access has been denied"
this message is totally missleading because neither one is true, DCs are
avaliable and I have access to them at the same time I cannot access shared
drives on dfs.
access to is set exactly the same on all shares and roots for all files
servers in DFS name space in addition I'm domain admin so this cannot be
that, and I can access it no problem while in the office.
what I found is that if I do "net stop dfs" & "net start dfs" on dfs file
server I should be connected to no problem I get access with out even
restarting PC or reopening windows explorer. What I have to mention is also
that at the time this happens DFS namespace service is still running, no
hangs, crashes, not a single indication in event log that there is a problem
with service.... and if I connect remote desktop to workstation located in
LAN and try to access same share drive I have no problem accessing it without
restarting dfs service. So what ever this stop/start dfs does it is allowing
vpn client to connect to shares. WHY?!

Post by RW
I have setup 2 x 2008 files server and DFS name space, each server is in its
own phisical loction connected site-to-site vpn, replication works as
expected problem we are facing is that some people have problem with
accessing shared drives over vpn connection when connecting with vpn client
from home. locally on both sites all works. What is interseting those who do
have this problem can access \\domain\netlogon but cannot access
\\domain\namespace they can in second case path not found and because of that
any share in format \\domain\namespace\share cannot be map
any idea? there is nothing unique about those user AD profiles, laptops are
built base on same image