networking驱动器盘符分配的最佳做法

我们正在从Novell迁移到Active Directory。 在过渡期间,我们将根据当前的标准来评估我们的驱动器映射,以确定我们所做的工作是否符合最佳实践,简化资源pipe理等。目前,我们有11个不同的映射的驱动器映射。 对我来说,对于最终用户来说,这似乎是太多而相当混乱了。 这些驱动映射也似乎涉及组织中存在的一些旧的约定,如下所示:

  • K:\ – Novell服务器的物理CD-ROM驱动器的映射
  • N:\ ITpipe理脚本和实用程序
  • S:\ – 如果需要,另一个用户的主文件夹
  • T:\ – dBase III映射(迁移后希望这个消失)
  • U:\ – 项目或其他组份额
  • V:\ – 项目或其他组的股份
  • W:\ – 工作(部门或单位工作份额)
  • X:\ – 应用程序共享
  • Y:\ – 主文件夹
  • Z:\ – 系统音量

对于我们组织内的用户,最终用户和IT来说,这是一个非常混乱的结构。 我想询问行业最佳实践以及其他人如何devise驱动器映射。 你应该注意哪些事情,以及如何补偿或控制这些项目? 从pipe理和维护的angular度来看,应该考虑什么?

我们的客户将会是Windows XP,Windows Server 2003,Windows 7 Pro和Windows Server 2008.稍后,我们希望将Linux和Macintosh OS X(10.6或更新版本)客户端也纳入我们的驱动器映射中。

任何帮助,想法,资源,或您可以提供的链接将不胜感激。

我们在一年半前面对这个确切的问题。 主要的问题有三个:

  1. Novellnetworking历史上是基于驱动器盘符的。 每个人都知道,U:驱动器是用户的主目录,S:是共享的。 等等。
  2. Microsoftnetworking与驱动器盘符的联系要less得多,自从Active Directory出现以来,微软一直在推动UNC风格的寻址。 老牌的微软公司倾向于使用驱动器盘符,而对于需要驱动器盘符的旧应用程序则使用一些标准的盘符。
  3. 用户必须改变已build立的程序。 他们根本不会把联合国的驱动器信件放在一边,而且会继续用“Y:驱动器已经closures”的方式呼叫服务台。

由于1和3,我们在Microsoft迁移一年后仍然使用驱动器盘符。 用户们正在慢慢地习惯于UNC寻址,但是由于SAN上的大小原因,我们的共享卷(一个巨大的单片卷)需要被分割。 我们没有强迫每个人都与UNC打交道,而是想出了如何在集群中执行目录加载的卷。

如果您有select(例如极less数Mac用户),Microsoft DFS可以使事情变得更容易。 创build一个驱动器盘符,顶层目录本质上是旧的盘符映射。 在纯粹的Windows环境中,这可以很好地工作。 但是,任何使用Samba的东西都不能使用它。 用户只有一个驱动器号,从14个驱动器号到具有像“S:\ K-Drive \”这样的path的单个驱动器号非常容易。 我们有很多的Mac用户,所以不能走这条路。

我们已经在我们的login脚本中标准化的驱动器字母(Novell日子的另一个暂停):

  • P:=单片共享卷
  • S:=学生作业量(随着一切进入黑板,使用量逐渐减less)
  • U:=主目录
  • W:=最终用户软件存储库
  • X:=某些networking安装的软件包,主要集中在我们的ERP系统上
  • Y:=pipe理脚本和东西

我们还在Windowspipe理员组中运行了驱动器号registry。 如果驱动器被映射到login脚本中,则会logging正在执行的操作。 如果两个部门想要将T:驱动器映射到不同的地方,并且碰巧共享员工,这就节省了很多的痛苦。

我可以推荐的标准是:

  • 将集中授权的驱动器号保持在最低限度。
  • 在整个pipe理协调组中运行驱动器号registry
  • 如果需要,定期审核您的驱动器映射方法与您所期望的相反。

以我自己的卑微观点来看,如果你能够超越“驱车信”的概念,那就完全忘了它们。 UNCpath可以带你进一步,你不会碰到命名冲突。 您可能还想要将各种服务器名称和共享合并到一个(或几个)DFS根目录中。 这将提供一个单一的UNCpath,以便为用户查找任何和所有相关的共享…并提供选项来设置复制,故障转移和可伸缩性。

保持C:作为系统音量。 尽pipe我不能相信它仍然会发生,但是在软件被硬编码安装到C的时候,它仍然会发生(这些开发者应该被发现)。

保留C:(E:,F:,G :)后面的几个物理设备(CD / DVD,可移动媒体等)。

除此之外,我尝试将事情与开始的事情匹配起来(显然随着驱动器映射数量的增加,成功程度有限)。

H:=主驱动器
P:=项目驱动器或个人驱动器
等等…

我使用N:NETWORK。 它被映射到一个DFS分层,跨越了透明文件夹结构中的multipel服务器,供用户使用。

我在服务器上使用其他字母(X:= dataa,S = Sql,T = Temp,L = logs – 注意这是针对服务器的,所以TEMP是临时数据库的dricve)。

用户通常只能看到一棵树。 由于技术原因还有两个(未映射)。

我们主要使用用户个人驱动器的P:驱动器。 和一个S:驱动公司共享。 这些是我们使用的两个主要驱动器盘符。

因为您将使用Active Directory,一个好的做法是使用组策略对象来决定谁将得到一个驱动器号,谁不会。 您可以设置login脚本来映射基于安全组filter的共享驱动器。

例如,您有一个需要访问Q:驱动器的计费部门。 您将设置一个新的GPO,该GPO具有映射Q驱动器的login脚本,并且具有适用于Billing_security_group的安全filter,因此他们将是唯一获得Q驱动器的GPO。

有关安全组过滤的更多信息: http : //technet.microsoft.com/en-us/library/cc781988(WS.10).aspx

看到我对squillmans post的评论。

在我支持的一个环境中:

  • H:Homedrive
  • G:普通驱动器(分为每个部门的文件夹)
  • 我:IT驱动

etc.etc。

我还想补充一点,当你移到Windows时,你可能想实现基于Access的枚举。 Novell原生处理,但这不会让用户看到他们无权访问的任何文件或文件夹。

不要映射用户特定的目录。 使用GPO将其“我的文档”文件夹redirect到networking共享。

然后向公司提出一些商业问题。 人们如何工作,他们在共享/组织级别处理什么样的信息。 select几个大的(部门,客户,项目)和映射驱动器到每个目录的顶层。