I have spent some time during my holiday playing with Opalis. Opalis is really exciting and it will be interesting to see where Opalis will fit in together with existing authoring tools, diagnostic tasks, recovery tasks, manually tasks and workflows in for example Service Manager.

Opalis is an automation platform for orchestrating and integrating IT tools to drive down the cost of datacenter operations, while improving the reliability of IT processes. It enables IT organizations to automate best practices, such as those found in Microsoft Operations Framework (MOF) and Information Technology Infrastructure Library (ITIL). This is achieved through workflow processes that coordinate System Center and other management tools to automate incident response, change and compliance, and service-lifecycle management processes. More info at source.

My first scenario was a simple account creating scenario. I build a windows form application to generate files. These files were the start of my Opalis policy. The workflow first decided if it was about a service account or a user account. Then it includes two sub policies, one for service accounts and one for user accounts. When the sub policy is complete it returns the result to the main policy which will inform “someone” by e-mail about the new account.

This is the main policy. It uses a custom start, and I trigger it with Opalis remote trigger. The rule file looks like

For more information about remote trigger, click here. The first object in the policy reads the latest .user file in a specified folder. I generate the .user file with a small Windows Form Application I wrote in Visual Studio. As you can see in the picture below it creates the .user file and the lines tells Opalis in this case that it will generate a user account for someone named John Richard Doe.

I use that object to get the latest file if there are multiple .user files, then all other objects use the output from this object. For example step two which reads the second line in the file gets the file name from the first object.

Depending if the first line in the file is “ServiceAccount” or “UserAccount” the main policy will trigger the “Service Account” policy or the “User Account” policy. My two “sub policies” looks like this

The first one is for service accounts. It checks if the account already exists in Active Directory. If it does it will add a single copy number after the account and create it. For example you order a service account for server FILE110 and the account will be used with MOM, the account from this policy will normally be SVC-MOM-FILE110. But if that account already exists it will be SVC-MOM-FILE1101. The policy then publishes the data so the main policy can access it.

The second policy is used for user accounts. It starts by generating a SAM account name and checks if it exists in Active Directory. This step is a little more advanced than for service accounts, as the sam account name will be the tree first letters from the first name and the tree first letters from the surname. If the SAM account name already exists it will create a new account with including the first letter from the middle name. For example John Richard Doe will be JOHDOE, but if the account already exists it will be JOHRDOE. The policy then publishes the data so the main policy can access it.

As you can see these two are almost identical. The main policy continues and deletes the .user file and sends e-mail notification about the new account. I have added a lot “Logfile” objects as I want Opalis to write a profitable logfile. That is always good. If you want to play with this workflow you can download it here, ContosoOpalis. You will find a number of good Opalis resources here and if you want to download a trail version of Opalis you can do that here.