Effects of Universal Groups on the Global Catalog

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).