Mapping shares based on group membership?

[Jon K]

Hey all,

Currently we're mapping drive letters either locally (annoying) or by a logon script which is cumbersome. Is there an easy and convenient way to map drive letters based on what groups a member might be associtaed with? For instance if a user is a member of "Production" they get a drive mapping to a share, and if I add them to "Operations" group they inherit another share? This is within a Windows 2003 Server environment.

Thanks all.

Jon

Edited December 6, 2007 by Jon K

[cluberti]

Have you looked at this?

[beats]

Security Groups and GPO's are your friend. And this little tool:

http://www.microsoft.com/downloads/details...;displaylang=en

That said. I would rather define Login Scripts at the OU level.

[nmX.Memnoch]

KiXtart has been doing this in logon scripts for years.

If InGroup("Production")
   Use X: "\\server\share"
EndIf

See this thread for my KiXtart logon script example.

Edited December 6, 2007 by nmX.Memnoch

[fizban2]

how many shares are you talking about? if htere is a large amount, you may want to look into creating an XML doc with the shares in it as nodes and have a vb script compare groups to the shares to see if htey match and map them from there

[nmX.Memnoch]

Why do all the extra work? If you're mapping multiple groups to multiple shares there are several ways to handle it with a quick script (be it KiX or VB) that don't require creating yet another file that would have to be modified if group membership changes. Here are a couple of KiX examples:

Example 1:

Select
   Case InGroup("Production")
	  Use P: "\\SERVER\Production"
   Case InGroup("Testing")
	  Use P: "\\SERVER\Production"
	  Use T: "\\SERVER\Testing"
   Case InGroup("Development")
	  Use P: "\\SERVER\Production"
	  Use T: "\\SERVER\Testing"
	  Use X: "\\SERVER\Development"
EndSelect

Example 2:

If InGroup("Production") Or InGroup("Testing") Or InGroup"(Development")
   Use P: "\\SERVER\Production"
EndIf

If InGroup("Testing") Or InGroup("Development")
   Use T: "\\SERVER\Testing"
EndIf

If InGroup("Development")
   Use X: "\\SERVER\Development"
EndIf

The difference being that with the "Select...EndSelect" the code section stops processing on the first true "Case". So for example if the user is in the "Production" group then it'll process that part of the Select...EndSelect statement without processing the "Testing" or "Development" sections. This results in code that runs a bit faster, especially if you order the groups logically (which does need to be thought out in the event there's say a user in both the "Development" and "Production" groups).

My main logon script is ~1330 lines of code, and calls another script that's ~350 lines of code. The script maps drives, checks AV version and definitions, sets Office user values, configures settings and checks other application versions. It all runs in under a second.

Edited December 10, 2007 by nmX.Memnoch

[eyeball]

thats really interesting stuff nmx, so do u prefer kixtart over any other script to be run at logon? if so why? ease of use? or just familiarity with that language?

thanks

[nmX.Memnoch]

Yeah, I prefer it because I'm familiar with it (I've been using it for some 8 years or so now). One of the main reasons I prefer it though is that it's very well documented, easy to learn and once you get the basics down you can do some pretty advanced stuff with it.

There's also a wealth of information (1, 2, 3) and a ton of User Defined Functions (UDFs) the other people have already made that can be used in your scripts. Full COM object support makes it really easy to do some of the more advanced stuff. If you want a good example of what can be done see the thread I linked above. I included a cleaned up version of my logon script in that thread.

The editor I use is AdminScriptEditor 3.x. Originally it was KiXScript Editor and was (as the name would imply) only for KiX scripts. But they extended it to support VBS, AutoIt, PowerShell, Batch/CMD files, HyperText Applications and the last update added syntax highlighting for ADM templates (find that in another script editor!). The last update also added a script formatter (hit Enter at the end of your line and it reformats the line to "recognized coding standards"). The script formatter is a little buggy right now but it was a first release. Guaranteed they'll have it right in the next release or two. I highly recommmend downloading the demo to check it out (the current demo is a version or two back, but it has all of the important features).

[fizban2]

Why do all the extra work? If you're mapping multiple groups to multiple shares there are several ways to handle it with a quick script (be it KiX or VB) that don't require creating yet another file that would have to be modified if group membership changes. Here are a couple of KiX examples:

but what happens when you have ~400 shares to manage? that is why we have the xml file, the vb script pulls the users group membership and compares it to the xml file each share is noted by a corrisponding node in the xml file

<SSQA0000>
	 <DriveLetter>O:=\\Server\Share</DriveLetter>
	 <Printer/>
</SSQA0000>

when a share is created an entry is created in the XML file, from there all we worry about it adding the user to the proper group and all gets mapped.

just another solution to the problem

[nmX.Memnoch]

but what happens when you have ~400 shares to manage? that is why we have the xml file, the vb script pulls the users group membership and compares it to the xml file each share is noted by a corrisponding node in the xml file

It's still solvable by using a single script (be it KiX, VB or whatever your chosen language). Yes, your solution works just fine...all you're doing is pulling the same data from an XML file. I prefer not to use more files than I have to though. Calling that other file means that the originating script has to call another process to open another file...adding run time to the logon script. The less files you call, the quicker it runs.

And trust me...we have that many or more shares here. Not at my level, but at this location as a whole. There are somewhere between 10-15K users at this single location. Every single one of them uses the same logon script, and in some cases (such as mine) a seperate script is called for their organization. I would much rather it be a single one, but that's not a call I get to make.

My script currently calls one other script, but that's about to get merged into the main script (if I add major functionality to my script I begin by using a seperate file and then merge it into the main one once all the bugs are ironed out).

As has been proven in this thread alone, there are multiple ways to do the same thing...it's just a matter of what you're most comfortable with and what works best for a given situation. ;D