网络驱动器号分配最佳实践

Modified on: Wed, 12 Jun 2019 18:00:02 +0800

我们正在努力从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:用于共享。等等。
  2. Microsoft网络对驱动器号的依赖性较小,自从Active Directory问世以来,Microsoft一直在推动UNC样式寻址。历史悠久的微软公司倾向于使用随身携带的驱动器号码,对于需要驱动器号的旧应用程序使用一些标准的。
  3. 用户haaaaaaate改变已建立的程序。他们根本不会在侧面投掷驱动器号码以支持UNC,并将继续拨打帮助台“Y:驱动器停机”。
  4. 醇>

    由于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管理员组中运行了一个驱动器号注册表。如果驱动器在登录脚本中映射,则会记录谁正在执行此操作。如果两个部门想要将T:驱动器映射到不同的地方,并碰巧共享员工,这可以节省很多麻烦。

我可以推荐的标准是:

  • 将中央授权的驱动器号保持在最低限度。
  • 在整个管理员协调小组中操作驱动器号注册表
  • 如果需要,请定期根据您的预期审核您的驱动器映射方法。
作者:sysadmin1138

相关问答

添加新评论