IT automation is a useful tool in any industry which can reduce costs, streamline operations and make outcomes predictable.
IT Automation Pros
- Once built, IT automation can continue to provide ROI for years
- Saves time and frustration for engineers, application managers and end users
IT Automation Cons
- Changes to existing IT automation usually requires an IT automation expert to edit
- IT automation requires high-end scripting and logic skills
- Time and resources must be dedicated to test and deploy rebuilt automation workflows
IT Automation What-If
- Give the operational administrators the ability to make changes to existing automation without the need of an IT automation expert
- No testing and deployment time required
- No need for high end scripting or logic skills
Microsoft System Center Orchestrator
Microsoft System Center Orchestrator (SCO) is an excellent tool for overall automation.
- Seamless integration with the rest of System Center and other Microsoft products
- Easy to interpret visual workflows
- Simplifies complex scripting needs
Orchestrator is a great IT automation solution. However, it faces the same challenge as other automation tools; only an expert of the tool can build or make changes to the scripts.
There are ways to alter the automation dynamically, such as using variables, but even then, the variables need to be altered by someone familiar with the Orchestrator Runbook console.
Wouldn’t it be better if we could make changes to this automation without calling the Orchestrator expert and give the operational administrators control over certain points of the automation?
As an example: Onboarding a new user is a frequent occurrence, sometimes daily, of any entity. Part of onboarding a new user is creating tasks for the application manager(s).
For example, a new human resources application is acquired by an entity that uses automation, usually a new set of tasks must be generated for the automation to continue to work. This new automation can be costly as outside resources are a lot of times required.
You have automation through Orchestrator that generates these tasks for you already, but now, you have just acquired a new Human Resources application. A whole new set of automation must be generated to create tasks for new user permissions to this application. Typically, you would call up your Orchestrator expert and pay them to create this new piece of automation.
If dynamic automation through Orchestrator was being used in the environment, there would be no need to call an outside resource. In an environment with Orchestrator, an approved application manager will fill in data in an easy to understand formatted data set and SCO will handle the rest.
Through this method of dynamic automation, instead of having Orchestrator using set information in a runbook, SCO would perform the following:
- Pull data from a premade data set that is easily readable and configurable by end users
- Parse the data to be inserted into fields
- Insert the data into the correct, corresponding field for the application
Dynamic Automation Data Set (DADS)
When designing dynamic automation data sets, hereinafter know as DADS, there are different paths that can be taken in setting up a user-friendly data set which Orchestrator can use.
Simple and timeless. Excel is used for a variety of different reasons and almost everyone in a business setting has some experience and knowledge using Excel. Overall, it is an efficient way of storing related data that is easy to read and manipulate.
Below is a screenshot of an example for the example scenario detailed above:
Pros of Excel
- Can be stored on a share drive accessible by users to view or edit the fields as necessary and even add lines to create more requests
- Information is clearly readable and easily editable
- Orchestrator can pull information from the DADS in the share location and will always have the most up to date data
- Almost everyone has experience with Excel and owns the software
- Can be submitted through the Service Manager (Microsoft’s ITSM Solution) portal and pulled into Orchestrator ensuring that the data has been documented in the database
Cons of Excel
- The data displayed can be unattractive at times
- Excel does not always show line breaks and other formatting that could help break up data
- Verifying information, such as correct usernames, can be difficult to enforce
- Usually means setting up a data connector that could potentially be arduous depending on what data you are trying to verify
- Any non-technical user could change certain case-sensitive data such as the column headers that would be used to properly parse data in the runbook
- A PowerShell script is necessary to parse information
Excel was the first iteration of DADS. It was effective, but rudimentary and there were too many possibilities for user error. The next evolution in the DADS lifecycle were SharePoint lists. It shares all the benefits of the Excel spreadsheet and more.
Information here is stored in a very friendly user interface that can be drilled down for more details.
In addition to this easy to use interface, there are additional features such as:
- Classes like users and devices that are synched with Active Directory can be setup for editors to choose from a pick list instead of manually typing the information
- Easy to setup dropdown selectors for certain columns so that editors can only selected what it accepted and possibly needed depending on the automation actions
- The list is cloud-based and can be accessed anywhere if the user has permissions
- Customizable permissions allow users to be classified as edit or read only
- Furthermore, users can be assigned permissions to alter the settings of the list and its columns
- Critical information, such as column headers, cannot be changed by any user
- Automation Integration
- Orchestrator has built in SharePoint integration
- PowerShell scripts are not needed to parse data from a spreadsheet
The automation part of this can be broken down into three simple steps:
- Get the data from the DADS
- Parse information from the DADS into appropriate outputs to be used for the end application
- Submit parsed data into proper fields for the end application
Notice that both 1 and 2 in the above example are Get List Items. This is because the SharePoint integration allows both of those steps to be done at once.
Step 3 is not as straightforward as it may sound depending on the processes that needs to be completed. In this example, the processes consist of numerous sub-steps. However, all these sub-steps are using the information parsed from the DADS to submit data to the application
Tedious and time-consuming static runbook development is a thing of the past with this method. Handling bulk tasks with dynamic automation is easier than imagined. It can be used for simple tasks such as rebooting servers on a set schedule or used in more complex instances such as creating numerous Service Request tickets. With this system, complexities and reliance on expert automation resources can be minimized.
Want to Know More?
If intrigue has struck you like a bolt of lightning, feel free to reach out to us to learn more! Also, if you are interested in the technical end of this process, I will be posting another blog next week going over the inner workings of how the runbook receives and uses the data for both CSV’s made in Excel and SharePoint lists. Stay tuned!