• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 45
  • Last Modified:

DFS suddenly screwed up?

We had a problem this morning where suddenly, inexplicably after months of running with no issue, some of users were routed to the wrong file share via a DFS path.  Here's the setup:

We have two sites: Corporate (actually called Default-First-Site-Name) and DR.  In AD Sites/Services, we've defined these Sites by IP ranges - our 10.12.XXX.XXX ranges are Corporate and our 10.13.XXX.XXX ranges are DR.  In DFS, we a folder target (\\blah\public\profiles) with two paths: one for Corporate and one for DR.  The DR file share (obviously) is located on a file server in our DR site, and is a mirrored copy of the file share located in our Corporate site.

This has never been a problem, until today, when suddenly all of users reported really slow sessions.  Some quick research revealed that users were drawing their profiles from our DR site thru the DFS path for some unknown reason.  Nothing had changed in the configuration in months.  We disabled the DR path in DFS, had everyone reboot, and all was back to normal.

So, how can this happen?  My understanding is that when you logon to the domain, you'll be assigned to the appropriate Site based on your IP, and then you'll resolve your DFS paths based on your Site, full stop.  Is there some sort of load balancing going on underneath the hood that I don't know about that might elect to pop someone over to a different path that isn't supposed to be available to that Site?

Matt Hentrich
Matt Hentrich
  • 2
1 Solution
Matt HentrichAuthor Commented:
Nevermind, I found the answer to my own problem.  It's called 'Referral Ordering', found by right clicking on the DFS Namespace and looking at the Referral tab.  It uses a 'lower cost' calculation to determine which folder to hand out, which *usually* be the server in the same site, but maybe not always.  Something must have made my DR file server a 'lower cost' than my Corporate one for a short while this morning - what that something is remains a mystery, but that's my answer.

There is a setting for 'Exclude targets outside of the client's site'.  I'll be setting that to resolve the problem in the future.
Matt HentrichAuthor Commented:
Addendum to my last comment: Actually, I'll be toggling the 'Exclude targets outside of my client's site' flag on the Folder Target group itself, not the Namespace, so that I don't screw the rest of those folders up.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now