I often build new sandboxes and test environments for different reasons. One common scenario with all these lab environments is that I never have any data in it for example in Active Directory, in databases, in Service Manager CMDB or in Exchange mailboxes. I have solved this with a number of Opalis workflows. For example I have one to generates a lot of data in a Service Manager CMDB, one to generate mail traffic and then one for Active Directory.
The Active Directory policy is actually three policies. It is one for creating AD users, one for creating AD computers and one for generate common data to the two other policies.
When you are building larger and complex policies it is a good practice to break it down to smaller parts. You can then also call the different parts from different policies and re-use your policies in different scenarios. In this example I have a policy to generate the location data for both users and workstations. Instead of build the same functionality in two policies I have one, which the other two is using. Another thing is to configure the working path green, it gives you a good overview how you want the policy to work. Red links can be failure or fail-over, path that your policy takes when something didn’t turn out the way you were hoping.
I tried to put all info that I will change often in variables, for example domain name, AD paths and number of AD objects I want to generate. It is much easier to change one variable and then configure 10 objects to use it then changing 10 objects in the policy each time I copy the policy to a new environment.
The 1.1 policy (users) and the 1.2 (workstations) policies works almost the same
- Starts with a custom start
- Reset a counter to 0. This counter will be used to count number of objects we create
- Generates a four digits random number that will be used as employment number for users and single copy for workstations. We will also use the first digit here to set the department of the user object
- Trigger the 1.3 policy and then waits until it is done. The 1.3 policy will generate a location and a short name for the location. We use this as for example location and office for user objects and in the name of workstations
- Generate a two digits random numbers that will be used to map first name
- Generate a two digits random number that will be used to map last name
- Map first name, last name and department. I have used a list that I found on the Internet with top 100 first names and top 100 last names. Think it was a Swedish list. Random numbers generated will be mapped to a first name and a last name. We will use the first digit of the 4 digits random number to set the department of the user.
- Next step creates the user object. As you can see we re-use a lot of the digits that we have generated, for example to set phone, postalCode and MobilePhone. We use the first name and last name in different combinations and also the variables set under global settings in Opalis. Total of 16 attributes will be configured for each user object.
- Next step enables the user account in Active Directory
- Set the counter value to +1. We reset the counter in the beginning to 0 and for each created object we add one (+1) to the value
- We compare the counter value with the target value. The target value is set by a variable. If we dont have enough objects we will follow the orange link and create more, else we will follow the green link and generate a platform event saying the policy is done.
There are a number of variables that you need to configure before you use the policy.
As you see in the policy there is a lot of random data. For user objects there are 100 first names, 100 last names, 10 locations and a 4 digits number used in a number of ways. That would give us more than 100,000 different user combinations. You can download the policy here, 1. Demo Data. Please note that this is provided “as is” with no warranties at all.