Slashdot Mirror
Documenting a Network?
Philip writes "Three years ago I was appointed as a network manager to a barely functioning MS-based network. Since then I've managed to get it up and running — even thriving — but have been guilty of being too busy with the doing of it to document the changes and systems that were put in place. Now as I look back, I'm worried that I am the only one who will ever know how this network works. If I get hit by a bus or throw in the towel for any reason, I'd be leaving behind a network that requires some significant expertise to run. Ultimately, this won't be a good reference for me if they are trying to work out technical details for years to come. It looks like I'm going to have to document the network with all sorts of details that outside consultants could understand too (no, I don't want to be the outside consultant), especially since it's likely that my replacement will have less technical expertise (read 'cheaper'). Are there any good templates out there for documenting networks? Is anyone who has done it before willing to share some experiences? What did you wish your predecessor had written down about a network that you inherited?"
Sounds like a very easy way to over work and over stress your self, get some help one way or another. Summer is coming and I'm sure there are plenty of Comp Sci/Network Engineer/IT students that could of help. It may not be a bad idea if you make a plan of some kind before you go head in.
The next step up from a Post-It, though, is a snazzy label-maker. My portion of the company uses these extensively to document our development lab (we do some NMSy stuff). Of course, it's not a production network, and standards are a little different.
The World Wide Web is dying. Soon, we shall have only the Internet.
Whether the comment was intended to be funny, I find this to actually be a serious issue...
The phone numbers/emails for points of contact in other departments/companies.
You likely don't run *everything* and the new person needs to know who to contact when the interaction between inside and outside fails.
20 characters max for the password? How will I use my favorite poems as passwords?
I maintain a largish network with vmware-dominated x86 Linux and Windows platforms.
I started with a live document containing a network diagram and a list of servers - meaning anyone can add to it. I use word - and have it in "outline" mode for easy collapsing..
No Passwords are kept in it (passwords are referred to a documented, password protected area within the IT group folder; a sync'd copy in the DR site and a copy with the DR documentation (just in case)).
The document is replicated to DR for survival when you have to rebuild.
My documentation stated with a network diagram now includes a rack layout and wiring diagram; and have now added details such as DHCP configs (although they change... thus the live document - so don't print it or its out of date).
I've even added underground cable runs (found when they pop the lid of the pit - with photo goodness) where fibre run to pits and the electrical company details to how the generator kicks in - who to contact i the event of a transformer blow etc... just in case I forget in 10 years time!
All IT team and top-level managers know "its in the network documentation" if they need to refer and I'm not there. They add their relevant parts - its a live document afterall.
Of course, you MUST make stipulations that this document should NEVER be released outside of the company - otherwise it will be handed over for tender responses; sales/marketing reports; sales people interested in the network; due dillegence reports; accounting audits and toilet-reading-for-those-who-have-nothing-better-to-do... for some reason managers love to use your hardwork to reduce them having to do hardwork - no matter how detrimental it is to the business!
Anyway - keep it a work in progress... and don't put anything in there that could compromise the company if fallen in the wrong hands (see above)..
Good luck... this job is never finished... but will feel good when you have it up-to-date.
Draw a horrible diagram in Visio (or similar) of what's connected where without any indication how it actually works!
Not really, because as most high level executives know, IT doesn't really do anything!
Mod me down, my New Earth Global Warmingist friends!
...or if you show it to them they won't bother with reading it
This is more to the point. Most network admins have the attention span of a flea and won't read past the first sentence of anything you write; actually, I could probably expand that statement to include most people generally. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
"The network started horrible, here is how I cleaned it up" is a GOOD reference. I have killer references from two jobs I automated myself out of this way. Each time I got a more interesting more challenging better paying job by doing so.
Present client I am at I inherited a network of about 15,000 clients that was previously managed my a very incompetent IT department. Started by looking at the existing flowcharts and discovered that almost everything that was documented was wrong... Long story short I have been spending a fair bit of time reverse engineering their production environment so that we could accurately document it. Unfortunately we had come to the conclusion that we can use /nothing/ that the previous administrators left behind for documentation. You don't want someone like me coming in and looking at your documentation and declaring you incompetent, it can cost you your job.
You haven't detailed the size of your organization to know if you will need sign off from other departments or not. If possible try to get sign off so that they have a reference and you can create a standard that can be used to fix things and to ensure your designs don't get trampled by a new admin in another department. You really need to provide more detail on your environment for people to answer you.
I do most work in Visio, starting at 50,000 feet and working my way down. At this level I need to document network topology, server distribution and database server distribution. I work my way down from there using a zoom in style that has served me well for 30 some clients. Depending on the size, complexity and your area of responsibility you may need to flowchart anywhere from a 2-3 levels to potentially dozens of disparate processes. You haven't mentioned much about process development, I assume you want people to know how to do at least critical portions. Never write a process without flowcharting it, this will save you grief by getting people to focus on the process instead of a step by step set of directions. It takes someone fairly good to document the complex and make it look simple, that is your job at this point in time.
The bottom line is that your documentation should show dataflow for each critical system. As long as you can do this someone else can step in and work with what you have, even if they may not understand a given piece. One of the big advantages of flowcharting everything (especially processes!) is that this will readily show you weakness and holes that may have been previously overlooked. When flowcharting complex processes don't be afraid to have a single point represent an entire additional complex process that can be distictly referenced of it's own accord (as an car repair manual of mine once described the process to replace a crankshaft "Step 1. Remove Engine".) If you try to put to much detail in a given process you lose your audience and the value of the documentation.
Bottom line when I am done with a design document it covers server, network, database and client topology in varying levels of detail with dataflow. A typical design document I would turn over would be 150 pages with most of that broken down into different sections describing what was done, why it was done, the best practices followed for build, and best practices for lifecycle. The document typically does not get read by any one person, instead it would be a reference for a number of different departments that will each reference it according to their own needs.
Most equipments systems and application have fancy features that allow to do elaborate things efficiently with less resources. This is an enjoyable part of our work, unfortunately it should be banned.
Restrain Yourself from the temptation to use those features.
Implement everything with the most basic and standard approach.
This may be frustrating, you may feel that you are wasting cash and time and sacrificing performance, but actually you'll get a more reliable and flexible system. And and outsider will be able to understand it more quickly.
Most systems allow to insert comments in the configuration. Use that extensively. The comments are the most immediate documentation and usually the most up to date.
One last hint: once your system is running and you have removed anything fancy from it leaving only the necessary complexity, take 15 minutes to describe the profile of the person that is eligible to manage it. Include books with the general knowledge that this person will need. Handle the description to your management.
This approach has following advantages:
- screening out totally unfit candidates
- helping the successor filling gaps in his knowledge
- avoiding to describe in your documentation common knowledge (in my experience this is 30-70% of the document and could be replaced with references to appropriate books)
- (free bonus) giving the management a better understanding of your own value
There are drawbacks as well:
- Going through books would take more to get a grasp than if you explain everything inline.
You can palliate by giving references to specific chapters. And stress on the fact that no one should be allowed to touch the systems *before* having the knowledge in the book. It's like driving the car: you should learn *before*, not *while* going to the highway.
I work as an architect rather than at the coalface of keeping a network of the kind described going, but one policy I would suggest is that if there are particular aspects of your network you think will be hard to document, it would be profitable to change the truth about those aspects to something you will find easier to describe.
Ideally you should do this by changing the implementation without noticeably affecting the services provided to end-users. Software development people may recognize this as relating to the concept of refactoring.
If you are in the server room, and you have:
A: a spreadsheet that your predecessor made.
B: a post-it note on the switch saying it what it does.
Which one do you trust?
For the physical/low-level network the documentation should be in the network. Just like source code should contain comments about this particular piece of code, a similar approach works reasonably for the physical network. I see no point in a having an outdated spreadsheet. It is more useful that the cables and ports are labelled and numbered, that there is a post-it note on a switch say where the links go, etc.
The grand overview should be in electronic form, though. A scanned hand drawing is fine. A photo of a whiteboard drawing is fine too.
For the logical network put comments whereever possible. On settings, VLAN configurations, server connections, account setups, ...
Again, the grand overview should be in electronic form.
I have found it useful that the information is timestamped, so you know when it was last valid.
A summary diagram (dia/visio) is still pretty key, but nmap (or specifically the latest versions of zenmap (the gui frontent to nmap) provides a good detailed view of network topology and if you include the capture file, you can annotate specific computer details in the notes section (ofc you have to assume your replacement will be familiar with zenmap for that to be useful though)
IranAir Flight 655 never forget!
No wonder our field and many of our professions have such a bad reputation.
I have read only a few posts and two (moded up 5) say pretty much to ignore the issue.
In several networks I have worked with fundamental information was non existent. This translated in lost time, down time and actually losing money (if you lost your job in one of those companies recently, the indolent SAs or Network administrators may be partly to blame).
You never know who the next guy will be, if he is less experienced or capable then the documentation will be very valuable, if he is more experienced or capable then you would have saved their time to do some real work, after all they (and you) have not being hired to do forensics.
How a professional can hide behind the "let's be real" nonsense is beyond the pale.
IANAL but write like a drunk one.
Attempting (even facetiously) to blame SPAM on Windows is wrong. If every copy of Windows on the Internet somehow magically disappeared, the SPAM problem would not abate. Bot herders and spammers would simply shift their efforts to other platforms.
If your doubt this, consider what the winner of this year's PWN2OWN contest had to say about why it's easier to target Mac OS X.
BTW, this is not a troll, and I'm not a (Windows|Mac|Linux) evangelist of any kind. I just find kneejerk Windows bashing rather tiresome
That's always.
Those who don't document don't have job security. They are an insecure leach sucking up a paycheck fearing -- and rightfully so -- the day they are going to be replace.
Those who DO document show their value to the organization, and should have no fear of being replaced. Their position is secure -- and should they go elsewhere -- they have something to show of and for their work.
I disagree with the parent vehemently and will say so based on years of experience as a techie, a techie manager, a manager of techies, an executive, and (thankfully) a techie again. You can never document too much, but those who don't cost the organization more in the long run each and every time.
Document. Document well and often. Ignore the parent.
Ehud
At which point you won't be getting the passwords anyway since you fired him/her? Good idea. ^_^
You can't take the sky from me.
the easiest solution is to destroy all data as part of your corporate policy. after all they can only ask you for what you have, so unless there is a legal or business reason to store data, destroy it.
If you mod me down, I will become more powerful than you can imagine....
So what happens if said predecessor gets hit by a bus, has a heart attack or a stroke and can no longer tell you the passwords? Or, worst case scenario, the whole IT team gets taken out in a road accident on the way to a team building session for example? I've read a few "deserves to be fired" comments on /. and usually tend to agree (or occasionally get embarrassed because I think hmm, that's me!), but in this case you are being a fool.
Of course, if you are dead then you won't care if they have the passwords, but some of us actually like our places of work and even our colleagues, and want our place of employment to be able to chug along even in our absence.
which is totally what she said
If the predecessor does write the passwords down, he deserves to be fired.
That's knee-jerk stupidity, and you should be ashamed of your non-thinking fundamentalism.
Passwords do need to be written down, and stored in "escrow". I put the list of passwords in an envelope, lick seal it, sign and date the seam, and then seal it again with clear packing tape. Give it to the boss to put in his safe.
Yes, it's easy to open, but you'd know whether someone tried to tamper with it.
"I don't know, therefore Aliens" Wafflebox1
circuit ID ? in that a farmer's synonym for "MAC address" ?
Not everything is ethernet.
Yay me!
If it is large enough (which it doesn't seem to be) you should divide stuff up in modules. Start from OSI layer 1 and work your way up.
If it's small, you probably wind up merging loads of stuff into one document in which a serious amounts of stuff is considered to be "the network" although it isn't.
/. to get this information. You're not the first person that has to do this. Must be a slow day here.
Having said this, there are places to go other than
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
All you are doing is wasting your companies money paying you salary for doing what they probably don't care about.
Doing a good job isn't just about doing what you are told. Just because management don't care about something doesn't mean you get to not care too.
Sometimes you have to do the right thing and often the right thing is helping the next guy who gets your job so that everything says running.
Read a lot of good posts and ideas so far here. From my perspective, the most cost effective solution for you and the business is, you need a backup engineer for in case you do get hit by that bus. Having a person knowledgeable enough about your network to keep it running in the event you are incapacitated for a length of time is by far the most beneficial, if for no other reason, because of the quick turnaround time they can come in and take over vs. company looking for another engineer, and the time it takes to learn the network and scrounge threw docs you created.
Very few documents are actually that meaningful if the engineer is halfway competent so as others have mentioned, no need to go documentation crazy. There are key docs I feel though that should be created and maintained and have been mentioned above.
1) Passwords, I cannot stress this enough, get all accounts privileged accounts and service accounts documented with passwords and secured somewhere (preferably off the network, such as a USB key with the data on it in a safe) as without this, it can be a very ugly scene.
2) Next, overall, logical and physical network diagrams are paramount. If done correctly can make troubleshooting a breeze, and a nightmare if not done correctly. One link that I like is a reference to a best practice guide about the Cisco 4000, 5000, and 6000 series equipment found here ( http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml#management_cfg ). Go to the network diagrams section and review the overall, physical, and logical section. Create your docs with this as a guide and any engineer who may have to troubleshoot the network will love you for it.
3) The answer to what 'other' documents should I create? Comes from you. Knowing what you know about your network, pretend you are coming into the network for the first time, and ask yourself, what I would wish I knew about this network? Make a list of your business critical functions where people would be screaming if the service was inaccessible. Document what would be useful info in a DR scenario of recovering the service. This leads me to the last doc I would recommend as useful only as an insurance policy for the business.
4) A procedural document of how to recover various business critical services. Again, key focus is on business critical, business users or clients will care less about non business critical services or be a lot more forgiving. This can assist greatly an engineer if good recovery procedures are documented, especially in area where customizations have been done (i.e. scripts and what not)
The other biggest important thing you should do is manage the businesses expectations. Talk with the business to get feedback as to What are the business critical services and document them. Next, get your Service Level Agreements ( SLAs ) agreed upon between you and them. And make sure you can meet them. If not, get a projects/tasks list together of what needs to be done so that either A) the business will fork over cash to meet agreed upon SLAs or B) they will accept the current SLAs.
The SLAs are important because it will force you to take a hard look at the network to see if you meeting their expectations. That is really what it all comes down to. When I.T. does not meet expectations is when the business gets all bent outta shape. Manage the expectations and get your SLAs agreed upon for restoration of services and you will be ok.
One more link that can help in ensuring you can meet SLAs is getting your RTO and RPO defined for you business critical services. Here is a nice easy link that talks about this that should help you.
( http://findarticles.com/p/articles/mi_m0BRZ/is_3_24/ai_n6017376/ )
Good Luck!
My school's network admin used to say that when he didn't have to do anything at all during a work day, he completely deserved his pay.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
Here we run mainly Windows anyway, the only password that is really important to keep safe is the domain administrator password.
Nope, local admin password on the PDC is far more important than domain admin.
I am the lawn!
If you actually *need* the password to the root account, UR DOIN IT RONG. Seriously. You should be sudo'ing everything.
So to get yourself in the wheel group, you might initially need the password of another sudo'er, but you don't need root. I like to randomize (and forget) my root password after adding my own account to wheel.
First: You must make everything as self-documenting as possible. Label every server, every cable, every power lead to within an inch of its life. And establish processes which say "when a cable is moved or added, labelling is updated accordingly". If you don't have a labelling machine, buy one.
That deals with basic "what's plugged in where" and is far more likely to stay up to date than a spreadsheet or wiki page.
Second: Whatever you choose, it must be something which can scale to your needs and which you can live with.
It will need regular updating - and quite frankly, very few people are able or willing to regularly update a single 200 page Word document complete with embedded spreadsheets, diagrams and photographs. A wiki - or even Sharepoint, if that's your thing - may be better. But if you do take the Wiki route, make sure you keep hard copies of the documentation which says "If the sh1t hits the fan, this is what you need to do to recover".
Others have said "don't bother, your successor won't read it" - I say balls. Documenting is more than just helping your successor - it also helps you remember what is set up, clarify how things work and as part of the process you start to look at things and think "hang on a minute.... this document I've written describes something quite absurd. Are we really doing that?"
Whether or not your successor reads it is really not your problem.
no, in the real world most businesses dont interface with the internet via cable modem or dsl. Ckt ids refer to the Telco designations for the connection to the outside world for your network.
Chuck
>when he didn't have to do anything at all during a work day, he completely deserved his pay
BS - there should always be longer term projects you can work on when everything else is running correctly.
Think about what you would want to know if you walked into your network cold. (don't document the passwords, but make a provision for passing them on).
Don't document every detail. Point to reference material, but you shouldn't be documenting theory, just your implementation.
Also, I hate to take the pessimistic view, but based on my experience, even if you do a stellar job, there's only a small percentage chance that anyone but you will read the document. But you can sleep well at night knowing that they can figure out your handiwork (network design) from your writting if they do decide to RTFM.
Either he writes the passwords down, or he uses weak passwords that a human mind can remember.
Besides, a password is a security token. A piece of paper or a little plastic card with the password printed on it or a USB stick with SSH key or whatever saved on it are also security tokens. They aren't inherently less secure than memorized passwords; you simply have to secure the physical object by, for example, locking it in a safe.
"Passwords should never be written down" is an idiotic rule, right there with "never use goto".
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
And rather than running back to your computer to type it up into files, carry around a pack of index cards and write a card per system, a card per router, a card per patch panel, a card per printer.
Yeah, I think that's more or less true. At one of my previous jobs, I had a guy try to imply that I didn't deserve my pay because I "wasn't doing much". When I asked him what I should be doing, he said, "It's just that you have a really easy job. The IT guy at my last job had it much harder. He was always running around, fixing things. You just sit at your desk because nothing ever breaks."
I can't remember now, but I think I might have done a literal facepalm right then. I said something like, "Has it occurred to you that, if you think none of our IT stuff ever breaks, I must be doing a good job? If the IT stuff at your last job kept breaking all the time, he was doing a worse job than me?"
under the keyboard ...
if they can't replace you they can't promote you
I'm familiar with the ideas behind electronic discovery, and I think ultimately it is just going to go away. It is the brainchild of people who want to treat the entire electronic world the same way they treated the paper processing world, and they have no idea how much data they're actually trying to wrangle (much less the costs involved in wrangling it). Entire industries have cropped up to feed off of the eDiscovery nonsense, and you can directly measure how much productivity is being sapped from industry by measuring the wealth being accumulated by all of these eDiscovery Solution Providers. In the long run, I think people will recognize the whole process as an unreasonable burden on industry and find some alternative way to satisfy the random and often pointless legal requests for electronic discovery. If not, I think industry will eventually look at the money they're wasting on complying with the whims of the US legal system and simply decide to move a lot of their operations to places that don't impose the same kind of wasteful overhead.
You're a fucking retard. No one uses Windows in a server environment.
Except for entire Colleges and many Universities. Other than that, and a million and a half other places, you're correct.
does no one on this site know how to restart a machine off a bootdisk and zero out a password with vi seriously =/
I also try to stay away from documenting things in static formats. If you ask me, incorrect documentation is even worse than no documentation at all, and the fastest way to get incorrect documentation is to create a process that relies on a person doing all of the updating manually.
I know a lot of people love their spreadsheets and their diagrams, and maybe they update them religiously. Nonetheless, that process is *always* prone to error. And if a technician goes to a document for information and finds out that the document is wrong, the document loses its credibility. If that happens a few times, the technician will simply stop trusting the document, and it will just fade into obscurity.
If you want to document a system, look for ways to make the system document itself. Switches keep real-time lists of the MACs that are connected to them. Routers keep real-time lists of which MACs map to which IP addresses. Routers and switches will always tell you their current configuration if you ask, and you can automate the process of asking and storing and checking for changes. Most servers will tell you their serial numbers automatically if you ask them, so you should automate the process of asking them and storing that information. The same goes for what kind of hardware is in the server, where the server is attached to the network, etc.
So much information can be collected automatically rather than recorded by hand, and when you collect the information automatically, it will always be up to date. It will not matter if a tech decided to re-rack a server in the wrong place -- even if they didn't write it down, your network knows that it moved, and it will tell you if you ask it. So the next time you sit down to write a 200 page document describing the network, you should ask yourself a) how much will it cost in time and effort to keep this document relevant, b) how likely is it that the document will become out of date either through accident or negligence, c) how quickly will people abandon this document if it does become out of date, and d) aren't there huge parts of this document that could be totally dynamic instead of written in static text on a page?
Something I found to be VERY good policy that was implemented at my former position (as Network Admin) was to hand to the boss (CEO, CIO or whatever) a sealed envelope with EVERY relevant password (most importantly the admin password :) ), to be held in the company's vaults (if your company has such a thing of course, or similar).
:)
Whenever an important password was changed, I would hand over the new envelope
There are three kinds of lies: lies, damned lies, and statistics.
Hire a tech writer with a specialization in documenting networks. During the interview, ask the candidates to describe their process. You want someone who says, "I try to get all the way through the whole thing once in the [insert time period here, 1-2 weeks or so]. It's cruddy, but then we go back and make it better. I have templates so that we can begin by filling in the blanks, but they will need to be customized at some point to show your circumstances." Check out the job bank at www.stc.org to find someone who can do this work for you. You might need the tech writer on a contractual basis for now, but given how IT people HATE documenting their work, having a designated person to make it happen (NOTE THAT: not to write the stuff, but to follow up on it with management support when needed) is really valuable.
You're also looking for a person with a plan for updating on a schedule, and a way to archive the information so it's findable by the people who should find it. CVS works pretty well.
Disclosure: I was a tech writer, but not for networks.
I was taught that the proper way to store admin passwords for an emergency situation (such as admin gets hit by bus) was to
1. Write each password on an individual piece of paper
2. Seal each piece of paper in an envelope
3. Store the envelopes in a Safe/Deposit box that a limited number of people have access to, (company owner, CTO, CEO, IT Manager)
4. Put policy in place that requires passwords to be changed and re-recorded any time the envelope it is stored in is opened.
It may seem low tech, but it is probably the best solution for a small to medium sized business.
That's my USD$0.02
The AC has a very good list, I'll see if I can add anything to it.
Network diagrams should be at a network, physical and datalink layers. Only the simplest networks can have all this information on a single diagram and have it be useful. Seperate the network drawing from the datalink and physical drawings as requred but be sure to leave enough detail to connect the drawings (Visio has a nice linking feature for this). Also keep a spreadsheet or database of assigned networks, IP ranges, and assigned static IPs, including a responsible POC for each entry. Also, a spreadsheet of all infrastructure devices with model and options documented along with firmware versions, and support contract information. All ports should have a description entry for what it connects to, and the project/request/change identifier that created the connection.
System documentation starts with the system name, project, admin, data owner, system specs, OS and application software name/vendor/version information, as well as support contracft information. Then comes backup and recovery procedures. After that you have the build procedure, including all configuration changes, and scripts. Also include any system standards i.e. all sofware added is in /opt or D:, all scheduled scripts send output to admin-report mail list, all tape drives are DLT. Supplement with the afore mentioned RCA documents.
Domain/authentication system documentation should include a description behind the premission model and standard premission and logging settings for all systems related. There should be procedures for credential and access changes that are documented and understood by everyone with administrative privilege. All systems should be build to not share credentials, and imperitive credetials should be in a sealed, tamper evident envelope in a secure location (a safe typlically). Things like root and domain admin passwords can be made by 2 or more people and added to the envelope, so no person can make changes without an audit trail.
Databases should have all the system documentation along with schema information, connection parameters, and roll back procedures. Any configuration made for logging transaction logging should be docuemntated and scripted where possible (anyone who has had to custom roll persistent trace logging for MSSQL databases will empathize).
Logging and managment systems should have procedures for adding new systems and new metrics. Managed systems should be baselined, using system thresholds where possible.
Patching and patch testing should have procedures and deployment schedules (i.e. MS patch Tuesday patches should be full deployed within X days/hours of release, Sun patches will be applied to the dev environment within 24 hours of release and deployed to production after 7 days etc.)
Whenever possible use a central system for this information. A Sharepoint, Zope/Plone, or even a wiki can make the information accessible. If the support folks use the docuemntation, it will be maintained. If nobody uses it, no procedures mandate it, it will die. If you have a change management system that enforces documentation updates then people will use what you've done for years to come.
Spyder
Wouldn't a password vault or encrypted text file on a non-networked pc be much simpler? (Not to mention more likely to actually be updated on a regular basis?)
I've found that nurturing one's Zen nature is vital to dealing with technology. Violence is pretty damn useful too.
Since when is a computer -- subject to various sorts of software and hardware malfunctions -- much simpler than a freakin' piece of paper in a locked box?
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Someone will still need the password to decrypt the store.
Public-key cryptography to the rescue!
You can encrypt the file in such a way that any of a set of private keys can decrypt it. You can also encrypt it in such a way as that a combination of keys are needed (i.e. 5 keys used in encryption, and you must have 2 in order to decrypt.)
You can also send that machine's logs to all 5 owners, so that an intrusion by any one will be more likely to be noticed (and it will be harder to tamper with the logs.)
You could probably even automate the entire encryption process. Any time a password changes, automatically re-encrypt with the public keys and store on the server. That way, you remove the human element, which could screw up encryption or signing, or forget to update the file.
Didn't Bruce Schneier once say "If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography"?
I don't think this solution is nearly as good as the envelope system. In particular, I don't expect the company owner or the CEO of the average small to medium business to have the expertise keep their private key files and password accessible to them and no one else. That means that either you're actually relying on two out of the other three keys being available (if those two fail to keep their private key files accessible to themselves) or you have poor security (if those two fail to keep their private key files accessible to no one else), whichever is worse.
In contrast, all of the trusted people probably know how to keep a physical key reasonably secure and accessible, and if you use a deposit box at a bank there may be identity checks as well.
In general, if your solution requires detailed technical knowledge from non-technical people, your solution is broken. Pick something low-tech instead.