eugene81
asked on
Help me determine the best way give multi-site users mappings to all of their shares
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.
- 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.
remmett70
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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!
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!
ASKER
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.
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.
ASKER
Didn't exactly point out the solution, but planted the seed for me to figure it out. Thanks.