AD DS数据库复制排错

AD DS数据库复制原理

为了尽可能降低AD DS数据复制的延迟时间，在不同的域控之间复制时，途经的域控不能超过三台。例如，从DC1开始复制，经过DC2，DC3到达DC4等。而且DC1并不会同时通知自己的所有直接复制伙伴，而是每隔三秒，依次通知自己的复制伙伴，这样可以防止DC1负担过大。即使出现新增域控的情况，KCC也会遵循上述规则，重新创建复制拓扑结构，保证从源域控到目标域控之间的域控数量不超过两台。

对于同一个站点中的所有控制，往往通过高速网络连接，这可以保证快速高效地在彼此之间复制AD DS数据库信息。通过更改通知的方法，当同一站点中的某台域控的AD DS数据库出现变动时，系统会等待15秒才会通知自己的直接复制伙伴。收到通知的域控如果需要同步变更信息，会发送更新数据的请求给源域控，当源域控收到并确认请求后，就会通过KCC程序来复制所需的数据。

但是，对于用户账户密码变动、账户锁定策略变更、账户变动、密码策略变化等情况，系统会利用紧急复制机制，立即通知自己的复制伙伴执行AD DS数据的更新操作。此外，当KCC在创建复制拓扑结构时，会针对AD DS数据库中的不同目录分区，来创建不同的复制拓扑结构。例如，对于DC1，当复制AD DS数据库中的配置目录分区时，DC2可能使其直接复制伙伴。当复制应用程序目录分区时，DC6可能使其直接复制伙伴。

解决AD DS数据库复制故障

在复制AD DS数据库时，可能因为各种原因出现冲突的情况。例如，多个具有系统管理员权限的用户在不同的域控上建立相同的对象（例如账户名等），因为AD DS数据库中的很多数据是利用多主机复制模式执行复制操作的，任何一台域控中的AD DS信息发生变动，都会自动更新到其他的域控中。这样，产生复制冲突的情况就在所难免了。为了有效解决该问题。活动目录域服务使用了STAMP戳记这一方法来化解矛盾。戳记由版本号，修改事件，域控的GUID等参数组成。每一个属性值的版本号初始值为1，当每次修改该属性值时，版本号数值就会增加。

当属性值被修改时，原始的时间即作为修改时间被保存起来。当操作者在某台域控上执行修改操作时，原始域控的GUID值即是域控的GUID参数值。所谓GUID是全局惟一标识符，每台计算机都拥有惟一的GUID值。当操作者修改了AD DS数据库中的某个对象的属性信息后，与该数据值对应的戳记就会发生变化。当出现AD DS复制冲突时，是按照戳记值最高的为准。在两台域控中，目标属性值的版本号谁最高，就以谁为准。如果两者的版本号信息相同，就比较两者的修改时间，谁的修改事件靠后就以谁为准。如果修改时间相同，就继续比较两者的原始域控制器的GUID值，谁的GUID值高就以谁为准。

例如，当两位管理员在不同的域控上分别修改了A账户的办公室部门信息值。 执 行 和“repadmin /showmeta CN=A账户,OU=XXX部 门,DC=XXX,DC=com”命令，在项目列表中的“版本属性”列中“physicalDelivery OffName”的版本号信息，其中的“A账户”表示具体的账户名，“XXX部门”标识具体的部门，“xxx.com”标识具体的域名。可以看到，在这两台域控上部门属性的版本号的变化是相同的，所以需要比较两者的修改时间，谁修改的事件靠后就已谁的为准。

有时会出现某个管理员在某台域控上，将AD DS数据库中的某个OU删除，但是别的管理员却并不知情，继续在该OU中创建新的账户，或者将其他OU中的账户移动到该OU中，因为该OU已经消失，所以系统会将这些账户信息自动存储到名为“LostAndFound”文件夹中。如果两个管理员在两台域控上分别创建相同的账户名，那么这两个账户名其实都会保存下来。所不同的是，根据戳记值（版本号，修改事件，域控GUID）来确定优先级较高的账户名，将其作为正常的账户信息使用，对于优先级较低的账户，其账户全名会按照具体的格式进行修改，具体的格式为“对应的相对可分辨名称 通用名：对象的GUID”。