6

We are working on migrating from Novell to Active Directory. During the transition, We are going to evaluate our drive mappings in light of current standards to see if what we have been doing still fits, is in alignment with best practices, simplify administration of the resources, etc. At present, we have 11 different drive mappings that are mapped. This seems, to me, to be a few too many and rather confusing for end users. These drive mappings also appear to relate to some older convention that existed in the organization that ended being something like the following:

  • K:\ - Mapping of physical CD-ROM drive of Novell server
  • N:\ - IT administrative scripts and utilities
  • S:\ - Another user's home folder, if needed
  • T:\ - dBase III mapping (this should hopefully disappear after the migration)
  • U:\ - Project or other group shares
  • V:\ - Project or other group shares
  • W:\ - Work (departmental or unit work share)
  • X:\ - Applications share
  • Y:\ - Home folder
  • Z:\ - System volume

This is a very confusing structure for users, both end users and IT, within our organization. I would like to ask for industry best practices and how others design their drive mappings. What are some things that one should be aware of and how do you compensate or control those items? What are things that should be considered from a management and maintenance perspective?

Our clients are going to be Windows XP, Windows Server 2003, Windows 7 Pro, and Windows Server 2008. Later on we would like to incorporate Linux and Macintosh OS X (10.6 or newer) clients into our drive mappings as well.

Any help, ideas, resources, or links that you can provide would be greatly appreciated.

squillman
  • 37,618
  • 10
  • 90
  • 145
John
  • 2,266
  • 6
  • 44
  • 60

7 Answers7

5

In my own humble-opinion, if you can get past the concept of "drive-letters"... forget them altogether. UNC paths can take you a lot further, and you won't run into naming collisions. You may also want to consolidate your various server names & shares into a single (or a few) DFS roots. That will provide a single UNC path to turn to in order to find any & all relevant shares for the users... and provide options to setup replication, fail-over, and scalability.

TheCompWiz
  • 7,349
  • 16
  • 23
  • 2
    This is a great point about UNC paths, but I invariably run into massive training issues getting non-technical people to use them. Even in my own dept where we're a mix of techs and technical business analysts it is a stumbling block. – squillman Apr 13 '11 at 15:10
  • This is a great idea actually. not one I'd considered in previous projects. Perhaps have a mapped 'User' drive (U:\ ?), and when further drive access is needed simply have helpdesk drop a preconfigured shortcut to \\SERVER\ShareRequired$\ in the U: drive. Therefore a new 'Project' drive, often a short lived requirement, can simply be dropped in, called something useful, and easily managed. Also works nicely where you have permission issues for secondary access within secured folders. +1 for the tip. – Patrick Apr 13 '11 at 15:19
  • Using DFS, would one want to make the folder hierarchy more flat and wide or does depth of levels matter? – John Apr 13 '11 at 15:19
  • In my experience... it doesn't matter too much. Obviously, the deeper you go, the more trouble users have finding stuff. On slow links, there might be issues with lookups & such, but I wouldn't expect it to be too much. – TheCompWiz Apr 13 '11 at 15:31
  • @Patrick - that is a good idea that I had not thought of. It would definitely make adding all of those one-off drive letter mappings for special groups, committees, and projects easier to manage. I wonder what the permissions implications would be and how tough it would be to manage? – John Apr 13 '11 at 15:31
  • @John I put a new file server in place for a client. they were all very happy about having a folder per dept (\Finance, \Operations etc) until we needed to provide access to (for example) \Finance\Revenue\BACS\ to someone who wasn't in Finance. At which point we went down the route of new ACL's providing 'list only' to the parent folders. Its become a management nightmare. Just being able to drag a link to the direct location and saying to the user "its in your folder with all the others" would have made things loads better. It would have made managing the permissions infinitely easier. – Patrick Apr 13 '11 at 15:48
  • @Patrick - I hate to be the security nazi here... but simply obscuring the shares from the users provides no security at all. ACLs should ALWAYS be set properly. For a *common* folder, it would be easier better to create a new share that would be common between the two. Or, create a new folder higher-up in the tree and assign permissions appropriately to allow access to that folder alone. – TheCompWiz Apr 13 '11 at 15:54
  • @TheCompWiz Yes. Agree completely. I would be applying ACL's. Continuing from my example above I would set a group to Read/Write on \Finance\Revenue\BACS\ and give the non-finance users membership, allowing them to connect directly to the folder in question via UNC rather than traversing the parent folders, meaning we wouldn't have to apply that group to the parents. Don't hate to be a security nazi. I'm the same. Its why I put the new file server in anyway (previously 550 users, one folder called \Anybody that everyone had Full Control over. You can imagine the state it was in) – Patrick Apr 13 '11 at 16:03
  • @Patrick I'm still battling our own 450-user "Public" folder behemoth. Sitting at an uncomfortable 900gig+ right now and slowly shrinking. (gotta love that previous guy) – TheCompWiz Apr 13 '11 at 16:12
