For customers using universal groups in larger systems with slow
connections, the following issues should be addressed to avoid
performance and availability problems:
Authentication of a user requires global knowledge of the
user's group memberships in order to compute all the groups that
user (directly or indirectly) belongs to. With universal
groups, the global catalog service (GC) is used to perform this
membership computation. If a GC is not available at logon time, the
user is not able to log on to a native-mode domain. On a mixed-mode
domain, the user may not have the appropriate access to resources
according to universal group memberships in other domains.
Solution: To avoid GC availability problems when using
Universal groups, configure one or more GC servers per
site.
Because authentication requires the GC to compute a user's
universal group memberships, the GC must contain all universal
group memberships. If only universal groups are used, a high
level of GC replication traffic may be generated if the universal
group memberships are changed frequently. A medium-sized branch
office might not be able to afford the network bandwidth required
to keep a GC up-to-date.
Solution: To avoid unnecessary GC replication traffic
with frequently changing group memberships, nest global groups
within universal groups and make membership changes in the global
groups. This leaves the universal group membership static (this
avoids the need to replicate membership changes in the GC) and
enables administrators to make changes frequently to global groups
(global group membership is replicated only within the
domain).