Configuring and Maintaining the Active Directory Infrastructure - MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration - page 436

Other reasons to create site link bridges manually include the following:
• Control traffic through firewalls —You might want to limit which DCs can communicate
with one another directly through firewalls. You can configure firewalls to allow traffic
between DCs at specific sites and create site link bridges as needed.
• Accommodate partially routed network —Normally, the KCC considers all possible con-
nections when determining the replication topology. If sites are connected only intermit-
tently, you can configure site link bridges between only the sites that map to full-time
network connections, which bypasses intermittent links.
• Reduce confusion of the KCC —A complex network that involves many alternate paths
between sites can cause confusion when the KCC and ISTG create the replication topol-
ogy. You can force what kind of topology is created by using custom site link bridges and
disabling transitivity.
To disable transitivity of site links, right-click the IP or SMTP folder under Inter-Site
Transports, and click Properties. Click to clear the Bridge all site links check box. To create a site
link bridge, right-click the IP or SMTP folder and click New Site Link Bridge. Give a descriptive
name to the site link bridge, and then add at least two site links to it.
The Global Catalog and Universal Group Membership Caching
As you know, the global catalog is a critical component for many Active Directory operations,
so access to a global catalog server must be considered when designing sites and configuring site
replication. Having a global catalog server used to be critical in sites with more than a few users
because it speeded logons and forest-wide searches for Active Directory objects. However, repli-
cation traffic is increased considerably in sites with global catalog servers.
Windows Server 2008 resolves the potential conflict between faster logons and increased
replication traffic by introducing universal group membership caching . When this feature is
enabled, the first time a user logs on to a domain in the site with no global catalog server, the
user's universal group membership information is retrieved from a global catalog server in a dif-
ferent site. Thereafter, the information is cached locally on every DC in the site and updated
every 8 hours, so there's no need to contact a global catalog server. Having this feature available,
however, doesn't mean a global catalog server should never be placed in a site. Microsoft rec-
ommends placing a global catalog server in the site when the number of accounts (user and com-
puter) exceeds 500 and the number of DCs exceeds two. With 500 cached accounts, the traffic
created by refreshing every 8 hours might be higher than global catalog replication traffic. In
addition, you need to determine whether the other benefits of having a global catalog server
(faster forest-wide searches, faster updates of universal groups) outweigh the reduced replication
traffic of universal group membership caching.
To configure universal group membership caching, in Active Directory Sites and Services,
expand the site object, and then open the Properties dialog box of the NTDS Site Settings object.
In the Site Settings tab, click the Enable Universal Group Membership Caching check box. In
addition, you can select which global catalog server is used to refresh the cache.
Working with Operations Master Roles
As discussed in Chapter 4, Active Directory uses a multimaster replication scheme to synchro-
nize copies of most information in the Active Directory database. However, some critical infor-
mation is subject to a single master replication scheme to avoid any possibility of the information
becoming unsynchronized. The servers that keep this critical information are assigned a Flexible
Single Master Operation (FSMO) role. FSMO roles were described in Chapter 4 and can be sum-
marized as follows:
• Forest-wide FSMO roles —Only one DC per forest performs these roles: domain naming
master and schema master.
• Domain-wide FSMO roles —Only one DC per domain performs these roles: PDC emula-
tor, RID master, and infrastructure master.