Automation – Orchestrator Back to Basics – Use Cases Spotlight (5 of 5)

  • Article

This is post #5 out of 5 in the “Orchestrator – Back to Basics – Use Cases” series, full series posts are located here:

  • #1 : Alert Remediation, where automation is used to monitor specific situations, and react automatically. This is also the introduction post to the series.
  • #2 : Maintenance tasks, where recurring tasks are being handled in a consistent and automated manner, triggered manually or when a specific condition is met
  • #3 : Provisioning and Change Management Automation, where automation handles backend processing or user requests from a service catalog or any provisioning process worth automating in your context
  • #4 : Cross-technology integration . Here automation can be used to integrate otherwise silo’d technologies, or help in better together and migration scenarios (integrate a monitoring solution to a manager of manager, or into a ticketing solution)
  • #5 : “Miscellaneous” scenarios, like dynamic resource allocation, and new user onboarding as examples (this post!)

Use Case #5 : “Miscellaneous” scenarios

In this last post from our “Orchestrator – Back to Basics – Use Cases” series, we’ll cover…well.. anything that could not easily fit a previous category!. Many items could be covered here, but we’ll focus on two scenarios:

  • Using automation to automatically scale out the front end of a web site
  • Using automation to manage new user onboarding

 

Scenario #1 : Dynamic Resource Allocation

The idea behind this scenario is to be able to scale a service as needed, based on current activity, or possibly on a calendar basis (at the end of the month for example).

A Runbook could look like this, getting monitoring data from Operations Manager, computing the name of a new VM to handle the load (based on a counter here), and adding the new VM to the load balancer as needed.

image

For illustrations purposes, there are multiple ways to enhance such a Runbook:

  • Pre-creating the next VMs and just add it to the load balancer, to speed up mitigation of the web site performance
  • You could also split it in two Runbooks, if approval should be needed before deploying the new server. This would be similar to how we split the SQL Server Maintenance Task Runbook in this post.
  • Using a PowerShell activity to compute the number/name of the new VM, and also use PowerShell to scale out a Service Template (possibly handling VM creation load balancer integration at the same time). Eventually, it could look as simple as this! (you can find examples for the content of these two PowerShell activities in this blog post)

image

  • Using the Windows Azure Pack (WAP), where scaling out an Virtual Machine Role means moving a slider, just like in Windows Azure!

Note : In a hybrid cloud scenario, you could also have a Runbook where Operations Manager monitors the status of a Windows Azure application, and the issue is resolved by deploying new Virtual Machines or Web Roles. Charles Joy’s post series has plenty of examples on this topic.

Scenario #2 : New User Onboarding

Here is a scenario where a Runbook is monitoring new recent users in specific organizational units in Active Directory (going as far as triggering the synchronization from FIM). When new contractors are being discovered, an onboarding process is being kicked off.

image

This onboarding subroutine handles finding a laptop for the user – querying a custom database which could also be a CMDB – and adding that laptop MAC address and name into Configuration Manager. The laptop then just has to be booted on the network to receive an Operating System Task Sequence with the right applications, the machine having inherited some variables from the collection. Here, the Runbook goes as far as starting the “laptop”, since we’re using virtual machines in this example.

image

In the previous screenshot, there are also two Active Directory activities, respectively updating the user description to “Processing” and “Processed”. This doesn’t serve any technical purposes, but is just a way for someone looking at the Active Directory console to understand something is happening for this specific user.

As you probably know, new user onboarding would touch many more processes and solutions in reality. The beauty of automation is that it can link these systems together, but does not need to do all the work : For example, we were using new Active Directory users as the trigger here, after they’ve been created via FIM. FIM would handle many others things that our process does not need to take care of, like distribution groups. Likewise, adding the user in Configuration Manager might result in having automatic assignation of the user and his/her machine in multiple collections, assigning configuration baselines, inventory settings, antivirus settings, new application deployments, etc.

This closes the “Orchestrator – Back to Basics – Use Cases” blog post series. I hope you found it useful and that it sparked a few ideas where automation could help tour organization on a daily basis.

Thanks for reading!