Windows Server

Jeff VanBishler · Guest

Greetings all. I'm having some problems with my DFS/FRS implementation and
am hoping someone here might point me in the right direction. Here's the
setup:

We have two offices which I'll call "HQ" and "Branch".

Prior to adding two new Windows 2003 DCs a few weeks ago, we had a newer
Windows 2000 DC at our HQ office; I'll call this server HQ-DC2K. There are
several other Windows 2000 Servers in our HQ office, including a second,
"backup" DC that's getting a bit long in the tooth. However, none of these
other servers were involved in DFS or FRS and so I think we can safely
ignore them. At our Branch office we had a Windows 2000 DC, which I'll call
Branch-DC2K, and a Windows 2000 member server running Exchange, which I'll
call Branch-MS2K.

Each of these offices is on a different IP subnet and each is configured in
Active Directory Sites & Services as its own site. There is an IP Inter-site
Transport configured in ADS&S which maps to the 512 Kbps WAN link between
the two offices. I'm fairly certain I have all of the site information
configured correctly in Active Directory.

I set up a DFS namespace root called "Corp" on HQ-DC2K. I wished to add a
replica of that root to our Branch office site, but because the domain
controller in the branch office (Branch-DC2K) is quite old and nearing
replacement, I decided to put it on the newer non-DC server in that office
(Branch-MS2K) instead. I then started adding various DFS links to the Corp
root. Each of these links had two replicated targets - one in our HQ office
and one in our Branch office. The data that these links referred to was
basically roaming profile and desktop/My Documents redirection data. I
wanted our users to be able to roam between the two offices but have their
desktop/documents/profiles remain local to them no matter which office they
were in. Everything seemed to be working well. So far, so good.

At this point I brought in two new Windows 2003 servers (our first 2003
servers, btw) and set them up as domain controllers. One was going to
replace the "backup" DC in our HQ office. The other was to replace the
Branch-DC2K server. I'll call these new servers HQ-DC2K3 and Branch-DC2K3,
respectively. I started by setting up both of these new servers in our HQ
office. This meant that, at least initially, the server that was destined to
become the new domain controller in our Branch office was part of the HQ
site temporarily rather than the Branch site. I did this because, in
addition to being easier to set up when both servers were in the same place,
there was a large set of Word document data (about 4 GB) that I wanted to
set up in DFS to replicate between the two new 2003 servers. Up to this
point, that data had only resided in our HQ office and Branch users were
forced to access it across the WAN, which meant some annoying delays for
those users. Now that we were rolling out two new 2003 servers, I figured it
was a good opportunity to add that data set to our DFS/FRS system, which was
working pretty well so far.

Once all that data had replicated, I moved the new Branch-DC2K3 server from
the HQ office down to the Branch office and moved it from the HQ site to the
Branch site in AD Sites & Services. This is where the problems started. Even
after a week of being on-site, DFS referrals to our Word document data were
frequently pointing users in our Branch office to a server in our HQ office
instead of one in the Branch office and vice versa. No matter what I tried -
and I tried everything I could find from a whole host of references,
including this newsgroup - nothing worked. At this point, it would probably
help if I illustrate what our DFS namespace and DFS/FRS links looked like:

DFS Root named "Corp" - two replicas: HQ-DC2K and Branch-MS2K
DFS link named "Profiles" - two replicas: HQ-DC2K and Branch-MS2K
(roaming profile data)
DFS link named "Redirection" - two replicas: HQ-DC2K and Branch-MS2K
(folder redirection data)
DFS link named "WordData" - two replicas: HQ-DC2K3 and Branch-MS2K3
(company Word documents)

My only thought was that because the two servers that hosted our namespace
root were running Windows 2000, they were having trouble when referring to
links running Windows 2003. Alternatively, since the Branch office root host
was not a domain controller, but merely a member server, I theorized that
might also be causing or contributing to the problem.

My solution then was to change the root hosts to our new Windows 2003
servers and remove the Windows 2000 servers from that job. I didn't want to
rebuild the entire DFS namespace (and all of the file replication that would
entail) so I figured the easiest way to accomplish what I wanted was to, one
at a time starting with the Branch office, add a 2003 server as a new root
target and then remove the 2000 server it was replacing.

I started by adding the Branch-DC2K3 server as a new root target to the
"Corp" set. I then waited a day for active directory replication to complete
and for file replication to occur. However, I believe I made two mistakes:
one I did this over a weekend when no one was on the system and no files
were changing, and two I failed to fully test how DFS referral was working
on the 2K3 server. I then made a further blunder by removing the Branch-MS2K
server from the Corp root target set.

Come Monday morning, it became clear that something had gone very wrong.
Users were reporting that their desktops and My Documents had disappeared!
It didn't take me long to figure out why. The "Corp" root target on the 2003
server in our branch office is behaving not like a root target, referring
clients to the nearest folder share containing the data they want, but
rather it is acting like a giant DFS/FRS link with data showing up under the
"Corp" share on that server. For example, on the HQ-DC2K server which is
still working okay, if I go to the directory called "Corp" which has the
"Corp" share mapped to it, I can see folder names for all of the DFS links
that it manages, but if I try to access one of those folders, I get an
access denied message. Also, if I get a referral to a DFS link from that
server and I check properties on that link and go to the "DFS" tab, I'll see
the two servers and shares that I expect to see for that replica set, eg.
\\HQ-DC2K\Profiles and \\Branch-MS2K\Profiles. However, if I get a DFS
referral from the Branch-DC2K3 server and check the "DFS" tab for that link
I'll see that the two server shares listed are \\HQ-DC2K\Corp and
\\Branch-DC2K3\Corp no matter what the link is supposed to be. If I further
check the "Corp" folder on the Branch-DC2K3 server, all of the folders are
accessible and they have data in them, albeit not all of the data as not all
of our users had logged in yet when I found the problem and so I was able to
take some stopgap measures to stop the bleeding.

So now, my DFS namespace is broken and looks like this in the DFS snap-in:

DFS Root named "Corp" - two replicas: HQ-DC2K and Branch-DC2K3
DFS link named "Profiles" - two replicas: HQ-DC2K and Branch-MS2K
(roaming profile data)
DFS link named "Redirection" - two replicas: HQ-DC2K and Branch-MS2K
(folder redirection data)
DFS link named "WordData" - two replicas: HQ-DC2K3 and Branch-MS2K3
(company Word documents)

It *looks* right in the DFS snap-in, but it's obviously not working right.
So my questions are:

1) Am I right in my assessment that the procedure I used to add the
Branch-DC2K3 server as a DFS root target for Corp and to remove the
Branch-MS2K server from that same root was incorrect? If so, how should it
have been done and what can I do now to correct the problem?

2) Does anyone have any idea how I can solve my original problem of not
getting the consistently correct DFS referral based on how I have AD Sites &
Services and DFS configured?

Apologies for the length of my post and thank you very much for any help
that any of you might be able to offer.

-Jeff VanBishler

Paul Williams [MVP] · Guest

Thanks for that novel Jeff ;-)

Jeff VanBishler · Guest

"Paul Williams [MVP]" <ptw2001@hotmail.com> wrote in message
news:%23jow%23k43FHA.1184@TK2MSFTNGP12.phx.gbl...

Paul Williams [MVP] · Guest

On a serious note, it's much better to have a long, full, informative post
as opposed to me having to ask for more details. So no need to shorten.
: )

	Windows Server Forum Index -> DFS and FRS	All times are GMT
Page 1 of 1