Thanks, Joe.
I tend to agree regarding standard names, no random driver letters,
etc. (which you could probably already infer from my initial e-mail/post).
However, that doesn't really answer the question of what the process
should look like when, for example, creating a new PROJ-related share
and/or folder?
Example - a new, large project starts up, and a PM asks to allocate a
50GB share somewhere. How do you figure out where to put it? What if
there is no available server with adequate free space? How do you tell
that the project has wound down, and it's a good time to recover that disk
space for new work?
What happened in this scenario when you worked at that Fortune-5 where
you used to (still do?) work?
Cheers,
-- Idan
---------- Forwarded message ----------
Date: Fri, 18 Aug 2006 21:00:58 -0400
From: joe <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: RE: [ActiveDir] [OT] Process for requesting,
authorizing and creating shares?
Resent-Date: Sun, 20 Aug 2006 21:37:10 -0600 (MDT)
Resent-From: Idan <[EMAIL PROTECTED]>
Resent-To: Idan Shoham <[EMAIL PROTECTED]>
Resent-Subject: RE: [ActiveDir] [OT] Process for requesting, authorizing
and
creating shares?
In general I think it is better for larger orgs to have a very locked down
strong share policy. Even down to specifying specific standard share
names,
permissions (like auth users FC and then locking with NTFS unless there
will
be no change access then R). For instance names like APPS, PROJ, DATA,
BINS,
etc. One large multinational you are familiar with has shares for users as
username$, then shared file served applications or application
installation
packages are located in APPS, and all group shared data goes into a share
called PROJ and permissioning is handled at the folder level. The software
delivery system uses another hidden share but it is a single name across
the
entire enterprise. The only thing that varies are the servers. This makes
life easier for the users and the administrators. People aren't browsing
to
find things and/or trying to recall what the sharename was... I like
having
as few shares as possible because I have seen too many cases of alphabet
soup with connected drive letters where users get to the point that they
only know what drive letters they had, not what they were connected to. I
recall in a job back in the mid-90's where any given user of about 2000 at
the local site was connected to about 10-12 shares but what shares they
were
connected to depended on what part of the building they were in and what
department they were in. We had to carry around a pocket guide to the
areas
so when someone said I need my I: drive back you knew exactly what share
to
connect for them.
If someone would rather have an ad hoc system, I would say follow any
normal
provisioning process with workflow. I wouldn't want to have to come in and
clean that up in 5 years though once someone finally realizes how
ridiculous
it is because everyone is running out of drive letters to use.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 9:21 PM
To: [email protected]
Subject: [ActiveDir] Process for requesting, authorizing and creating
shares?
Hi folks,
Slightly off-topic here -- i.e,. related to managing Windows environments
generally, rather than just Active Directory.
I'm wondering whether any of you have seen good business processes for
managing share creation (and for that matter, deletion)?
We are working with a large multi-national where the current process by
which business users request new shares (i.e., network-attached, shared,
access-controlled disk space), and by which those requests are approved
and implemented, is pretty weak.
We are hoping to help them automate this process, but would obviously like
to lock it down first.
For example -- can any user request creation of a new share?
--> If not, who can/can't?
Should users specify a share name, server name and disk volume or should
these variables be calculated based on variables such as the user's
location and amount of disk space requested?
--> If you do let users choose, how would they know which server and
disk volume to pick?
--> If you automate server/share name/volume assignment, do you have
standards for things like new share names?
Do you typically apply quotas to new shares?
Do you typically over-subscribe disk? i.e., user A asks for 10GB, user B
asks for 20GB, you create 2 shares on a 25GB disk volume on the theory --
like the airlines use -- that actual usage will be less than reserved
usage.
How should a file server be assigned?
--> What happens if there is not already a server with adequate
disk space?
--> How does the server-selection process escalate to requisitioning
physical hardware?
Once a server and disk volume have been assigned, should someone (e.g.,
like a server owner or disk space owner) approve the request before it
is authorized?
--> If so, how do you assign owners/authorizers to servers?
Should requests include timeouts and renewals, such that un-renewed
requests
are auto-terminated (share deleted)?
--> If so, do you give users advance warning and an opportunity to
renew?
How do you handle cases where shares get full?
--> Can users ask for more space?
--> Do you have system monitoring software alert someone that
a given disk volume is getting full?
Do you normally setup shares as visible to all users, and manage ACLs
on NTFS, or do you also apply ACLs to the shares directly?
Do you generally ask users to define ACLs using existing AD groups, or
require the creation of new AD groups?
--> What scope of groups do you typically use in ACLs?
(Universal, domain global, domain local, or even server local?)
Does NAS change any of the above?
Is there anything else I should ask about? :-)
I hope to assemble some best practices from your responses, and set our
customer off in the right direction from the start.
Since this is a rather lengthy inquiry, and the results might be valuable
to everyone, I promise to summarize any and all good advice and post
back to this list in a single, legible e-mail.
Thanks!
--
Idan Shoham
Chief Technology Officer
M-Tech Information Technology, Inc.
[EMAIL PROTECTED]
http://mtechIT.com
****************************************************************************
For more information on M-Tech's Regulatory Compliance Solution visit:
http://mtechIT.com/compliance/
****************************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken or
omitted to be taken in reliance on it, is prohibited and may be
unlawful.
****************************************************************************
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
