A Scripting Automation Success Story
One day a few months ago a client of mine came to me with a dilemma. They had a massive employee onboarding process that consisted of creating a name badge, providing a laptop and phone, creating an account in their phone system, creating an Active Directory account, a home folder and a lot more activities.
Every time a new employee came onboard, HR would send IT an email notifying them of the employee’s name, department, etc. IT would then create a bunch of help desk tickets for all of the required activities and send them off to the responsible parties.
The IT director was frustrated because when the process was finally completed, multiple weeks would go by and usually the employee would always request something that the team had forgotten.
The director was at his wit’s end, but someone on his team stumbled across my blog when trying to create an Active Directory account with PowerShell. After building an automated sync process to create new Active Directory accounts from an HR database, he then went on to spill out all of the other things they have to do every time a new employee is hired. It was crazy!
The majority of tasks could be automated like triggering a new employee activity from a database update, creating the Active Directory account, creating the Exchange mailbox, home folder, creating the computer account in Active Directory, etc. But, some tasks simply couldn’t be represented in code.
This was a child company of a larger organization which didn’t give this team access to perform certain activities. Instead, they are forced to open a ticket, assign it to someone in the parent company and wait for the task to be completed before they could complete their onboarding process.
As the director was explaining this to me, I could hear the disappointment in his voice. He was 100% onboard and excited to automate this entire workflow, but he thought that since everything couldn’t be done via code that might be a show stopper. He was wrong. We simply needed to break down that task into everything that could possibly be automated.
This company used SCCM, and one of the tasks was to move the computer account into a particular collection. Normally, we could have easily have done this with PowerShell but no matter; we’ll just automate whatever we can. Instead of throwing up my hands and griping about politics and how humans get in the way (true by the way), I decided to provide him a solution that he previously didn’t know was possible with “just a script”.
Rather than running the new employee tool all the way through until we got to the SCCM part and stop, we instead just added it as yet another step but with a wait time. As soon as the SCCM part came up, we broke down exactly what the tool needed to do; it would create a helpdesk ticket via an API, assign it to the appropriate person and just wait. It would pause, but it wasn’t just paused and doing nothing. During this break, it would occasionally poll the help desk system to get a ticket status. I was able to determine that the next trigger would be when the ticket was closed. The script would be polling for this as it was waiting. As soon as it detected the ticket was closed, it would proceed as usual.
Unfortunate enough to have another human intervention step? No problem. We just defined the trigger to start, and the trigger to start again and used the data collected along the way to finish out the process!
Too many times in my career I’ve seen small setbacks like this completely derail massive projects. Granted, the director did not know was PowerShell was capable of but also did not stop to come up with a creative solution to the human problem.
Successful scripting automation projects all come down to first documenting a repeatable, standardized process, building the code necessary to perform each task in that process and finally gluing it all together. Just because you encounter a hiccup along the way and the process can’t start at A and end at Z in one script execution doesn’t mean the process can’t benefit from automation.