我正在尝试修复完全无计划的非结构化Active Directory层次结构。 在Windows Server 2000上首次创build域时，不会为用户或计算机创build任何容器或OU。 所有用户在默认的“用户”容器下集合在一起，并且所有的计算机都集中在默认的“计算机”容器中。
该域最终得到升级，我现在有两个Windows Server 2008 x64数据中心。 但当然，目前的结构或缺乏是分配权限和应用组策略的噩梦，所以我需要重组整个事情。
我的问题是，如果将用户和计算机迁移到OU和组（如果有），我应该期待什么样的业务中断？
任何build议如何做到这一点？ 任何指向最佳实践的指针？
以防万一需要时，环境的其余部分是Windows Server 2008文件服务器，Windows Server 2003 R2打印服务器，Windows Server 2003 R2 Exchange 2003服务器和运行SQL Server 2005 SP2的Windows 2003 R2 x64服务器。
如果与Active Directory交互的服务全部（或主要）来自Microsoft，则不应该有任何中断。 微软产品将知道如何dynamic地查找帐户，所以您的重组对您的操作环境将是透明的。 其他产品（例如通过LDAP）绑定到高级目录并执行子树search也应该不受影响，具体取决于它们绑定的级别。
您应该查找的是可能使用Active Directory（通过LDAP或类似方法）的其他服务，并在查看时使用硬编码绑定到较低级容器对象（OU）或叶级别对象（帐户，组等）为目录中的对象。 您的重组将导致这些查找失败。
例如，我们使用的是一个非MS数据库平台，是的，它与AD进行用户authentication。 但是，它维护着自己的内部用户数据库，并且在为该系统创buildlogin时，必须将绝对ADsPath与每个用户帐户相关联。 当用户帐户移动到不同的OU时，该用户的身份validation将中断，直到我们使用新的ADsPath更新帐户。
自动search这些服务不是微不足道的，所以如果您有这些服务，我强烈build议维护连接到AD的应用程序/服务的清单。
你不应该期望任何中断。 将对象移动到不同的容器不会造成任何中断。 由于您无法将策略直接应用到默认OU，您甚至不必担心确保正确的策略适用于新策略。
相当多，你很好去。
就最佳实践而言，我倾向于在新的环境中创build三个顶级OU。 UserAccounts，Groups和Machines（或类似于计算机的东西）。 从那里，我为特定types的机器（例如服务器/工作站），pipe理组/分配组/资源组等制作子OU。这样就可以很容易地将所有用户/计算机用于广泛的策略，并将更具体的策略链接到更具体的OU。