Blogging from my Diaper

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.

So Part 2 is where we created our bullet list as we prepare to build our full blog. I put my original bullet list below. Don provided me with some feedback to make the last bullet as an action. Don suggested that the last bullet should be something like “Test in a VM environment first”. When I first thought about this I was going to add the “Test in a VM..” action in next step when I expand on each bullet point. But after thinking about it I see how having that action here helps me expand my list quicker, because I have my action defined.

• Audit findings that need to be addressed
• Same task needs to be done multiple times
• Coworker at previous job used VB for a lot of tasks
• Inherited the AD environment so not sure how everything is configured
• Don’t Break anything!

So now my assignment is to expand this list into an outline. So here we go.

1. Meeting with Auditors after a three week audit
   • Primary focus of Audit on User Security and AD settings
   • User Accounts had privileges they didn’t need
   • User Accounts not disabled when they should have been
   • AD OUs not protected like they should be
   • AD had users able to perform actions they shouldn’t be able to do
2. Will need to perform the same action multiple times to resolve the findings
   • The staff will need to touch every OU in AD
   • Have many users that need to be disabled
   • Have many users that need permission changes
   • Need a list of users in certain AD groups
3. How can I automate this?
   • At a previous job a Coworker used VB for a lot of repetitive tasks
   • Last time I wrote scripts I was using FORTRAN and COBOL
   • Is there something I can learn quickly to help with most or all this?
4. Like most people, I didn’t build this AD and the person that did is now gone
   • Since the person that did the original install and all changes to the AD environment is not an employee.
   • Will need to understand the current settings and understand what the proposed changes will be. User changes should be fine, but AD changes will need to be looked at closer
   • Try to get information from current staff to see if they remember why certain settings were configured.
5. Build a test environment so we don’t break production
   • Using VMWare Workstation build a test AD environment
   • Configure the test environment as close to the production environment as possible.
   • Assuming that an easy way (for me) to script these required changes is found, keep testing until the scripts work as required.

So that is my outline for now. I’ll review it again in a day or two. I can feel myself wanting to jump in and just write, but after doing this outline I can see myself getting my thoughts organized up front.

Part 2 is to make a bullet list of my topic. Below is what I think I will be covering.

• Audit findings that need to be addressed
• Same task needs to be done multiple times
• Coworker at previous job used VB for a lot of tasks
• Inherited the AD environment so not sure how everything is configured
• Don’t Break anything!

Topic: How I started to learn a new technology

Audience: Anyone that knows there is a better way to do a task; but doesn’t know that better way yet.

Hi All and Welcome to my learning blog. I hope to use this to build some skills and then start sharing things I do at work to help others.

My name is Greg and about 8 years ago I got the nickname the Crabby Admin from some non-IT friends. I had a couple of bad days in a row at work so I wasn’t in the best mood. So someone called my the Crabby Admin and that name stayed with that group of friend.

Welcome and I look forward to any feedback you can provide me.

-Crabby