Setting up a domain tree

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

Where can I find information on setting up a domain tree over a VPN? We're
planning on having a root domain server and as we open offices adding child
domains to the root domain.

I'm interested in how roaming profiles behave in this environment. Which
domain controller should store the profiles? How is the profile maintained
between the domain controllers?

Thanks!!!
 
Ideally you should have the users profiles stored on domain controllers in
the location they work out of. Downloading a profile off a VPN will more
than likely be pretty cumbersome. You may want to consider setting up a DFS
amongst the DCs/file servers at the sites for redundancy.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com
 
DFS is distributed filesystem. Basically what happens is you use the conrol
panel widget for it and define a "DFS Root", which is like a network share,
except accessible via \\your.domain.dns.name\sharename. Then, inside the
root properties, you specify one or more servers which will host the actual
content. Replication amongst the members can be configured, and when a user
accesses the DFS Root, they will automaitcally be connected to a server
which is a member of the DFS.

Does this make sense? If not, let me know so I can try and explain it
better.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com
 
Thanks Brian,

That makes sense. Can I use the dfs to store profiles and have them
available at all sites?

Where can I find more information on how to set up a DFS?

Thanks!!!
 
-----Original Message-----
Thanks Brian,

That makes sense. Can I use the dfs to store profiles and have them
available at all sites?

Where can I find more information on how to set up a DFS?

Thanks!!!

is you use the
conrol like a network
share, will host the
actual configured, and when a
user on domain
controllers profile off a VPN will
more consider setting up
a open offices
adding


.
Click to expand...
Dave,

Going to jump in here for a quick second. Brian, hope
that you do not mind!

About creating children domains - this *MIGHT* not be
necessary. You did not provide any particulars so I just
want to mention that you *MIGHT* not have to do this.

With WIN2000 AD you can make use of Sites. So, you can
have one domain, such as yourdomain.com, but several
physical locations. For example, if you had two Offices
in New York, one in Washinton D.C., one in Boston, one in
Atlanta, one in Miami, etc. etc. etc. you would *NOT*
necessarily need to have a whole bunch of Child Domains (
unless you have other reasons that this is being set up as
such ). You would simply have a whole bunch of Sites: one
for New York ( possibly two ), one for Washington D.C.,
one for Boston, one for Atlanta, one for Miami, etc. etc.
etc. When you open an Office in another City you simply
set up another Site, create the appropriate Subnet(s) and
associate the Subnet(s) with the appropriate Site.

You would just need to set up Site Links and possibly Site
Link Bridges.

And I like that idea about the VPN Connection. I would
strongly suggest a Site-to-Site VPN ( aka Firewall-to-
Firewall VPN ).

HTH,

Cary
 
Hi Carey,

I'm not sure what I need.

Here's what we want to do.

We have a domain server and a SQL server set up at our first site. On the
domain server we keep our roaming profiles including Outlook.pst files.
We're going to open new sites in about 8 months. We want to control all
sites from a central point. We want all sites to access our SQL server for
data input. We also need our managers to log in at any site and have the
same profiles that they have at their home office.

We're planning on using router-to-router VPN's between all sites.

Do I need domains at every site to have users log into? I've tried logging
into a domain through a vpn and it takes a long time(about 30 min), so I
thought that having domains that talk to each other will oliviate this
problem. I did log in with a roaming profile even though the user was a new
user and had a small profile(<1 Meg). Do I need a domain server to
establish trusts between the subnets(or just dns or wins servers)?

Right now I'm trying to find out what the best way to set this up will be.

Thanks!!!
 
-----Original Message-----
Hi Carey,

I'm not sure what I need.

Here's what we want to do.

We have a domain server and a SQL server set up at our first site. On the
domain server we keep our roaming profiles including Outlook.pst files.
We're going to open new sites in about 8 months. We want to control all
sites from a central point. We want all sites to access our SQL server for
data input. We also need our managers to log in at any site and have the
same profiles that they have at their home office.

We're planning on using router-to-router VPN's between all sites.

Do I need domains at every site to have users log into? I've tried logging
into a domain through a vpn and it takes a long time (about 30 min), so I
thought that having domains that talk to each other will oliviate this
problem. I did log in with a roaming profile even though the user was a new
user and had a small profile(<1 Meg). Do I need a domain server to
establish trusts between the subnets(or just dns or wins servers)?

Right now I'm trying to find out what the best way to set this up will be.

Thanks!!!



.
Click to expand...
Dave,

I will just comment about the need / non-need for Child
Domains. I do not necessarily like jumping in on other
people's posts but do sometimes to either add a
clarification or to point out something that I see that
has not yet been mentioned. Brian is very well-versed in
these things so I will restrict our conversation to the
Child Domain need / non-need....Brian can handle the rest
( I am quite sure! ).

