Schema扩展需在验证完备、权限到位、备份齐全、测试通过后执行；须确认必要性与版本兼容性，确保账户属Schema Admins/Enterprise Admins/Domain Admins三组，完成系统状态、数据库及Schema快照备份，并在测试环境验证成功后方可生产执行。

准备 schema 扩展环境不是简单运行一个命令，而是确保整个林级目录服务稳定、可回退、权限合规的前置工程。核心原则是：不可逆操作必须在验证完备、权限到位、备份齐全、测试通过后执行。

确认扩展必要性与版本兼容性

并非所有升级都需要手动扩展 Schema。Windows Server 林功能级别提升会自动触发部分更新，但 Exchange 和 SCCM 等组件通常需独立执行 /PrepareSchema 或 extadsch.exe。

• 查清目标组件所需的最小 Schema 版本号（例如 LAPS v2 要求 ≥87，SCCM 当前主流版本要求 ≥88）
• 用命令 ldifde -f schema.txt -s -d "cn=schema" -l objectVersion 获取当前 Schema 版本
• 比对官方文档（如 Microsoft Learn 或产品部署指南），确认版本差是否需扩展，避免冗余或越级操作

确保账户权限与角色归属

Schema 扩展必须由具备林级权限的账户执行，且该账户需同时属于三个关键内置组：

• Schema Admins：唯一拥有修改 Schema 的权限组
• Enterprise Admins：用于后续域级对象创建（如 System Management 容器）
• Domain Admins（所在域）：保障本地域内委派和配置操作权限
• Exchange 混合部署场景还需额外注意：若使用 /TenantOrganizationConfig，必须先通过 PowerShell 连接 Exchange Online 并导出组织配置 XML，否则会报错“检测到与 Office 365 的混合部署”

完成三项强制性备份

Schema 扩展失败无法回滚，离线重建 DC 是最后手段。因此以下备份缺一不可：

• 系统状态备份：在架构主机（FSMO Schema Master）上执行，包含 Schema、配置分区、启动文件等
• AD 数据库文件备份（ntds.dit + 日志）：建议使用 Windows Server Backup 或 VSS 方式，确保一致性
• 当前 Schema 导出快照：运行 ldifde -f pre_schema.ldf -s -d "cn=schema" -p subtree，便于事后比对变更

验证环境与执行流程

跳过测试环节是生产事故高发原因。正式扩展前务必完成：

• 在非生产林或隔离测试域中完整复现流程：运行 extadsch.exe（SCCM）或 Setup.exe /PrepareSchema（Exchange），检查日志（C:\extadsch.log 或 SetupProgress.log）是否含 “Successfully extended”
• 确认架构主机（Schema Master）在线且复制正常，使用 repadmin /showrepl 验证
• 扩展后等待至少 15 分钟，再用 repadmin /syncall 强制全林同步，并在其他 DC 上重复查询 objectVersion 验证传播结果