我们有一个现有的SBS2011服务器，并希望迁移到新的2012 R2服务器。 理想情况下，我们希望在一个新的领域做到这一点 – 1，我们想重新组织OU去除“SBS”命名的东西（即所有的用户不在用户，他们在SBSUsers等）。 ..）和2.我们想要去一个更符合最佳实践（subdomain.ourdomain.com而不是name.local）的域名。
我正在试图找出执行此迁移的最佳方法。 我读过的大部分内容都是通过将新的DC添加到现有的域中来进行迁移，并将其推广，让所有内容同步，然后降级旧版本。 但是，这并不能解决我们对命名或重组的担忧。
我也想过也许是跨越森林的东西，但从我可以告诉你需要ADMT（2012年不支持），或者可能是一个付费工具（不是一个可能的select，因为我们是一个非营利和有一个最低的预算为了这）。
最后，我可以导出用户并导入它们，但是这似乎会涉及用户，计算机，组等的不同步骤，而且我担心它会如何分离。 另外，据我所知，没有上述工具之一（甚至可能还没有！），我仍然不能做到这一点，没有让所有的用户重置他们的密码。
在我们将它迁移到Office 365的时候，Exchange并不是一个variables（我不认为！），为了简单起见，现在不添加SSO，直到其他所有内容都被sorting为止。
有没有一个选项，我错过了，这将使我们能够符合我们所有的标准 – 更改域名的能力，并保持标准的OU布局，而不是SBS，不购买昂贵的第三方工具，并没有影响用户帐户/密码？
Exchange 2007和更新版本阻止您执行域重命名 。 既然你说你在放弃内部交换，那不是一个因素。 这为我所认为比创build新的森林或领域的任何forms更容易的过程打开了大门：
完成您的迁移到Office 365并从您的SBS 2011环境中删除Exchange。
将临时DC添加到现有域中，并将AD（和所有FSMOangular色）从SBS服务器中移出，然后将SBS服务器降级回过程中的域成员。 （在此之后，您将有21天时间完成迁移。）
执行域重命名。
添加您的永久W2K12 R2 DC，降级/删除临时DC。
在AD中重命名/移动OU（GPO等）以满足您的喜好。
从SBS机器上迁移任何其他function并将其解除。
临时区议会不是绝对必要的，但我可能会这样做（因为我迷信）。 域名重新命名听起来很困难，但没有Exchange它实际上是非常简单的。 如果你对使用孤立networking上的虚拟机模拟你的环境并试用（最好使用从生产networking“收获”的真实AD副本并放到虚拟环境中）来进行模拟。
您将不得不违背SBS 2011安装程序创build时的默authentication书颁发机构。 假如你没有真正使用它， 退役企业CA也不是那么难。 （如果你是，那么无论你采取什么样的迁移策略，你都需要担心这一点。）
当你完成所有的工作，你将有一个很好的新的域名，你的OU看起来像任何你想要的，所有的用户密码将是完整的，并且所有域成员计算机将具有完整的域信任。
计划，testing和正确执行生产域名重命名和迁移可能只需几个小时即可完成。 （显然，当你真正做到真正的事情时，你花费在前面的计划和testing将会付出巨大的利益。）
（我还会在新的W2K12R2机器上导出共享，反映旧的SBS机器导出的共享，并且将SBS机器添加为新的服务器的DNS别名 ，然后现有的快捷方式，UNC等将“只是在工作之后“。）
编辑：
我不知道为什么人们在域名重新命名时如此谨慎。 你需要规划出来并有条不紊地执行它，但是对我来说却是痛苦的。 我已经完成了三个生产域名重命名，并没有任何问题（除了需要更改的embedded式设备中长期被遗忘的FQDN之外）。 两个环境有Exchange 2003，一个没有。 一个有一个DC，另外两个有多个DC。 我嘲笑虚拟机中的前两个（有Exchange的环境），但是第三个我只是在没有模型的生产networking上运行（因为它非常简单 – 单个DC，没有Exchange）。
以上是从上面的“执行域重命名”的项目符号，分解成步骤。
根据微软的文章，我更喜欢： 域名重命名是如何工作的这篇文章包含了很多多余的背景，但是基本的步骤在那里。
对于具有单个DC的单个域森林来说，这个过程非常简单：
取消任何企业CA根目录。
为新域名创build一个新的AD集成DNS区域。
将森林function级别设置为Windows 2003或更高版本。
运行rendom /list来生成森林描述文件（ Domainlist.xml ）。
编辑Domainlist.xml文件以反映新的DNS和NetBIOS域名。
运行rendom /showforest ，以“友好”的方式显示Domainlist.xml文件，并检查输出以确保进行了适当的编辑。
运行rendom /upload命令将新的域名安装到Active Directory中。 在这一点上不会发生重命名 – 你只是准备AD重命名。 在多DC环境中，这将启动将重命名指令复制到所有DC。
运行rendom /prepare命令来validation是否准备重命名。 在多DC环境中，此命令会检查每个DC，以确保它们都收到了重命名指令。 直到所有DC都复制了重命名指令，重命名才能开始。 （所有AD数据库副本几乎同时发生变化是必须的）。一旦你执行了rendom /prepare你就不能将任何新的域添加到森林或者DC到域中，直到你执行了rendom /clean （见下面）。
运行rendom /execute命令执行重命名。 这指示DC执行重命名。 每个DC将AD数据库切换到单用户维护模式，执行重命名，然后重新启动回到正常的操作状态。
一旦所有DC完成了重命名，执行带有适当的新旧域名的“Gpfixup” ，将对旧域名的引用更新为组策略对象中的新名称。
更改每个DC上的主DNS后缀， 因为它们不会自动更改 。 我不知道为什么微软自动没有这些变化，但他们没有。 进行此更改后重新启动DC。
重新启动所有域成员计算机两次。 这不必马上做（我在这个状态保持了几个星期的域名）。 域成员计算机将“检测”域名重命名已经执行，并在这两次重启时自动更新自己。
重启所有域成员计算机两次后，执行rendom /clean命令清除AD中的重命名指令，并将域返回到正常运行状态。
从AD中删除旧域的DNS区域，一旦您将任何非域成员logging迁移出去。
就像我所说 – 一个域，单一的DC环境很简单，因为您不必担心域重命名指令的复制或能够联系所有的DC。
就副作用而言：
您需要认识到域DFS根名称将会更改。 如果您有来自域DFSpath的组策略软件安装，您将看到重新安装软件（因为组策略客户端会认为该软件未安装）。
如果您在/clean域名太早（在所有成员计算机重新启动两次之前），则可能会遇到需要手动分离并重新join域的计算机状态。
在较大的环境中，当新的DNS区域填充时，您将看到增加的复制stream量。