FSMO Placement

[Dan]

One of my customers has a Windows 2000 domain. Approx. 3500-4000 users
through 25 locations. Currently, the schema master sits on the root dc:

"dc1.ads.company.com"

The remaining FSMO roles sit on another dc:

"dc1.hq.ads.company.com"

*** There are about 15 DCs. All domain controllers are Global Cat. Servers
***

My question: We read KB223346 page 2. As long as all DCs hosts GCs is
there a need to move any of the FSMO roles from the dc -
dc1.hq.ads.company.com?

Whould there be any performance issues with keeping all the FSMO roles on
the same DC once all 4000 users are brought into the domain?

Other info...

Here is the report of where the FSMO roles sit:

Schema owner adsdedc01.ads.company.com

Domain role owner btsdedc01.hq.ads.company.com

PDC role btsdedc01.hq.ads.company.com

RID pool manager btsdedc01.hq.ads.company.com

Infrastructure owner btsdedc01.hq.ads.company.com

Should we follow the information below or keep the FSMOs where they are at??

W2K AD domain controllers split up the master operations roles. This is
usually transparent to most administrators. Active Directory will manage
which domain controller ( DC ) has which master operations role. The key is
normally. There are five master controller roles. By default, they are on
the first domain controller in the domain. For performance issues, you
probably want to split the roles apart. Microsoft recommends in kb article
Q223346 and my own study confirms:

Place the RID and PDC FSMO emulator roles on the same DC.
Place the infrastructure FSMO master on a non-global catalog server.
Place the domain naming FSMO master on a Global Catalog Server.


Security upgrade:

Microsoft recommends placing the schema master and domain naming master on
same server. From a performance perspective it makes some sense but not from
a security perspective. I would place the schema master role on a dedicated
DC and I would keep it shutdown except when schema changes need to be made.

 

[Ozone]

These recommendations are just that. If you have a Domain that has a large
amount of updates then you are best in splitting the FSMO roles to balance
the load of each role. If you have a domain that is some what stable with
little modifications to objects, then you could certainly keep more than one
role on a server. These recommendations are there to serve as food for
thought. I think if you look at the number of object modifications (Add,
change, deletes) your domain will sustain over a period of time, you should
place your FSMO roles based on these predictions.

Ozone

> One of my customers has a Windows 2000 domain. Approx. 3500-4000 users

> through 25 locations. Currently, the schema master sits on the root dc:
> The remaining FSMO roles sit on another dc:
> *** There are about 15 DCs. All domain controllers are Global Cat. Servers
> ***
> My question: We read KB223346 page 2. As long as all DCs hosts GCs is

> there a need to move any of the FSMO roles from the dc -

> dc1.hq.ads.company.com?
> Whould there be any performance issues with keeping all the FSMO roles on

> the same DC once all 4000 users are brought into the domain?
> Here is the report of where the FSMO roles sit:
> Schema owner adsdedc01.ads.company.com
> Domain role owner btsdedc01.hq.ads.company.com
> PDC role btsdedc01.hq.ads.company.com
> RID pool manager btsdedc01.hq.ads.company.com
> Infrastructure owner btsdedc01.hq.ads.company.com
> Should we follow the information below or keep the FSMOs where they are at??

> W2K AD domain controllers split up the master operations roles. This is

> usually transparent to most administrators. Active Directory will manage

> which domain controller ( DC ) has which master operations role. The key is
> normally. There are five master controller roles. By default, they are on

> the first domain controller in the domain. For performance issues, you

> probably want to split the roles apart. Microsoft recommends in kb article

> Q223346 and my own study confirms:
> Place the RID and PDC FSMO emulator roles on the same DC.

> Place the infrastructure FSMO master on a non-global catalog server.