I'm not using DFS for redundancy or replication but for the namespace, so my shares look like \\myorg.com\Public\Apps. The advantage for me is that I don't have to change update scripts or worry about server renames, I just update the DFS to point to the share(s) as needed. I find this particularly useful so that network installs of say Office don't break over time. Also, separating the server name from the share gives a more consistent naming approach to network resources.
"What would I name the RG’s? FWIW we have more than one server using the share name “Applications” (don’t ask…)." Okay.....I won't ask. Presumably there is some logic/reasoning behind this and you will have to identify a naming scheme that makes sense for your organization. Let's pretend for a moment that SERVER-1 is used by the Engineering group. Due to your current naming convention, you will have to do some work figuring out appropriate names. Server1 has a resource ( a share) named Applications currently shared as \\Server1\Applications Create the groups and assign permissions as shown. RG_ENG_Applications *Full control permissions* RG_ENG_ApplicationsRead *Read only permissions* RG_ENG_ApplicationsModify *Modify permissions* Where convenient mappings don't exist for adding groups to the above RG_ group, you can create another set of groups if needed: AG_ENG_Applications AG_ENG_ApplicationsRead Use these groups to add your one off type users such as an administrative assistant who is assisting the Engineering group, but you don't want to add for example all admin assistants. This methodology requires more upfront work, but saves work over the long haul. Using DFS namespace for shares also reduces maintenance over the long haul and may provide other benefits depending on your organizational needs. -Jeff Steward On Mon, Aug 30, 2010 at 12:59 PM, David Lum <[email protected]> wrote: > No DFS here – they use clusters and SANs to achieve their desired > redundancy. > > > > I’m trying to wrap around how I would apply this at %dayjob%. For example, > I have one server here that I have 14 security groups for example: > > SERVER1-Applications > > SERVER1-Applications-Planning > > SERVER1-Applications-Planning-2010 > > SERVER1-Applications-Planning-2010-Readonly > > SERVER1-Executive > > SERVER1-Shared > > SERVER1-Shared-Development > > Etc > > > > What would I name the RG’s? FWIW we have more than one server using the > share name “Applications” (don’t ask…). > > > > Dave > > > > *From:* Jeff Steward [mailto:[email protected]] > *Sent:* Monday, August 30, 2010 9:15 AM > > *To:* NT System Admin Issues > *Subject:* Re: Finding unused/dead groups? > > > > Link to discussion of AG/RG method: > http://technet.microsoft.com/en-us/library/cc740013(WS.10).aspx > > > > It may be helpful to preface your security group names with AG_ RG_ ACL_ > to differentiate between the group types. > > > > -Jeff Steward > > On Mon, Aug 30, 2010 at 12:06 PM, Andrew S. Baker <[email protected]> > wrote: > > +1 > > > *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> > *Exploiting Technology for Business Advantage...* > * * > > On Mon, Aug 30, 2010 at 11:56 AM, Ken Schaefer <[email protected]> > wrote: > > For scalability you should use an Authorisation Group -> Resource Group > strategy. > > Your AGs are based on teams or departments. Your RGs are assigned to the > ACLs for each resource. You put your AGs into your RGs. This makes > provisioning/deprovisioning simple. > > Your RGs probably shouldn't have the server name embedded. You use DFS-N > right? So, the RG can be based on the share name and the type of access. > > For really small environments your strategy can work, but it won't scale. > > Cheers > Ken > > > -----Original Message----- > From: David Lum [mailto:[email protected]] > > Sent: Monday, 30 August 2010 11:48 PM > To: NT System Admin Issues > > Subject: RE: Finding unused/dead groups? > > In no environment (of six that I manage) have I moved servers outright > where this would be an issue, replacement file servers (quite rare in fact) > inherit the same name and new servers get new groups. > > Having said that, you do bring up a good point to consider going forward. > Is it possible to script changing AD group names in bulk? If I had 20 group > names that started SERVER1_ change them to SERVER2_ ? > > If not server names, what do you use for an AD group name used to accessing > file shares? > > Dave > > -----Original Message----- > From: Ben Scott [mailto:[email protected]] > Sent: Wednesday, August 18, 2010 3:08 PM > To: NT System Admin Issues > Subject: Re: Finding unused/dead groups? > > On Wed, Aug 18, 2010 at 5:54 PM, David Lum <[email protected]> wrote: > > Not to mention our group name itself is in the form of > > <Server>_<Share>_<RWXD> > > I don't like that because it means if you move servers your group names > either change or become misleading. > > But we otherwise do something similar. Things like "QMS Doc Editors" and > "QMS Doc Readers". > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > --- > You are currently subscribed to ntsysadmin as: [email protected]. > To unsubscribe click here: > http://lyris.sunbelt-software.com/u?id=8067386.9ba9124c64785c7a6c24608e24352b78&n=T&l=ntsysadmin&o=9079487 > > (It may be necessary to cut and paste the above URL if the line is broken) > or send a blank email to > leave-9079487-8067386.9ba9124c64785c7a6c24608e24352...@lyris.sunbelt-software.com > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > --- > You are currently subscribed to ntsysadmin as: [email protected]. > To unsubscribe click here: > http://lyris.sunbelt-software.com/u?id=8250068.606d17937843617f86ab4441e27acc58&n=T&l=ntsysadmin&o=9079542 > > (It may be necessary to cut and paste the above URL if the line is broken) > or send a blank email to > leave-9079542-8250068.606d17937843617f86ab4441e27ac...@lyris.sunbelt-software.com > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- You are currently subscribed to ntsysadmin as: [email protected]. To unsubscribe click here: http://lyris.sunbelt-software.com/u?id=8142875.a9cf90b99baa17cb4fcf8293a59eb3b1&n=T&l=ntsysadmin&o=9079616 or send a blank email to leave-9079616-8142875.a9cf90b99baa17cb4fcf8293a59eb...@lyris.sunbelt-software.com
