全局编录（gc）是域控制器内置角色，非独立服务，用于支持upn登录、通用组权限验证及跨域搜索；仅存储高频属性只读副本，多域环境须避免与基础结构主机共存。
配置全局编录（gc）服务器不是“加装一个服务”，而是为域控制器（dc）启用一项内置角色，核心目标是让跨域对象搜索、upn登录和通用组权限验证能快速、可靠完成。关键不在“怎么点”，而在“在哪点、为什么这么点”。
明确GC在AD中的实际作用
GC不是万能索引库，它只存森林中所有域对象的高频搜索属性（如userPrincipalName、displayName、mail、sAMAccountName），且是只读副本。它的价值体现在三处：
- 用户用 user@domain.com 形式登录时，DC必须联系GC才能定位该UPN归属哪个域
- 用户属于通用组（Universal Group）时，GC是唯一存储其成员关系的位置；没有GC响应，登录后令牌缺权限，应用访问常被拒绝
- Outlook地址簿、Exchange收件人解析、ADUC中“在整个林中搜索”等功能，底层都查GC，避免逐个DC轮询耗时
正确启用GC的操作步骤
在已加入域的DC上操作，无需重启，变更即时生效：
- 打开Active Directory 站点和服务
- 展开“站点” → 找到对应站点 → 展开“服务器” → 展开目标DC名称
- 右键“NTDS Settings” → 选择“属性” → 勾选“全局编录” → 点击“确定”
- 系统自动触发PAS（Partial Attribute Set）复制，通常15–30分钟内同步完成
验证是否生效：运行 nltest /dsgetdc:yourforestname /gc 或直接 telnet dc-name 3268 测试端口连通性。
多域环境必须避开的硬冲突
在多域森林中，GC不能与基础结构主机（Infrastructure Master）部署在同一台DC上。否则会导致跨域对象引用失效，典型现象包括：
- 通用组成员变更不生效或延迟数小时
- 移动OU后，对象显示仍留在原位置
- 组策略应用异常，尤其涉及跨域安全组筛选时
解决方法：
- 先用
netdom query fsmo查出Infrastructure Master所在DC - 检查该DC在“AD站点和服务”中是否已启用GC
- 若已启用，需先在另一台DC上启用GC，再取消原DC的GC勾选（无需重启）
单域与多站点下的推荐配置
单域森林不存在上述冲突，且启用GC几乎零开销：
- 不增加磁盘占用（PAS数据极小）
- 不加重复制负载（本域全量数据本就已复制）
- CPU消耗可忽略
因此建议所有DC都启用GC，提升高可用性：任一DC宕机，其余GC仍可支撑登录与搜索。
多站点部署时，每个站点至少应有一台GC。否则跨站点查询会引发额外网络延迟和带宽消耗，影响Exchange、Skype for Business等依赖林级搜索的应用。
