Blagged IT job - any tips?

Curio

Curio

Curio

Soldato
Joined
14 Mar 2004
Posts
8,040
Location
Brit in the USA
Well, didn't really blag as such. I'm 38 and started a systems admin degree earlier this year. Wasn't expecting to land a job until I had finished, but this "bit of everything" job came along and I got it! It's a small company (15-20 people) and the job is basically helping out wherever I'm needed (shipping, accounts, graphic design, etc) but I'll also be solely responsible for looking after their computers and network. Although I have tons of experience with hardware and client-side stuff, I'm an enterprise sever/network noob. I didn't lie about this to the company - they're cool with it :)

They have two servers. One runs Server 03 and is basically just the mail server, from what I gather. The other runs Server 08 and hosts Sage Business Works, which everybody accesses via RDP.

I was going to be taking classes in all this, however as this job is 40 hours per week I'll be putting my course on hold (do some evening classes maybe, and my A+) so I'll be learning on the job instead!

So, IT professionals, please hit me with some top tips, things to avoid, stuff I should learn ASAP, or anything else that might help me. I'm a little nervous :o

Thanks!

ps. I have Server 08 running in VM at home.....so I can practice before I take the whole company down :D
 
First thing I did when I landed my IT job was set up a domain at home on an old PC with a couple of VMs. Start by messing around with Active Directory, Group policy, etc.

Nothing beats learning by experimenting.

One tip... If you ever make a new account for RDP use, make sure you log in once before the user does. First login can take ages to apply settings and prepare the desktop, and the user assumes it's broken as its just a blank screen.
 
Last edited:
asim18 said:
One tip... If you ever make a new account for RDP use, make sure you log in once before the user does. First login can take ages to apply settings and prepare the desktop, and the user assumes it's broken as its just a blank screen.
Click to expand...

Whaaat. Maybe if you're using hardware from the 80s :p

The first thing I would focus on is creating scheduled backups of both servers and any critical data. That way if you royally screw things up you can revert back and not get a P45.

It's probably a good idea to prepare a diagram of the infrastructure for your own troubleshooting / improvement planning purposes.
 
First things I would do is document the whole network and check the Server loads, backups etc.
 
Check your support contracts with vendors too, if something breaks you'll need to know how quickly you can get it replaced.

Also, as you're "the IT guy" I'd very quickly dispel the usual misconceptions about the guy who works in IT by introducing yourself to your user base. Doesn't have to be in one hit, but for 15-20 people I'd spend 15-20 minutes with each over the course of a couple of weeks. Get to know what they do, how they use their machines and what apps/software they are reliant upon to do their job. It'll help you get a feel for urgency, and allow you to prioritise your work effectively.

Backups and restore procedures would also by high on my list, as well as any steps to recover from a total failure. Health checks on arrays, event logs etc. would give you a good idea of what you're working with.

As Duke says, documentation is also very important. With a bit of luck they'll have some already. If not, get yourself a portable wiki or something and bang it on a USB stick to start off with. When it's sufficient in size, see if you can host it somewhere internally. If they have no central documentation or content server it might be a good call to get one setup. Instead of "everything is stored on my H drive". :)
 
First things first, throw that Server 2003 box in the bin and move your email onto Google Apps. Email is arguably the most important thing to keep running, and having it hosted off-site puts you in a massively better off position should something fatal happen to the server (fire, flood, theft etc). Also if you aren't comfortable running Exchange, which I assume you aren't, you don't want to be the one responsible for it. If it's not Exchange then Google Apps is better anyway so it's an upgrade at the same time.

See what the SLAs are with their current net connection, get the emergency contact numbers for them so you can get hold of your ISP if required, set up some monitoring if none exists already. See what expectations are in terms of disaster recovery, if you're expected to be on site ASAP then negotiate a company phone and some sort of extra pay to cover this. It will also make it a lot easier to get the budget for a server monitoring system in place.
 
randal24 said:
Check your support contracts with vendors too, if something breaks you'll need to know how quickly you can get it replaced.

Also, as you're "the IT guy" I'd very quickly dispel the usual misconceptions about the guy who works in IT by introducing yourself to your user base. Doesn't have to be in one hit, but for 15-20 people I'd spend 15-20 minutes with each over the course of a couple of weeks. Get to know what they do, how they use their machines and what apps/software they are reliant upon to do their job. It'll help you get a feel for urgency, and allow you to prioritise your work effectively.

Backups and restore procedures would also by high on my list, as well as any steps to recover from a total failure. Health checks on arrays, event logs etc. would give you a good idea of what you're working with.

As Duke says, documentation is also very important. With a bit of luck they'll have some already. If not, get yourself a portable wiki or something and bang it on a USB stick to start off with. When it's sufficient in size, see if you can host it somewhere internally. If they have no central documentation or content server it might be a good call to get one setup. Instead of "everything is stored on my H drive". :)
Click to expand...

+1 All good advice - know what you're dealing with before you change anything. The advantage of being the only support tech is that you'll learn their business systems pretty fast - in a bigger organisation IT jobs get compartmentalised
 
Duke said:
First things I would do is document the whole network and check the Server loads, backups etc.
Click to expand...

top tip there, get server names, roles, IP address' subnets routers (and locations of).. passwords line numbers and ISP contact details.. get a list of contacts

get a media library going (with mutiple copys of important CD's)
 
m3csl2004 said:
Is a company of 20 people likely to have a good enough net connection for cloud email?
Click to expand...

you know email is not real time? it does not matter if it take 2 mins for an email to upload or download.... the email client (outlook) does it in the background.... there would only be little bit more traffic than having an exchange server on site (assuminng there is not a lot of staff to staff emailing of large attachmants)
 
forgot to say check nothing integrates with exchange and the calendar integration would need some proper testing if it was an important function
 
You must log in or register to reply here.
Back
Top Bottom