需要记住的是，KCC不能看到物理网络，要依靠管理员配置物理网络中联结域控制器的站点链接。当CHI站点出现问题，KCC就会察觉到。因为CHI-NYC域ATL-CHI间存在联结性，物理网络联结了ATL与NYC，但是管理员不能从ATL-NYC中创建明确的站点链接。KCC负责这种勘漏和ATL、NYC之间的复制，直到CHI恢复工作，在这种情况下，KCC将拆除ATL-NYC联结，并通过CHI建立初始联结。我们可以决定使SLB实效（默认情况下它是可用的）并简单地创建ATL-NYC链接，但是在较大环境里，管理起来比较困难。
在我们所讨论的问题中，比较重要的一点是Windows 2000本身存在一些限制，基于这种原因微软建议在企业中的域控制器站点最多不能超过200个，对单一轴心站点的复制不能多于120个，因为除了KCC限制外，硬件配置也是很重要的一方面。我们现在无法对该主题展开来说，但是在推出的KB文章里有很好的说明，如KB244368以及Branch Office部署指南。通常的解决方法是使SLB失效，减少KCC中的载荷，并切实消除多数情况中的问题。Windows 2003使用完全不同的支持生成树算法，可允许KCC消除那些限制，让我们重新使用SLB。
因此，在消除DR站点到远程站点中所创建的复制链接时SLB起到什么作用呢？如果我们利用原来在ATL，NYC及CHI站点中用到的例子，就能发现它是如何工作的。在那些例子里，CHI是轴心站点，ATL是DR站点。但是除了NYC，我们还有很多其他的远程站点，当然SLB也被激活。在例子中我们看到，在CHI站点中的域控制不可用时，远程站点NYC是如何被复制到ATL的。这种情况也适用所有其他的远程站点。因此，如果CHI的域控制器不可用，KCC将最终确定CHI没有可复制的域控制器，它将创建链接到ATL，允许在远程站点与ATL之间建立联结对象，完成网络容错备援设置。
需要指出几个重要问题：
在主要轴心站点与DR站点间建立低成本的站点链接，确保两者间的频繁复制，从而保障DR站点同主要站点一起随时得到更新。这也意味着物理网络在那两者间应该有一个可靠，高速的链接。
不要在DR站点与远程站点间创建站点链接。
不要手动创建联结对象到DR站点中。
当出现故障的站点得到恢复后，Windows 2000在清除旧的联结对象时并不出色，这就需要管理员手动清除旧联结对象到DR站点上。Windows 2003的清除工作确非常出色（这也是选用Windows 2003的另一个原因）。
当然，这些都取决于DR站点与远程站点间的物理网络联结性如何。
通常，在投入生产前都要在实验室里进行测试。总会有些情况你没有首先想到，因此不要总是等到灾难性问题出现时再去解决。
在多种核心轴心站点里，当一个出现问题，（SLB可用），KCC将调整其他节点中的联结情况。它们都会互相成为对方的内置DR站点。
控制KCC行为的最好方法时给它设定足够的参数，这样它就不会走入歧途。如果给予过多自由，KCC通常不能按你预期的那样进行复制。允许SLB传递性既可。
总的来说就是以尽可能简单的模式设计复制的拓扑结构（中心辐射结构提供到达远程站点的单一路径），允许SLB在主要轴心站点发生故障时提供冗余配置。
