A few days ago, I was browsing some of the LinkedIn discussion groups, and one new and upcoming IT admin had posted a question asking other admins to give advice on what the top 10 things would be, that would be crucial for him to be an admin. Most of the responses were essentially for him to go and get certified. Though I do think that getting certified can be very beneficial, I have seen both sides of the coin: one of them is me, where I have no certifications, but I am successfully managing a pretty large Active Directory infrastructure, following Microsoft Best Practices, and I think I do a pretty good job at it. The other side — and I have seen it — is someone who has multiple certifications, but knows nothing to the extent that I would expect to know given all these certifications. I will not develop further on this, as it is not really the point of the article. Here are the 10 things that I thought a new IT Administrator should know. Though not really technical, in my experience, they are crucial to be successful, well, and not to get fired during the first day on the job.
Here are my Top 10 advice for the new admin:
- Don’t be afraid to ask questions: We always feel that it’s our responsibility to know how to solve everything, and in a lot of cases it is. But, remember, you may deal with something that someone may know more details about, and may be useful for your purposes.
- Google is your friend: 70% of problems, I don’t have the answer to in the beginning. By the end, I have the issue resolved. There is rarely anything that you will encounter that someone else hasn’t already solved. Sometimes, even what seems like the most obscure problems.
- Make sure that your company has support contracts with your major providers. Sometimes, you are going to face a problem where you need some assistance from them. In my case, I’m the most senior guys, so my support is Microsoft, for you, you may have more senior guys in your environment, so, you may be able to refer to #1.
- If you’re making changes, don’t make more than 1 change at a time. If you’re in a big environment, changes often-times take a while to replicate, and though in the beginning everything may seem good, you could come in the next morning, and your change would’ve wrecked havoc in your environment.
- Related to #4, keep record of any and all changes you make. If your company has an IT policy / Security policy, you may have a change process that you need to go through anyway. If you don’t, keep track of your own work anyway. I personally keep a private blog for me and my department with all changes related to AD. Sometimes, you won’t see a change, but others will, and will report it to you.
- Read books, articles, blogs. The Windows 2008 Server Resource Kit book has a lot of insight on how to setup an environment correctly. If you’re in an already established environment, it would still be good to read this, to learn about a lot of the best practices.
- Learn scripting: If you’re in a large environment, your life will get inefficient quick if you don’t learn some sort of scripting language. I would suggest VBS and/or PowerShellI you feel that this is completely out of your element, there are other 3rd party tools which are quite easy to use, and allow you to make bulk changes. Someone made a recommendation for a free product. I will also recommend, User Management Resource Administrator (http://advtoolware.com). It does way more than just AD.
- Half the problems you’re going to deal with are going to be somehow related to DNS. Learn DNS, Love DNS, Respect DNS.
- If you’re working in a large environment. Patience is key. I have dealt with this problem so many times, that I now have a code for it, I call it a “Patience Error”.
- Don’t be afraid to take risks, reasonable ones that is. By that, I’m not suggesting to go and make a change on your production environment without testing. But, eventually, you’re going to find things that can be done better. Research them, suggest them, test them, and implement them. Chances are, a better solution, backed up by best practices, and a good business case will likely be adopted.
I hope that this advice from my personal experience will prove useful to anyone who is looking to get into the IT field as a systems person (administrator/engineer/architect, etc ..)