![将 2012 R2 服务器提升为 2003 域上的域控制器时出错](https://linux22.com/image/675861/%E5%B0%86%202012%20R2%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%8F%90%E5%8D%87%E4%B8%BA%202003%20%E5%9F%9F%E4%B8%8A%E7%9A%84%E5%9F%9F%E6%8E%A7%E5%88%B6%E5%99%A8%E6%97%B6%E5%87%BA%E9%94%99.png)
当尝试将 2012 R2 计算机提升为 2003 forest\domain 级别域上的域控制器时,它在执行 adprep 和 forestprep 程序时出现以下错误:
ADPrep 执行失败 --> System.ComponentModel.Win32Exception (0x80004005): 连接到系统的设备无法正常工作。请查看 C:\Windows\debug\adprep\logs\20160128201714 目录中的日志文件以获取详细信息。
ADPrep 日志显示以下错误:
[2016/01/28:20:17:14.402] 传递给 ldifde 的命令行是 ldifde -i -f "C:\Windows\system32\adprep\sch32.ldf" -s "ral-ad1.AD.mydomain.com" -h -j "C:\Windows\debug\adprep\logs\20160128201714" -$ "C:\Windows\system32\adprep\schupgrade.cat" [2016/01/28:20:17:33.382] 错误:从文件 C:\Windows\system32\adprep\sch32.ldf 导入失败。错误文件保存在 C:\Windows\debug\adprep\logs\20160128201714\ldif.err.32 中。
如果错误是“权限不足”(Ldap 错误代码 50),请确保指定的用户有权读取/写入架构和配置容器中的对象,或者注销并以具有这些权限的用户身份登录并重新运行 forestprep。在大多数情况下,同时成为架构管理员和企业管理员的成员就足以运行 forestprep。[2016/01/28:20:17:33.393] Adprep 无法升级架构主机上的架构。
[状态/后果]
该架构将不会恢复到其原始状态。
[用户操作]
有关详细信息,请检查 C:\Windows\debug\adprep\logs\20160128201714 目录中的 Ldif.err 日志文件。[2016/01/28:20:17:33.393] Adprep 无法更新林信息。
[状态/后果]
Adprep 需要从架构主机访问现有的全林性信息才能完成此操作。
ldiff.err.32 日志显示
15:CN=User,CN=Schema,CN=Configuration,DC=AD,DC=mydomain,DC=com 条目 DN:CN=User,CN=Schema,CN=Configuration,DC=AD,DC=mydomain,DC=com 从第 232 行开始的条目上添加错误:不愿意执行
服务器端错误为:0x20c5 架构更新失败:辅助类列表中的类不存在或不是辅助类。
扩展服务器错误是:
000020C5:SvcErr:DSID-03260249,问题 5003 (WILL_NOT_PERFORM),数据 8389
sch32.ldf 的第 232 行如下
dn:CN=User、CN=Schema、CN=Configuration、DC=X changetype:ntdsSchemaModify 添加:systemMayContain systemMayContain:1.2.840.113556.1.4.1929
因此,它似乎正在尝试修改用户架构,但失败了。我已验证我的用户帐户位于 Schema\Domain\Enterprise 管理员组中。我还使用 adsiedit 验证了这些组对 Schema 容器具有写访问权限。我能找到的最接近的匹配是这个。MS MVP Ned Pyle 在评论中指出,这可能是由第三方工具先前错误地扩展属性造成的。建议用户联系 Microsoft 支持。我猜 Microsoft 不再支持 Windows 2003,所以这条路可能走不远了。有人见过这种情况吗?感谢您的帮助。
答案1
您可能会对 Microsoft 支持部门的回复感到惊讶,因为这个问题似乎与支持 Server 2003 无关,而是阻碍您迁移到 2012 R2 的障碍。至少,您应该这样理解。
我几乎可以肯定这是由于架构自定义造成的。通常由第三方软件造成,但有时也可能是 Exchange 安装不当造成的。您可能可以重新调整架构以便进行升级,但请注意,这样做可能会破坏最初进行架构修改的软件。
以下内容不提供任何保证和担保。请自行承担风险。如果可能,请先在实验室中尝试。正确的做法是先致电 Microsoft,看看他们是否会在自己尝试之前为您提供帮助。
从模式中转储用户类定义:
ldifde -d "CN=User,CN=Schema,CN=Configuration,DC=contoso,DC=com" -f user.txt
在文件中查找所有auxiliaryClass
字段。您可能会看到shadowAccount
、,posixAccount
也可能看到其他一些字段。
对于每一个辅助类,也要转储它们的模式定义,就像转储 User 类定义一样。
在每个辅助类定义中,检查它们的objectClassCategory
属性。它是 1 吗?如果是,则应该是 3。将其更改为 3。
objectClassCategory
记录在这里:
https://msdn.microsoft.com/en-us/library/ms679014(v=vs.85).aspx
4 个字节。结构 1、抽象 2、辅助 3。类 88、0 不应使用。
辅助类的值应为 3。如果辅助类的值为 1,则表示有人在修改架构时犯了错误。将其更改为 3 并允许 AD 复制架构,然后重试adprep
。
您发布的错误信息:
服务器端错误为:0x20c5 架构更新失败:辅助类列表中的类不存在或不是辅助类。
结合我上面概述的内容,现在变得更加有意义了。