我们正在从 Novell 迁移到 Active Directory。在过渡期间,我们将根据当前标准评估我们的驱动器映射,以查看我们所做的工作是否仍然合适、是否符合最佳实践、是否简化了资源管理等。目前,我们有 11 个不同的驱动器映射。在我看来,这似乎太多了,而且对最终用户来说相当混乱。这些驱动器映射似乎还与组织中存在的一些较旧的惯例有关,最终变成了以下形式:
- K:\ - Novell 服务器的物理 CD-ROM 驱动器映射
- N:\ - IT 管理脚本和实用程序
- S:\ - 其他用户的主文件夹(如果需要)
- T:\ - dBase III 映射(希望在迁移后消失)
- U:\ - 项目或其他群组共享
- V:\ - 项目或其他群组共享
- W:\-工作(部门或单位工作份额)
- X:\ - 应用程序共享
- Y:\- 主文件夹
- Z:\-系统卷
对于我们组织内的用户(包括最终用户和 IT 人员)来说,这是一个非常令人困惑的结构。我想请教行业最佳实践以及其他人如何设计驱动器映射。应该注意哪些事项以及如何补偿或控制这些事项?从管理和维护的角度来看,应该考虑哪些事项?
我们的客户端将是 Windows XP、Windows Server 2003、Windows 7 Pro 和 Windows Server 2008。稍后我们还想将 Linux 和 Macintosh OS X(10.6 或更新版本)客户端合并到我们的驱动器映射中。
如您提供任何帮助、想法、资源或链接,我们将不胜感激。
答案1
一年半前,我们因为同样的原因遇到了同样的问题。主要问题有三点:
- Novell 网络历来都是基于驱动器号的。每个人都知道 U: 驱动器用于用户的主目录,S: 驱动器用于共享。等等。
- Microsoft 网络与驱动器号的依赖程度较低,自 Active Directory 问世以来,Microsoft 一直在推广 UNC 样式寻址。历史悠久的 Microsoft 公司倾向于使用手头现有的任何驱动器号,并为需要驱动器号的旧应用程序使用一些标准驱动器号。
- 用户讨厌改变既定程序。他们根本不会为了 UNC 而放弃驱动器号,并会继续打电话给帮助台说“Y:驱动器坏了”。
由于 1 和 3,我们在迁移到 Microsoft 一年后仍在使用驱动器号。用户正在慢慢习惯 UNC 寻址,但我们的共享卷(一个巨大的单片卷)由于 SAN 上的大小原因需要拆分。我们想出了如何在集群中执行目录挂载卷,而不是强迫每个人都处理 UNC。
如果您有选择(例如很少有 Mac 用户),Microsoft DFS 可以使事情变得容易得多。创建一个驱动器号,顶级目录本质上是旧的驱动器号映射。在纯 Windows 环境中,这可以很好地工作。但是,任何使用 Samba 的东西都不能使用它。用户只有一个驱动器号,从 14 个驱动器号移动到一个带有“S:\K-Drive\”等路径的驱动器号非常容易。我们有很多 Mac 用户,所以不能走这条路。
我们在登录脚本中标准化的驱动器号(Novell 时代的另一个保留):
- P:= 单片共享卷
- S: = 学生课堂作业量(随着所有内容转移到 Blackboard,使用量逐渐减少)
- U:=主目录
- W:= 最终用户软件存储库
- X:= 某些网络安装的软件包,主要围绕我们的 ERP 系统
- Y:= 管理脚本和其他东西
我们还在 Windows Admin 组中运行驱动器号注册表。如果驱动器在登录脚本中被映射,则会记录是谁在做这件事。如果两个部门想要将 T: 驱动器映射到不同的地方,并且恰好有相同的员工,那么这可以省去很多麻烦。
我可以推荐的标准是:
- 将集中授权的驱动器号保持在最低限度。
- 在您的总体管理协调小组中操作驱动器号注册表
- 如果需要,请定期审核您的驱动器映射方法是否符合您的预期。
答案2
以我个人的拙见,如果您能摆脱“驱动器号”的概念……那就彻底忘掉它们吧。UNC 路径可以让您走得更远,而且不会遇到命名冲突。您可能还想将各种服务器名称和共享合并到一个(或几个)DFS 根目录中。这将提供一条 UNC 路径,以便为用户查找任何和所有相关共享……并提供设置复制、故障转移和可扩展性的选项。
答案3
将 C: 保留为系统卷。虽然我不敢相信这种情况仍然会发生,但当软件被硬编码安装到 C: 时,这种情况仍然会发生(那些开发人员应该被枪毙)。
将 C: 后面的几个空间(E:、F:、G:)保留给物理设备(CD/DVD、可移动媒体等)。
除此之外,我会尝试将事物与它们的起始点进行匹配(显然,随着驱动器映射数量的增加,成功率会有限)。
H: = 家庭驱动器
P: = 项目驱动器或个人驱动器
等...
答案4
我们主要使用 P: 驱动器作为用户的个人驱动器。S: 驱动器用于公司共享。这是我们使用的两个主要驱动器号。
由于您将使用 Active Directory,因此一个好的做法是使用组策略对象来决定谁将获得驱动器号,谁不会获得驱动器号。您可以设置登录脚本以根据安全组过滤器映射共享驱动器。
例如,您的结算部门需要访问 Q: 驱动器。您可以设置一个新的 GPO,其中包含用于映射 Q 驱动器的登录脚本,并将安全筛选器应用于 Billing_security_group,这样他们就是唯一可以访问 Q 驱动器的人。
有关安全组过滤的更多信息,请访问此处:http://technet.microsoft.com/en-us/library/cc781988(WS.10).aspx