感谢最近对我的问题的回答，我能够使用 sysprep 创建一个 Windows 7 系统映像，以便在我们的组织中部署。
我了解到使用 sysprep 的过程会为系统创建一个新的机器 SID，从而在新部署的系统上不需要运行 newSID 软件。另外，我看到Mark Russinovich的博客文章指出机器 SID 不再是问题。但是，我仍然有点困惑：
作为我们小组中的一名技术支持技术人员，我有时会接到客户的电话，他们的计算机无法连接到我们的 Windows 域，或者无法使用他们的 AD 凭据登录（错误消息类似于“无法访问域”等，而其他计算机可以）。
根据我们的一位管理员的说法，故障在于重复的计算机 SID，因为计算机无法登录是因为另一台具有相同 SID 的计算机已经登录。他说这就是为什么有时无法加入域的计算机现在会一个小时后突然可以加入，因为另一台冲突的机器已关闭。
他会要求我们在有问题的计算机上运行 newSID 来解决问题。有趣的是，在 (1) 离开域，(2) 运行 newSID，然后 (3) 将计算机重新加入我们的域之后，用户将能够使用 AD 帐户登录。这似乎与我提到的声称机器 SID 不再有用的博客文章相冲突。
为了更好地帮助我的客户并更好地理解这一切是如何运作的，我想问以下问题：
(1) AFAIK、newSID 和 sysprep 都为计算机提供新机器SID。这台机器 SID 对成功加入域或使用 AD 凭据登录计算机有何作用？当具有相同机器 SID 的两个系统尝试这样做时会发生什么？我们管理员所说的“SID 冲突”是否与此有关？为什么运行 newSID 会有所帮助？
(2) 这个问题在 Windows XP 和 Windows 7 之间有什么不同吗？
(3) 微软有没有关于这一切的官方文档？
预先感谢您的帮助！
我相信您的管理员对 SID 在域环境中的工作方式有一些不正确的假设。机器 SID 与在 Active Directory 中为机器生成的 SID 没有直接关联。由于另一台机器在线而导致机器无法登录或加入的全部信息实际上意味着您的管理员对 AD 的理解不够完善。
您看到的问题很可能是由于机器/计算机帐户密码过期造成的。这些密码在 AD 中自动生成，每 30 天轮换一次。如果在此期间机器处于脱机状态，它将尝试使用其旧密码进行身份验证。用户将无法通过这些机器登录，因为 AD 主动拒绝验证计算机帐户。我相信您的管理员提供的解决方案有效的原因是因为在域取消加入/重新加入期间重新生成了帐户和密码。您可以绕过第 2 步来测试这个理论。
或者，如果您的计算机上有可用的 powershell v4，您可以使用新的Test-ComputerSecureChannel命令行开关检查该计算机与域之间的信任关系状态。如果 powershell v4 不可用，也可以使用Netdom来重置机器密码。
如果您的信任/身份验证检查成功，那么您可能正在查看 AD 的其他问题、潜在的复制和/或 FSMO 角色的问题。
某些 Microsoft 软件功能（WSUS、SCCM、SCEP 等）仍使用机器帐户 SID。我还看到了 3rd 方供应商使用的机器 SID（看着你 symantec）。您可以不进行系统准备而侥幸逃脱，但在这个拥有可用成像技术的时代，没有理由跳过系统准备您的图像。
关于你的（2）问题。Win7 和 XP 之间有一些结构变化，但据我所知，SID 的运行方式不应该有任何根本性的变化，尽管正如我所说的，一些软件要求已经改变。
对于您的第三个问题，我建议您阅读 Microsoft 的两个SID的技术网络页面，并查看加入和身份验证故障排除页面（也是技术网络）。如果这不能回答您的所有问题，我会考虑购买一两本关于该主题的书，LDAP 和 AD 确实可以深入研究，但它们背后的概念是现代 IT 工作者知识集的重要组成部分。
它没有帮助。通过重新加入域，还有一些其他问题正在解决（或暂时被掩盖）。
这会导致域出现问题的唯一情况是机器是用于创建此域的第一个域控制器的克隆（没有新的 SID）。
由 NewSID 重新生成的 SID 不是活动目录中计算机对象的 SID（或更准确地说，子权限 ID）（您可能会遇到冲突），它是用于本地用户帐户数据库的权限 ID .
回到“第一个域控制器”——那台机器的 SID 权限 ID 成为域的权限 ID；对于本地用户也具有相同 SID 的其他系统也会在域上遇到问题。除了这种情况，没有可能的冲突——尤其是不会导致域通信问题的冲突。
换句话说 - 他让你找错地方了 :)
不，同样的行为。
那篇博客文章可能是最好的文档，真的。