Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: IT Staff Handovers -- How To Take Over From an Outgoing Sys Admin?

Soulskill posted about a year ago | from the don't-use-the-words-lame-duck dept.

IT 195

Solar1ze writes "I've just started a role in an IT services firm. I'm required to take over from an incumbent who has been in the position for three years. What are some of the best practices for knowledge transfer you have used when you've taken over from another IT staff member? How do you digest the thousands of hosts, networks and associated software systems in a week, especially when some documentation exists, but much of it is still in the mind of the former worker?"

Sorry! There are no comments related to the filter you selected.

There is only one way... (2, Funny)

Anonymous Coward | about a year ago | (#44460277)

Hope to Christ he took good notes.

Re:There is only one way... (5, Insightful)

icebike (68054) | about a year ago | (#44460481)

Hope he is leaving on a good note, and not holding grudges.

Then systematically go through each machine for which he has a password and have him record these in some secure password vault application of your choice. And also any root passwords he has. Passwords to routers, print-servers, off site corporate backups, corporate accounts (supplier's web sites etc), certificates owned, domain names, email accounts, etc. (You'd be surprised how many small to mid sized businesses wake up two years hence to find their website unreachable because the renewal went to some gone-guy's inbox and/or bounced).

Go over the system layout (map of the network, interconnects, lans, NAS's, servers, etc), and for EACH NODE, ask if anything has been changed since it was created. If you ask if the document is up to date, he'll just say "pretty much" but if you go over it one router at a time, he will remember things that don't appear in the notes for one reason or another.

But mostly pray he's leaving happy, and not pissed.

Re:There is only one way... (5, Insightful)

khasim (1285) | about a year ago | (#44460643)

If he is leaving happy, get his contact info and ask if you can check in with him in the future if you have more questions.

Most of the issues I've run into over the years did not center around HOW something was done but WHY that particular design was chosen. Usually there's one or two weird items at every site that the rest of the system has be designed to accommodate.

Re:There is only one way... (3, Insightful)

thereitis (2355426) | about a year ago | (#44460879)

You might get a couple of freebies with his contact info but I suspect it'd be better policy for an installation this size to set up a paid arrangement with the outgoing sysadmin. I'm not in IT so I don't know what precedents there are around this, but relying on him to reply for free just seems against human nature.

Re:There is only one way... (0)

Synerg1y (2169962) | about a year ago | (#44460915)

It may sound completely foreign to you but some people take pride in their work and accept responsibility for what they do and are thus available after they leave to help with stuff they've done. My rule is if its only something I'd know I'll answer, if its an under-sight or technical incompetence, or just pure laziness, I don't respond. I've also never answered a cold call from a former employer. If it's important enough they can leave a voicemail.

Re: There is only one way... (2, Insightful)

Anonymous Coward | about a year ago | (#44461015)

While I take pride in my work, all my efforts have to be compensated. I am just like any other business.

Re:There is only one way... (2)

egamma (572162) | about a year ago | (#44461289)

You might get a couple of freebies with his contact info but I suspect it'd be better policy for an installation this size to set up a paid arrangement with the outgoing sysadmin. I'm not in IT so I don't know what precedents there are around this, but relying on him to reply for free just seems against human nature.

This is great advice. A two-week after-hours contract with the admin for after he leaves is a great investment.

Re:There is only one way... (1)

Darkinspiration (901976) | about a year ago | (#44460967)

Do remember that with time is memory will wane. Your contact info might not be the salvation hoped. Dont forget to check any automated task setup. It's always annoying to be paged at 3:00AM because some automated script does not have it's expected input.

Re:There is only one way... (4, Insightful)

Spazmania (174582) | about a year ago | (#44461301)

If he's leaving happy, ask him (and your boss) to work out an hourly consulting rate so you can reach out to him for the next few months and he'll be properly compensated for it.

Re:There is only one way... (5, Insightful)

houghi (78078) | about a year ago | (#44460897)

But mostly pray he's leaving happy, and not pissed.

That is basically with every person you need to replace.
If this is an issue at IT level, it will be an issue at every level.

If it is an issue, then the 'hit by a bus' problem will also exist.

At every company I have worked, I see it at some level. Only one person responsible for some task. Sales rep who is the only person who has contacts with specific customers. HR person the only one who does salary. Accountant the only one who knows the password to critical files.

The first thing I try to do when I get at a company is to get away from the 'This is my problem/customer/whatever' and go to 'This is the companies problem/customer/whatever'. This will not be easy for people who feel insecure.

Try to ask 'what department is responsible for ...' instead of 'who is responsible for ...'. And remember : Graveyards are full of irreplaceable people.

Re:There is only one way... (4, Insightful)

icebike (68054) | about a year ago | (#44461053)

The big difference here is that some filing clerk or HR drone, or Sales exec leaving, pissed or not, does not put your entire infrastructure at risk.
A pissed sales exec might try and take his customers with him. The HR drone won't be missed, they are a dime a dozen.

But the Sys Admin, leaving pissed, can put you in a world of hurt by just changing his phone number, not doing any skulduggery.
A vindictive ex-sysadmin can put your company down for the count months or years in the future, when you least expect it, from a cafe in Puerto Viarta.

Re:There is only one way... (1)

neye_eve (212185) | about a year ago | (#44461743)

"And remember : Graveyards are full of irreplaceable people."

Man, I wish I had mod points to give today, because that's a pretty awesome quote :-)

Re:There is only one way... (1)

Synerg1y (2169962) | about a year ago | (#44460973)

Everything here with the addition of asking why something was done the way it was if you're unfamiliar with it.

Re:There is only one way... (3, Insightful)

Penguinisto (415985) | about a year ago | (#44461009)

Some other bits:

First, oddball configs - that is, take notes on any custom settings and processes.

Nothing is more irritating than to troubleshoot something, only to find that the configs are some goofball way-out-of-the-ordinary rigging that somehow works in spite of itself. Or worse, discovering that what looks like a straightforward deal becomes a messy multi-day-outage when you try to fix it according to best practices.

Sure, you can build-up a replacement that has far better/standard configs, or put together better processes... But that doesn't help you out when $system is down and your users want it back *right now*. It's better to at least get some insight into why it was set up the way it was, and you can then plan of rectifying that before it goes down (and as a bonus, knowing how and why it's rigged like it is, making t-shooting a lot easier to do.)

Also, I'd get some insight into what projects he had planned and in process - those will give you some insight into what you yourself will really want to pay attention to. For instance, if there's a backup improvement project planned, it may well be because the existing backup solution either sucks balls, fails any integrity checks you may have, or is about to collapse any day.

Finally, sit the admin down and go over all vendor-supplied services and service contracts (service, certificates, etc), and find out what's about to expire. It would kinda suck if you have your SAN (or worse, core switch, Oracle DB product, etc) crap out, then discover that the platinum 4-hour service contract attached to it expired a week after that guy left... per-hour charges are brutal, parts are moreso, and if your company does the whole PO thing? It's gonna suck.

Overall though - wring that guy's brain out, and record it to audio if you can. It'll save you a lot of headaches down the road.

Re:There is only one way... (3, Interesting)

cusco (717999) | about a year ago | (#44461447)

One more thing that I would add, something non-technical, is ask the outgoing guy who in the organization has caused him the most problems. It might just be the idiot CFO who thinks the Sys Admin is the one that needs to fix his laptop when the latest version of AOL has hosed it, or the branch manager whose answer to every network issue is to yank the power plug on the router to reboot it, but sometimes it can be more troublesome, like the mainframe admins who deliberately try to obstruct projects carried out by the Windows admins. Get a really good handle on the workflow, ticket tracking, and reporting requirements as well (I didn't and am still floundering sometimes).

Re:There is only one way... (2)

rickb928 (945187) | about a year ago | (#44461751)

Assuming you both can find or figure out or guess each device's existence.

Without a current inventory, you are probably doomed. Something will be missed.

I've left a couple of positions on bad terms, but never, never refused any information. I've inherited several positions, and at least half of them were give to me with the incumbent angry as hell. Anyone remember the Emergency Boot CD? I used EBCDs during the NT era lots of times to hijack the Administrator's account on PDCs and BDCs after hostile dismissals. Windows Servers presented bigger challenges. Novell Servers were lots o fun, but doable.

Cisco stuff was the worst to get into in the absence of the previous admin. Most of the time I got lucky and had running.config files hanging around, and I got so I would scan for common config files right up front. Wireshark and other protocol analyzers came in handy to literally scope out networks and links to see what was going where. Once I rummaged through purchase histories to find out what was actually at a coloc and get prepared for going in to figure it out.

But I've never held up a former client. I've taken calls 2+ years after a gig and answered questions. It's unprofessional to do otherwise.

How To Know Coming In (1)

djupedal (584558) | about a year ago | (#44460285)

Ask to see the last year's quarterly reports that went to Department Supers with signing power over budgets.

Only one week? (3, Funny)

Anonymous Coward | about a year ago | (#44460315)

Run like hell....

Re:Only one week? (0)

Anonymous Coward | about a year ago | (#44460953)

The coward has spoken!

(I bet AC needs former admin to show him how to log in to his PC (wtf is AD???))

Re:Only one week? (1)

aix tom (902140) | about a year ago | (#44461607)

Well, you would definitely need the former admit to show you how to log into something *if you don't have the password*.

That's the one main problem I had taking over stuff from "disappeared" people. The other being something like "something happens every night at 03:00 that processes some data in a DB or on a network share, but nobody knows from where it is run anymore"

It is of course possible to get into systems without a password, or figure out what data flows around the different servers by doing network traces, etc..., but it usually turns things that would taken a few minutes into jobs that take a few days.

Hire Me! (1)

zenlessyank (748553) | about a year ago | (#44460319)

And just give me your paycheck that you would have collected, and we will pretend you didn't ask this question. Obviously your new boss is an idiot.

Re:Hire Me! (0)

Anonymous Coward | about a year ago | (#44460719)

And just give me your paycheck that you would have collected, and we will pretend you didn't ask this question.
Obviously your new boss is an idiot.

I was thinking the same thing as soon as I read the article summary. If the incoming system administrator has to ask the question either the organization has no written policies or the manager is a fool for hiring the new employee. The simplest answer to the person's question...ask the current system administrator whom you are replacing.

Start with Foundational Systems: Network, DNS, (2, Informative)

Anonymous Coward | about a year ago | (#44460325)

Did this recently. Started with core network topology documentation, moved on to DNS. Foundational stuff. Documenting subnets, figuring out what documentation and systems should be deprecated. Made lots of diagrams. Reviewed monitoring tools. Prioritized systems by importance to review for best practices. Got a network security audit to find holes. Bam.

Re:Start with Foundational Systems: Network, DNS, (4, Interesting)

skids (119237) | about a year ago | (#44460853)

Yep, whenever you change core IT people, you have them do a sloppy braindump if possible before they leave, and you clear the new guy from almost every task save updating the documentation and diagrams, with a few mundane tasks thrown in to get procedures down. This means you postpone your big projects if you have a staff change instead of expecting the new guy to shoulder that. Skillsets are not the same as in-situ knowlege.

take over (0)

Anonymous Coward | about a year ago | (#44460333)

hope they have documents

Re:take over (1)

sabri (584428) | about a year ago | (#44461465)

hope they have documents

If they don't just ask your local NSA guy, I'm sure he'll be able to help out with some diagrams and backdoors to your systems.

shadow while you can and guesswork there after (0)

Anonymous Coward | about a year ago | (#44460335)

Unfortunately if he / she hasn't already done due diligence documentation there wont be time.
I suggest you spend 50% of your new job for the first 6 months documenting or searching for documents.
Then document as if you might be killed in a car accident on the way home to work and your manager has to take over.

Re:shadow while you can and guesswork there after (2)

tqk (413719) | about a year ago | (#44461527)

Then document as if you might be killed in a car accident on the way home to work and your manager has to take over.

I've never understood why any admin would care about this. If the employer is too cheap to realise they need support in depth to actually be supported, why should I care about the operation going tits up if I get taken out by a bus? They gambled knowing the risks and lost. Suck it up.

Real support is more than one over-worked wizard who knows and controls everything (cf. San Francisco). I want to be training a PNG into the position who can learn, who I can bounce ideas off, who comes in with a different perspective and history from mine, helps with the drudge work, and takes over when I'm not there (sick, recovering from an outage, holidays, bus error).

Any employer who can't see this can go fsck themselves. You get what you pay for. You gamble wrong, you ought to lose your shirt.

Re:shadow while you can and guesswork there after (1)

1s44c (552956) | about a year ago | (#44461653)

Some companies can't afford 2 sysadmin people. It's not that they are deliberately gambling, they are doing the best they can with limited money.

Obviously this only applies to tiny or failing companies.

Re: shadow while you can and guesswork there after (0)

Anonymous Coward | about a year ago | (#44461655)


Get all the passwords! (0)

Anonymous Coward | about a year ago | (#44460347)

One rule to rule them all: get the passwords!

Ideas (4, Insightful)

funky49 (182835) | about a year ago | (#44460349)

Primarily, you'll want to build an honest rapport with the other person. Get inside their head a little and allow them to brag A LOT. Ask how they found the place and what they did to change it. You'll want to breeze through all of the high level and important documentation first so you'll have a baseline. Take as much notes as you can. Ask what websites/resources they use to make it easier to follow in their tracks. Explain your situation to them. It will humanize yourself in their mind and you might be able to engage their compassion for you. Perhaps they would be available to answer questions after they leave! Is there budget money for them to be used as a compensated resource? Hopefully they like the idea of helping others and putting some scratch in their pocket.

Bon chance!


Re:Ideas (2)

cbelt3 (741637) | about a year ago | (#44460409)

Good approach. Making a mortal enemy of the outgoing sysop, or simply his object of scorn, will screw you badly.

Other than to say "you're screwed", the big step is to also ramp up the professionalism and start building a better system governance policy and documentation process. The best way to explain that to management is to ask "Do you fail the Hit By a Bus Test? ".... If your key administrators are hit by a bus, will your systems go dark ?

Re:Ideas (0)

Anonymous Coward | about a year ago | (#44460629)

You are still no where near qualified to fill his shoes. You were hired because your boss thinks cheaper is better, that a 2 year degree is sufficient to do anything in IT. Since you really don't know what the outgoing sysadmin was talking about while you took notes, and after you wrote down all the passwords, you MUST berate him in order to save face with your boss. You MUST hide the fact that you are an idiot. "He refused to tell me _____ and _____, in fact the passwords he gave me don't even work!" (hides notes in drawer).

Re:Ideas (1)

AmiMoJo (196126) | about a year ago | (#44461063)

In software development we have something called the "code mocking [] ". There must be something similar for network admins. As well as gaining an understanding of how the network operates you will also acquire a stockpile of excuses for when things go wrong. Blaming the last guy is industry standard best practice.

A week? (1)

Doug Otto (2821601) | about a year ago | (#44460367)

On my current gig, I got one day...

Re:A week? (0)

Anonymous Coward | about a year ago | (#44460439)

One place I started at I had -1 month, company had hired a contractor to cover until I started, he didn't know much!

Is upper management the real problem ? (1)

Anonymous Coward | about a year ago | (#44460381)

Who the hell manages to become responsible for 1000s of systems and networks without being forced to document them as part of their job ?

BTW, is this a voluntary or involuntary job move by the outgoing person ? That's going to affect the quality of data you are going to receive.

Re:Is upper management the real problem ? (2)

David Gerard (12369) | about a year ago | (#44460535)

Who the hell manages to become responsible for 1000s of systems and networks without being forced to document them as part of their job ?

Lots of people. Welcome to system administration! Here's your accordion.

(I spent three years documenting furiously. We finally got a third sysadmin. He found my notes incomprehensible. Sigh.)

Re:Is upper management the real problem ? (0)

Anonymous Coward | about a year ago | (#44460705)

I spent three years documenting furiously. We finally got a third sysadmin. He found my notes incomprehensible. Sigh.

This is the difference between taking notes and creating documentation. Taking notes is not worth anything to anyone, including the one writing, because several months or years later no one will be able to make sense of them. Documentation is much more formal and does not leave room for interpretation.

That being said, even when you have documentation people rarely update it until after they have already had a problem which required it.

Re:Is upper management the real problem ? (1)

1s44c (552956) | about a year ago | (#44461735)

Lots of people. Welcome to system administration! Here's your accordion.

(I spent three years documenting furiously. We finally got a third sysadmin. He found my notes incomprehensible. Sigh.)

How? Did you write them in Russian or doesn't he understand the systems he is paid to manage?

Re:Is upper management the real problem ? (1)

1s44c (552956) | about a year ago | (#44461705)

Ineffective companies don't ask for documentation. In my job I document because I believe it's the right thing to do. If I never documented anything management wouldn't notice the difference. I suspect no-one currently there even understands my documentation but if I quit the next guy should.

The old team won't help you as you think they will (0)

Anonymous Coward | about a year ago | (#44460393)

They will be out the door. You can ask for the world, but really you'll get nothing. Get what you can and plan a path forward. I've done it three times, after six months or so it dies down. Start documenting things you find, port maps, cubes, etc. Create what you don't have. Switch your hours so your working 1-2 hours yours users are not per day. During that time you will get more done then the other 6-7 hours of the day. Good luck.

Re:The old team won't help you as you think they w (1)

1s44c (552956) | about a year ago | (#44461765)

Switch your hours so your working 1-2 hours yours users are not per day. During that time you will get more done then the other 6-7 hours of the day.

I do exactly that. It's the best productivity advise ever. I also try to work weekends instead of weekdays some of the time just to get a better thoughput of work.

Step 1: Get Off Of SlashDot... (1)

xxxJonBoyxxx (565205) | about a year ago | (#44460397)

>> How do you digest the thousands of XXXs in a week?

Dude, step away from SlashDot RIGHT NOW.

Re:Step 1: Get Off Of SlashDot... (0)

Anonymous Coward | about a year ago | (#44460685)

If they were a competent admin monkey, they wouldn't even ask this question, but would be asking why the existing one hasn't been marched from the building as soon as they handed in their notice. But seeing as they're only talking about one, it's obviously a tin-pot outfit and admin duties are basically changing tape backups and feeding printers with paper, plus the obligatory Have you troid, toirning it off and oin again?.

Create your own documentation (3, Informative)

schneidafunk (795759) | about a year ago | (#44460399)

I would start by writing your own manuals and have the outgoing person review them.

Re:Create your own documentation (1)

Great Big Bird (1751616) | about a year ago | (#44461035)

Reminds me, I should start writing documentation :-).

Just learn the important stuff (0)

Anonymous Coward | about a year ago | (#44460401)

Find out which systems or processes breaks the most and learn them, this is where most of the support will come from.
Learn the other systems later when needed.

Re:Just learn the important stuff (1)

trevize42 (1086179) | about a year ago | (#44460511)

Lol good luck!! A few years ago when I left the company I worked for when a certain very large bank that was taking over the very large bank I worked for.. I took the package. They sent a Unix (AIX) admin to come learn about my 400 (ish) Solaris systems. Most of which where Oracle RAC and VCS Clusters. This poor AIX guy knew nothing of Solaris, Oracle or VCS. All the documentation in the world wasn't going to help him. So, I did what any self respecting UNIX guy did. I told the very large bank what my very large hourly rate would be going forward after I left and gave them all the help I could for the next six months while they found a Solaris knowledgable UNIX admin.

You're Doomed! (0)

Anonymous Coward | about a year ago | (#44460411)

Give up now - one week is useless. Just kick them to the curb and take over - about as good!

Questions (2)

whitelabrat (469237) | about a year ago | (#44460417)

Take over right away. Don't let him do anything. Ask lots and lots of questions. Take notes.

1. Get da passwords. Verify them.
2. Support contracts.
3. "What are common problems"
4. "Can I get your email" :)

Things to do (4, Funny)

Anonymous Coward | about a year ago | (#44460419)

Make sure you have thick gloves and sanitize everything. Check for booby traps. Never push any buttons till you've traced the wires back to their origins.

Depends on a few things... (1)

Demoknight (66150) | about a year ago | (#44460425)

Where did this "in a week" concept come from? You or management?

Depends on how big of a company this is too - are you in a team? - are you tier 2 with a helpdesk underneath?

Anyway, slow down and be realistic. Focus on the users of the systems (your customers) and not the systems themselves and you'll be fine.


Re:Depends on a few things... (1)

SuricouRaven (1897204) | about a year ago | (#44460647)

A sudden transition implies the previous administrator is either leaving unhappy, did something to get fired, or died without warning.

Re:Depends on a few things... (1)

Jeff Flanagan (2981883) | about a year ago | (#44460835)

A week of transition indicates the present sysadmin wasn't fired, and hasn't died. It usually means they found something better and are moving on.

Re:Depends on a few things... (1)

idontgno (624372) | about a year ago | (#44461021)

A week of transition indicates the present sysadmin...hasn't died

I think you're seriously underestimating how screwed up management expectations could be.

"Look. He hasn't actually started decomposing in earnest yet. I'm sure he'll tell you if you ask him nicely."

Although it might take an hour or more.. (1, Insightful)

JeanCroix (99825) | about a year ago | (#44460429)

Eat his brain. Just be careful of kuru.

Thousands of Hosts? (1)

krelvin (771644) | about a year ago | (#44460435)

If they don't have them documented... good luck.

Re:Thousands of Hosts? (1)

Anonymous Coward | about a year ago | (#44460637)

If they don't have them documented... good luck.

Even if they do have them documented; one sysadmin, thousands of hosts? Holy shit. Here is a very important question to find the answer to: why is the current sysadmin leaving?

happend to me this year (3, Informative)

sdinfoserv (1793266) | about a year ago | (#44460437)

1) Need passwords... immediatly change them.Exiting person should have no futher access except through you.
2) Require exiting person to produce network diagram. Make it their last duty if one doesn't exist.
3) Now starts the pain... audit devices and systems for rogue accounts.
4) document as you go.
5) turn in passwords to supervisor.
Good Luck

Re:happend to me this year (1)

sconeu (64226) | about a year ago | (#44461133)

ha ha ha ha....

2) Require exiting person to produce network diagram. Make it their last duty if one doesn't exist.

"What are you going to do? Fire me?"

Wiki everything. (1)

lasermike026 (528051) | about a year ago | (#44460451)

The only way to address an information void is to fill it with good information. Hopefully everything is standardized.

Let them teach you (1)

Kookus (653170) | about a year ago | (#44460503)

The incumbent will know what to teach you if you only have a week. If they are leaving on good terms, they probably won't be adverse to having some questions asked by email after they leave, so it's not the end of the world after 7 days.

I've left jobs almost a decade ago and still get an occasional question once or twice a year. It's not that it wasn't documented or couldn't be solved through a few hours of investigation, it's just that a 2 minute email and a 2 minute response later you get your answer and move on. Much more efficient. Sooner or later, the questions stop, and they are self sufficient.

Keep them on consulting (2)

David Gerard (12369) | about a year ago | (#44460507)

Keep them on as a consultant, and *pay* that $$$ per hour when you need to.

(This assumes they are quality folk in the first place, of course.)

Secret Server (1)

cascadingstylesheet (140919) | about a year ago | (#44460509)

Secret Server (or something like it) is very cool. Get the outgoing person to put all the access passwords, locations, etc. for every bleeping system in it.

Then change the master password after he leaves.

Time for a little social engineering (1)

ALeader71 (687693) | about a year ago | (#44460513)

If possible, build a relationship with the outgoing administrator. Accept that a lot of his head knowledge will dissipate soon after he leaves the company but it wouldn't hurt to have him as an information resource for the first few weeks, just don't abuse the privilege. If he's moving on to another job, his loyalties and focus will be to them not his old company.

Get his permission and comb through his corporate inbox and home directory -- dump it to an offline location. I know you don't need his permission but a little humble pie goes a long way. Again, don't abuse the privilege. Burn a little overtime and construct your own documentation from whatever you find. Let your new supervisor know you're going to bill overtime and why it is necessary. A little work now will make your holiday season a lot smoother.

I did this in my first LAN Admin job. Within four months I was able to take off to the Caribbean for a week and I never received one phone call.

Ask (1)

jameshofo (1454841) | about a year ago | (#44460521)

Ask about the problem children and squeaky wheels (regarding to servers), that will get you down to the one-off fixes that are held up by bits of string and expect scripts that rely on chaining ssh across 5 machines to touch a file that doesn't exist. Ask about the oldest equipment, and spend some extra time getting to know your world. Leverage the time you have with him, when he goes home for the day scour the network and start looking at boxes and going over notes, when you run into problems write them down and ask him about those.

And you dont have a week you have 4 days, because the last day he may show up but you most likely wont get much out of him unless its a quick Q and A. That and keep your resume up to date because you may want to use it again soon.

Look out for outsoureing pit falls with this (1)

Joe_Dragon (2206452) | about a year ago | (#44460563)

Now if the old guy worked for the IT services firm then you should not have the outsoureing roundabout in the way.

But if they worked at the place that the firm took over then there may be paper work / other things that get in the way like some things that the old IT guy used to work on are now not part your IT firm systems or things that you control / are part of your pricing.

Or other stuff the like the non manged box that does not have uses log to in but runs say the phone switch or the one that runs the door systems that if they get put under the domain / your over IT plan for uses they will fail or will end up being that box needs to be tied to user or it may get kicked off or out of the network / office.

WHAT!? (1)

Anonymous Coward | about a year ago | (#44460565)

NO ONE here suggested the most expedient and obvious solution - the Vulcan mind-meld!
Aside of that, ask LOTS of questions, take LOTS of notes. You only have 5 days.

Get most important stuff first. (3, Informative)

jellomizer (103300) | about a year ago | (#44460579)

The first thing is to figure out what are the Most Mission Critical systems, and cover them in order of priority, really try to press the criticalcality of the system.

Top Priority: Systems where there is a Downtime has an immediate impact. There is NO Work Around, it needs to run
High Priority: Systems where there is downtime work around and they can tolerate it down for a few hours while you mess with it
Medium Priority: Systems that can be down for a Day
Low Priority: Systems that can be down longer then a day

Try to get the passwords, or make sure you have a passwords and rights to all the systems work in order of priorities.
Create a network map, inventory every system, switch and router... Make sure you have access to them.
Find the Power Users in the area, they may be able to help you out later on, they may not know everything the sysadmin does but they know their little section and sometimes has tips and tricks that don't get passed on. If there is an issue after he leaves you have contacts.
Get the vendor support numbers if available.
Working in order or priority find the custom stuff programs/scripts etc... Do an overview on what they do, what language affect what systems...
On the second to last day, shadow the old admin, on the Last day do everything, he should only mentor.

After he leaves. CHANGE ALL THE PASSWORDS he knows, and check for back doors in the network to prevent him from entering the system.

Due to short time of transition you will probably stumble a bit, but you should have enough to hit the ground running.


beer (2)

NikeHerc (694644) | about a year ago | (#44460601)

Make sure the person leaving knows you'll buy him or her a beer or two when you have a question you can't figure out on your own in reasonable time.

Re:beer (0)

Anonymous Coward | about a year ago | (#44461187)

Unprofessional, see the comment about a paid source

Re:beer (1)

dpidcoe (2606549) | about a year ago | (#44461685)

Every IT department I ever worked in was the definition of "unprofessional", as least as far as most peoples definitions were concerned. jeans and a t-shirt featuring a metal band were standard despite the business casual dress code, sometimes someone would wear a polo shirt if they were feeling particularly formal.

How to get what you need: (1)

Anonymous Coward | about a year ago | (#44460617)

Step 1. Kidnap his wife/girlfriend
Step 2. Tell him the only way he'll see his Significant Other is if he gives you all the information and passwords you need.
Step 3. Torture his SO, and then call him up and let him listen to her screaming.
Step 4. Tell him that if he tries to call the cops you'll torture her to death.
Step 5. Wait for him to give you the information and passwords.
Step 6. Kill him and his SO. Don't leave any evidence. Don't keep any trophies. Drop the bodies off in a predominantly African-American ghetto to reduce the likelihood of a serious investigation.
Step 7. ???
Step 8. Profit.

Re:How to get what you need: (1)

CelticWhisper (601755) | about a year ago | (#44460929)

The twist: He's already kidnapped yours, too.

Re:How to get what you need: (0)

Anonymous Coward | about a year ago | (#44461303)

False. He has no wife/girlfriend.

break something (0)

Anonymous Coward | about a year ago | (#44460631)

fastest way to learn

Use some tools to Dig the Network (0)

Anonymous Coward | about a year ago | (#44460659)

If there is nothing else, you can Dig your network with some Autodiscovery software, Whatsup Gold for example will do the trick.
I can use Layer 2 and Layer 3 tools to map your entire network, probably you can see or reset snmp passwords on your devices and help the thing a lot.

Two letters (0)

Anonymous Coward | about a year ago | (#44460713)

Your predecessor should hand you two letters.

Open the first at the first crisis, it should read something like: "Blame it on your predecessor"

At the second crisis, you should open the second letter, which should read "Write two letters...

Vulcan Mind Meld (1)

stox (131684) | about a year ago | (#44460789)

It is the only way to be sure.

Record everything (1)

SlamMan (221834) | about a year ago | (#44460807)

Every conversation you have with the outgoing admin, record (with permission, of course). When they're showing you something a workstation, screen capture it. Write notes up for all of this the first while its still fresh. Have them walk you through each server, each device, and all the issue with it. You won't remember everything they've said, and they aren't going to do as great a job documenting things as you'd like during their last week, as they're head's already out the door.

An Ideal handover...? (0)

Anonymous Coward | about a year ago | (#44460823)

I may be reading too much into the OP's statement but I get the impression that the sysadmin may be the walking repository of knowledge for IT in that organisation.

That is A Bad Thing.

Why? Because everything that sysadmin knows should exist in a system accessible to the successor. Infrastructure should be documented. Business value and use should be described. Change records since implementation should be available. The successor should be able to recreate and describe the current state (or at least a recent last known good) from the body of knowledge.

It's understandable that some organisations don't go the full ITIL, but some kind of record keeping would be expected. That means that any handover could be limited to training the successor in the systems and processes unique to the role and a walk through of a transition document outlining what is where.

If such a body of knowledge is not readily available the successor should make it a first priority and an agreed short-term objective to baseline the systems while detailing to their line manager why this is required and the risks arising from effectively building a picture of the business' IT from scratch.

DR (1)

raind (174356) | about a year ago | (#44460871)

One good way to learn the new environment is to test any existing disaster recovery procedures, you will find out quickly what's important and things that don't work.

Very difficult but possible (0)

Anonymous Coward | about a year ago | (#44460911)

1. Know the bau issues, and how to fix those.
2. Know the architecture and at least 4 day to dy work.
3. Get the passwords and check
4. Get thwe name of most priority systems and understand the pain ares.

It sucks from the other side, too. (1) (245670) | about a year ago | (#44460917)

When I quit my last job, I was there for 5 weeks after saying, "I'm gonna go ahead and leave." I said I could stay as long as they needed to have a smooth transition but that was clearly a mistake. 2 weeks in, absolutely nothing had been done to transfer my tasks so I set a firm date for 3 weeks later. Had all my tasks documented but no direction on who would take over. Another week goes by. "Who is taking over these tasks?" And another. "Who is taking over these tasks? I would really feel more comfortable walking them through their first week." [cricket_chirps] A couple days before I left, I emailed my documentation to the remaining department employees with one last reminder that, even if everything else is ignored, backups and archiving are very important and require daily attention. I assume they figured things out without catastrophic failures because they're still around.

Ask Slashdot: Do my job! (0)

Anonymous Coward | about a year ago | (#44460923)

I don't belong in a sysadmin role because I can't use available software tools to document the system setups myself. Help me, slashdot! Do my job!

How many admins are there? (0)

Anonymous Coward | about a year ago | (#44460931)

A lot of the posts assume you're replacing the only sys admin there is, but if you're joiningt a team and only going to be responsible for part of it then there's different questions to ask.

My straight answer... (1)

abirdman (557790) | about a year ago | (#44460957)

I have been doing this for the last 18 months, since our sys admin was terminated. Write stuff down. Find a secure place (or two) on the network to store an Excel spreadsheet with IP addresses, dns names, and credentials for servers, databases, routers, printers. Encryption keys, vendor support websites. Save root, administrator, and sys passswords, and any other admiinistrivia, in some sort of order you can decipher in 3 months at midnight. I use worksheets to identify categories of information.. It's probably more secure to not keep this stuff all in one spreadsheet, but the fact is the document becomes a corporate asset. You can be the keeper of it, and the central answer person--lots of parties need that kind of information. Back it up, encrypt it, whatever. Where I work, only the CIO, two database admins, and the network admin have read permissions on it. Do not print it out, or carry it on a usb stick that can be misplaced. It's an admirable gesture, but probably masochistic to try and store this information in a secure database, because that may run on the server that goes down at midnight when you most need that list. Plus it's freeform-- we keep different columns of data for OS's, servers, cert keys, routers, databases, etc.. It's also nice to have it handy and organized, so you can paste it into vendor inquiries. Saves money and consternation next time you don't have to look up the info ad hoc. It's easy enough to find out the MySql version, but when there are 10+ servers, you will be glad you've got it in one spreadsheet.

Save model numbers, sales staff information, customer contacts, warranty information, service contracts. Also record server software versions. It's easy to remember if you just bought it, but in two years, you will be glad you know It's Oracle and not just 10g. All the big IT suppliers-- Oracle, Microsoft, HP, Dell, NetApp, SAP-- have their own twisted bureaucracies, ticket tracking systems, incident reporting and escalation, and lines of communication. Put as much of that info in the spreadsheet as you can. You can even embed links to support sites in Excel.

Try and figure out which servers talk to each other, which have dependencies and would be affected by an issue with another server. It's good to learn the network topology-- which equipment and services are in which segment and why. Where does the internet come in? Try not to work too late. Don't carry a gun to work. Be nice to the users. That's about all I've got.

Collaborate with outgoing on a runbook (1)

idontgno (624372) | about a year ago | (#44460993)

Seriouly, there's no hope you'll actually be able to cram everything you need to know into your brain and make it stick. You need runbooks [] .

Here's a Technet Article [] on how to put together a Windows server run book. You'll also be able to google for Linux or Unix examples, although you'll find mostly snippets focused on how to write a runbook section for one specific product or another.

A high-level runbook should document overall systems architecture: network layering, external and important internal connections, service agreements, contacts, roles and responsibilities. The per-system runbooks should focus on configuration details and functional description (why the server is in the architecture). Per-service runbooks crosscut servers and describe how a particular service is deployed, started, stopped, upgraded, etc.

It's a lot. If you don't already have a lot of this, start now. If you do, get it current and updated now.

Map the network (0)

Anonymous Coward | about a year ago | (#44461025)

There is a Linux tool called netmap (package netmapr on RHEL systems, in the rpmforge repository). It will help you build a graph of the hosts and connections on the network. That's a good place to start. Also, look at the configuration of the local hosts in your local DNS server (assuming you have one, right?).

Reverse engineering (1)

ls671 (1122017) | about a year ago | (#44461075)

Overview the available documentation, talk with the guy if he is available. A lot of times I ended up reverse-engineering everything although so be ready for that possibility.

Think about what you need and set the pace (1)

rathaven (1253420) | about a year ago | (#44461087)

I had to do this after a company ran for 6 months without an admin and with no documentation whatsoever left for others. From when the sysadmin left to when I arrived, most things went to rack and ruin with only some developers doing a little sysadmin on the side. In the end it took nearly the same amount of time as the time that the company was without an admin to find out the information or rebuild what couldn't be salvaged.

I have to say that it gave me a lasting impression of what a company can lose when handover fails.

Luckily, I've also had some good handovers and the best way I've found to do it would be to book the whole week as a workshop. Nothing the outgoing staff member can do is more important than the handover and it can often create a level of goodwill in that you are asking for their assistance and making them realise how important they have been.
However, there are also some rules to the week. Some apply to you - you need to check what you are being told. Anything that starts to look hinky or just plain wrong needs to be constructively challenged. If it still doesn't add up after a challenge and you know they are lying then you need to get them on garden leave as soon as you have the keys and passwords.
My approach for general sysadmin has been to try to understand the systems from the ground up very quickly and I've found it useful to have the following as general headings:

1) Passwords - where they are, how they are kept, what policies are in place? Generally find out how it has been managed in the past. Most important - verify them.
2) Network diagrams - use network scanning and mapping tools to verify what you are finding
3) Infrastructure services - understand the setup for anything important to the infrastructure of the systems. Things like DNS/DHCP/NIS/Kerberos/Pam/LDAP/AD/Certificate Authorities/Identity Management/etc/etc.
4) Storage services - SANs/Makes/models/Where to find support contracts/BACKUPs/Data replications/File stores/etc.
5) Core end user services - File/Print/Core Databases/Core Apps.
6) Cloud services/domain registration accounts/3rd party supplier access

There will always be more to find out but hopefully having a list of what you need can stop your company wasting a lot of time and money in having to rebuild what it can't support.

What if? (0)

Anonymous Coward | about a year ago | (#44461229)

What if you never see the guy like I did, oh, the last three positions I've had? Interviewed, got the job, never saw the guy but inherited his mess. The hiring manager has his contact info but depending on the way he left and the culture of the organization it may be impossible to get much out of the departed. It's been months of finding lovely little "projects" that were turned into production systems. Ugh. I am now gutting the place little by little and instituting proper processes and procedures, as well as detailed documentation. Sysadmins aren't the best at this in most cases. There are usually gaping holes in the docs...sometimes miles wide! Grin and bear it until you can get things righted.

Social aspect (0)

Anonymous Coward | about a year ago | (#44461355)

Win his trust, become his friend. (However annoying or stupid or malevoolent he is.)
That's the basis, without it you will not get any sensible information, let alone light in the dark corners.

I pretty much do this for a living (1)

zacherynuk (2782105) | about a year ago | (#44461369)

(working for an IT Support firm)

Most of the above posts pretty much have it nailed... The point made about WHY things were done is very astute - not just technically but politically.

I would like to add one thing though - do your very best not to slag off the departing sysadmin or the environment – it is a sad fact that IT people get a bad rep and many of them do not deserve it (See the point about WHY things were done) – often this ‘bad mouthing’ starts from the client – but it should not readily be agreed with, unless there are very obvious and serious failings!

Try to think about your profession and the industry as well as your current role and DOCUMENT! & COMMUNICATE!

Wear a helmet. (0)

Anonymous Coward | about a year ago | (#44461391)

This is the service you are providing. Get to work.

As the outgoing admin/developer ... (1)

PPH (736903) | about a year ago | (#44461453)

... for an enterprise critical app at a large corporation (why I wore so many hats is a long story), I was introduced to my replacement with about 60 days to go. I gave him a copy of my 'run book' (you real life admins call them) and showed him where all the requirements and development documentation was. I told him that I'd be redirecting some (easier) administration issues to him and call him in on the tough stuff for the next two months.

Most of the stuff was 'glued together' with Perl. So one of the job requirements for my replacement was an understanding of Perl. So I sit down with him on a simple task and have him look over my shoulder as I patched one of the Perl CGI scripts. After about 5 minutes of his silence, he asked, "What language is this written in?" And there we were, staring at the "#! /bin/perl" line at the top of the script. Things were not going to go well.

As my end date approached, I gave him a copy of a configuration file that managed sending out e-mail/paging on error conditions and suggested that upon my departure, he put his own e-mail address and pager number in there. One of the addresses was my home e-mail account. For the next three years, I continued to get, "The server is up/The server is down" messages.

Some time later, the company outsourced the whole system to an offshore company (Strange, I thought, for a DoD contractor). They found my name in the headers of all the files I had revised (its a rather unique name, easy to Google) and hired me as a well paid consultant to assist them in maintaining the system.

Trust No One - Backup Everything (0)

Anonymous Coward | about a year ago | (#44461617)

First step is plan a maintenance window and shutdown everything and back it up, preferably before they depart and bring it back online. Video tape if possible the procedure the outgoing SysAdmin performs. Assume you will never ever have contact with them beyond this encounter.

Plan the week carefully (0)

Anonymous Coward | about a year ago | (#44461711)

Day 1 - get the passwords and test them all.
Day 2-5 - off site knowledge handover at the pub. Buy the cnut 1 million beers and listen to all his bitching. You'll learn *everything* from the bitching.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?