我读过了一些 文章声称使用 Active Directory 用户主目录属性自动映射主驱动器是一种过时的方法，已弃用或不推荐使用。我链接的第二篇文章给出了一些不推荐使用这种方法的充分理由。
然而，我到处找了，却没能找到任何官方的微软文章给出这个建议。官方的立场似乎仍然是要么使用主目录属性，要么使用文件夹重定向。下面是一个例子文章从 2013 年开始，Microsoft MVP 仍然使用主目录属性实践，这是在一篇由“脚本专家”认可的文章中提到的。
这里有没有人知道这方面的历史，并且可以提供一个更“官方”的建议链接，即通过 GPO 映射主驱动器是否是现在的最佳做法，而不是使用主目录属性？或者这只是在实践中采用但从未得到官方认可的做法？如果是后者，不使用主目录属性是否会丢失任何功能？
答案1
这HomeDrive 属性并未弃用，并且可能永远不会被删除。它之所以受欢迎是因为它是第一个消除使用登录脚本映射用户驱动器要求的属性。管理员现在可以在创建用户时以编程方式指定主驱动器，而不必担心维护登录脚本。对于管理简单的小型组织来说，这很有效。
对于较大的组织，业务需求决定了并非所有用户帐户都是平等的，有些帐户需要与其他帐户分开。这些组织要么继续使用，要么创建大型、复杂的登录脚本，通常检查成员的组成员身份以确定将哪些驱动器映射到哪里，包括他们的主驱动器。
这些登录脚本在登录期间执行...等待...如果出现问题，例如网络路径无法访问或拒绝访问，它们就会挂起。组策略处理的默认超时时间为 10 分钟。这就是整个“登录到您的计算机并在等待时为自己泡杯咖啡”的由来。因此，现在您已经意识到性能问题和可靠性问题，因为组策略出错并且没有正确完成处理。这当然会引发对 Microsoft 的支持呼叫，很多用于解决主要映射的网络驱动器的登录脚本故障的呼叫次数。
然后奇迹出现了，新的组策略首选项出现了驱动器映射扩展！驱动器映射扩展还支持项目级定位，例如组成员身份。现在，所有驱动器映射登录脚本错误的支持呼叫都可以通过将其转换为此扩展来自动“解决”。由于它是组策略的一部分，因此该扩展由 Microsoft 正式支持，而登录脚本则得到了最大努力。
组织现在可以通过 Microsoft 支持的方式根据组成员身份映射网络驱动器、微软减少支持电话和解决登录脚本问题的时间，管理员可以通过组策略管理所有事务，全面取胜。顺便说一句，您可以使用 Drive Maps 进行映射用户的主驱动器，（使用 %logonuser%）。