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.
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.
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...
We faced this exact question for the exact same reason a year and a half ago. The main problems are threefold:
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):
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:
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).
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
See my comment on squillmans post.
In one environment that I support:
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.
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.