全局编录（gc）是域控制器的内置角色，非独立服务，用于支撑upn登录验证、通用组令牌生成和林级快速搜索；其存储森林中所有域对象的高频属性只读副本（如userprincipalname、displayname、mail等），多域环境须避免与基础结构主机共存，单域建议所有dc启用以提升高可用性。
全局编录（gc）不是可安装的服务，而是域控制器（dc）的一种内置角色。启用它，本质是让这台 dc 同时承担林级对象索引与验证任务——直接影响用户能否用 user@domain.com 登录、通用组权限是否生效、outlook 地址簿能否搜到全森林的人。
GC 的真实作用：登录、令牌、搜索三件事
GC 存储的是整个森林中所有域对象的“高频属性只读副本”（Partial Attribute Set），比如 userPrincipalName、displayName、mail、sAMAccountName 和通用组的成员列表。它不存完整对象，也不可写，但三个关键环节离不开它：
- UPN 登录验证：用户输入 user@domain.com，DC 必须联系 GC 才能快速定位该账户在哪个域
- 通用组令牌生成：登录时若用户属于通用组，GC 是唯一存储其成员关系的位置；缺失 GC 响应，访问令牌缺 SID，应用访问常被拒绝
- 林级快速搜索：ADUC 中“在整个林中搜索”、Outlook 地址解析、Exchange 收件人建议，底层都查 GC 端口（3268/3269），避免逐个 DC 轮询
怎么启用 GC：图形操作 + 两个硬约束
在已加入域的 DC 上操作即可，无需重启，变更立即生效：
- 打开“Active Directory 站点和服务” → 展开对应站点 → 展开目标 DC → 右键“NTDS Settings” → 勾选“全局编录” → 确定
- 系统自动触发 PAS 复制，通常 15–30 分钟内完成同步
- 验证方式：运行 nltest /dsgetdc:yourforestname /gc 或 telnet dc-name 3268
必须避开的两个硬性冲突：
- 多域森林中，GC 不能与基础结构主机（Infrastructure Master）共存于同一台 DC。否则跨域对象引用（如通用组含其他域用户）无法更新，表现为组策略异常、OU 移动后对象显示错位、通用组成员变更延迟数小时
- 检查方法：先用 netdom query fsmo 查出 Infrastructure Master 所在 DC，再进“AD 站点和服务”确认其 NTDS Settings 是否勾选了 GC；若已启用，需先在另一台 DC 上启用 GC，再取消原 DC 的勾选
单域 vs 多站点：推荐配置逻辑
单域森林不存在 Infrastructure Master 冲突，且启用 GC 几乎零开销：
- 不增加磁盘占用（PAS 数据极小）
- 不加重复制负载（本域全量数据本就已复制）
- CPU 消耗可忽略
- 建议所有 DC 都启用 GC，提升高可用性：任一 DC 故障，其余 GC 仍可支撑登录与搜索
多站点部署时：
- 每个站点至少部署一台 GC，否则客户端跨站点查询会引发额外延迟和带宽消耗
- 尤其影响 Exchange、Teams、Skype for Business 等依赖林级搜索的应用
- 带宽充足且延迟可控时，远程站点可暂不配 GC，但需持续监控登录失败率与地址簿响应时间
GC 不可用时的临时应对：UGMC 缓存
当 GC 全部宕机或网络分区，UPN 登录将失败（错误提示常为“用户名或密码错误”，实则 GC 不可达），通用组权限丢失。此时可启用通用组成员身份缓存（UGMC）作为容灾兜底：
- UGMC 默认关闭，需通过组策略启用：路径为“计算机配置 → 策略 → Windows 设置 → 安全设置 → 本地策略 → 安全选项 → “Network access: Sharing and security model for local accounts””（实际策略名以域功能级别为准，常见为“Domain controller: Allow universal group membership caching”）
- 它只缓存“曾在该 DC 成功登录过的用户”的通用组关系，新用户或首次登录该 DC 的用户仍无法绕过 GC
- UGMC 是临时手段，不能替代合理规划 GC 部署
