每个活动目录管理员都要处理移动用户并控制移动目标的挑战，但是可移动的域呢？最近，我在类似这样有趣的环境中工作，而不同的是，它真实地显示出了活动目录是那么的灵活。就像我们后面看到的案例分析一样，记住，不管环境怎样，活动目录按以下基本原则有效运作。

　　案例分析1：

　　A公司（由于不出名）偶尔需要将整个域架构迁移都到一个远程位置一段时间，然后再将它迁移回原来的地方并接入本地局域网。这个域是多域林的一部分。通过授权的DNS，A公司包括域控制器（DC）、全局目录、服务器和客户机等，基本上整个包都移出域一段时间。

　　挑战

　　但不太寻常的是，这能够实现（它是不是最佳选择另当别论）。这种配置仍然有一些事情需要注意，例如：

　　网络应用——一切都必须是自足的，因此不要通过域外的网络共享来安装应用软件

　　网络共享——明显地，所有共享都必须在域中。它可以通过创建分布式文件系统（DFS）共享来在复制域中的数据。在公司总部所在地保留DFS服务器和DC，允许远程服务器在连接到LAN后同步备份。这和灾难恢复一起作用，但在公司总部服务器上一定有一些限制，所以用户不能在此更改数据当域从LAN断开，如果用户在公司总部服务器上和远程服务器上修改了一份文档有些人就会丢失他/她的工作结果。这种配置在图1中显示，关于“选择”的详细描述在案例2中介绍。

　　跨域验证——如果使用通用组且林中存在多个域，那么在域中需要建立一个全局目录（2个冗余）。

　　延迟目标——创建延迟目标有很多方法，但方案是相当简单：将期满时间值设置为域从网络断开的最长时间再加上30天。如果运输人员罢工，你还可以将活动时间设置得更大，最大为365天。注意，如果你调整域从LAN断开的活动时间，你也需要单独在移动域控制器上作调整。

　　返回投诉——是的，当域控制器接入LAN后，事件日志中会有一些抱怨（你不能将整个域分裂得不相干还让所有人都开心）。处理的一个方法是过滤这些事件日志，但是甚至连Windows Server 2008都不能让你在事件日志中设置过滤器来隐藏来自远程域控制器的抱怨。也许有第三方工具可以做到这一点，但是要小心，你不会希望过滤掉本地局域网中域控制器上的一些危急事件。

　　选择

　　有很多其它可以考虑的选择。对我来讲，显而易见的选择是把移动域当做一个单独的林来创建，然后设置两个林之间的信任关系。不需要考虑复制，移动域可以自动管理，当服务器返回之后你能够得到共享资源带来的好处。当然，有些条件下它可能无法正常工作，但值得考虑。

　　另外一个主意是将LAN中的远程域撤走一个域控制器。这不会减少域服务事件日志中的抱怨，延迟目标危险也继续存在，但这将在森林中以“保留最后一个站点”的方式保留域的位置。如果运输崩溃了，至少你保留有可以重建域的信息。

　　案例分析2

　　B公司是一个有船队并需要在不同港口从事海运的公司。这种情况下，这些域控制器在陆地上的总部，只有客户端在船上。这个公司拥有一个三层网络：

1. 当船到港口，它们连入LAN。
2. 当船驶离港口，它们使用UMTS（通用移动通讯系统），一个3G网络。在离港之后，UMTS提供一定距离的连接。
3. 当旅行距离超出了UMTS范围，就没有网络连接。

　　挑战

　　抛开船和三个网络层这些信息，处理远程用户确实是常见的挑战。在这种情况下，当船驶出UMTS支持的范围就会遇到问题，客户端需要45分钟才能登录。没有接入网线时没有有延时。

　　我们发现，客户端配置文件中的家用驱动器像DFS共享一样映射在陆地上的服务器中。这种配置的最大挑战就是在船上没有服务器或域控制器资源。

　　解决方案

　　通过大量研究，我发现有很多公司专门为货船、巡洋舰等创建像这样的活动目录环境。军事组织很好地使用了这样的配置。我发现有一个名为iDirect的公司，甚至提供一个在海上可以持续访问的卫星网络宽带连接。

　　这种典型配置中，每条船都有自己的域，并通过在公司总部的林根组织在一起（就像案例1）。我没有看到更多详细信息，但它们如图1所示，每个公司的域都有一个域控制器。

图1. 远程域架构

　　这与在陆地上拥有一个在各个位置的域都有域控制器的多域林没有太大区别。公司网站上针对所有有复制组域的DFS服务器，包括船上的DFS服务器，会像在线备份一样良好运行。这使每条船都是独立存在的，当船进入港口，共享数据将会被完整地复制回域服务器（双向）。在船上发生灾难的情况下（进水、大火等），它将允许来自陆地单一来源的备份。

　　为移动域配置活动目录域架构与设立固定基础的域或林没有太大不同。这都要考虑客户端和域控制器之间的网络连接性，就像在移动和固定域之间一样。通过考虑配置文件、共享资源、应用程序、复制和验证，来决定客户端从林分离后如何工作。不要忘记容灾——将移动域的一个域控制器接入公司，这会让清理和之后的维护工作大大减少。