DFS replication of user profiles and home directories

[Gordon Fecyk]

Back in May 2004 a gentleman named "ptwilliams" game me some pointers on
setting up roving user profiles that can rove between locations, ie: between
branch offices. I was able to create a DFS root share, replicate it between
two DCs, and set up a user's home directory and profile on it. The user's
profile and home shares looked something like this:

\\example.com\dfsroot\users\%username%
\\example.com\dfsroot\profiles\%username%

When I create a user using these folders, it creates the folders with the
correct permissions. I checked each DC's copy of the dfsroot share and
everything gets replicated properly including the permissions. The trick
now is to ensure that workstations (All Win2K Pro SP4) use the nearest DC
for copies of the dfsroot, and therefore its profiles and home shares.

So far, so good, but ptwilliams recommended that I restrict the number of
DCs to "one per site." Right now, the domain which I'll keep calling
example.com has just one site, the "Default-First-Site-Name," and I've added
a subnet for each office to this site. In this case the subnets are:

10.0.1.0/26
10.0.1.64/26

Once I've replicated everything I need, I'll move the new DC to
10.0.1.64/26. The first DC, which happens to be a SBS2000 machine and is
"king of the DS forest" as such, is in 10.0.1.0/26. Routing is taken care
of through VPN routers.

Now, do I need to create a new site in Active Directory Sites and Services
for each office, and in turn each subnet, and then move each DC to its own
site? Or is it adequate to define these subnets in a single site and just
have one DC in each subnet? All I need to make sure of is the workstations
use the closest DC for their logon server, logon scripts and local DFS
replica.

Each DC at each office will have its own DHCP services, and settings which
point to itself as the primary DNS server, so the machines on a given subnet
should use that subnet's DC as its primary DNS server.

 

[Dave Shaw [MVP]]

<Inline comments>

Back in May 2004 a gentleman named "ptwilliams" game me some pointers on
setting up roving user profiles that can rove between locations, ie:
between
branch offices. I was able to create a DFS root share, replicate it
between
two DCs, and set up a user's home directory and profile on it. The user's
profile and home shares looked something like this:

\\example.com\dfsroot\users\%username%
\\example.com\dfsroot\profiles\%username%

When I create a user using these folders, it creates the folders with the
correct permissions. I checked each DC's copy of the dfsroot share and
everything gets replicated properly including the permissions. The trick
now is to ensure that workstations (All Win2K Pro SP4) use the nearest DC
for copies of the dfsroot, and therefore its profiles and home shares.

This is done by creating sites and placing the workstations and prefered DCs
in the same site. Once done, the workstations will select (by cost) the
closest DC.

So far, so good, but ptwilliams recommended that I restrict the number of
DCs to "one per site." Right now, the domain which I'll keep calling
example.com has just one site, the "Default-First-Site-Name," and I've
added
a subnet for each office to this site. In this case the subnets are:

10.0.1.0/26
10.0.1.64/26

This will work, but what you should really be more concerned about is the
inter-site traffic. Once the content has arrived at the DC in a remote
site, the hard work is all done. Since a site is defined as a collection of
subnet objects sharing relatively high bandwidth, you could very easily
extend the DFS to other DCs in that site without issues.

Once I've replicated everything I need, I'll move the new DC to
10.0.1.64/26. The first DC, which happens to be a SBS2000 machine and is
"king of the DS forest" as such, is in 10.0.1.0/26. Routing is taken care
of through VPN routers.

Now, do I need to create a new site in Active Directory Sites and Services
for each office, and in turn each subnet, and then move each DC to its own
site? Or is it adequate to define these subnets in a single site and just
have one DC in each subnet? All I need to make sure of is the
workstations
use the closest DC for their logon server, logon scripts and local DFS
replica.

Create a site for each area that qualifies as a "LAN" or area of relatively
high-quality connectivity. Create subnet objects that match the network for
that area. Computers with IP addresses that fall within the scope of the
subnets you create will automatically be associated with the site those
subnets are in.

You really only need to have one DFS in each site to accomplish what you
want. Any client within that site will automatically prefer the DFS in its
own site. Failing that, it will prefer a DFS in the next closest site
(according to cost - and as long as the AD is 2003).

Keep in mind that you don't necessarily need to use a DC for this. DFS will
replicate to member servers in an Active Directory.

