Hi,

 Originally Posted By: Allen
Curious... are you just checking group memberships?


well ... no, not only :-)

As stated in my original post, I need to retrieve specific attributes for the user currently running the login script, as most relevant things, e.g. drive/printer mappings and branching into specific script sections, are done based on AD attribute content.
The actual login script has no hard-coded elements inside - it only does what it sees in several external sources.

For example, users can manage their individual persistent drive/printer mappings in an AD attribute (instead of their local profile, if they would map it locally) via a web interface, and get all mappings at each login. Still, those individual mappings can be managed centrally, if a share needs to be moved or renamed, by simply running a search/replace against the AD. No coding involved, no need to update local drive mappings !

The group membership check (using the memberOF attribute) is something we came up with some years ago, partly because of the hazzle of determining group memberships (of computers) and the execution time of such checks - memberOf is retrieved only once and cached in KIX, while individual group membership checks would require to access the AD for each check. But, mainly, because of the following: The name of the group the user or computer is member of contains the parameters used by the script.

Therefore, I don't know the full name of the group in advance, only the indicator (root) component. The rest of the name varies, depending on the usage.

For example:
A drive mapping group is named like
ADLogin_Map_Drv_Description_Q_server_share_dir

The script code only needs to know the "ADLogin_" part, plus "Map_Drv_" to indicate a drive mapping (this is the root component). If this string is found in the memberOF data, it gets extracted, split up and passed to the drive mapping UDF, resulting in a drive mapped as Q: = \\server\share\dir

This is what I called Dynamic Mapping Groups - makes the script more flexible, and avoiding any code changes at all, if some mappings need to be changed.

We even put this into self service: A delegated group owner has the right to manage the group members (as for other regular groups), plus: The teams managing the servers and shares don't need to fiddle around with error-prone script updates anymore ! They just create the share and the matching group, assign the access rights and group members, and the people get the new share mapped. Moving or renaming a share - nothing easier: Update the share, rename the group, done.

There's groups and code provided for Drive mapping, printer mapping, script branching, individual script execution. Need to run something (e.g. pick up a local log file) for a bunch of users: Create the script plus matching group, assign it to one or more users, and it runs at the next login.

Cool, eh ?

Only now, all this is broken for the Win7-64 users ... :-(

Andy