• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 199
  • Last Modified:

Best Pratice for deploying fileshares to users

I'm in the process of trying to cleanup our existing file share system.

We currently host our shares (50+) on server 2003 and deploy shares to users using windows NT style login scripts. With each assigned to users individually in Active Directory.

AS you can imagine, this is become quite problematic as the number of fileshares keeps increasing, a number of users need access to files from different departments and drive letter mappings are overlapping frequently causing alot of unnecessary confusion for the users and making an administrative nightmare for IT.

I am also aware of a number of issues in server 2008, Vista and 7 that prevents drives mapped in this manner from displaying correctly in applications and would like to avoid hacking registry settings to make it work.

I've used some technologies like Access-based enumeration, and deploying scripts via AD before but never to this extent. I also completely new to the new options available in server 2008.

If I were willing to start fresh with how we deploy fileshares, what would be the best practice in a server 2008 domain?

What options do I have for deploying shares? what works best?

How would I setup an individual to have access to multiple departments shares simultaneously?

Is there a way to still provide specific drive letters to some users and they are quite dependent on them?
2 Solutions
You can use Group Policy Preferences to map network drives. (XP machines needs a client side extension installed)


The easiest way may be to define what groups need access to which network drives.
Hypercat (Deb)Commented:
Group policy preferences, as mentioned in the previous post, are pretty much the only option other than scripts to create drive mappings across a large group of users.  I have also used a rather complex login script that creates drive mappings depending upon group membership. These options can both be deployed through group policies to streamline the management of which users get which drive assignments. I don't know what exactly you mean by saying that your login scripts are "assigned to users individually in Active Directory," but if you're referring to an individual login script assigned on the Profiles tab in the user's AD properties, then that is certainly very clumsly. Login scripts can be deployed to groups of users through group policy (Windows Settings/Scripts/Login in the User Configuration section of the policy).  If you're not already doing that, it might be a place to start.

The crux is that you want to be able to create groups that encompasses the users who need access to the same resources and then create your preferences or scripts or whatever based on those groups.  In your case it sounds as though your groups would most likely correspond to departments, but not necessarily.  You might want to look at your situation from a totally different point of view. For example, try creating a spreadsheet of your shared resources and then map out which users have access to which resources. You might find some common groups there that spread across departments and would make your management of the resources easier.

Another approach, which might be more complicated in the short run but might yield some useful results, would be to take a look at the resources being shared and see if you can consolidate them in various ways. For example, do you have files on several different servers that are all shared out to the same group of users? If so, perhaps you could consolidate the shared file resources on the same hardware resources so that they could be shared out as a single share (mapped drive) instead of multiple shares with different mapped drives assigned to each.

The objective of all this would be, of course, that you could get to the point where, when a new user is set up, or an existing user needs access to a different set of resources, all you have to do is manage the group membership of that particular user to ensure that he/she gets access to all resources that are needed.

These are just some ideas - if anything strikes you post back with any additional questions.
PerimeterITAuthor Commented:
"an individual login script assigned on the Profiles tab in the user's AD properties"
That's exactly it

Pushing out the drive mappings via group policy sounds like a good solution for us. Users are already mapped to groups based on department for access to there folders so using the same groups to define what drive mappings they get would be straight forward.

The only catch would be how to get a user to see multiple departments? Say an executive that is responsible for multiple departments.
The department drive is defined as a specific letter 'H', since you can't have multiple 'H' drives how do you reconfigure without having multiple different letters for each drive?

I would rather avoid having multiple letters if possible so as to not confuse the users by changing around drive letters on them. That and we have a number of internal documents etc that have links dependent on the current file structure (oh the headache!)
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

I don't think you can escape the use of multiple letters (in particular if you use the letter as a reference in document).

While you've potentially got the opportunity to start fresh, look at consolidating some of those shares. ABE works brilliantly and would be well worth implementing. If you haven't already got it turned on, enable VSS on your server share partitions/LUNs so that when users accidentally delete or modify files you can quickly and easily restore them without having to search for the backup tape.

The way our HO file service is currently structured is we have our main S: drive and below that are the various departments which the users only see if they have access i.e. ABE. Occaisonally there are users who require access to multiple departments and that means they either get added to the appropriate departments groups or sometimes we have to manually add the user to the specific sequence of directories they require access to.

Each branch also has an S: drive which is only visible at their own branch and not accessible by HO staff.

We have an N: drive which HO departments use when there are files that branches and HO need to share access to e.g. an Excel quote register that the branch sales reps update and the regional manager at HO generates reports from.

All users also have a H: drive for personal documents which their My Docs is redirected to.

I've recently deployed a site where there is no logon script. All registry changes, share and printer mapping and folder redirection is performed through GPO and it has made the site so much easier to maintain. I just need to put users in the correct groups and they see exactly what they need without me having to remember which logon scripts need to be updated or which printers need to be installed every time I add/rename a user.
Hypercat (Deb)Commented:
A possible alternative way to look at this is to treat the user's own department's documents share as their Home directory.  You're sort of doing this by mapping the same drive letter in each department.  You could set this drive up as the home directory on the Profiles tab in the user's properties for all users.  Then, you could create group policies based on membership in various "foreign" department user groups (i.e., users who are not in the department but need access to that department's documents). Then once you add membership in that department to the user, he/she would get those mapped drives. A user can be a member of any number of groups, so there wouldn't be restrictions except by the number of drive letters available for use. This would still require you to use different drive letters to map the drives for users who are outside the department but need access to the department's documents.  There's really no way around this if you're going to use mapped drives.  

As for links within documents, first of all natively within a lot of programs links will be created using FQDNs rather than drive letters, and you can train users to do this.  But again there's really no way around the problem if users create links using mapped drives specifically and then the user who opens the document has different mapped drives.  The only way to really solve this problem would be to change the basic structure of using the same drive letter in each department. If everyone throughout the organization used the "S" drive, for example, to get to the Service department's documents, it would make things much easier in the long run...

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now