在添加UPN而不是尝试更正我们的AD域名方面有什么弊端？

不幸的是，我继承了一个Active Directory域，该域的名称是该公司不拥有的DNS名称-我们将其称为ABC.com。我希望它成为company.com下的内容（根据MDMarra在AD命名上的回答，我可能会使用ad.company.com，因为您永远不想使用用于其他用途的DNS名称），但是对于现在将能够在今年使用目录同步功能将电子邮件移动到Office 365。为此，看来我至少需要一个与我们的电子邮件域（company.com）相匹配的UPN。好的，添加第二个UPN的过程似乎很简单。测试它并转移帐户，直到它们全部都位于所需的UPN上似乎是足够合理的。

这样做有什么弊端吗？如果我们无限期地使用ABC.com的“非拥有”域名，技术债务严峻收成者最终会到达吗？

作为参考，我们有一个单一的目录林，单个域，其中包含处于2012R2级别的所有内容（目录林，功能级别，所有DC）以及该域上的Exchange 2010。AD（大量的开发/测试自动化）中大约有150位用户和450台计算机。尽管从2003年到2012R2我一直在安全地导航，但我绝对不能称自己是AD的专家。

似乎一般不建议使用域名重命名，并且由于我们在域上安装了Exchange 2010，所以我什至不认为这是一个选择。

如我所见，我可以：

• 添加第二个UPN并完成。我可以处理在创建/添加事物时必须手动设置UPN的问题...
• 在目录林中添加第二个域，移走所有内容，并永远拥有我无法删除的旧根域
• 创建第二个森林，森林<->森林信任，从头开始在新森林中按照我真正想要的方式进行操作...移动所有内容，并最终删除原始森林。真的很慢，真的很仔细，前后测试，并且可能要付出很大的代价（花费最少的时间）。在理想的世界中，这似乎是最好的选择，但是我不确定我是否可以为此辩护（除非有人指出收割者将到来）。
• ??? 我没想到的其他事情

因此，关于不拥有您在内部使用的域的生存危机-从Office 365角度来看，这很好。Office 365关心验证您正在使用的电子邮件域，而不是AD域。因此，通过更改UPN以匹配用户的电子邮件地址而采取的方法是正确且正确的。

现在，从纯粹的AD角度来看，您将永远无法获得该内部DNS域的第三方证书，因为您不拥有它。这可能对您来说不是问题。您也永远无法与拥有相同名称的另一个域建立信任关系，因此，在极少数情况下，如果您与拥有该域的公司合并，并且它们也使用该名称，您将面临迁移的噩梦。我想这的可能性接近于0。

这是一个很大的工作，并可能极大干扰最终用户重命名或迁移域的出来。在这一点上，我通常认为您应该离开名称不佳的域，除非其中一种极端情况导致您心痛，并确保在下一个解决方法中正确解决此问题：）