SAPIEN Forums

Hi all,

I would like to create login script with VBscript which determines the OU of the logged in user and run a batch file.
So for example if user1 is logging in and he is from OU1 then run batch1.bat. If user2 is logging in and he is from OU2 then run batch2.bat. Based on the OU where they belong to.

Any help please?

Thanks

Hi all,

I would like to create login script with VBscript which determines the OU of the logged in user and run a batch file.
So for example if user1 is logging in and he is from OU1 then run batch1.bat. If user2 is logging in and he is from OU2 then run batch2.bat. Based on the OU where they belong to.

Any help please?

Thanks

I know how to write out the user`s details with this script:

set objSysInfo = CreateObject("ADSystemInfo")
set objUser = GetObject("LDAP://" & objSysInfo.UserName)
wscript.echo "DN: " & objUser.distinguishedName

So in the output I get: ...OU=users,OU=school...
How can I create an IF statement, for example:
IF OU=school THEN run batch1.bat...etc

Thanks

This is done via Group Policy.

Add the batch file to the logon scripts for tehOU that you want to target. This is the recommended method.

But I only want to run these batch files on ONE server.

To further what JVierra was saying, you would have to either create an OU and create a user policy for that OU or create another policy in the existing OU and utilize WMI filtering to apply the policy only to that system. Also, just to take your script a bit further:

Dim objWSHShell : Set objWSHShell = CreateObject("WScript.Shell")Dim objSysInfor : Set objSysInfo = CreateObject("ADSystemInfo") Dim objUser : Set objUser = GetObject("LDAP://" & objSysInfo.UserName) 'Get the user's DN
WScript.Echo "DN: " & objUser.distinguishedName
'Get the parent object of the user, which should be an OUWScript.Echo objUser.Parent
' Connect to the OUDim objOU : Set objOU = GetObject(objUser.Parent)' Get the Name of the OU
WScript.Echo objOU.Name
' Use a select statement to run the appropriate batch
Select Case UCase(objOU.OU) Case "OU=PRESCHOOL" objWSHShell.Run "preschool.bat", 0, True Case "OU=SCHOOL" objWSHShell.Run "school.bat", 0, True Case "OU=COLLEGE" objWSHShell.Run "college.bat", 0, TrueEnd Select

Sorry rasimmer but that is not what I was indicating.

If we just add batch file to a GPO as a logon script then filter the GPO on the server there is no need for other logic. This is how we determine what OU run which script/batch against which servers/workstations/users.

1. OU side login
2. Add WMI filter for the server that is to get policy

You are detecting the OU which has already been detected because the GPO is applied at the OU and applies only to items in the OU. It is also restricted to only apply to the OU items the folder further restricts the policy to only the one server.

Once an admin learns how to do this it makes for a very powerful method. Scripts will no longer need complex logic to determine what policy to enforce. The logic is handled by the policy engine. Once the policy engine detects the correct conditions the script is run. WE can also have multiple script/batch files run at different levels of the AD hierarchy and they will all work together like one big script.

Unfortunately Admins that are not certified in Windows AD are afraid of GP because they have been told that it is an unpredictable monster. I think it is time to dispel that myth. GP is an administrator

Ah...I see what you're saying. Basically, on the school OU, create a policy with a WMI filter for the specific server to run the required 'school.bat' I don't understand your need to make things simple..shhessh. )

Well - I am simple minded at times so I need to keep things simple and tidy. Large rambling scripts are a pain to maintain and hard to debug when they break.

KISS - my moto.

OUs are not old school. VBScript logon scripts are old-school. The technique was put inplay to compensate for NT4 not having Group Policy. Scripted LOgons are legacy. GROP Policy and GP Prefences can do almost everything needed for a logon.

IN todays world everything is 'policy' based. THe goverment, the insurance companies and the corporate lawyers all insist on policies and enforcement. Everyone wants a policy compliance audit. Windows Group Policy was developed to satisfy that need.

Group Policy is called 'Group Policy' because it implement 'policy' based enforcemtent of Corporate Policy. RSOP is one of many compliance tools. We are now seeing dozens of auditing tools that merge GP and security audits with other information designed so a corporation can be sure that it is in compliance with all of the laws and rules.

Login scripts cannot be read by auditing tools. Keep them as simple and benign as possible. You should alsways use multiple scripts tied to multiple a policy objects which then become the description of the policy being implemented.

Example:
GPO name: Fix Old App,exe Policy" Description: THis GPO adds an environment variable to force patch on app.exe'

The VBS or BAT file can have as little as one line.

Suppose you have a requirement (Policy) to hav allusers map apublic drive. That single mapping should be in a separate policy and not combined with all other mappings. Use CMD for this as it is more efficient.