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
determine OU of logged in user
Forum rules
Do not post any licensing information in this forum.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
Do not post any licensing information in this forum.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
determine OU of logged in user
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 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
determine OU of logged in user
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
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
determine OU of logged in user
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
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
determine OU of logged in user
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
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
determine OU of logged in user
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.