Network Drive Letter Assignment Best Practices
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.
Solution 1:
We faced this exact question for the exact same reason a year and a half ago. The main problems are threefold:
- 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.
- 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.
- 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.
Solution 2:
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.