Help me determine the best way give multi-site users mappings to all of their shares

eugene81
eugene81 used Ask the Experts™
on
I work in a multi-site environment where each location has its own OU and subcontainers and unique login script linked to that location.  I have some users who will be working at 2 places and therefore need shares mapped from multiple places.  At this point I have just inserted an entry into both login scripts (kixtart) that says if they're a member of some group (which is unique to the other site) then map some share.  That works fine, but I don't want have to manage 2 identical login script entries in 2 different places.  For example:

- Site A, Site B
- Users 1, 2, and 3 work at Site A but have been assigned duties at Site B.
- Users 4, 5, and 6 work at Site B and share responsibilities with 1, 2, and 3.

So I created a security group "SPECIAL GROUP", adding users 1-6, and added the following to both scripts:

    If InGroup ( "SPECIAL GROUP" )
      use L: "\\ServerB\ShareB"
    Endif

Of course this is standard for the Site B login script, but the Site A script is full of "\\ServerA\ShareA" entries with this one exception.

This kind of situation is arising more and more as budgets are slashed and broader duties are assigned.
 
I was thinking of linking Site B's login script GPO to Site A's OU and vice versa so that users at both sites process both login scripts, but I'm concerned about the increased load on the DCs, especially at Site A, which is very large and processes a lot of logons.  Honestly I'm sure the DCs can handle it fine but I'd like to find a more elegant solution, and I'm not sure what the ramifications on the network side of things would be (our LAN at Site A is not exactly "zippy" as it is).

Are there any other alternatives?  I believe the other admins here have traditionally mapped cross-site shares with local batch files in these cases, which is a terrible idea IMO.

I have seen the InContainer() Kixtart UDF, which would work if it worked against child OUs of the specified container, but it does not and I'd rather avoid having to become a Kixtart guru and customize my own UDF to accomplish this task.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
remmett70Network Manager

Commented:
Is there anything in the naming of the computers that could identify the location of the computers.  Like a state or city identifier that could be used to key the scripts to map the different drives for that special user group?

Besides using OUsyou could use security groups and use ifmember from the resource kit.

http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_2003_Active_Directory/Q_22746869.html

Mark

Author

Commented:
It has occurred to me that OU location would be worthless because if the user resides in a different OU then they wouldn't be calling that script anyway.  

markpalinux, I think you're right in that groups is that way to go.  Example:

SiteAscript.kix:
    If InGroup ( "SiteA-Site B Users" )
          call "SiteBscript.kix"
        Endif

SiteBscript.kix:
    If InGroup ( "SiteA-Site B Users" )
          call "SiteAscript.kix"
        Endif

I think this is efficient as it will get but will wait a couple days for any better ideas before awarding pts.  Thanks!

Author

Commented:
To take this a step further, I think the most efficient way to handle login scripts in general would be to have each site posses a general users group, e.g. "Site A Users", "Site B Users", "Site C Users", etc. and have a single GPO login script apply to the entire domain:

DomainLoginScript.kix:

    If InGroup ( "Site A Users" )
              call "SiteAscript.kix"
            Endif

    If InGroup ( "Site B Users" )
              call "SiteBscript.kix"
            Endif

    If InGroup ( "Site C Users" )
              call "SiteCscript.kix"
            Endif
    ...

If a user works at both Site A and Site B, simply add them to both groups.  Of course there are thousands of existing users who need to be added to their respective groups, but that's nothing that can't be fixed with a simple ADSI script.

We should probably have these groups anyway to help with any site-wide policies/settings.

Author

Commented:
Didn't exactly point out the solution, but planted the seed for me to figure it out.  Thanks.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial