Scenario: You are in a large organization and want the whole company to run the same login script, while still...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
being able to fine tune the script for each location, department, etc. You have organized your user accounts in a OU structure like:
London (location) Support (department) user1, user2, .. Helpdesk usera, userb, .... Development Tokyo Payroll userq, userw,... RecruitmentYour script implements a number of actions using VBScript (map a drive, connect a printer, environment setting, etc.). The script is located on the sysvol share of a domain controller. That location contains a number of folders with the names of the locations (London, etc.) (VBscript is able to retrieve the exact (sysvol) file-location it is running from; the London folder would simply be a subfolder of "the script location.")
Using VBScript, it is easy to retrieve the location of the user account in AD. Get the name of the parent OU, which will be the department; the parent of the department OU gives the location.
The script now knows all these names and looks in the location folder on sysvol for a locationdata file, which is simply a number of actions it knows how to perfom, like each action on a single line.
file:locationdata map a common application share map a common writable shareHow you want to code the directive for the script is up to you. It could be something like:
Now have a departmentdata file in the same location folder with lines like this:
file:departmentdata SUPPORT, MAP,Q:,SERVERNAME,SUPPORTSHARE HELPDESK, MAP,Q,SERVERNAME,HELPDESKSHARE SUPPORT, PRINT,SERVERNAME,SUPPORTPRINTERSHARE
It is easy to have the script implement a number of strictly defined actions, which can be specified in the data files.
The result is a script which is able to perform a number of actions in a very controlled way, yet it can be tuned up to the department level without additional coding.
So, simply placing the user account in the correct OU will automatically lead to the correct actions (mapping, etc). User1 would get the mappings for London and Support. This all boils down to: use the AD OU structure to drive your script.
The level of organization below the location can be extended as needed. (A department can be subdivided into smaller units.) For those still with me: using the same scheme, based on groupmembership, you can have:
file:groupdata nameofgroup1, MAP,T:,SERVERNAME,SHAREX nameofgroup2, ENV,TEMP,C:TMP
(Sorry, I will not supply code samples.)