IT Employment

Ask something
Discussion Locked

Best Practice For Documenting a Server

0 helpful
35 replies

by aaronpctech 3 views

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

You guys are so great with helping me out along my way to becoming a great Admin. I have another question tat might seem dumb, but I want to know the right way.

I am in the process of documenting different things on my network and I have came down to the Servers.

What are some key things I should document about these servers. SO far I am thinking the obvious: ipconfig settings, which are domain controllers, what applications are on each....

What else should I look for and/or pay close attention to.

Any and all of your opinions are greatly appreciated.

35 replies

by ccthompson

You kind of already said this, but maybe just a deeper dig into it. Applications running on the server, maybe also map out which services are needed for each application, if they are a manual or automatic startup and what they depend on to startup. Usually when i have a problem with exchange server 2003, it turns out to be a service got hung on starting, or didnt start properly. Knowing which services are needed are sometimes critical.

Hope this helps!

by ccthompson

You kind of already said this, but maybe just a deeper dig into it. Applications running on the server, maybe also map out which services are needed for each application, if they are a manual or automatic startup and what they depend on to startup. Usually when i have a problem with exchange server 2003, it turns out to be a service got hung on starting, or didnt start properly. Knowing which services are needed are sometimes critical.

Hope this helps!

by garydw

Download the PSTools kit (it's free).

This will allow you to list out things like services, Installed software, Patch levels and a whole other bunch of stuff. May not be everything you want for documentation but it goes a long way.

There was also a server documentation template on here somewhere....

by msit

I have a Server spreadsheet which includes the Mfg, Model#, Serial#, MAC Address, IP Address, Speed,RAM, Function, and OS w/sp. If it's a large organization, the Dept Administrator would also be helpful. Hopes this helps.

by aaronpctech

Damn you guys give some good info. I will definitely consider all of these. I would like to try those tools suggested by gary just to get the basics down.

If there are any more tips I am all ears. I will begin your suggestions 1st thing tommorrow morning.

by markguer9

All of the things listed so far are invaluable to have around when preparing for disaster recovery of a server.

I would recommend creating a manilla folder that you keep OFFSITE for each server on your network.

It woulds contain a printed spreadsheet that outlines ipconfig, share info, RAID controller version and configuration, configuration of hard drive partitions, amt of RAM, OS service pack level, applications installed, tech support numbers of those applications, serial numbers of applications, copies of installation media for the applications installed, copies of installation media for OS, things like SQL, Exchange, etc., cd-rom key codes for apps and OS

Make a list of the things you would need to rebuild the servers from scratch. That is what you should have included in your documentation.

Hope this helps..
--Mark

by aaronpctech

Damn you guys give some good info. I will definitely consider all of these. I would like to try those tools suggested by gary just to get the basics down.

If there are any more tips I am all ears. I will begin your suggestions 1st thing tommorrow morning.

by gadgetgirl

make note on the paperwork of the date and time of the last patch. Why? So you know (definitively) that that particular server has been patched, and if doing a full restore after the patch has screwed, you know where to stop the restore....

oh, and keep a copy of your server documentation in your DR crashbox along with your installation discs.

Date and time of last patch also makes sure that the server documentation is regularly updated, and not just left to sit and fester for years when you've moved onward and upward....!!

GG

by gadgetgirl

because I'm in the UK!

A DR Crashbox is a box (obviously!) in which you need to store all the necessities to initiate Disaster Recovery (DR)

I've just redone the list for where I work: it contains the minimum items which should be kept both onsite in the server room, and in the general ICT area. (yes, 2 boxes, but only because there is half a mile difference between those locations!)

As examples: first aid kit (racks cut!) paper, pens, spare cell phone and batteries, with charger, tool kit, spare discs where possible, emergency contact sheet, SERVER CONFIG SHEETS, install discs, spare CD writer, blank discs, spare back up tape drive, spare USB hub and that's only part of it....

I think you'll get the idea now - sorry if I caused any confusion, I keep forgetting the difference in terms!

GG

by newbeeadmin

I have no problem with hardware documentation. I do that as much detail possible in the excel document. But with regards to Software Documentation have no idea where to start what to include in it. Done few but internally dont feel as if thats it for the documentation. Any body have any kind of template with regards to Software Documentation and would like to share that would be great.

by alessandro.panzetta

I hope this helps, hereafter a short list of what I normally write for server's dox:

-manufacturer/model/serial (if you can link the manufacturer's specs dox)
-addon peripherals (SCSI, DATs, REV, etc)
-RAID config
-Ipconfig
-Running services (AD, DHCP, DNS, WINS) and for every service the applied modifications (DHCP range and options, AD GPOs etc)
-Administrative Users and where the passwords will be kept (Like the DSRM pass, the Administrator pass in which room/locker)
-Any additional software and its settings (APC PowerChute, Symantec Corporate, etc)
-Responsible personnel/contacts

by aaronpctech

I need to add RAID COnfig an More of the running services.

Not exactly sure what the DSRM pass is.

by tony hopkinson

The documentation should allow you take take a collection of hardware and software and build a replacement from scratch. It should also tell you enough that you can highlight and work round any differences in hardware and software at the time you need to do it.

Oh and don't keep it only the server, and do keep it up to date.

The last one is key, by the way. It's not something you are going to do often, it's quite likely (hopefully) the person using it has never done it before, so divergences from the documention are not going to met with aplomb, extreme panic is more likely.

Oh and bear your audience in mind. Resist all attempts to have you write an idiots guide, you want the idiot to be too scared to do it and shout for professional help.

Put a revision history on the front page in 40 point bold red characters as well, just in case you get some clever git who knows all about it.

by aaronpctech

Thank you Tony for your entertainig, yet important tip. When you say dont keep it only the server, what are you refereing to? Are you refering to writing up SOP's for all procedures that I do?

by tony hopkinson

Oh we keep it on the server that the doc pertains to, so it's easy to keep upto date and you can always find it.

I'm seeing a problem here !

by aaronpctech

I see what you mean, I thought you were saying dont document jsut the server. I gotcha now. That would not be smart keeping all the documentation on the server.

by noyoki

Unless it were backed up offsite... We only *have* one (real) server, and starting very soon, it will be backed up via the net offsite. (Otherwise, we had the server backed up to cd's weekly and to a diff comp daily... with the exception of the internet backup stuff, it's not the best system, I know, but it's what I was given.)

by tony hopkinson

your offsite backup is corrupted and then you lose the backed up server. It's eggs and baskets time, depends on how the backup is done. Must be verifiable and you must prove that what you have backed up will enable you to restore. The latter is the bit that people forget. A documentation server does not have to be expensive, nor is a filing cabinet with a paper backup. But whatever system you put in place, from Marvo the memory man to outsourced data-centre with muliple redundancy, document management is the key. I forget how many times people had excellent hardware systems chock full of out of date documentation.

by lowlands

Depending on how many servers you have, you might want to think about automating the process as much as possible. From a central server run scripts that gather information on all your systems. Make sure the output gets backed up.
With vbscript(windows) or perl(Unix) you can pull almost anything you like from your systems. If you schedule these scripts to run on a regular basis, you'll always have up to date information on your systems. If you want to get really fancy, you can even export all the data to a database. It leaves just a few things to add manually, passwords for example.

by aaronpctech

I wish I could do scripts but I have no experience in that area. Does anyone know of a good website that'll teach one how to write simple scripts?

by markguer9

Search the web for WMI server configuration, there are tons of working examples you can mooch.

by rasilon

There are some useful programs that can automatically extract information about a computer (hardware, software, patches, etc). I've used:

Belarc Advisor
AIDA32
Everest Home Edition

Hank Arnold

by tidbits

Try also SIW (System Info by Gabriel Topala) - freeware - version I use is 1.54 Sept 20, 2005

Like Belarc and AIDA32, it digs through and present to you all sorts of info about the system.

Here is where you take a 'snap-shot' of your system - generate a report to save as htm. Use this as your baseline.

I keep a folder for each server/workstation for time stamped snapshots. I could have also build an Access database to import and organize the 'essentials' but it is not on my priority right now.

And yes, have a copy secured off-site and append passwords, registration keys etc to the documents. You need these in emergencies.

Regards.

by jmaechtlen

- if you are doing a DR, you may not (yet) have anything to restore onto?
That's why you need the paper docs, so you can get the machines running to start restoring/patching/whatever.

right?

by toklas

there is lots of good advice above.

1. automate as much as possible. manual information is just that... manual and is only as good as the people keeping it up. the more people you have the more this becomes a problem.

2. all the items listed in other posts of things to reocord is great. here are a few more.
a. ports - any ports needed open for communication in or out. this is usually helpfull for the wan engineer.
b. responsible admin - person responsible for this machine on the hardware level and on the app level.
c. end of life - if it is leased you want to make sure the lease end date is recored so you know when to start thinkin of replacing or other alternatives.
d. agents installed - list any agents installed on the machine. like management agents
e. backup info - is it being backed up. what is being backed up.

Along with this information you want to keep a change log for each server. This might be electronic or on paper. we keep a binder with tabs for each server. Record every change made to each server. things like reboots, patches, updates, config changes, everything should be listed here and the date it happned. this is very important for troubleshooting problems later on. make it easy to get to or it won't get used.

by stephenmoriarty

On a tower model I always open the server and put an envelope containing hardware / bios settings and some general info on name of server, type of usage ect. then I seal it back up that ways if it ever is replaced or lord forbid password lost Its inside the box. Admiitted I ran a small shop and it may not be useful in a large installation. I also do it on my home network as well.

by stubby

I agree with GG here - but am not convinced it's a cultural thing.

I'm a UK'ite and have never heard this term before. What GG refers to I simply call a "DR Kit".

Horses for Courses I guess.

by gadgetgirl

(Mine is Newcastle Upon Tyne, btw)

I made the distinction because the HR department where I used to work had a DR Kit - which covered eventualities for the entire organisation, barring IT.

The DR Crash box was so named to enable techies to respond when the servers crashed.....

And as you appreciate, we just had to make the distinction for the (l)users......!!

:D

GG

This discussion is closed to new replies.