Taking over support from outsourced IT company

if you were asked to take over as net admin for a small network (~12 servers, 200 clients, 2 locations etc) from an outsourced IT company, what are the first things youd do?
im thinking:
get admin passwords
check firewall accts
service agreements for servers
licensing agreements
log files and records of escalated/recurring issues
ISP contacts?
maybe set up a corp acct with someone like CDWG?
how about drafting a network user policy? are there templates online for this?

storage and email are both done off site. email to be moved in house soon.

can you guys think of anything else?

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Plantwiz

Operating Budget - know how much you have for repairs/replacement and staff. Make a plan to upgrade equipment that is too old or getting to old to keep the company profitable as well as plan for next software upgrades.

Get an inventory of what type of equipment, SN#, install dates (if possible), age of equipment, est expected useful life of equipment.

Evaluate the method users request support and see if that still works with inhouse IT or if that needs to be channelled differently.

All the rest I agree on.

the_Grinch

Best advice I ever received was from a professor in a disaster recovery class. He said he would always do the following:

Setup in a conference room with a large whiteboard
Draw on the board the current network setup
Call in various users at various levels and find out how they do their job
Use the board to fill in gaps on the network diagram

He used this method for a very good reason. Most network diagrams are very much out of date. He liked to see a flow from various people on how things worked and how they did their work. His example was one time he was on site do the disaster recovery planning in which they were going completely IP based. They were about to wrap up this exercise of calling people in, when they had one last user show up. Everything looked good until they found out this user had an application that required a dial-up modem to get in and to send information out. No where was it on the diagram or on the documentation. Had this user not come in, they would have missed this fairly mission critical application.

Other than that, make sure you can still contact the old company for support when needed. Takes about 3 months (from what I see at my company) to have some stability in working on issues for a new client.

Daniel333

Great method above, btw.

We are an outsourced IT, so we do this all the time. Just reversed.

1) Make friends with the person/team you are replacing. Take them to lunch. offer them a few bucks to stay on as a retainer. This isn't always possible, but most of the time it is. No amount of documentation and good intention beats their experience.

2) I love the idea of drawing the network from the farthest points in. Domain admin, firewalls etc are obvious. The ones that we always have to fight for are the external and vendors resources
A) Public DNS

Software support
C) remote user's local admin accounts
D) Shared keys on vpns
E) MSDN accounts

3) Probably the best check lists in the world is the table of contents from your MCSE/MCITP books! Then do your CCNA, CCNA: Security and then Voice. This also helps you build documentation and take note of things when are you are ready to start in on proactive work.

it_consultant

I would check to see why they are releasing their outsourced company. Many times if they can't handle an IT company they are even more poorly set up to deal with an internal IT person. If you can be on friendly terms with the outgoing company, I would ask questions about how users deal with problems, perception issues, etc.

I can't tell you how many times I have heard "that old IT company sucked" and I look in the documentation and see that the company was trying to do the right thing and was beaten down by the client.

SharkyMarky

Congratulations on your new project.

In addition to the things you list on the initial post, here's some items I just thought of:
1- Meet with department heads and senior management to determine expectations and create or review Service Level Agreements/Operational Level Agreements. Everyone on the IT team should be made aware of these, and know their part in meeting the goal.

2- Make sure you have (or begin looking for) a ticketing system adequate enough to track trouble calls, maintenance activities, Install/Move/Add/Change (IMAC) issues, etc. and provide management with the kind of metrics they are expecting to see. I recommend BMC Remedy or Siebel.

tdean

it_consultant wrote: »

I would check to see why they are releasing their outsourced company. Many times if they can't handle an IT company they are even more poorly set up to deal with an internal IT person. If you can be on friendly terms with the outgoing company, I would ask questions about how users deal with problems, perception issues, etc.

I can't tell you how many times I have heard "that old IT company sucked" and I look in the documentation and see that the company was trying to do the right thing and was beaten down by the client.

