通过上次
活动目录系列之四：单域环境的实现（多站点）--基..
的学习，我们已经完成了跨地区活动目录环境的实现，基本上也可以充分利用站点的优点，对用户登录和AD数据库的复制进行很好的管理，下面我描述一个场景，大家看如何解决？
场景：根据上次我们已经完成不同地区单域环境的搭建，在北京/上海/广东分别创建了三个站点，并在每个站点布置了一台DC（根据公司实际情况也可以放置多台DC）。试问，如果上海和广东站点无法联系北京站点，此时用户登录是否会出问题？
分两种情况分析：
情况一：如果域的功能级别是windows2000 mixed模式，上述案例不用再做任何优化，不会出任何问题。
情况二：如果域的功能级别是windows 2000 native模式下，上述案例用户登录会出问题，甚至会出现登录不了的情况。如何操作，可参考 《再谈域环境下用户不能登录问题！！（缓存故障）》有详细的解决方式。即如下有两种方法。
法一，分别在上海和广东的站点找一台DC作为GC，默认下北京站点的DC已经是GC了。设置方法如下图所示：
法二，分别为上海和广东的站点启用“通用组成员关系缓存（来自北京站点），如下图所示：
这样，优化工作就完成了。至于为什么，我会在下篇为大家讲一下有关域用户登录过程！大家就明白。这里的两篇文章我会在后面陆续推出！！
场景：根据上次我们已经完成不同地区单域环境的搭建，在北京/上海/广东分别创建了三个站点，并在每个站点布置了一台DC（根据公司实际情况也可以放置多台DC）。试问，如果上海和广东站点无法联系北京站点，此时用户登录是否会出问题？
分两种情况分析：
情况一：如果域的功能级别是windows2000 mixed模式，上述案例不用再做任何优化，不会出任何问题。
情况二：如果域的功能级别是windows 2000 native模式下，上述案例用户登录会出问题，甚至会出现登录不了的情况。如何操作，可参考 《再谈域环境下用户不能登录问题！！（缓存故障）》有详细的解决方式。即如下有两种方法。
法一，分别在上海和广东的站点找一台DC作为GC，默认下北京站点的DC已经是GC了。设置方法如下图所示：
法二，分别为上海和广东的站点启用“通用组成员关系缓存（来自北京站点），如下图所示：
这样，优化工作就完成了。至于为什么，我会在下篇为大家讲一下有关域用户登录过程！大家就明白。这里的两篇文章我会在后面陆续推出！！
本文转自 jary3000 51CTO博客，原文链接：http://blog.51cto.com/jary3000/122077，如需转载请自行联系原作者