Each DC at each office will have its own DHCP services, and settings which
point to itself as the primary DNS server, so the machines on a given
subnet
should use that subnet's DC as its primary DNS server.

This isn't necessary either. You could mount 2 DHCP servers in the central
office that could serve the entire enterprise and simply enable BootP across
your routers. All clients will gain addresses from a much simpler and more
managable source. Ensure the leases are long enough to ensure clients keep
leases for at least as long as any percieved WAN outages.

-ds

 

[Gordon Fecyk]

Create a site for each area that qualifies as a "LAN" or area of relatively
high-quality connectivity. Create subnet objects that match the network for
that area. Computers with IP addresses that fall within the scope of the
subnets you create will automatically be associated with the site those
subnets are in.

OK, so I'll create a site for each office (each office has its own LAN and
subnet) as long as this works for a single domain. The AD is 2000, not
2003, so I can't depend on routing metrics or costs to determine where the
nearest DC or DFS is.

I want to have a DC at each office to ensure domain logins work in case of
WAN/VPN outages. It's going to cost me ($$$) just as much in server and
client licenses wether I use member servers or DCs. Having DHCP and DNS at
each office also costs me ($$$) nothing extra and lets each office operate
independently in case of WAN outages.

I've done this before with NTLM, but never had the luxury of DFS. The old
replicator service just isn't sufficient to replicate user profiles.

OK thanks for the feedback.

 

[Gordon Fecyk]

OK, I was able to set up the second site. There were just some delays while
waiting for AD changes to replicate to both domain controllers, but once
that was done I got roving profiles and other stuff to follow me between
sites.

The connection speed between sites is only 320 kbps, which is my ISP's
maximum upstream DSL speed. They don't have the bandwidth to support many
SDSL customers yet. Add to that the delays the VPN routers introduce with
encryption. Even with this, replication seems to happen fairly quickly.

Too bad there isn't a simple Interbase database replication system to go
with this.

 

[Cary Shultz [A.D. MVP]]

Good evening to the both of you.

Dave, I am going to jump in for a second. Hope that you do not mind.

Gordon, you made the statement that the AD is 2000 so that you can not
depend on routing metrics or cost to determine where the nearest DC is. I
would take issue with this. If Sites are properly configured and the
Subnets are associated with the correct Sites and everything is intact with
DNS then the clients should be able to find the closest Domain Controller -
first in its Site and then a DC configured to 'help' that Site. This is how
things are supposed to work. Granted, they do not always but with a little
digging and a little help you should be able to set things up so that this
is pretty tight.

Additionally, you do not need to create a Site for each location. You
probably would do this ( and this is a very vanilla suggestion ) but I do
not recall seeing any information as to the number of users in each Site and
the connection between them.

HTH,

Cary

 

[Gordon Fecyk]

Gordon, you made the statement that the AD is 2000 so that you can not

depend on routing metrics or cost to determine where the nearest DC is. I
would take issue with this.

Actually, what you just described is what was recommended to me from the
start: Establish a site at each location and have one DC and one DFS replica
at each site.

Additionally, you do not need to create a Site for each location. You
probably would do this ( and this is a very vanilla suggestion ) but I do
not recall seeing any information as to the number of users in each Site and
the connection between them.

I had inter-Site troubles today so if I were able to avoid creating a Site
for each location I might've saved myself some grief. As it currently
stands, the totals for user and profile directories in my DFS root are just
under 7 GB, and I'd have preferred to replicate that at the main site first,
and then move the server to the new site.

Which actually brings me to my next question. I've just finished rebuilding
this DFS root (the first build went horribly wrong and I ended up
reinstalling the second DC, plus I had to use a different name for the
root). I have to repeat this feat with a server that's getting installed in
another city.

I'll end up creating a Site for the third location and then delivering the
server to that location. Rather than wait 18 hours to replicate nearly 7 GB
(at 320 kbps), is it practical to perform the inital replication at the main
Site, and then move the server to the new Site? The last time I attempted
this FRS got stalled because the staging area was too small (since bumped to
10 GB).

It will take several days to get to the new site, plus I have to set up the
VPN connection there first, before installing the new server. I've read
that DFS doesn't take kindly to extended outages and I'd risk journal wraps.
Based on the file count and MS's recommendations I've hardwired the journal
size to 512 MB ( < 400 000 files).

That's it for now.