KEEPING A SYSTEM ADMIN. BOOK 3

[lisabennett]

HELLO,
I AM TAKING OVER THE IT IN MY COMPANY . THE PERSON THAT WAS DOING THIS BEFORE HAD NO BOOK AND WAS PRETTY MUCH DOING EVERYTHING FROM MEMORY.
THIS HAS MADE EVERYTHING I TRY TO DO VERY DO DIFFICULT. I WANT TO CREATE A SYSTEMS ADMIN BOOK, BUT I'M UNSURE OF WHAT SHOULD BE KEPT IN IT. I DON'T WANT TO KEEP TOO MUCH, OR NOT KEEP SOMETHING THAT MAY BE NEEDED. IF YOU COULD SHARE WHAT IS IT YOURS , ID APPRICIATE IT.
THANKS,
LISA

 

[butchrecon]

Well personally I keep a list of day to day activities (Things that should be done). I keep all the network settings. Then I keep in my note book problems and solutions I occure that I have not seen before. I dont think you can really have too much info in your book as long as it is pertains to your IT environment. James Collins
Systems Support Engineer
A+, MCP

email: butchrecon@skyenet.net

Please let us (Tek-tips members) know if the solutions we provide are helpful to you. Not only do they help you but they may help others.

 

[lisabennett]

Thank-you for sharing. I have sections for each computer and I'm keeping network setting and email setting in it, I guess that my idea of this book is something that it's not, That it should be a big book of knowledge & Answers. I'm sure in time I'll have it all at the flip of a page. .
Thanks again. Lisa

 

[butchrecon]

An admin book is an ever evolving proccess. You will always add things and remove things according to how your domain evolves. As long as you keep good notes you should not have any major issues. James Collins
Systems Support Engineer
A+, MCP

email: butchrecon@skyenet.net

Please let us (Tek-tips members) know if the solutions we provide are helpful to you. Not only do they help you but they may help others.

 

[dkediger]

Commonly overlooked is a section on your suppliers - where you buy the stuff you you need. Detail on the smallest vendor isn't needed, but the major ones - the ones you have open accounts and terms with. Keep info on your contacts and your account numbers.

This is also handy info to have duplicated offsite. In case of a disaster, securing replacement equipment will be a priority. I try to maintain a fairly consistent purchasing level with at least one of the major online sources - CDW, Insight, etc in order to be able to lean on them in this eventuality. I may not get the best price initially, but over time, if you really need something in a hurry, you have that contact who is willing to help you out.

 

[CJTyo]

dkediger has that right. If you develop excellent relationships with your supplier contacts, they'll move Heaven and Earth to help you when you need it. I made SURE my main supplier contact was indebted to me for all eternity (of course it was only 4 months before I left the company, but STILL...) by introducing her via telephone to my counterpart across the country, and less than a year later they were married! You can't pay for good will, and having it is priceless.

C

*~*~*~*~*~*~*~*~*~*~*~*~*
Insanity is a matter of Perception.

 

[TomKane]

We have a Lotus Notes based logging system and as issues arise our users create an entry and assign it to one of us in the IT team we then enter our analysis and resolution details and finally the thing is completed - what's handy with this is that we can analyse recurring problems, we can do keyword searches for error codes, etc and we can pinpoint what's taking up people's time - we found that programmers were having to do fix an awful lot of password lockout's - so we took that away from them and gave it to a more appropriate person - freeing up the time for programmers to do more programming.

Because it is driven by the users there isn't as much discipline required in keping it up to date as the work is done for us - we're just required to fill in the answers. But at the very least we can see if a problem has happened before, and who fixed it - so we can go and ask them if needs be......

 

[carp]

Definitely keep records of any changes you make to the system as well as why you made them.
Also, if you don't already have a disaster recovery plan this is the best time to start working on one. When very bad things happen, there's nothing as comforting as a good plan and checklist!

 

[KenCunningham]

