活动目录的设计可以说是一门科学，它是如此的复杂，以至于在一篇文章中是不可能对所有的差别都进行说明。因此，在本文中，我将与大家一起分享十条要诀，它们可以帮助你设计出性能更高、管理更方便和问题更容易解决的活动目录。

　　1.保持简洁

　　在设计活动目录时，第一要诀就是越简单越好。活动目录是用来提供灵活性的，可以提供多种类型的对象和组件。但是，可以提供并不意味着应该使用。保持尽可能简单的设计，有助于提高活动目录的整体效率，并在问题出现的时间更容易处理。

　　2.适当使用站点拓扑

　　 尽管在前面，我们指出了简单化的好处，但如果实际效果更合理的话，你也不应该回避创建更为复杂结构的必要性。较大的网络总是需要多个活动目录站点。该站点拓扑结构应该可以镜像出整个网络的拓扑结构。网络的高度关联部分应该属于单独的站点中。站点连接应该镜像出广域网连接，每台物理设备都应该由单独的广域网连接和独立的活动目录站点分割开。

　　3.使用专门的域控制器

　　 我经常看见很多小公司都试图为域控制器添加更多的功能。举例来说，公司的域控制器经常也承担文件服务器或邮件服务器的功能。只要有可能的话，域控制器就必须运行在专门服务器上（物理的或者虚拟的都可以）。添加额外功能到域控制器上可能会影响到服务器的性能，降低安全性，导致备份进程或者服务器恢复进程复杂化。

　　4.至少设置两台域名系统（DNS）服务器

　　对于试图节约成本的小公司来说，另外一个经常犯的错误就是仅仅只建立了一台DNS服务器。这样的话，就会导致活动目录的可靠性完全依赖DNS服务。如果你只有一台DNS服务器的话，只要它出现故障，活动目录就会停止工作。

　　5.避免把所有鸡蛋放在一个篮子里（虚拟化时应注意的问题）

　　公司选择使用多台域控制器的主要理由之一，就是在一台域控制器出现故障的时间，可以提供容错能力。然而，这一措施往往会被服务器虚拟化技术所破坏。我经常看到这样的情况，公司将所有虚拟域控制器放在一台虚拟主机服务器上。这样的话，如果该主机服务器发生了故障，所有域控制器也都将当机。虚拟化域控制器这样的措施是正确的，但应该将所有的域控制器分散到多台主机服务器上。

　　6.不要忽视的灵活单主机操作（FSMO)角色（备份过程中应注意的问题）

　　尽管Windows 2000和此后的每一个Windows服务器版本都提供了多主域控制器模型，可以将某些域控制器设置为比其它的更重要。但域控制器上存取灵活单主机操作（FSMO）角色对于活动目录的安全来说是至关重要的。活动目录被设计成这样的目的，如果域控制器的主机FSMO角色出现故障，活动目录还可以继续工作一段时间。尽管到最后，FSMO域控制器的故障可能极具破坏性。

　　我曾经听到来自一些信息技术专家这样的建议，你不必对网络中的所有域控制器进行备份，因为活动目录的信息可以在域控制器之间进行复制。尽管这一建议有一定的道理，但备份FSMO角色持有者是至关重要的。

　　我曾经协助一家公司对一台发生故障的域控制器进行恢复处理。不幸的是，该域控制器承担了FSMO角色的所有功能，并且是公司里唯一的全局目录服务器，还是唯一的DNS服务器。而且让情况变得更坏的是，这里没有域控制器的备份。最后，我们不得不从头开始重新建立活动目录。这是一个非常极端的例子，但它说明了备份域控制器的重要性。

　　7.对域结构进行规划，并坚持维护

　　大多数公司在建立活动目录架构的时间都经过精心策划。但随着时间的流逝，活动目录的演化可能出现偶然的变动。为了避免这种情况的出现，我个人建议对活动目录的发展进行规划。你可能无法对活动目录的增长情况进行准确预测，但至少可以通过一些维护措施来保证应用增加时架构不会出现变化。

　　8.在开始架设服务器前，确定可行的管理规划

　　正如需要事前规划好活动目录架构一样，你也需要先指定好可行的管理规划。谁将担任活动目录的管理员？是一名管理员还是一支团队来对整体架构进行管理，或者是按照域还是公司部门划分管理责任？这些管理方面的决定，必须在建立域控制器之前就给出结论。

　　9.在实施过程中，尽量避免作出重大调整

　　尽管，活动目录的设计非常灵活，并且可以在不关机或者导致数据丢失的情况下进行重大调整。但我还是建议，如果可能的话，尽量避免对活动目录进行重组。我已经不止一次看到这样的情况了，架构调整过程中，特别是在不同版本的Windows服务器之间的域控制器上移动项目，导致活动目录中一些项目的损坏。

　　10.每个站点应该至少建立一台全局目录服务器

　　最后，如果你的活动目录中包含了多个站点，请确保每一个都建立了自身的全局编录服务器。否则的话，活动目录客户端将不得不利用广域网连接来对全局信息进行查询。

　　更多的要诀？

　　你有其它的设计方法可以推荐么？在实施活动目录项目的时间，你曾经对作出的决定感到后悔么？