Planning a Shared Folder Structure

Friday Nov 10th 2000 by Brien M. Posey

In a Windows network, mixing up the different the different techniques for sharing resources may be the way to make sure that users get access to information they need while being kept out of restricted areas.

When you're creating a new network or installing a new file or application server, it's easy to get confused about how to share the resources on the server. There are a couple of schools of thought on the subject. Some administrators like to share everything at the root level and allow NTFS permissions to control access to individual folders. Other administrators prefer to share each data directory or application folder individually. I prefer to use a mixture of these two techniques. In this article, I'll share my thoughts on the subject with you.

Sharing at the Root vs. Sharing Individually

Ideally, your goal is to make the appropriate resources available to the necessary people, while protecting the resources from those who shouldn't be allowed to have access. While both of the techniques that I described above work, they both have flaws when you consider them in terms of your goal.

The situation in which everything is shared individually has problems because each share point is a resource that the server must track. Having too many shares can consume large amounts of memory and processing power, thus slowing your server down. The other danger of having such an arrangement is that it's easy to accidentally overlap shares. For example, suppose that you had a directory called \DATA\A. Now, suppose that you gave the user full access to DATA and read only access to A by using share-level permissions. In such a situation the shares would overlap because A is a subdirectory of DATA. If the user tried to access the A directory through the A share, they would receive the appropriate read-only permissions. If they attempted to go in through the DATA share and drill down to the A directory, they would have full access because of the permissions assigned to the DATA share.

On the other extreme, only having a single share point for each volume and using NTFS to handle security isn't that bad of an idea. However, this approach may make it difficult to navigate to a desired location within the directory structure. Although this approach might work fine for you and for some users, it's not a bad idea to make things easy on the rest of the users by creating a few share points that they can use to directly access frequently used folders. With this approach, it's appropriate to use NTFS permissions instead of share permissions. Whenever I create a share point, I like to set the share permissions to allow everyone to have full access. I handle the security at the NTFS level.


Where to Create Shares

When it comes to creating shares, I usually create one share for each major directory tree or application. For example, suppose that you have a directory called USERS that contains a subdirectory for each user in the domain. I'd create a share point on the users directory so that any user can click on it and then go straight to their data directory. Likewise, if you had a directory that contained the setup files for Microsoft Office, it's not a bad idea to create a share point for that directory. That way, if a user needs to install an optional Microsoft Office component, there's no question about where that component is located. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved