必须用ADSI Edit连接配置分区修改garbageCollPeriod，单位为小时（1–168），且tombstoneLifetime须≥3倍GC间隔，否则静默回退至默认值；修改后需验证复制状态与事件日志ID 1646/1647。
修改 garbageCollPeriod 要用 ADSI Edit 连到配置分区
ad 垃圾回收（gc）默认每 12 小时运行一次，这个间隔由 garbagecollperiod 属性控制，它位于全林范围的配置对象中。不能通过 gui 工具修改，必须用 adsi edit 或 ldp.exe 直接编辑 cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=domain,dc=com 路径下的属性。
常见错误是连错命名上下文——必须连接到「Configuration」分区，而不是「Default Naming Context」或「Schema」。连错会导致修改失败且无提示。操作前建议先导出当前值做备份：
-
garbageCollPeriod单位是小时，合法范围是 1–168（即 1 小时到 7 天） - 设为 0 无效，会被拒绝；设为非整数（如 12.5）会截断为 12
- 修改后需等待复制完成（通常几分钟），所有 DC 才会同步新值
tombstoneLifetime 修改后可能触发自动回退
这个值决定已删除对象在数据库中保留多久才被 GC 彻底清除，默认 180 天（旧版可能是 60 天）。但它和 garbageCollPeriod 存在强约束关系：TSL 必须 ≥ GC 间隔 × 3（即至少覆盖三个 GC 周期），否则系统会静默重置为默认值，并把 garbageCollPeriod 也一并改回 12 小时。
例如你把 GC 间隔设为 25 小时，那 TSL 至少得是 75 小时（≈ 4 天）；若只设成 3 天（72 小时），AD 会拒绝该设置，最终回退到 180 天 + 12 小时组合。这种回退不报错、不写事件日志，只能靠事后检查确认。
- 检查是否生效：用
Get-ADObject查询配置对象的tombstoneLifetime和garbageCollPeriod属性值 - 修改后务必验证所有 DC 的复制状态（
repadmin /replsummary），避免部分 DC 拿到旧值 - 缩短 TSL 有风险：会影响从备份恢复的窗口期，也限制了跨域控制器恢复已删除对象的时间
GC 间隔调短 ≠ 回收更快，反而可能加重负载
把 garbageCollPeriod 从 12 小时改成 2 小时，看起来能更快清理 tombstone，但实际效果有限。因为 GC 只清理「已超 TSL」的对象，而 TSL 本身没变；同时高频 GC 会增加 CPU 和磁盘 I/O，尤其在大型林中易引发 ESE98 日志事件或临时性能抖动。
真正影响回收速度的是 TSL 长度本身。如果你希望 tombstone 更快消失，优先考虑合理缩短 tombstoneLifetime（比如从 180 天缩到 90 天），而不是调高 GC 频率。
- 在线 GC 过程中会顺带执行轻量级在线碎片整理，但不会释放磁盘空间——要减小
ntds.dit文件体积，仍需离线整理 - GC 不处理禁用账户、空 OU、过期 GPO 等“活着但无用”的对象，这些需人工归档或清理
- 启用了 AD 回收站后，GC 不再删除逻辑删除对象，而是等
msDS-DeletedObjectLifetime到期才清理，此时tombstoneLifetime不再起作用
修改后验证 GC 是否按新间隔运行
不能只看属性值变了就认为生效。GC 是后台线程，实际触发时间受 DC 负载、服务启动顺序等因素影响。最可靠的方式是查 Windows 事件日志：
在「应用程序」日志中筛选事件 ID 1646（GC 开始）和 1647（GC 完成），观察时间戳间隔是否符合预期。注意：首次修改后可能要等一个完整周期才会出现新日志，别急着重试。
- 如果连续两次
1646之间间隔仍是 12 小时，说明修改未同步到该 DC，检查复制状态和配置分区连接点 - GC 运行期间会短暂提升
lsass.exe内存占用，属正常现象；若持续飙升或伴随Event ID 409，说明数据库有潜在损坏 - 不要依赖
dcdiag /test:gc验证——它只检查 GC 服务是否启用，不校验间隔设置
真正容易被忽略的点是：GC 间隔和 TSL 的联动校验发生在 DC 启动时，而非修改瞬间。所以即使你改完立刻重启某台 DC，它也可能在启动过程中发现参数冲突，然后默默回滚——而你根本看不到任何告警。
