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.

 

[Herb Martin]

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??

Place the RID and PDC FSMO emulator roles on the same DC.

These must be centrally located (from a network perspective) so that
ALL other DCs.

Further, the PDC emulator must be available to all/any BDCs, and all
legacy clients (without DSClient upgrade), and all potential Master
Browsers can find the PDC emulator.

The above is just to make everying work and isn't really a "recommendation"
but a virtual necessity.

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

To work correctly this is the most generally applicable method.

Place the domain naming FSMO master on a Global Catalog
Server.

You can have as many GCs are you need versus the trade off
in loading too many GCs -- probably only an issue in large forests
so for medium to small forests you can have as many GCs are you
wish.

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.

It is a bad idea to keep any DC completely offline -- my recommendation
is to modify this idea to include a DC fully online (from the perspective of
the other DCs) and the Schema/Domain-Naming connected and firewalled
so that under normal conditions it only communicates with this one (or 2)
DCs.

As to protecting the actually AD, that is a job better left to regularly and
timely backups.

Rest-of-your-NET -- DC -- SM/DNM/DC

 

[Dave Shaw [MVP]]

inline -

snip <

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?

No. Just have, as a plan, a designated machine to move the roles to in case
of extended server power-down or disaster.

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?

Not on a properly configured modern server, no.

snip <

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:

First of all, this is incorrect. The server roles do not distribute
themselves (if I'm reading this correctly). All roles are installed on the
first domain controller installed into the first domain of the forest and
stay there until an admin moves them.

Place the RID and PDC FSMO emulator roles on the same DC.

Fine. No problem here.

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

Irrelevant. It's a single domain forest. The Infrastructure Master never
comes into play. You can make all DCs GCs and never have a concern.

Place the domain naming FSMO master on a Global Catalog Server.

Since there is only one domain, it's irrellevant.

My recommendation is to keep all the roles on one server and watch over it
with reasonable care.

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.

Once again - it doesn't matter. There is only one domain. The only time
the domain naming master comes into play is when new domains are created and
exist.

-ds