Several people have asked about how to keep onsite documentation consistent with offsite documentation. There are several pieces to this puzzle. For example,
1) More work is being done remotely. Sometimes this is just because you can. Sometimes it's related to managed services (onsite is charged, remote is included). And some people are just finding that gas is too darned expensive.
2) More people are using a PSA systems or other toool to track work and client configurations. These include ConnectWise, Autotask, Zenith, and even Result Software. There are now approximately twenty-seven thousand ways to track this information.
So what's the problem?
Well, the most important documentation (no matter what your first impression or personal bias is) is the printed, onsite documentation. When the server's smoking, you've got the network documentation binder. When you get hit by a bus, the client has the NDB. The client owns the network, the hardware, the software, and the configuration thereof. The client needs an accurate onsite copy of this stuff.
But you also have information in your system. You have configuration pages from ConnectWise, Zenith, etc.
When your technicians make changes, they need to update the net doc book.
So, you need a process to keep these things in sync. One argument I've heard is simply "you know that won't get done."
No. I don't know that. If you make documentation a priority, it will get done. We make documentation a part of every single service request we work on. In fact, the last line of every single time entry on every single service request should be
"-- Documented work."
That tells our service manager that the technician fulfilled this part of his job.
When you make important changes, such as reconfiguring the firewall, you need to make sure that information is updated in your system. Period. Just do it. If you're onsite, you need to update the documentation in the binder. Again, just do it.
But if you do this job remotely, how do you keep the local docs up to spec? There are two pieces to this puzzle.
First, on the root drive of the primary domain controller, there's a directory called c:\!Tech, and within this is a directory for TechNotes. Within that directory you will place tech notes with any information that would go in the first page of the Network Documentation Binder. For example:
June 1, 2008: Backed up firewall config to C:\!tech. Reconfigured firewall to allow ftp traffic into DMZ for Server3. Backed up new firewall config to C:\!tech. -- karlp
Notes such as this are stored in TXT or RTF, depending on what works best for you. (We like to be able to print them directly from the server and MS word is rarely installed on the server, so we rely on Notepad or Wordpad.)
As a matter of policy, your technicians will print these notes when they're on site. They go to the front of the NDB.
Second, if something is particularly important or you don't expect to have someone onsite in short order, you can ask the client to print out the files and put them in the binder. This might be transmitted by email, fax, or you can simply point them to the UNC (\\server\techshare\filename).
Alternatively to all this, you can print out a configuration from your PSA or service delivery system and put that in the NDB. Or, again, you can fax this to the client. Or print to pdf and email it to the client.
The bottom line is: If you think it's important to keep the network documentation up to spec, you'll find a way to do it. There are dozens of ways to do this. There's only one way to not do it: Don't make it a priority, and it won't get done.