使用 AD 主目录属性来映射主驱动器真的不再是最佳实践吗?

opt*_*tic 9 windows active-directory user-management group-policy home-directory

我读过一些 文章,声称使用 Active Directory 用户主目录属性自动映射主驱动器是一种遗留方法,已弃用或不推荐。我链接的第二篇文章给出了一些不推荐这样做的充分理由。

但是,我搜索了高低,并没有找到任何给出此建议的微软官方文章。似乎官方立场仍然是使用主目录属性,或使用文件夹重定向。这是2013 年的一篇示例文章,其中 Microsoft MVP 仍然使用主目录属性实践,在“脚本专家”认可的文章中。

这里有没有人知道这方面的历史,并且可以提供一个链接,指向更“官方”的建议,即通过 GPO 映射主驱动器现在是否是最佳实践,而不是使用主目录属性?或者这是刚刚在实践中采用但从未得到官方认可的东西?如果是后者,是否会因不使用主目录属性而丢失任何功能?

小智 6

HomeDrive属性并未被弃用,并且可能永远不会被删除。它之所以受欢迎,是因为它是第一个消除使用登录脚本映射用户驱动器的要求的属性。管理员现在可以在用户创建期间以编程方式指定主驱动器,而不必担心维护登录脚本。对于管理简单的小型组织来说,这种方法效果很好。

对于大型组织来说,业务需求决定了并非所有用户帐户都是平等的,有些帐户需要与其他帐户分开。这些组织要么继续使用,要么创建大型、复杂的登录脚本,通常会检查成员组成员身份以确定哪些驱动器映射到何处,以包括其主驱动器。

这些登录脚本在...等待...登录期间执行,如果出现问题,例如网络路径无法访问或访问被拒绝,它们将挂起。组策略处理的默认超时为 10 分钟。这就是整个“登录到计算机并在等待时给自己泡杯咖啡”的由来。因此,现在您已经感觉到性能问题和可靠性问题,因为组策略出错并且没有正确完成处理。这当然引发了对微软的支持电话,很多电话都花在对主要映射的网络驱动器的登录脚本进行故障排除上。

然后神奇的是,新的组策略首选项和驱动器映射扩展一起出现了!驱动器映射扩展还支持项目级定位,例如组成员资格。现在,所有这些对驱动器映射登录脚本错误的支持调用都可以通过将其转换到此扩展来自动“解决”。由于它是组策略的一部分,因此该扩展受到 Microsoft 的官方支持,同时登录脚本也得到了最大的努力。

组织现在拥有 Microsoft 支持的方法来根据组成员身份映射网络驱动器,Microsoft减少了支持电话和排除登录脚本故障的时间,并且管理员可以通过组策略管理所有内容,从而全面获胜。而且,顺便说一句,您可以使用驱动器映射来映射用户的主驱动器(使用%logonuser%)