AD Expansion Guidance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I need some insight from people who have done this and are more familiar with
it then I am.

One of our overseas offices now requires some server/network structure and
we're trying to determine how we want to set this all up.
* The users and computers already exist in our existing AD 2003 domain.
* They will need to continue to access resources in our other offices via
terminal server and VPN so maintaining the same user accounts is important.
* We would like them to have their own DNS zone, their workstations will not
need to resolve DNS names from our primary zone (in fact that would be a
problem because of poor design when they implemented DNS and overlapping
names with our public namespace)
* They will not have a static link to our main site for replication of
DNS/AD. More likely we will schedule replication at points we can schedule
automated VPN links. This means user/computer authentication will need to
take place against a domain controller in that site.

How can we best meet most of these requirements?

If we just make it an separate site in our current domain can I setup
separate DNS in that site that will not replicate?

If we make it a child domain in our existing site will I need to move the
PC's and computers?

Should we setup a separate domain completely and setup a transitive trust
and then somehow move the users/computers?

I'm taking any and all input.
 
Josh,

I've answered your questions inline:
One of our overseas offices now requires some server/network structure and
we're trying to determine how we want to set this all up.
* The users and computers already exist in our existing AD 2003 domain.
Ok

* They will need to continue to access resources in our other offices via
terminal server and VPN so maintaining the same user accounts is important.

Ok

* We would like them to have their own DNS zone, their workstations will not
need to resolve DNS names from our primary zone (in fact that would be a
problem because of poor design when they implemented DNS and overlapping
names with our public namespace)
Click to expand...

Well then you can't have them use any of your existing AD infrastructure, as
the clients at the other end need to resolve DNS to find the DCs, GCs, root
domain info, etc. You could certainly create a zone for resources over
there, but I don't think that would make sense.
* They will not have a static link to our main site for replication of
DNS/AD. More likely we will schedule replication at points we can schedule
automated VPN links. This means user/computer authentication will need to
take place against a domain controller in that site.
Click to expand...

Ok. I'd put a minimum of two DCs over there if it would be a problem if the
one DC goes down and there's no WAN link. You can just make them GCs as well
since you only have one domain.
How can we best meet most of these requirements?
Click to expand...
See below a bit.
If we just make it an separate site in our current domain can I setup
separate DNS in that site that will not replicate?
Click to expand...

Well, per the above point about DNS, with a child domain, the child and
often the PCs will need to contact the root domain DNS for forestwide info.
I don't think a child domain will solve your problems
If we make it a child domain in our existing site will I need to move the
PC's and computers?
Yes

Should we setup a separate domain completely and setup a transitive trust
and then somehow move the users/computers?
Click to expand...

You coudl do this and use ADMT to move the security principals, but, I think
you're making your situation even more complex taking this route.

You can configure replication scheduling for site links in AD. This combined
with a scheduled VPN would work just fine. If the VPN is unreliable either
in the connection quality or the implementation of the schedule, you may
have a candidate for SMTP based replication which is much more resilient to
crappy WAN connections.

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

Http://www.briandesmond.com
 
Josh said:
I need some insight from people who have done this and are more familiar with
it then I am.
(...)

Should we setup a separate domain completely and setup a transitive trust
and then somehow move the users/computers?

I'm taking any and all input.
Click to expand...

One thing you did't mentioned is if this remote office is managed by
central IT stuff or has it's own IT department? I'm asking it becouse
this can affect the design (maybe You don't tust them so far to put them
in the same forest) but I assume that this is managed by one team or You
can trust the other team.

I don't know if rest of the people on this group will agree with me but
I think that the best solution for you will be:
- create child domain or new domain in another tree in Your forest for
this office
- migrate needed users and computers accounts from existing domain to
new one using for example ADMT v2.

Such design will give You:
- independent DNS structure in both domain - however domain resolution
should be avilable, You can use stub zones or conditional forwarding for it
- minimized replication traffic: only schema and configuration data will
be replicated between these domains

If You don't want to put this new domain in existing forest You can
create it in the new forest and then join this forests using forest
trusts. In this case also You can maintain separated DNS spaces and
between the forests there is no replication so You will not have to
bother about it.
You can also migrate this users accounts from existing domain to the
domain in new forest
 
Back
Top