Design advice from single domain forest to regional domain model

Hi,

We currently have corp.abc.com as our forest name as well as our internal
domain name which are used by 4 sites. I'm planning to create sub-domains
for each of the sites - site1.corp.abc.com, site2.corp.abc.com,
site3.corp.abc.com and site4.corp.abc.com.

I have some idea on how to accomplish this but haven't done it before so I
need some expert advice from this forum to avoid mistakes.

On the client side, I'm not also sure if the domain to login can be changed
through Group Policy. Otherwise, we have to go to each machine to do this.


Thanks in advance.

Archie

Why would you move from the MS recommended way to do this to a way, that in
the end, will create more work for you? The main reasons for creating a
separate domain is the need for different password requirements or
"political" reasons. More domains means more admin work.

Sites are the way to go instead of separate domains.

hth
DDS


"agcastle2000" <agcastle2000@discussions.microsoft.com> wrote in message
news:A76AC846-56DC-48BD-994A-94A641231FEF@microsoft.com...
> Hi,
>
> We currently have corp.abc.com as our forest name as well as our internal
> domain name which are used by 4 sites. I'm planning to create sub-domains
> for each of the sites - site1.corp.abc.com, site2.corp.abc.com,
> site3.corp.abc.com and site4.corp.abc.com.
>
> I have some idea on how to accomplish this but haven't done it before so I
> need some expert advice from this forum to avoid mistakes.
>
> On the client side, I'm not also sure if the domain to login can be
> changed
> through Group Policy. Otherwise, we have to go to each machine to do this.
>
>
> Thanks in advance.
>
> Archie
>
>

Hi Danny,

Thanks for your reply.

Our WAN links are slow so I'm thinking that if I create sub-domans
(regional domains in MS documentation), I could somehow reduce the
replication traffic. But with low number of users in each site (between 80 to
90 users) I don't know if the benefit that I'll get with reduce replication
would outweigh the price of more admin overhead.

For now, I'm more inclined of not touching the structure but can you please
share how this should be done just for my knowledge?


Thanks,
Archie



"Danny Sanders" wrote:

> Why would you move from the MS recommended way to do this to a way, that in
> the end, will create more work for you? The main reasons for creating a
> separate domain is the need for different password requirements or
> "political" reasons. More domains means more admin work.
>
> Sites are the way to go instead of separate domains.
>
> hth
> DDS

Two ways, both require a ton of work. I'm assuming that by site you mean a
DC and the clients on a particular subnet.
Use ADMT and set up a new server in each office in it's own domain "side by
side" on the same wire, and create a trust between the two domains and use
ADMT to migrate the user from the site in your old domain to the new domain.
I'm fairly sure you will have to touch each workstation to join it to the
new domain.
OR
just dcpromo each DC in the site to a member server (loose all user
accounts) remove it from the domain, dcpromo it again while connected to the
existing domain and set it as child domain. Then you will have to manually
enter the 80 to 90 user accounts into the new domain, manually remove their
workstations from the old domain and join them to the new domain, users
loose their profiles. Plan on a lot of user disruption and a lot of work on
your part. After you are done, plan on a lot of work just keeping things
running. New password policy? You now have to set it up in each domain. New
group policy? set it up in each domain. Not to mention that the best
practice is to change the passwords used by services periodically, now you
have to do it in each domain, and document each domain.

If by "site you mean just a group of computers in a city and they
authenticate to a DC in the main office you might consider adding a DC to
each site and setting up "Sites" as Microsoft suggests.

hth
DDS

"agcastle2000" <agcastle2000@discussions.microsoft.com> wrote in message
news:342AD061-884A-4C83-9096-394A733B2D5D@microsoft.com...
> Hi Danny,
>
> Thanks for your reply.
>
> Our WAN links are slow so I'm thinking that if I create sub-domans
> (regional domains in MS documentation), I could somehow reduce the
> replication traffic. But with low number of users in each site (between 80
> to
> 90 users) I don't know if the benefit that I'll get with reduce
> replication
> would outweigh the price of more admin overhead.
>
> For now, I'm more inclined of not touching the structure but can you
> please
> share how this should be done just for my knowledge?
>
>
> Thanks,
> Archie
>
>
>
> "Danny Sanders" wrote:
>
>> Why would you move from the MS recommended way to do this to a way, that
>> in
>> the end, will create more work for you? The main reasons for creating a
>> separate domain is the need for different password requirements or
>> "political" reasons. More domains means more admin work.
>>
>> Sites are the way to go instead of separate domains.
>>
>> hth
>> DDS
>

"Danny Sanders" wrote:

> Two ways, both require a ton of work. I'm assuming that by site you mean a
> DC and the clients on a particular subnet.
Yes.

> Use ADMT and set up a new server in each office in it's own domain "side by
> side" on the same wire, and create a trust between the two domains and use
> ADMT to migrate the user from the site in your old domain to the new domain.
> I'm fairly sure you will have to touch each workstation to join it to the
> new domain.

I would have thought that I would just delegate the city1. sub-domain,
city2. sub-domain and city3. sub domain to the DNS servers in each of these
locations (which I call sites). (I changed the sub-domain name to cityx to
avoid confusion.) They would still be in the same forest so I don't think
there is a need to create trust. All DCs (which are also DNS servers) are
running Windows Server 2003 and are on the same domain forest.

