我读过一些声称使用Active Directory用户主目录属性来自动映射主驱动器的文章是一种传统方法，不build议使用，或者不推荐使用。 我链接的第二篇文章给出了一些很好的理由，为什么不build议这样做。
但是，我已经search了高低，并没有find任何正式的微软文章给出这个build议。 看起来官方的立场仍然是要么使用主目录属性，要么使用文件夹redirect。 以下是2013年的一篇文章 ，其中，Microsoft MVP仍然使用主目录属性练习，在“脚本人”认可的文章中。
有没有人知道这个历史，并可以提供一个更“官方”的build议的链接是否通过GPO映射家庭驱动器现在是最好的做法，通过使用主目录属性？ 或者这是在实践中被采用但从未正式认可的东西？ 如果是后者，是否有任何function由于不使用主目录属性而丢失？
HomeDrive属性不被弃用，并可能永远不会被删除。 它受欢迎的原因是因为它是第一个删除使用login脚本映射用户驱动器的要求的属性。 pipe理员现在可以在用户创build过程中以编程方式指定主驱动器，而不用担心维护login脚本。 对于pipe理简单的小型组织来说，这个结果很好。
对于大型组织来说，业务需求决定了并不是所有的用户帐户都是平等的，有些需要与其他用户分开。 这些组织继续使用或创build大型，复杂的login脚本，通常检查成员组成员身份，以确定在哪里映射哪些驱动器，以包括其主驱动器。
这些login脚本执行期间…等待它…login，如果出了问题，如networkingpath无法访问或访问被拒绝，他们会挂起。 组策略处理的默认超时时间为10分钟。 这是整个“login到你的电脑，并让你自己等待一杯咖啡”从哪里来的地方。 所以，现在您已经感觉到性能问题和可靠性问题，因为组策略错误，并没有正确完成处理。 这当然产生了对微软的支持呼叫， 许多呼叫花费在主要映射的networking驱动器上的故障排除login脚本。
然后魔术，新的组策略首选项与驱动器映射扩展出现！ 驱动器映射扩展还支持组成员身份等项目级目标。 现在，所有这些支持驱动器映射login脚本错误的调用都可以通过将它们转换为此扩展来自动“解决”。 由于它是组策略的一部分，因此该扩展function得到了Microsoft的正式支持，而login脚本得到了最大的努力。
组织现在有一个Microsoft支持的方式来映射基于组成员身份的networking驱动器 ，Microsoft 减less了他们的支持电话和时间故障排除login脚本 ，pipe理员可以从组策略中全部pipe理，一路赢。 而且，顺便说一下，您可以使用Drive Maps来映射用户的主驱动器（使用％logonuser％） 。