What I Do

The question I get asked most is "what exactly do you do?"

Well, if you're not technical it can be hard to explain without using a lot of geek words and acronyms. So, I'll try to explain in "normal" words.

The first part is easy, I think.

I manage systems. OK, so what does THAT mean?

Many companies need a way to know who has what and what is on it when it comes to computers. There are programs that "manage" this information and it usually involves installing an agent that collects all the information and sends it back to the "mother ship" (a central server). I'm on board that "mother ship" and one of a few people that work in the "engine room" to keep things running smoothly.

What is typically collected is hardware, software, and user information. The agent can tell me what model computer you have, how much memory is in it, how big your hard drive is, how much space you have left on it, the last time you rebooted, and everything you have installed. I'm then able to use this information to determine if you need a newer version of software, if you are missing critical patches, if you are using unlicensed software, and if you are eligible for a system upgrade. That's really the point of managing systems. To know what's out there and what can potentially be a threat to the company or you as an individual and being proactive with that information.

When I started managing systems, we had nothing. I was literally put into a room (aptly named the War Room), told to evaluate possible candidates for managing systems as well as build a new corporate image. This was the result of me giving two or three pages of feedback on the last corporate image build. I later learned that this task of building corporate images was "rotated" among the System Administrators, so it was never consistent and that's how I was selected to do the job. :-)

A corporate image - yeah, I get that blank look a lot when that's mentioned. So, to explain that, this is the best I can do. I take one computer and put everything the company wants on it for every user and "take a picture (a.k.a. image)" of it. That allows us to copy that "image" to other computers and keeps it consistent with who gets what when a new system is deployed. That's the simplest explanation, but it is a lot more complicated than that and that method I just explained isn't actually done anymore really, but the concept remains the same. :-)

LANDesk and Altiris were the two products I was evaluating and we were already leaning towards Altiris. We ended up going the Altiris route and thus my journey into system management and image building began. This was as a contractor. It would grow into much more and, when I look back, I'm still not sure how I did it. :-)

Seven years later, I was officially hired and was still the only person that did what I did with occasional help from a contractor. A team slowly started to build from there, contractors included. It was long overdue, not just being hired, but getting the help I needed to keep up with the growth of the company. On top of maintaining the images, I also built "packages" of software to deploy to systems, assisted with creating a database of "solutions" (the how-to articles referenced by the Help Desk), supplied endless reports, and become the person that people went to when help was needed beyond simple troubleshooting.

Now in my 13th year, I've been part of a team of experts for about three years now. My role has changed to focus on software compliance and patch management, but I still do most of what I've always done, which is manage systems. :-) Altiris faded way and Microsoft System Center is the direction we've gone as well as from Windows XP to Windows 7. I've adapted fairly well, but not near the level of administration with System Center than I was with Altiris. This was because System Center experts were hired to make the transition, thus relieving me of a huge responsibility and allowing me to focus on my new roles.

Software compliance is becoming a big deal, not just for where I work, but with every company. The fines are huge if not enough licenses have been ordered or the wrong version is being used. The process is unique to each company, so one must build a process from the ground up. This has been extremely challenging for me. Part of me enjoys the hunt, but another dreads the amount of data that must be collected and sifted to find the flaws to make the necessary corrections to prevent them. It's like untangling Christmas lights to give you an idea. :-) I'm still untangling the first string!

Patch management is exactly what it sounds like. We "patch" systems to hopefully block vulnerabilities and protect the company from virus infection. The only daunting part of this is the risk of causing the dreaded "blue screen of death" (BSOD) and getting people to reboot their machines (that's going to be another blog in itself).

The knowledge base tidbit I mentioned is where I decided that maybe blogging would be a good idea. I've written or co-written over 500 internal articles used by our IT department for how to install and configure most of our software, troubleshooting guides, performance tips, etc. I was reminded of how much I owned or was a part of when the technical writing team was tasked with reviewing all of our existing articles and validating with the authors if they were still relevant or needed updates. I had no idea I owned so many and last I looked there were 3700 overall.

This post ended up being lengthier than I thought it would be, but now you know "what I do" and I'm going to try and share what I've learned over the years that could be useful to those that are intimidated by computers or are just average users getting by with the tools and technology that changes almost every day.