Sysadmin advice for a first timer?

November 23, 2008 4:53 PM

I'm starting a new job as a system administrator for small business in a few weeks, what can I do to prepare myself?

I'm quite excited about this position but I've never been a sysadmin before. I've done desktop support (which I'm quite good at) and tons of web programming but have never done server support and have never been the only IT person at a business.

It's a Windows XP environment with about 35 users and there is talk of moving to Exchange soon after I arrive. I will also have access to some contractors who will do much of the server set up and config.

Any advice tech gurus?

(I've already purchased the book "The Practice of System and Network Administration" by Thomas A. Limoncelli)

posted by talkingmuffin to work & money (15 comments total)

Can you tell us anything about the servers you'll be supporting?
posted by PueExMachina at 5:01 PM on November 23, 2008

I've worked in a small environment like that. Be expected for users to really want you to hold their hands on things. Really get to know their business, and how people from different departments structure their workflows. It's not the same if you're a cog in a giant IT wheel for a mega-corporation so you'll be better off being as much of a fixture as you can there.
posted by Burhanistan at 5:34 PM on November 23, 2008

Backups. Whatever servers you have running, make sure that everything is being backed up. Restore something from those backups as soon as you can to verify that they are really working properly.

Be sure to give extra attention to the suits. It's a small company, so there will be be an owner, and 5 or 6 upper level people. Do what you can to make their lives as problem free as possible. Make sure that you backup their personal machines at least once a week.

Be extra nice to the boss's secretary. Her opinion will likely determine how you are seen by the boss. I'd recommend replacing her monitor with something bigger the first week.

Resist the impulse to jump at every demand that comes in. Set a schedule for end-user support and stick to it. You need to establish boundaries early on because...
One employee is going to be responsible for about 80% of the reported problems coming your way. You'll know who it is within the first couple of weeks. If you don't push back, this person is going to run you ragged. The way to control this is to document everything. Track how much time you spend on each issue, and who the work was for. When the problem person starts complaining that you aren't their personal slave, you'll have numbers to come back with showing that they are eating up all your support time.

Have fun! I personally think system support for a small company is about the most fun job you can have in IT. You won't have much of a budget, but you will get to make all the decisions. Be sure to budget some training for yourself. Try to get out of town for a convention every year or two.
posted by Eddie Mars at 5:57 PM on November 23, 2008 [4 favorites]

document document document. if there's a ticketing system, love it and marry it. if you don't put something in a ticket, it didn't happen. if you're the only IT person, still try to document as though you were documenting it for someone new to come along and fix it. when you get called in the middle of the night and you're fuzzy and confused, having that documentation will make life simpler.

remember that a huge percentage of server side outages are self inflicted. make sure you have backups before you start any server upgrades. make a checklist of things to do and tests to run before you'll consider something fixed/operational.

repeatable builds make for supportable systems. if you've got a bunch of PC-based things, can you establish a standardized build (ghost images?) for servers? the worst thing is trying to maintain those "snowflake" systems that are unique and oh-so fragile. (i have a theory: the higher the 'snowflake' level of a machine, the more critical it is to the revenue stream of a company)

before you push patches out to everything, test it in a few places to make sure it's not going to shoot you in the foot.

avoid 'clever' solutions. 'clever' often leads to 'hard to support and hard to troubleshoot'.
posted by rmd1023 at 6:13 PM on November 23, 2008

Document everything. I installed DokuWiki on one of our internal web servers for this purpose. Pick something that compliments your own existing documentation tendencies and get that running as quickly as possible.

After you have the documentation system in place, put everything in it!

If you deal with code at all, install and start using a version control system like SVN. Even if you don't code version control systems can be great for keeping track of your work over time on a variety of file types. Dokuwiki has versioning built-in.
posted by odinsdream at 6:14 PM on November 23, 2008

Oh yeah, learn how the phone system works early. Figure out how to transfer calls off-premises automatically, and set your extension up that way. Grab a DID if there isn't already one for your extension, then give out only that number. Never give anyone your cell number.

This lets you control how the calls are handled - whether they go straight to office voicemail on the weekends, or to a coworker while on vacation.
posted by odinsdream at 6:18 PM on November 23, 2008

I've done the IT-department-of-one gig, and know a few other people who have also worked in very small departments. Here's some advice.

1. Use some sort of ticket/issue tracking system. For each problem, open a ticket. Everything you do regarding that issue, every call you make, etc, should be logged under the ticket. It would be nice to have a commercial ticket tracking system, but I know one guy who uses blogging software—each issue is a post. This is a practical organizational tool, and also a way of covering your own ass.

2. Very often, the smaller the department, the worse the documentation. Much of your initial time in the workplace may be spent playing detective. Leave better docs for the next guy. A wiki is good for that kind of thing (just make sure the where and how of the wiki is documented on paper somewhere).

3. It's important to communicate clearly about expectations. Talk to the managers or owners to establish some sort of informal "service level agreement". You're only one guy; you can't be on-call 24/7. What kind of uptime do they need for servers and networks? Are they willing to pay for redundancy? If not (probably not) they need to know that there will occasionally be outages. Remember the engineering triangle: good, fast, cheap—you can only choose two. I guess this is a round-about way of saying that managing user expectations is an important part of the job.

4. As said above: backups. You have to make sure you're getting the important stuff, and to understand what's important you'll need to talk to users. Make sure the backups and restores actually work. Think about taking backup media offsite, or at least putting it in immovable fireproof safe. It doesn't need to be novel-length, but make a disaster response plan and write it down.

5. Don't be that weird IT guy. Be friendly, smart, helpful, and professional.

Congratulations on the job. Good luck.
posted by paulg at 6:36 PM on November 23, 2008

Everything paulg said, and my own addition:

The people who are often successful in your role are good actors/actresses, are very polite and professional under all circumstances, are excellent communicators, and go to great lengths to explain things in a concise manner that's tailored to their knowledge of the people around them. They're great listeners, they're patient, and they're good at chatting and getting to know the people they work with.

I don't do that end of support (I'm one of those server consultant guys) because I use a lot of four letter words in the course of my daily tasks, I generally go HULK SMASH on things until they work without considering if what I'm going HULK SMASH on is a person or a machine, and I'm a horrible actor that can't hide when I feel that someone's a blithering idiot and is undeserving of my attention. If that in any way, shape, or form describes you -- start looking for your next job now.

