3. DC Placement
DC placement requires some forethought, especially
for environments with a lot of remote sites over slow links or remote
sites with few users. Implied with DC placement is the decision of
whether to make a physical location an AD site. The criteria generally
depends on several factors:
User population
Network infrastructure (available bandwidth, reliability, and so on)
GC requirements for Exchange or other applications
LDAP server requirements
Other AD-dependent applications
Available staff to perform administration duties
Physical
security concerns such as whether the DC/GC can be protected from
physically removing the server, disk drive, and so on, and compromising
sensitive data
Financial ability to purchase the hardware, software, and support services to maintain the DC
Reed Elsevier, developed an
ingenious flowchart to determine whether a physical location should be
designated an AD site, and if so, how many DCs should be deployed there.
Reed Elsevier has graciously agreed to allow us to publish the
flowchart, shown in Figure 3.
The chart uses a weighted system where each “Yes” answer to questions
in the decision tree is worth a weight of 1 or more. The cumulative
score at the end determines whether it will be an AD site and how many
DCs will be deployed there.
Note that if the site is unable to physically secure
the DC/GC or if that site does not have the finances to obtain the
hardware and software, the path ends and the request is denied.
Obviously, the financial requirement depends on the company's business
structure, but the security issue is important. A number of cases have
been reported where thieves have stolen disk drives from DCs or GCs and
were able to extract user information such as account names, personal
information, and financial data. In the design of security, don't forget
that a lack of physical security can negate all the software security
you put in place.
Of course, Reed Elsevier's logic might not include
the criteria or the weight on certain criteria that your company might
have, so this should be used as a guide, not a definitive solution. For
instance, Reed Elsevier attaches importance to the residence of company
executives at the site, but you might not want to add this into your
equation.
4. GC Placement
Windows 2003 made some significant enhancements to universal group functions.In a
Windows 2000 multiple-domain forest with native-mode domains, users must
contact a GC at logon to retrieve their universal security group
memberships. This forces the system architect to either put a GC at a
remote site or incur the additional traffic required for users to
connect to a GC over the WAN. In the four years I've worked with
customers in designing AD installations and troubleshooting problems,
where GCs should be placed is one of the most frequently debated issues.
Consider using the following checklist to determine GC placement:
Place a GC at all “Core” sites (that is, sites that are at the hub of the network topology with high available bandwidth).
Combine
remote sites as a single site, and deploy a single GC. Compaq used 2MB
as the rule of thumb, but you should determine this for your
organization.
Use the Windows 2003
Universal Group Caching feature to allow GC-independent logons with a
local DC (typically for small sites of a few hundred users at most).
Obviously, this is not a consideration in a Windows 2000 forest.
Create
a plan for implementation of the Install from Media (IFM) feature in a
Windows 2003 forest to reduce the downtime required when building a GC
in the event of failure. This includes providing remote sites with
periodic copies of backup media (less than tombstonelifetime old).
If
you decide not to put a GC at each site for reasons noted previously,
ensure that Exchange performance is acceptable. Often, this measure is
made by evaluating user complaints.
tip
Outlook 2003 has a feature called Cached Exchange
Mode. Outlook XP and 2000 showed significant performance degradation,
including a significant increase in TCP/IP traffic. Cached Exchange
Mode, enabled offline, caches the user's mailbox locally on the
computer, in much the same way the Offline Files feature does now. The
user is thus reading cached mail, which significantly improves perceived
performance, especially when viewing messages with large attachments.
Utilizing this feature in sites that don't have GCs could improve the
user's experience and not require a local GC.
You might consider using a table like that in Table 1 to identify GC placement.
Table 1. GC Placement Schedule
| Site Name | Domain | Exchange Server | GC Server |
|---|
| Atlanta | Company.com | EXCSRV001 | ATL-GC001 |
| Chicago | Company.com; NA.company.com | EXCSRV002 | CHI-GC002 |
| Boise | NA.company.com | (none) Uses Portland | Uses GC Caching and Portland GC |
| Portland | NA.company.com | EXCSRV003 | PRT-GC003 |
| Lyon | EU.company.com | (none) Uses Hamburg | Uses GC Caching and Hamburg GC |
| Hamburg | EU.company.com; Company.com | EXCSRV008 | HAM-GC008 |
Note that this table identifies domains that
are hosted at each site, implying DCs for those domains existing in
those sites. Exchange servers are noted as existing in the site or the
Exchange server used is noted. Also, the GC that serves the site is
noted. If a GC name is noted in the GC column for the site, the GC
exists at that site. Note that GC Caching is identified for the small
sites of Boise and Lyon.