It's always good to have hard copy, I think we humans need to be able to have a tangible reference which can't be blown away by a power surge. That's not to say, a database of events, cause and effect etc isn't appropriate and handy for searches etc, but a book will let you sleep a little better at night! I'd also suggest printing out and cataloguing those snippets you find on Tek-Tips - particularly useful when the search engine doesn't seem to be working, as today! Hope this helps.

 

[zeons]

I don't suppose anyone has a database they use for this do they? I am currently in a similar situation to lisabennett in that the systems I am now supporting were previously not documented. Not only am I currently having to find my way around the systems and work out what has/hasn't been done and why, but I have also been asked to document it all. I'm taking it from the viewpoint of dealing with issues as they arise from the customer and documenting ALL of them when I have worked it out. At least this way I can hopefully leave something useful for whoever takes over from me and not leave them in the dark.

 

[ASPProgrammerCliff]

I find that using a couple of books does the trick for me. I could be working on any part of the network at any time, and not know that's what I am doing until minutes before I start. I have a book that contains network information like Login Accounts for PC's and servers on the network, In the back of this book I keep a list of contact information for vendors, and website login info etc. I am also keeping another book that is tracking my tech tasks during a day. This was I can look up what I was doing on a machine on a certain day. Important operations get their own page like setup I did on the server, or the contact management software.

There are 2 other sheets that I keep around along with the last 2 or 3 versions of these sheets. The first sheet is just a task list for the day so I can be reminded of things that I might be able to do. The second is a list of the top priorities from my boss. The list I make is not always important to check every item on the list.

This system can fit in a small folder, and the books don't take up space on a shelf. I tried to use a database, but it wasn't very effective. I am still considering a method for archiving information using a database, but have nothing effective yet.

 

[EddieMunster]

I created a document in Word that summarizes the functions of each server, the IP addresses and of course the hardware configuration of each. I also maintain a list of static IP addresses in use for such things as the routers, switches etc. I added sections over time on what could go wrong and how to fix, as I came across them. If you only have to do something once every six months it seems you need to relearn it the second time, taking notes helps in this area greatly.
I also created my own Access database, it contains tables on each user, workstation, monitor, switch, dept, group, printers, problem reports etc. I keep it up to date and customized reports so when a user calls for help I can easily look up what workstation they are using and any prior problems. It isn't the best database in the world but I built it entirely from scratch and it works how I want it to, I find myself referring to it every day for one reason or another.
The only thing I wouldn't keep in your notebook is your passwords. If you find you have to many to remember use a software package that stores them in encrypted format.

 

[SMoarbes]

Hi Lisa,

I have more that 100 servers, and more than 6000 users acros Canada. keeping records on paper about each system is practicaly impossible.

my suggestion is that you have to standardize everything.... what I mean is that you should choose one or two hardware configuration for all users (Desktop /laptop). and then create one or tow images (ghost) that you can apply to all systems. like this you'll have a unique starting point for all systems.

then you should try to standardize all the software. same version on all machines, etc....

Servers is another issue. you should try to have the same version of the os. and keep all servers in sync...(same service pack on all, same security patches, etc....)


don't keep any documentation on paper....a database for your critical errors is the best. if the solution can be found on technet

http://www.microsoft.com/technet

don't add all the details, just put the technet reference....

all notes that you keep for one operating system will be useless once you upgarde to a newer version..

Sam
MCSE, MCDBA

 

[rkochis]

Lisa,

How large is your installation? All of the suggestions above have merit to some degree, depending on size! What works for a two office, 40 user network will not work for a (in my case) 152 building, 16 country, 4000+ user community.

I do keep some items on paper in my day-timer such as vendor numbers (purchasing), list of help numbers with the information the tech support people are going to ask for (contract number, etc...). Also I keep a Visio diagram (and a spreadsheet) of all the routers and switches in use. Te diagram is good for mgmt and the spreadsheet stays in my daytimer so I have help when someone calls me at 3am.