As I said in my first post, we have a single domain forest corp.abc.com and
there are 4 locations (sites). The DNS zone is also corp.abc.com. All 4
locations (offices or sites) are on the same domain forest. Since all
locations have DCs, I am thinking to create sub-domains in each of these
locations.


> OR
> just dcpromo each DC in the site to a member server (loose all user
> accounts) remove it from the domain, dcpromo it again while connected to the
> existing domain and set it as child domain. Then you will have to manually
> enter the 80 to 90 user accounts into the new domain, manually remove their
> workstations from the old domain and join them to the new domain, users
> loose their profiles. Plan on a lot of user disruption and a lot of work on
> your part. After you are done, plan on a lot of work just keeping things
> running. New password policy? You now have to set it up in each domain. New
> group policy? set it up in each domain. Not to mention that the best
> practice is to change the passwords used by services periodically, now you
> have to do it in each domain, and document each domain.

Do I still need to dcpromo the DC for each location?

Yes I got what you mean. I need to create new policy (password expiration
and things like that) for each domain.



> If by "site you mean just a group of computers in a city and they
> authenticate to a DC in the main office you might consider adding a DC to
> each site and setting up "Sites" as Microsoft suggests.

They authenticate to the DC in their location as each location has one or
two DCs.


Thanks.
Archie

> I would have thought that I would just delegate the city1. sub-domain,
> city2. sub-domain and city3. sub domain to the DNS servers in each of
> these
> locations (which I call sites). (I changed the sub-domain name to cityx
> to
> avoid confusion.) They would still be in the same forest so I don't think
> there is a need to create trust. All DCs (which are also DNS servers) are
> running Windows Server 2003 and are on the same domain forest.
>
> As I said in my first post, we have a single domain forest corp.abc.com
> and
> there are 4 locations (sites). The DNS zone is also corp.abc.com. All 4
> locations (offices or sites) are on the same domain forest. Since all
> locations have DCs, I am thinking to create sub-domains in each of these
> locations.


You create a domain when you run dcpromo to ADD AD to a server. You don't
"delegate the sub domain to the DNS server". Domains are set up using a
domain controller. A domain controller can only be in one domain at a time.
There are two ways to make a site into a child domain and I detailed them
earlier. Use ADMT OR run dcpromo to remove AD (loose all user accounts) then
run dcpromo to make the DC a DC in a child domain of your first domain.

Other than making more work for yourself now while causing major user
disruption at each branch office, and creating more work for you and whoever
takes over after you, you have not mentioned a single reason to under take
this course of action. Especially seeing that MS best practice is to do it
the way you have it setup now. We have 50 sites within the one domain.
Following your model of making each site a domain would be a nightmare. You
have the proper foundation set incase the company increases in size and adds
more branch offices. What would happen if the company expanded by 75
offices. As you sit now you are set and ready to go. If you change each site
into a domain you have just increased you work load by 75. Then you would be
trying to figure out how to move to the MS best practice for a shop with 75
branch offices, which is NOT to use domains for every office but to use
sites.

hth
DDS





"agcastle2000" <agcastle2000@discussions.microsoft.com> wrote in message
news:8ADD2962-F4C0-4981-A416-1C92184048D7@microsoft.com...
>
>
> "Danny Sanders" wrote:
>
>> Two ways, both require a ton of work. I'm assuming that by site you mean
>> a
>> DC and the clients on a particular subnet.
> Yes.
>
>> Use ADMT and set up a new server in each office in it's own domain "side
>> by
>> side" on the same wire, and create a trust between the two domains and
>> use
>> ADMT to migrate the user from the site in your old domain to the new
>> domain.
>> I'm fairly sure you will have to touch each workstation to join it to the
>> new domain.
>
> I would have thought that I would just delegate the city1. sub-domain,
> city2. sub-domain and city3. sub domain to the DNS servers in each of
> these
> locations (which I call sites). (I changed the sub-domain name to cityx
> to
> avoid confusion.) They would still be in the same forest so I don't think
> there is a need to create trust. All DCs (which are also DNS servers) are
> running Windows Server 2003 and are on the same domain forest.
>
> As I said in my first post, we have a single domain forest corp.abc.com
> and
> there are 4 locations (sites). The DNS zone is also corp.abc.com. All 4
> locations (offices or sites) are on the same domain forest. Since all
> locations have DCs, I am thinking to create sub-domains in each of these
> locations.
>
>
>> OR
>> just dcpromo each DC in the site to a member server (loose all user
>> accounts) remove it from the domain, dcpromo it again while connected to
>> the
>> existing domain and set it as child domain. Then you will have to
>> manually
>> enter the 80 to 90 user accounts into the new domain, manually remove
>> their
>> workstations from the old domain and join them to the new domain, users
>> loose their profiles. Plan on a lot of user disruption and a lot of work
>> on
>> your part. After you are done, plan on a lot of work just keeping things
>> running. New password policy? You now have to set it up in each domain.
>> New
>> group policy? set it up in each domain. Not to mention that the best
>> practice is to change the passwords used by services periodically, now
>> you
>> have to do it in each domain, and document each domain.
>
> Do I still need to dcpromo the DC for each location?
>
> Yes I got what you mean. I need to create new policy (password expiration
> and things like that) for each domain.
>
>
>
>> If by "site you mean just a group of computers in a city and they
>> authenticate to a DC in the main office you might consider adding a DC to
>> each site and setting up "Sites" as Microsoft suggests.
>
> They authenticate to the DC in their location as each location has one or
> two DCs.
>
>
> Thanks.
> Archie