Re: Designing file server file/folder structure.

["Kurt Buff" <kurt.buff () gmail com>]

On Mon, Oct 6, 2008 at 1:34 PM, Nick Vaernhoej
<nick.vaernhoej () capitalcardservices com> wrote:
> Hi,
>
> I have a request for ideas about how to design the folder structure on a
> Win2K3/NTFS share.
> What we have inherited is a  D:\ drive with a number of folders named
> according to departments, each folder is then mapped to a drive letter
> in a logon script.
> Each department has access to their own drive in addition to a drive
> everyone has access to.

<snip>

The model I use at $work is to have a single partition, as you do,
with a single directory on it called something like Groups, or
Departments, and share that out. Share permissions list Domain Users
with Full Control - it's easier to manage things with NTFS permissions
than with Share permissions, so it's not worth trying to manage the
Share permissions - simply open them up as much as reasonable.

I set NTFS permissions so that Domain Users have transit rights on
that top-level directory underneath the Share, and administrators of
the file server have Full Control. Each second-level directory is
named for the department, and again Domain Users get transit rights,
but I apply permissions for two distinct groups - members of the
Department, and Managers of the department. I have a Read-Only
README.TXT file at the root of each Departmental Directory, with the
following explanation of how permissions work in the Department's
directory:

         DIRECTIONS FOR USING THIS DEPARTMENTAL DIRECTORY:

          1) Only new directories can be created at the first level of
this directory - not new files - and those can only be created by
MYCOMPANY\_usGroupsDummyManagers or by IT.

          2) If a new top-level directory is created, initial
permissions on it will only be for MYCOMPANY\_usGroupsDummyManagers -
any further permissions will need to be added by IT.

          3) Permissions will only be placed on first-level
directories underneath the Department's directory. If permissions need
to be modified further down the directory tree, the subdirectory in
question should be moved to another top-level folder.

Permissions are applied and maintained with one of my favorite tools -
FILEACL.EXE. Google for it. Below is the syntax used. Note that Domain
Users have Read-Only rights to the Public directory, but none to the
Private directory, though they can see both.

FILEACL "k:\Groups" /S "MYCOMPANY\Domain Users":RX/U/U
FILEACL "k:\Groups\Dummy" /S "CREATOR OWNER":U/RWXD/RWXD /S
"MYCOMPANY\Domain Users":RX/U/U /S
"MYCOMPANY\_usHomeGroupsDummyManagers":RAWaWeXDc/U
FILEACL "k:\Groups\Dummy\Private" /S
"MYCOMPANY\_usHomeGroupsDummyUsers":RWXD /S
"MYCOMPANY\_usHomeGroupsDummyManagers":RWXD
FILEACL "k:\Groups\Dummy\Public" /S
"MYCOMPANY\_usHomeGroupsDummyUsers":RWXD /S
"MYCOMPANY\_usHomeGroupsDummyManagers":RWXD /S "MYCOMPANY\Domain
Users":RX


As a matter of policy and procedure, I keep NTFS permissions
inheritance, and that at the root of the partition only SYSTEM and the
local file server ADMINISTRATORS group are granted any permissions -
Full Control. Thus, I don't need to specify them ever again.

Kurt