Time to write the entire post. I’m starting with a tiny bit of my history to help the reader understand my career. I figured this would be in an “About Me” section on a full blog.
After graduation college I started my IT career by taking a job for a large Biopharmaceutical company. I was one of three IT staff at the location I worked at, with my primary job supporting the users. I eventually worked my way up to a server admin with my primary focus on Windows systems, Backup systems and Storage Systems.
About 12 years ago my family relocated and I found a job at a financial institution. They were preparing to replace their entire “Core” system as it was called going from an old terminal “green screen” system to a modern, multi-tired system. My coworker and I spent the next couple of years deploying Windows servers as needed to support the application, provisioning storage, replacing old legacy systems and all the other fun stuff you do as you prepare a major system replacement. The entire staffs hard work paid off be cause the migration went pretty smooth and the issues we did run into were correctable pretty quickly.
Something that was nice during those two years of work was not having to deal with Internal Audit. Now that time is over.
I return to my desk after sitting in a 3 hour meeting to discuss all of their “findings”. I take the 3 page Excel document out of my notebook to start looking at it again while it is still quiet. As with most audits some of these findings were valid and some findings are questionable. The IT staff made a commitment to research the resolutions to the issues and provide a response to Internal Audit with our planned actions and target dates.
When my coworker gets back to his desk we talk about some of the findings. Some are just busy work while others will be a little time consuming. An example of a busy work finding is the need to set all Active Directory accounts to disabled if the password hasn’t changed in 90 days. There were other AD findings that were busy work resolutions too.
My coworker was ready to jump into AD users and computers and start fixing the issues. I said to him that I know this can be scripted. At my previous job I worked with someone that enjoyed writing VB scripts and would create scripts for AD tasks all the time. It had been a while since I had written a script but I figured if I spent sometime now to figure out how to script this change, it will make AD easier to manage in the future. We decided that I’ll take two weeks to see if I can figure out how to use VB and address these issues. My biggest concern was I didn’t do the initial AD installation, and the person that did no longer worked there. Were there settings that could break something if they were changed? No matter what, I can’t break AD so I need to do a lot of testing.
At home later that evening I’m using Google to research ways to script AD tasks. I come across something new to me, called PowerShell. As I continued to read more about it I was starting to like it. To me, the “verb-noun” structure of the commands made it easier to know what you were doing. The next six hours flew by and I found articles and videos about PowerShell. To me, this isn’t scripting, it was doing system administration across multiple items quickly. After investing some upfront learning time, doing these tasks in the future would be easy.
PowerShell brought back an energy I once had with scripting/programming. Starting in Junior High school and all the way to my freshman year of college I loved writing code. Whether it was creating block pictures on the Apple IIe to solving problems in Cobal and FORTRAN in college, I always got an A in those classes. Then out of nowhere, I was done. I didn’t want to write code anymore.
Over the next couple of days I spent more time learning. Once I felt I had gathered enough of the basics, I was ready to start testing. As most people will do, I got a copy of VMWare workstation and installed it on my laptop. I installed a single Domain Controller since my laptop had limited resources and could only run one VM at a time, but that was all I needed.
Now that I had the DC to test with I was able to start building my tests commands. I had mixed results at first. I broke a few of my test accounts and had to rebuild the DC at one point, but the DC on my laptop is for testing and breaking. Eventually, I figured out what I was doing wrong, corrected the steps and was able to accomplish all of the AD findings using PowerShell.
A couple of days later I have the relevant people in a conference room to show them what I was able to do. I showed them how easy it is to make the changes to address the audit. I also showed them how we can do our own checks to make sure the AD findings won’t happen in the future. As with anything new, there was hesitation on their part, considering that everything done there in the past was a manual process and a lot of “sneaker net”. To me, “sneaker net” is when you have to manually touch each and every computer to make changes. The ability to do things from a single location to make all these changes brought concern and but also excitement to the group.
So now it was time to making changes to the production AD environment to address the Audit findings. Management provided me with the list of changes to start with. They wanted to start with the least impacted areas first. Each time we executed a change it was successful and everyone’s confidence grew. The original plan was to take two weeks to make all of the changes, but we did it in three days, because the scripts ran quick and we didn’t have any issues.
Once management saw the success from using PowerShell to make the changes I was asked what else I could do with PowerShell. I told them it looks like PowerShell can do a lot of things we are currently doing manually. I told them I would be happy to continue to learn but would need training, and a better laptop for testing. Both of these requests were added to the budget.
Sometimes you can’t be afraid to jump into the deep end of the pool alone. After a few years of playing it safe, I found something of interest to me and jumped in. I did spend some personal time learning and breaking things, but it made me grow professionally.
I will have additional blog posts to show some of the other things I have done for work, including making some GUI tools for the people that do not have a desire to learn PowerShell.