4

Keep C: as the system volume. As much as I can't believe it still happens, it does still happen where software is hardcoded to install to C: (those devs should be shot).

Keep the next few after C: (E:, F:, G:) reserved for physical devices (CD/DVD, removable media, etc).

Beyond that, I try and match things with what they start with (obviously with limited degrees of success as the number of drive mappings increases).

H: = Home drive
P: = Project drive or Personal Drive
etc...

squillman
  • 37,618
  • 10
  • 90
  • 145
  • +1 Came here to write this. I'm not aware of an industry standard except for A: B: C: and perhaps D:. The rest, I've basically tried to align with their function. In all the places I've worked, that had shares implemented, H was universally the HOMEDRIVE. – GregD Apr 13 '11 at 15:08
3

We faced this exact question for the exact same reason a year and a half ago. The main problems are threefold:

  1. Novell networks are historically drive-letter based. Everyone knows that the U: drive is for their user's home directory and S: is for Shared. And so on.
  2. Microsoft networks are much less attached to drive-letters and Microsoft has been pushing UNC style addressing since the advent of Active Directory. Long-established Microsoft houses tend to use whatever is at hand for drive letters, with a few standard ones for old apps that require a drive-letter.
  3. Users haaaaaaate changing established procedures. They simply will NOT throw drive-letters over the side in favor of UNCs, and will continue to call the helpdesk with "The Y: drive is down."

Because of 1 and 3, we were still using drive letters a year after our Microsoft migration. Users are slooowly getting used to UNC addressing for a few things, but our Shared volume, a massive, monolithic volume, needed to be split up due to size reasons on the SAN. Rather than force everyone to deal with UNCs, we figured out how to do directory-mounted volumes in a cluster.

If you have the option (such as very few Mac users) Microsoft DFS can make things a lot easier here. Create a single drive-letter, with the top-level directories being, in essence, the old drive-letter mapping. In a pure Windows environment this can work well. Anything that uses Samba, though, can't use it. Users just have a single drive letter, and the move from 14 drive-letters to a single one with paths like "S:\K-Drive\" is dead easy. We have a lot of Mac users, so couldn't go this route.

The drive-letters we have standardized in our login-script (another hold-over from the Novell days):

  • P: = The monolithic Shared volume
  • S: = Student classwork volume (usage slowly decreasing as everything moves to Blackboard)
  • U: = Home directory
  • W: = End-user software repository
  • X: = Certain network-installed software packages, mainly focused around our ERP system
  • Y: = Admin scripts and things

We also operated a drive-letter registry in our Windows Admin group. If a drive gets mapped in a login script, it gets documented who is doing it. This saves a lot of grief if two departments want to map a T: drive to different places, and happen to share staff.

The standards I can recommend are:

  • Keep centrally mandated drive letters to a minimum.
  • Operate a drive-letter registry in your overall Admin coordination group
  • If needed, periodically audit your drive-mapping methods against what you expect them to be.
sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
2

I use N: for NETWORK. It gets mapped to a DFS hierarchiy that spans multipel servers in a transparent folder structure for users.

I use other letters as appropriate on servers (X: = dataa, S=Sql, T= Temp, L=logs - note this is for servers, so TEMP is the dricve for the temp databases).

Users normally always only ever see the one tree. There are two others for techncial reasons (not mapped).

TomTom
  • 50,857
  • 7
  • 52
  • 134
1

We mainly use the P: drive for the user's Personal drive. And an S: drive for company share. Those are the two main drive letters we use.

One good practice since you'll be using Active Directory is to use Group Policy Objects to decide who will get a drive letter and who won't. You can set login scripts to map a shared drive based on a security group filter.

For instance, you have a billing department that needs access to a Q: drive. You would setup a new GPO that would have the login script to map the Q drive, and have security filter apply to the Billing_security_group, so they will be the only ones that get the Q drive.

More information about security group filtering here: http://technet.microsoft.com/en-us/library/cc781988(WS.10).aspx

Nixphoe
  • 4,524
  • 7
  • 32
  • 51
  • Do you see any problems with reusing certain drive letters for different departments/functional areas within an organization? For example, we assign drive letter M to the Personnel Management team as a secured area for them and then reuse drive letter M for the facilities management team's secured area. – John Apr 13 '11 at 15:14
  • @John: That will only lead to continued confusion. What happens when someone in the Personnel Management department tells someone in the Facilities Management department that the document they're looking for is on the M: drive? It's also going to lead to continued administrative overhead by having to manage multiple logon scripts, needlessly complex logon scripts, or multiple GPO preference settings based on user, department, etc. KIS should be your first mandate. – joeqwerty Apr 13 '11 at 15:21
0

See my comment on squillmans post.

In one environment that I support:

  • H: Homedrive
  • G: Common Drive (broken up into folders for each division)
  • I: IT drive

etc.etc.

I would also add that you probably want to implement Access Based Enumeration when you move to Windows. Novell handles this natively, but this will not let users see any files or folders they don't have access to.

GregD
  • 8,713
  • 1
  • 23
  • 35
  • Are there any concerns or things that we should be aware of when using Access Based Enumeration on Windows? I have a vague memory of someone telling me that it does not work quite like it does on Novell and that it is a challenge to manage correctly. Thanks for the ideas. – John Apr 13 '11 at 15:16
  • I don't find ABE any more challenging to manage but there is some user education required as users may/will get confused when userA in Finance can't see the same things that userB in HR can see. – joeqwerty Apr 13 '11 at 15:24
  • 1
    @John - from my recollection, you "just turn it on"(tm). There is no management of it. It's either on/off. I've had no concerns with it and it's never been an issue. Keep in mind that it's not a substitute for proper permissions.. – GregD Apr 13 '11 at 15:25
  • Does ABE work well with DFS like some of the other posters are suggesting to be used? I am worried about trying to sort through permissions, troubleshooting, auditing to make sure that the user is seeing what they should be seeing and nothing more, etc. – John Apr 13 '11 at 15:25
  • @joeqwerty - The assumption is that his users are moving from Novell, so it's an environment which they're already used to seeing what you describe. Novell has had ABE since before Windows. – GregD Apr 13 '11 at 15:26
  • 1
    @John, we don't use DFS. Having said that, ABE is just an enhancement to proper permissions. Always, always, always, plan for proper permissions. ABE will enhance that. – GregD Apr 13 '11 at 15:27
  • @GregD: True enough. – joeqwerty Apr 13 '11 at 15:28
0

Don't map a user-specific directory. Redirect their "My Documents" folder to a network share using a GPO.

Then ask some business questions to the company. How to people work, what kind of information do they deal with on a shared/group level. Pick a couple of the big ones (departments, clients, projects) and map drives to the top level of each of those directories.

Shawn Barrick
  • 1
  • 2