The ticket tracking suggestion, if one is not already in place, is an excellent one: There's lots of free or open-source tools, and they're really not that hard to build if push comes to shove out of available tools like an email account and a copy of Access. The documentation aspect that these things provide is helpful because when someone grumps to your boss about something you couldn't fix, you can call up tickets #124, #3223, and #8453 from the same user about the same problem with their CD tray and coffee cup and why that person's computer now has a slot-loading CD-ROM drive.
posted by SpecialK at 7:17 PM on November 23, 2008

If your infrastructure supports backing up every drive on every computer, awesome.

If that isn't true (and it's usually not), expect that no matter how many times you tell people "save your important files to the X: drive, not the C: drive," they are going to forget and then their computer will crash. Make sure you have a plan for this. (One option is giving people extremely small local hard drives so they can't form bad habits.)

On the flip side, if there's an employee who is reasonably technical, let that person have as much access and flexibility as they need and deserve. I'm a programmer and I've really resented IT folks who treated me like the sales manager, and assumed all my bug reports were coffee-cups-in-the-CD-drive.

Unlike being a programmer, you aren't working if you're not there when everybody else is. I had a sysadmin once who would insist that he put in 12 hour days, but those hours didn't start until 11am while the CEO's laptop had been broken for 3 hours. Late nights fixing the email server are appreciated, but lots of places will still expect to see you bright and early the next morning. Sucks, but that's how it is.

Good luck, though. My last job had a fantastic sysadmin and he was well-loved and respected.
posted by nev at 8:16 PM on November 23, 2008

Yes, some good advice in this thread. I should also add that once you have the basics addressed (this may take several months to a year) your best friend and watchword should be: automation. Learn a scripting language or two.
posted by paulg at 8:38 PM on November 23, 2008

This is what I do for a living. Email address is in my profile (it should be visible) and I live on it. Feel free to send any questions my way... It might help keep my sanity :)~.
posted by SirStan at 8:59 PM on November 23, 2008

Also; learn the delicate balance between users who want to know why it broke and how to fix it; and those who think you are the PC janitor. Address each as they prefer to be addressed. Talk shop/sports with the guys who don't care that they double clicked on AdWareForYou.exe, and help Susie in accounting write down steps to fix her missing printer if it happens to her again.

And never say "this shouldn't happen again" ...

Never assume everyone will understand computer humor.. people I have worked with have made the mistake of saying somehting jokingly and not following up with the real answer. Sometimes non-technical staff dont understand how "just kicking it" fixed it...

Backups are a pain in the ass. But not having them that one time you need them will cost you a job.
posted by SirStan at 9:02 PM on November 23, 2008

If you don't know an answer.. its ok to say so.

If you don't know Exchange.. and they implement it and it breaks in a horrible way...

a. DONT TOUCH IT, CALL SOMEONE WHO KNOWS HOW TO FIX IT.
b. See a.
c. If you think you know how to fix it, see a... but then backup the exchange database before you play with ANYTHING.
posted by SirStan at 9:04 PM on November 23, 2008

I work in the financial sector, so we're all a bit more paranoid about these sorts of things than most places--so take this with however much salt you usually add. But I've found that the best system administrators:

1. Always have a way to undo or revert
2. Prefer tried-and-tested ways of doing things

The first part means backups, documentation (a wiki is great advice), backups, a ticketing system (Mantis is an easy-to-setup, easy-to-use example), and backups.

The two most important things for your fellow employees:

1. Communication (E-Mail/Telephones)
2. Distraction (Internet)

Make sure these things work and it will be a cakewalk. Neglect them to your peril.
posted by Civil_Disobedient at 12:35 AM on November 24, 2008

Agreeing with setting up a base, standard ghosted end-user image on standardized hardware. Establish that you will support THIS kind of desktop and THIS kind of laptop and even if the users go out and buy their own laptop, if it is not the agreed-upon model, that you cannot support it. A standardized image and hardware will save you hundreds of hours of hair pulling.

Agreeing with the above advice on not giving out your cell phone number. Set up an oncall number where users can leave a message, the action of which triggers your phone/blackberry so you can retrieve the message without having to answer every single "omg 'emergency' I can't print!!" during off hours.

If you don't have centrally managed anti-phishing/spyware, try and get the users to run Firefox for general browsing instead of IE. Cleaning/reghosting due to spyware infestation can eat up a crazy percentage of your working hours if you let it. There will be users who have this issue again and again. And again. You will know who these users are in the first 2 weeks of the job.

Know, ahead of time, who you can call for support when something goes wrong. There will be genuine emergencies, be able to handle them well and they will be forgiven. Have a disaster recovery plan in place if there is not one already.

These sites are invaluable for Exchange system administration. The Microsoft site has some shockingly comprehensive and free webcasts and training-casts, particularly for Exchange. You can download and set up virtual Exchange environments to play with so you can learn Exchange in a low risk environment. If you are not familiar with Exchange I cannot recommend this more.

Good luck and memail if you need any specific advice, I've been in IT forever, and it hasn't killed me yet.
posted by 8dot3 at 11:34 AM on November 24, 2008