全局编录服务器（GC）是域控制器勾选“全局编录”后进入的角色状态，复用NTDS服务、监听3268/3269端口；多域环境中GC不得与基础结构主机共存，否则导致跨域对象引用异常；单域建议全启GC以提升容灾与应用兼容性；GC不可用时可启用UGMC作为临时兜底。
GC 不是独立服务，而是域控制器的一种运行状态
全局编录服务器（gc）没有单独安装包，也不需要启用新服务。它只是域控制器（dc）在 ntds settings 中勾选“全局编录”后进入的一种角色状态。一旦启用，系统自动触发复制流程，将本域全量数据 + 其他域的 pas（partial attribute set）属性同步到该 dc 的 gc 分区中。
常见误解是以为 GC 需要额外配置端口或服务，其实它复用 NTDS 服务，监听标准 GC 端口：3268（LDAP）、3269（LDAPS）。验证是否生效，直接 telnet dc-name 3268 或用 nltest /dsgetdc:forestname /gc 查看返回的 GC 列表。
多域森林中 GC 与基础结构主机不能共存
这是部署 GC 时最易踩的硬性冲突点。如果某台 DC 同时承担 Infrastructure Master 角色和 GC 角色，在多域环境下会导致跨域对象引用（如组成员中含其他域用户）无法更新，表现为：组策略应用异常、OU 移动后对象显示不一致、通用组成员变更延迟甚至丢失。
解决方法很简单但必须手动检查：
- 用
netdom query fsmo确认当前Infrastructure Master所在 DC - 打开“Active Directory 站点和服务”，逐个检查该 DC 的
NTDS Settings属性页是否勾选了“全局编录” - 若已勾选，需先在另一台 DC 上启用 GC，再取消原 DC 的 GC 勾选（无需重启，但需等待 GC 复制收敛）
单域环境建议所有 DC 都启用 GC
单域森林不存在 Infrastructure Master 冲突问题，且启用 GC 几乎零开销：不增加磁盘占用（PAS 数据量极小）、不加重复制负载（本域全量数据已复制）、CPU 消耗可忽略。反而带来明显收益：
- 任意一台 DC 故障时，UPN 登录、通用组令牌生成、地址簿搜索仍可由其他 GC 正常支撑
- Exchange Server、Skype for Business 等依赖 GC 的应用无需额外指定 GC 服务器
- 避免客户端因 DNS 轮询到非 GC 的 DC 而出现登录缓慢或失败（错误提示常为
The user name or password is incorrect，实则 GC 不可达）
GC 不可用时，UGMC 是唯一兜底方案
当网络分区或 GC 全部宕机，用户将无法使用 UPN 登录（user@domain.com），也无法解析通用组成员身份——此时即使密码正确，也会因访问令牌缺失组 SID 而被拒绝登录。Windows 提供的通用组成员身份缓存（UGMC）能缓解该问题，但它不是默认开启的。
启用 UGMC 需修改域策略：
- 组策略路径：
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options - 启用策略项：
Network access: Allow anonymous SID/Name translation（非此名，注意辨识）→ 实际应找：Domain controller: Allow universal group membership caching - 策略生效后，DC 会缓存最近登录用户的通用组成员信息，默认缓存 8 小时，可通过
gpupdate /force刷新
注意：UGMC 缓存的是“过去成功登录过的用户”的通用组关系，新用户或从未在此 DC 登录过的用户仍无法通过；它只是临时容灾手段，不能替代合理部署 GC。
