不幸的是，我继承了一个 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，我不相信它甚至是一种选择。
在我看来，我可以：
我们目前有大约 100 GB 的 CAD 文件（90k 文件，6k 目录）存储在几个 Subversion 存储库中。在 Subversion 中保留这么多二进制数据似乎是不必要的麻烦/负担。人们签入新文件也是一种负担，因为他们需要在提交之前添加和签出目录。唯一的“优势”，能够只是右键单击和“更新”，有每个文件存储 2 个副本的惩罚（svn 如何工作），并且非常慢。没有任何意义文件的版本历史记录 - 即，CAD 文件不会被进一步修改，如果是这样，在这种特殊情况下，它不是我们关心的数据 - 只有当前、最新状态或 HEAD...因此导出SVN 输出的数据很简单。编辑文件实际上并不是工作流程的一部分，更有可能是偶然的，它涉及 5 个以上的 CAD 系统，所以我不确定“PLM”类型的系统是否真的是理想的或有保证的。
文件服务器的当前环境是 Windows Server 2003 - 这可能会在 6 个月内发生变化（服务器 2008 R2 + big RAID 6，或 NAS，可能涉及任何一种方式的服务器 2008 R2）
由于庞大的规模，没有人真正经常检查所有部分（甚至给定目录），并且已经有一个只读网络共享，每天从 Subversion 更新一次。自动更新过程一直中断（svn 工作副本变脏或处于不良状态，需要清理）。这就是大多数用户访问这些部件的方式，因此他们已经相当习惯从共享访问，这主要是对部件添加方式的更改。
我想更新我们处理 CAD 文件的工作流程。当前桌面上的考虑是直接的 Windows 网络共享。理想情况下保持这种只读行为，但显然人们需要一个地方来转储新文件并将它们添加到共享中。如果网络共享成为数据的主要来源，重要的是人们不要一直打开、编辑和保存文件。我认为这的重要性是有争议的，但通常如果编辑，合同是他们将它们复制到他们的 PC 上，因此给定文件的“主”副本不会为其他人修改。
尝试将添加文件与访问文件分开的麻烦难道不值得吗？（保持共享的只读访问）
将共享设置为写入但不修改不一定是一个选项（如果保持只读是核心要求），因为像 Pro/ENGINEER 这样的 CAD 系统采用 CAD 文件 XYZ.prt，并且每次保存都会增加一个数字......例如. XYZ.prt.1、XYZ.prt.2 等，如果人们不小心将其保存到共享中，则会导致许多副本。
到目前为止，我有一个模糊的想法，我可以编写一些脚本来处理复制到共享的可写“投递箱”，例如...拒绝 zip 文件，并拒绝覆盖任何文件。这让我不得不手动删除任何文件（偶尔需要，但很少见 - 或者可以提供给选定的用户组）。也许尽管它不完美，但 Subversion 并不可怕……我在这里寻找其他一些意见。我不想改变每个人的工作流程只是为了让情况更适合我或用户（30-40 个用户）。