they just said it was way too expensive and they werent getting the response/support they wanted. im seeing a lot of companies move away from outsourced IT these days for those reasons. i dont think it makes sense for a company of 200+ people to not have an inhouse solution. they are already anticipating problems from the outsourced company, however, they are giving them a 30 day notice.

rsutton

Change all admin passwords, change public DNS / domain registrar password. Meet with management and make sure you understand what they expect of you, the last company may have been falling short in some area, this is likely an area you will have the opportunity to shine in.

This is also your chance to justify spending time creating a baseline run book for your network. The information you gather now will be incredibly valuable to you as you move forward. Stuff I find important to document initially includes logins for everything, network information, device warranty and support information, host names, licensing information and procedural information.

tdean

a lot of good ideas here. i was also thinking of meeting with an electrician to test the emergency shutdown procedure etc. gotta make sure the place doesnt crash in the event of a pwr outage.

tdean

regarding help desk ticketing systems, how does that work? arent they mostly web based? meaning i could install it on a server, then add an alias in dns to "help desk" and people could access it via browser?

tdean

rsutton wrote: »

Change all admin passwords, change public DNS / domain registrar password. Meet with management and make sure you understand what they expect of you, the last company may have been falling short in some area, this is likely an area you will have the opportunity to shine in.

This is also your chance to justify spending time creating a baseline run book for your network. The information you gather now will be incredibly valuable to you as you move forward. Stuff I find important to document initially includes logins for everything, network information, device warranty and support information, host names, licensing information and procedural information.

where would i get that, ISP?

rsutton

tdean wrote: »

where would i get that, ISP?

Whoever registered the domain name would likely have this. Sometimes it's been years since anyone logged in, so you may need to reset it.

tdean

rsutton wrote: »

Whoever registered the domain name would likely have this. Sometimes it's been years since anyone logged in, so you may need to reset it.

ok... i can see im gonna be doin a lot of investigative work.

the_Grinch

Also, don't forget the copiers! We brought on a customer with a copier and software used for scanning. They don't have the software, the password to get into the copier, and no idea how to set things up. Then all of the sudden something doesn't work and you spend the whole day looking for an admin password (if they left it as default, which they usually do) and then figuring out how to make whatever it is work.

Hypntick

tdean wrote: »

regarding help desk ticketing systems, how does that work? arent they mostly web based? meaning i could install it on a server, then add an alias in dns to "help desk" and people could access it via browser?

Some are web based, some are standalone. Just depends on your volume etc. For more info take a look at - http://www.techexams.net/forums/off-topic/62506-tickets.html That has some more info on ticketing systems. I'm familiar with two, Remedy (standalone) and USD (web based), although i'm not a ticket system admin i'm just the end user (help desk)

it_consultant

tdean wrote: »

they just said it was way too expensive and they werent getting the response/support they wanted. im seeing a lot of companies move away from outsourced IT these days for those reasons. i dont think it makes sense for a company of 200+ people to not have an inhouse solution. they are already anticipating problems from the outsourced company, however, they are giving them a 30 day notice.

Outsourcing a company with more than 100 users may not be the best idea unless its to support an already existing IT staff. As a consultant I would worry about taking on a business with that many people.

My experience is that people who go with consultants generally couldn't handle an internal IT person. Its easy to blame the IT person but often the corporate culture is as much to blame. You will have about a month of leeway before their old bad habits come out that caused them to be unsuccessful in the past with IT people and consultants. Use that time to hammer out good and reasonable expectations.

tdean

rsutton wrote: »

Change all admin passwords, change public DNS / domain registrar password. Meet with management and make sure you understand what they expect of you, the last company may have been falling short in some area, this is likely an area you will have the opportunity to shine in.

This is also your chance to justify spending time creating a baseline run book for your network. The information you gather now will be incredibly valuable to you as you move forward. Stuff I find important to document initially includes logins for everything, network information, device warranty and support information, host names, licensing information and procedural information.

this could be a tremendous pain if they are tied to system accounts etc, right?