Critical DFS problems

  • Thread starter Thread starter Bhargav Shukla
  • Start date Start date
B

Bhargav Shukla

Looks like the participation of experts in MS newsgrups has been going down.
I use the groups regularly and noticed nowadays my posts goes unanswered. I
get no answers for many days. Sorry for repost but the issue is critical.
Thanks for all help in advance.

All of a sudden this started cropping up in our network. Users started
getting errors with DFS shares. Here is what happens.

When user tries to open the DFS location they get the error
\\dfsroot.mydomain.com could not be found. When they try accessing the same
files using direct share \\server1\... it works!

For some users it even works when they type \\dfsroot but fails when they
try \\dfsroot.mydomain.com

For some users deleting the shortcut to DFS and recreating them solved the
problem. For others nothing worked!

All help is appreciated.

Thanks,
Bhargav Shukla
 
Is this a domain based DFS root or a standalone?
by what you are saying it looks like a standalone, so does that mean dfsroot
is the name of your server? which has a link that points to
\\server1\share ?

Can you give us your DFS layout? i.e some thing like
\\dfsroot.mydomain.com\share1 points to \\server1\share1 . How many
servers are involved? are you using FRS ? or just DFS redirection?
What is the exact error they get? "access denied"; "filename, directory
name, or volume label syntax is incorrect"

May be these answers will trigger the experts to answer them for you.
BTW, I am no expert on DFS, just begun implementing it in our environment
and every time someone brings up a DFS problem, it keeps me awake all night
hoping I don't get into a similar issue at my site :) We have put a lot of
effort to get DFS implemented and hope to benefit from it on the long run.
-G
 
Thanks for your response.

All referenced in my post are Domain DFS roots. We do not use standalone
roots.

Our dfs layout is \\company.parent.com\share (won't disclose actual names
due to obvious reasons). The share has 2 replicas on \\server1\share and
\\server2\share they are not DCs. Since they are domain DFS roots and
replicas and we have replication enabled on them, FRS is started and
automatic service.

Users are reporting different errors and we are 3rd level support so we
don't know exact errors. Most of them just can't get thru to the dfs share
when they use \\company.parent.com\share or \\company\share. They sure can
access the files when they use \\server1\share or \\server2\share. From one
of the tickets "The network path not found" is the error.

For your concern about your infrastructure, you are right. That's why these
groups comes handy. They are good resource and helps just to see what's
going on with others and it helps us avoid many issues if we are proactive.

We have opened incidense with microsoft. Let's see how we make out. If you
are interested in more details, post here and I will share.

Thanks,
Bhargav
 
First, you probably shouldn't have replication explicitly turned on for the
roots. I learned the hard way about that.

Second, I believe the syntax is \\domain\dfsroot - I don't know what you
meant by \\dfsroot.mydomain.com\share
 
Sorry about the confusion. In my second post I have it corrected to
\\company.parent.com (FQDN) or \\company (NetBIOS) which represents domain.

I did not understand the first part... about replication policy. If you can
explain a bit it will be helpful. Sorry if I'm asking stupid question.
Thanks for all your help.
 
Well, here's a couple of points about roots I learned the hard way

- you should not use the root for storing any files. It is only the
"placeholder" for the links.
- when you create a second root target, the placeholder information will
replicate automatically. you do not need to explicitly "turn on"
replication like you do on a link. Doing so will likely cause major
problems. (And it gets really nasty if you combine these two!)

They've changed the terminology a bit with Windows 2003 to make this a
little clearer.
 
Daniel,

Thanks for pointers.

You are right, we do not put any data in root itself. It's used only as a
placeholder.

Thanks,
Bhargav
 
Hi,

which operating systems do you use for your clients? If not Windows 2000 and
higher, do you use the "active directory client extensions" on the clients?

Are the now used target servers always used since the start of dfs. Were
there other servers in place, which are deactivated now?

Do you have a fully functional name resolution and Active Directory
Replication?

Are the clients in other subnets than the servers?

If you have multiple domains, can the clients, which reside in a subdomain,
resolve names of the root domain? I ask, because certain service records
like global catalogs are only stored in the dns root domain zone.

Greetings,
Daniel
 
Hi,

Daniel Vollmer said:
Hi,

which operating systems do you use for your clients? If not Windows 2000 and
higher, do you use the "active directory client extensions" on the clients?
Click to expand...

All W2K and WinXP machines.
Are the now used target servers always used since the start of dfs. Were
there other servers in place, which are deactivated now?
Click to expand...

Same Servers.
Do you have a fully functional name resolution and Active Directory
Replication?

Yes.

Are the clients in other subnets than the servers?

Yes.

If you have multiple domains, can the clients, which reside in a subdomain,
resolve names of the root domain? I ask, because certain service records
like global catalogs are only stored in the dns root domain zone.

Yes.

Greetings,
Daniel
Click to expand...


For some reason, the error disappeared. We still don't know what caused the
problem and what solved it. We had open support incident with Microsoft
(which is closed now) which did not help because we can't reproduce the
error.

Thanks for all your help.

Bhargav
 
Back
Top