A: GC-less login is related to the universal group membership caching feature that Microsoft introduced in Windows Server 2003. It lets Windows Server 2003 and later domain controllers (DCs) cache a user's universal group memberships. To do so, it uses the msDS-Cached-Membership attribute of the user's AD user object. Universal group memberships are cached in this attribute the first time a user logs on. On subsequent logins by the same user, the DC uses the cached universal group memberships and doesn't have to contact a GC server. They're automatically refreshed every eight hours.
Universal group membership caching and GC-less login can be enabled on the AD site level from the NTDS Site Settings Properties of an AD site object in the AD Sites and Services MMC snap-in. As illustrated here, you must select Enable Universal Group Membership.
Without GC-less login and universal group membership caching enabled, users always require access to a GC DC, because only GCs store the memberships of all universal groups in the Windows forest. GC-less login can be useful in small branch office site scenarios where you don't want to deploy a GC because of the extra WAN traffic that's generated to replicate the GC AD with other DCs. The need to contact a GC over a slow link at login time can also be problematic and it may result in branch office site users that are unable to log on to the domain if no GC is available.
The GC-less login feature doesn't completely take away the need to put a GC in every site—or at least to have one reachable GC for every site. Although GCs are no longer needed to find out about a user's universal group memberships, you still need them to resolve User Principal Names (UPNs—these are names of the format [email protected]_domainname) when your users log on using a UPN.
Also, if you still have Windows 2000 DCs, these DCs by default always requires a GC DC to retrieve a user's universal group membership. This means that, by default, if no GC is available, a user can't log on to a Windows 2000 DC. Microsoft provides a workaround for this Windows 2000 login requirement—you can instruct a Windows 2000 DC to ignore GC failures. A GC failure occurs when no GC can be contacted to find out a user's universal group memberships at login. This Windows 2000 workaround is based on the IgnoreGCFailures registry key (located in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa). If a Windows 2000 domain consists of multiple DCs, this must be set on all DCs.
An annoying side effect is that the above registry change can create security holes when universal groups have been used to set permissions on resources in your Window forest. For example, if a user's universal group memberships aren't expanded, users could potentially access data on which a universal group they belong to was given explicit deny permissions.