Heads of IT department may dream of the perfect team where every member can manage requests, changes and incidents in a fast and smart way by using automated scripts improving workflow quality and customers experience. Unfortunately, too many support people still make manual actions to solve issues without giving any clear risks and rollback methods.

I used to say to my team : If you do something twice, then you should have scripted it the first time.. Theory is so different from reality. I know very well that sometimes we don't have enough time or the appropriate knowledge at the right time to script everything.

However, if we don't make the first step, we will never go anywhere.

So let's have a look to the first step right now.

1. All requests, incidents or changes should be translated to standard input files.
2. These files should be used into a black box ¹⁾ to create output files summarizing the situation and testing if the request, incident or change makes sense. I call this step preCheck and it requires readOnly right because no modification occurs.
3. Next step consists of giving output files from preCheck to a second black box to execute requests or changes where preCheck results are accurate else they must be ignored and labelled as such. All actions applied into this implementation step require modification right.
4. Successful modifications are great, postImplementation checks are even better. How much frustrated it is to hear the sentence “it should have worked, it did on my computer” whereas the client has answered that it did not. It is even worse when you announced to your manager that the incident is closed whereas it is not. So, implementation files must be sent to a new black box to prove that all modifications have produced the expected behavior on your environment. And if some did not, then they must be identified.
5. Finally the rollback black box! Some people think it is optional, some others reckon it is mandatory. I would say: without it, risk is very high. I guess you get the workflow using input files from previous step to create new ones with results. Pay attention that if you had to rollback some modifications or even all of them, output files from rollback can be used as new input files for you preCheck step and now begin a circle! Plan makes sense.

A picture is worth a thousand words

Source DIA

Imagine, today is Monday and you start your on shift week. Your favorite IT ticketing system (ServiceNow, Jira, Octopus etc.) is waiting for you. The first ticket you opened requests you to modify AD users because some names are misspelled.

Action plan :

• Our first black box needs at least one input file which summarizes the request. Luckily, there is one CSV file into the ticket with all modifications the client requested. It looks like this :

This is a perfect input file for a preCheck function. Now we must wonder : what do we want to check ?

1. For each line:
   1. Is a real active AD User ?
   2. Are we sure that the AD User is the good one ?

Since we detected two checks, we are going to add two new columns to our output file: AdActiveUser and MailMatch.

Let's do it in Powershell for example.

This first function provides us a new file that we are going to use for the implementation step.

PreCheck provides us this new file.