This information in my daytimer is limited to: what will I need at home off-hours -or- what will I need if the data center is on fire!

Other than the above items, virtually everything is electronic.

(The reason I prefer a paper daytimer is I cannot 'type' fast enough on a PDA during meetings and have it understandable!)

Hope this helps
Bob Kochis

 

[sh0tzy]

I couldn't help put put in my .02 worth. I work for a non-profit hospital. About 5 years ago the Net Admin got mad and quit. The place came to a halt, no one had any idea how the servers, routers, switches, vlans, or anything else were setup. No ideas on passwords, he had most of it in his head and what he didn't he took with him. He held the hospital hostage for 6 weeks, after which he relented and came back...after they paid him for the 6 weeks off, and gave him a nice raise. Guess what, if he gets hit by that bus everyone talks about, we are screwed. Obviously technology had advanced and no one knows anything but him. I find it so frustrating, upper management knows this but they just let it slide.

 

[jrbarnett]

You have to think about it the other way though. I used to work for a company where all the techie knowledge was in the heads of 2 people before I started. I documented it, how to set a server up should the system get trashed, what settings to use for a workstation etc.
I even trained a colleague up in a programming language that he hadn't used before and I was the only proficient one in the company and wrote up documentation on everything I wrote in that language.
I was made redundant because of a lack of money in the company, and my knowledge was on paper and word documents so be careful is my advice to everybody else here.

 

[TomKane]

Wow - that's a tough break. Sorry to hear that.

 

[EdwardMartinIII]

A smart company knows that a good lab notebook is an excellent tool in the hands of a smart sysadmin, but is not a replacement. Such companies do well with their ISO-9002 certification, but still don't get anything done. But their failures are meticulously documented!

Smart sysadmins know that an excellent tool is a good lab notebook because then they don't have to keep everything in their heads. They can spend their brains thinking about a better plot for the next Star Trek movie (I'll beg if I have to!).

A company that treats employees as if they're simply procedure-following monkeys deserves the churn, so try to not worry too hard about if-I-document-my-work-they'll-just-let-me-go. Document everything you can, write down your procedures and processes, and keep a good notebook. If they let you go, then they'll either see the light at the first crash and offer you work back, or learn their lesson even more brutally when they hire some dingbat who can only follow procedures (oooh, a recent college graduate who will work for a third of the old IT guy -- what a bargain!), but not actually think.

An employee that holds a company hostage with operating data isn't worth the time. No one in this tight of a working environment can afford to be a jerk and I don't have a lot of sympathy for hostage situations. Documentation is vital and willful withholding of operations data in the interests of "job security" is a sure path to that which is now euphemistically referred to as the "Employment Department". If one of my hires was a data hoarder, I'd seek the soonest method of extracting them and find someone to rebuild an open structure. I might keep them on, especially if they were really helpful.

Keeping data and notes is vital, despite the occasional bad apple that uses it against you.

Cheers,


Edward

Like Lovecraft? Know Photoshop? Got time for the Unspeakable?

http://www.petting-zoo.org/Movies_Dreamquest.html

 

[smittytech]

Here's an article that might help:

http://asia.cnet.com/itmanager/project/0,39006404,39093721,00.htm

 

[GPOTony]

Hi,
When I started programming, problems and how they were fixed were written into a big ledger.
I thought this was a waste of time so I stopped updating it. Hell, if a was hard to program, it should be hard to maintian too, right?
Then one day I came across an error which had happened a year before and couldn't remember how I fixed it.
Now, I keep a record of every issue in a simple Access database, where I can add and amend details such as error messages, settings, problems and solutions, user requests, logs of backups etc. I can amend/cross-reference/search the details very easily, and also produce simple reports of the number of issues dealt with each week. Also, because it is stored on our network, it can be shared with colleagues, and it is automatically backed up each night.