To answer your question / concern about long logons over
a VPN: if Sites are set up properly your users would
authenticate against a local DC ( meaning, if a user is
located in the Miami Site, he/she would authenticate
against a DC in Miami; if a user is located in the Boston
Site, he/she would authenticate agains a DC in
Boston.....this should really cut down on that problem! ).

You see, you would *probably* have a DC ( hopefully
two! ) in each Site. Remember, they are all part of the
same domain ( in this example, yourdomain.com ). Making
use of Sites is simply a way to control Active Directory
Replication and User Logons.

Please remember that there are two types of AD
Replication: Intrasite Replication and Intersite
Replication.

Intrasite Replication is the replication that takes place
between all DCs in the same Site. So, as per my example,
all of the DCs in the New Your Site will replicate their
AD ( NTDS.dit ) with each other; all the DCs in the
Boston Site will replicate their AD with each other; etc.
etc. etc. Furthermore, please keep in mind that
replication takes place in both directions as a one-way
connection object.

Let's use New York as an example. Say that you have two
DCs in the New York Site: DCNYC01 and DCNYC02. There
would be an incoming connection object on DCNYC01
representing DCNYC02 ( that would represent the Intrasite
AD Replication from DCNYC02 to DCNYC01 ) and there would
be an incoming connection object on DCNYC02 representing
DCNYC01 ( that would represent the Intrasite AD
Replication from DCNYC01 to DCNYC02 ). Remember, this is
a one-way connection.

Furthermore, let's remember that there are three
partitions, or Naming Contexts, that are replicated
within AD: the Schema NC, the Configuration NC and the
Domain NC. The first two are replicated to all DCs in
the Forest while the Domain NC is replicated to all DCs
in a particular Domain.

How do you set this up? Well, you do not have to really
do anything *necessarily* for Intrasite Replication.
Something called the KCC ( or Knowledge Consistency
Checker ) does this all on it's own just magically. You
really do not need to do anything. Granted, you can if
you so choose. In order to do what it does the KCC makes
use of the Intrasite Topology Generator...

Intersite Replication is the replication that takes place
between Sites. So, how does this work? In each Site
there is something called a Bridgehead Server. The AD
Replication between, say, the New York Site and the
Boston Site would take place ONLY between the BHS in the
New York Site and the BHS in the Boston Site. Again,
this replication takes place in both directions as a one-
way connection object. So, you would have the incoming
connection object on, say, DCNYC02 representing DCBOS01 (
representing the AD Intersite Replication from Boston to
New York ) and you would have the incoming conenction
object on, say, DCBOS01 representing DCNYC02 (
representing the AD Intersite Replication from New York
to Boston ). Again, our friend the KCC does most of this
magically. It would use the Intersite Topology Generator
to do this. However, there is one thing that you, the
Admin, would need to do: create the Site Links and
possibly the Site Link Bridges. You simply need to
provide four pieces of information: name of Site Link and
Sites involved, Transport Protocol, Cost and Schedule.
Once you have done this the KCC has all the information
that it needs and does it's thing. Again, you can do
this manually if you choose or you could partner up with
the KCC or you can simply let the KCC does it on its
own. The choice is yours.

I could provide you a few links for this but I think that
I have covered it fairly well. Take a look at the
following two MSKB Article that describe how both WIN2000
and WINXP Clients locate a DC:

http://support.microsoft.com/default.aspx?scid=KB;en-
us;247811

http://support.microsoft.com/default.aspx?scid=kb;
[LN];314861

Also, take a look at this Article that helps to control
the Clients locating the proper DC...

http://support.microsoft.com/default.aspx?scid=kb;en-
us;306602

HTH,

Cary
 
Dave,

Cary did an excellent job explaning everything. In a nutshell, some things
to consider:

--> Don't create cchild domains in your setup unless you have some specific
reason (usually political, i.e, the parent company ABC Controls is in NYC,
and they own XYZ Toys in WashingtonDC, but the XYZ folks are all pisst off
about being bought out by ABC, so making them logon to ABCControls is going
to be politically tricky. Making them log into XYZControls will make them
happy.)

--> Setup a site at each geographical location, and place one or more domain
controllers in the site. This will alleviate the slow logons issue.
Replication will occur across the VPN between the bridgeheads.

--> You can certainly replicate the profiles on the DFS across the WAN, but
take into consideration the available VPN bandwidth and how much data you
have to replicate. This number could get to the point where you'll need
dedicated lines between the sites.

--> SQL will work fine across the VPN, but it could get slow. You might
consider another SQL server at the remote site and set them up to replicate.

--> You'll need a DC & DNS on each subnet unless you've got routers moving
the traffic between the subnets. In your setup, I'd recommend a subnet at
each location, DC & DNS in each, and replication across the VPN

Hope this helps!

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com
 
Back
Top