By Patrick Kaak
In this article I will take you through some new features in RES Automation Manager 2011 SR1. You may know already that you can create user accounts with RES AM, but what it doesn’t do out of the box, is make exceptions when the user account to be created, already exists. Such an exception is useful when you try to created a bulk of accounts using an csv-file with RES Automation Manager, where multiple user’s full names may result in duplicate logon names.
In most environments user account names are created using rules or standards. For example [lastname]+[first letter of the first name] +[a number when the combination of the last and first name already exists]. This is actually possible to do in Automation Manager with the new options to update parameters and creating conditions based on the task completion status of the previous task.
In this article the screenshots will have a lot of module parameters in it, so I hope you guys have some knowledge of those. The module parameters give us great flexibility and possibilities in RES Automation Manager. For this setup to work, you need to have an Active Directory Connector in place.
We first need to create a new module. Give it a nice, descriptive name like ‘Create a domain user’. Add the task ‘Create Active Directory User’. For more info on this, you could follow Rob de Korte’s article “How to get rid of those spaces in Windows User Accounts”. At the end your task would end up looking somewhat like the thumbnail on the right:
This first task will only create the user record with the most basic details in place. When that is done, you would likely want to configure some more information for this account, like homedrive, telephone number(s), user profile, etc. You can do all this by adding a second task ‘Manage Active Directory User’ and use the already created parameters in the ‘Settings’ tab. This is exactly why you always should consider using module parameters, as they save editing and typing the same stuff multiple times.
On the next tab, ‘User Properties’, you would do well by using new parameters for telephone numbers, fax etc. You can use the earlier created logon name-parameter on profile and home drive settings. When you’re done your task should look something like this:
At a minimum your module parameters should include the ones shown above in order to configure a working user account. Some may already be filled in, as shown below. LogonName is obviously an important parameter. In summary you can generate it by using a combo of functions such as listed below:
- $Firstname and $Lastname are read from CSV file
- $FirstnameInitial = @substring($[FirstName],1,1)
- $LastnameWithoutSpaces = @replace($[LastName], ,)
- $LogonName = $[LastnameWithoutSpaces]$[FirstnameInitial]
All this is explained in details in earlier mentioned blog article.
Now you have a module that creates a user account in Active Directory and which you can use when bulk-creating users with an CSV file. This is easy as you now have used a lot of parameters, which can be populated by the CSV-file.
That’s all well and nice, but what if you have two or more users? Say; Donald Duck and Daisy Duck? Using the rule set above, both would end up having the same username DuckD. Obviously the attempt to create the second instance would fail. Let’s update our tasks to handle that exception.
- First we need to make a new parameter. Lets call it Counter, as it’s purpose is to count how many accounts – if any – are already created with the same loginname. We will create it with an empty value. Make sure you un-check the input when scheduling and importing on the Input-tab of the Counter module parameter. In addition, make sure you mark ‘hide parameter when not directly used’ as checked and ‘parameter value is required’ unchecked.
- Now we need to edit the LogonName-parameter. Place the new Counter-parameter on the end of it as shown below. Now when the counter is empty (that’s the default value) it still creates the regular username as expected. But when the counter has another value like 4, the logonname would be ‘DuckD4’ accordingly.
The first part of the module is now ready. Now we need to look at to use it and increment the counter when needed:
- First set the ‘Create AD User’-task to ‘Continue job on error’. This can be done on the first tab ‘Properties’ under the ‘Error control’ section.
- Next step is to edit the ‘Manage AD User’-task. Open it and go to the ‘Condition’-tab. On this tab we can create one of the new conditions of RES Automation Manager 2011 SR1. Choose Add and select ‘Status of the previously executed task’ and give it the value ‘= Completed’.
At this point we need to let RES Automation Manager know what to do when this condition is met or what to do when the task failed. Select ‘Execute this task, but skip all remaining task in this module’ under ‘If condition is TRUE’. Select ‘Skip this task’ under ‘if condition is FALSE’. Also select the checkbox ‘Set parameter’ in this part. Choose the parameter ‘Counter’ and give it the value 1. When you’re done, the condition-tab should look like shown on the right:
So what have we built here? When RES AM tries to create a username that already exists, the task ‘Create Active Directory User’ will fail. But because we continue on error, RES AM will start the next task ‘Manage AD user’ and look up the condition. When the user account was created, it will manage it and after that step, it will stop this module from executing by skipping all other task (which we will create in a moment).
When the user account creation failed, it skips the managing of the account and sets a new value for the counter parameter, effectively changing the logon name to be created.
We now need to create addional create+manage tasksets in order keep trying to create this new logonname while incrementing the counter. Copying existing tasks is easy; just select the two tasks in the task-tab of the module, right-click select copy and paste it again. Do this as many times as you think you may have duplicates: If you think you at maximum have 4 users which would result in identical usernames, it’s enough to copy the tasks 3 times.
Now you have a big module with many tasks, but the counter hasn’t been updated yet. So if left unmodified, the counter variable is going to get passed the value 1 all the way down. In order to fix this, edit the 2nd ‘Manage User’-task on the condition tab and give the Counter the value 2. Do this the same for the 3rd, but give it the value 3, and so forth.
On the last ‘Create AD user’-task you should switch the ‘Error control’ back to ‘Stop job on Error’. This way RES Automation Manager will stop the module with the status ‘Failed’ if it still could not create the user. This could be an indication that you have more user names that result in the same login name than you anticipated. Otherwise something worse is wrong. If all goes well, when Mr. Donald Duck already exists in the system (with username DuckD), Daisy Duck will get the username DuckD1. When you open the job, it will show something like this:
As you can see, above the first CreateActiveDirectoryUser-task (1) failed. That’s expected as it’s trying to create a user that already exists. The second ManageActiveDirectoryUser-task (2) is then skipped. Again, this happens because we previously configured the condition on the ManageUser task to this: If the previous CreateUser task fails, then skip the ManageUser task and set the Counter parameter to 1. When the next instance of the CreateActiveDirectoryUser-task (3) runs, it will complete as it will successfully be able to create a user with LogonName: DuckD1. Since the CreateUser task completed successfully, the following ManageUser task (4) will also run. However since we configured the condition on the ManageUser task to ‘Execute this task, but skip all remaining tasks in this module’, and nothing more has to be done with this user so all the other tasks are skipped (5). The module will unfortunately complete with one error. There’s not much we currently can do about that.
As now the method may be perhaps perceived as a bit crude, but the module gets the job done while retaining the execution logic and keeping scripting out of the picture. It is hoped to improve this module in the future using the existing @CALC($[Counter,+,1) function to increment the Counter parameter more efficiently. Right now the limitation is that we can’t use a function when specifying a new module parameter value inside a condition.