Trench Tales: Poor or missing IT documentation can leave you feeling lost

In a previous edition of Trench Tales here at TechGenix, I talked about a friend of mine who has been doing IT for many years and who recently changed jobs, taking on a new position of managing IT for a public company in Vienna, Austria. My friend’s name is Martin Urwaleck and when he arrived at the new company, he discovered that he had his work cut out for him. As we saw previously, one of the immediate problems he was faced with was restructuring the company’s network. This was necessitated by the requirement of bringing the company’s network into compliance with the recently enacted EU General Data Protection Regulation (GDPR) legislation that we’ve talked about a lot on this site.

But that’s not the only challenge that Martin has faced in his new position. Another one that immediately hit him when he joined the company was how poorly the company’s IT systems and processes had been documented. And I’m sure many of our readers who work in managing and administering IT have faced similar problems when they change jobs and move to a new for business and organization. The discovery that your predecessors have not done their job properly and have left a mess behind for you to clean up is a common one, and it’s not pleasant. To illustrate what can go wrong in this area, we’ll start by examining the kinds of problems Martin encountered with respect to poor or missing network and IT documentation at his new employer. Then we’ll look at some of the different kinds of initiatives Martin is taking to try and rectify the problem.

Poor or missing IT IT documentation: Scope of the problem

“Missing documentation has different aspects for me," Martin says. “The scope includes software, infrastructure, servers, clients, Active Directory, security, and so on.”

Let’s start off with the software development side of things, I said to Martin. “Software development? Only inline documentation inside the code!” he replied. “We have no idea what formulas and algorithms former programmers used for some tasks, which makes reengineering time-consuming and complex. Modifications of existing programs are inevitably risky because we have no complete view of the connection between different modules. So, a fix in one module might break another depending one. And we have a lot of modules, some of them from the late ’80s! I can identify a least three eras of IBM RPG programming in our current codebase.”

And that’s not all. “Infrastructure is another concern,” Martin says. “Having an IP address list is not enough! We have a bunch of LAN components like switches, access points, firewalls, and mail gateways, but there’s no overview of how they all interconnect — not to mention a unified configuration and a documentation of all the different configs.” I nodded my head at this as I’ve encountered a similar situation in many of the established businesses and organizations I’ve worked with or visited over the years.

What about servers? Are they running a recent version of the Windows Server platform? “We are actually just now rebuilding our Microsoft infrastructure by replacing Windows Server 2008,” Martin said. What about client systems? “Windows 7, but we’re replacing them.” And none too soon, I suggested.

“Active Directory is another big area of concern,” he says. The more we use it the more we are impacted by missing documentation. For example, there are a bunch of GPOs linked to different OUs that are interfering with each other. And we even have a modified Default Domain Policy that no one was even aware of.” I grimaced when he said this as the Default Domain Policy should never be modified. “We also have active user accounts that haven’t been used for years. I could go on and on.” Lots to clean up there, obviously!

“Then there’s security,” Martin says. “There’s no written security policy, and as long as I don’t have a written-down policy, I simply can’t stick to it. Security is more best practices than a thoughtful concept.” I asked him also about whether he thought his servers were configured securely. “Well, we’ve found a lot of installed services on them that have never been used and would never be missed. And of course, they expand my attack surface inside our network.”

Solving the IT documentation problems

It’s time to move on to solutions, so I asked Martin if he could describe how he plans to solve his problem of missing network documentation including which aspects he is prioritizing and how he is approaching them. “I’m doing some tasks right now in parallel,” he replied. “For example, we are now using a tool called DocuSnap for setting up our documentation. This tool allows us to get some information automatically and also add our own when needed. In the long run, I expect to get our disaster recovery handbook out of the information we collect with this tool.”

What about any existing documentation you find lying around? I’m sure that some of it is incomplete or even misleading if it hasn’t been regularly updated. “Yes, all our existing documentation is screened, then unneeded docs are deleted while to-be-updated docs are marked accordingly. New and updated documentation is then reviewed by another peer before releasing it. I expect about six months until this is all finished.” Good process, I thought to myself when he told me this.

“We have also established templates for documentation, and these have to be used when creating new documentation. We are expanding and improving these templates continually.” Aha, that’s another best practice I need to keep in mind when helping companies try and get their documentation processes in order. “Plus, we only approve external work when documentation is delivered end reviewed,” he added. “And preferably based upon our templates.”

I finished off my discussion by mentioning how he had talked about creating a disaster recovery handbook for his new employer. I assumed that was probably going to be a work in progress, and Martin readily agreed. “We actually do a disaster recovery test once a year for both our Windows and IBM environments, and we do this based on our handbooks and documentation to discover any gaps in these documentations.” Now if only I could convince the businesses and organizations I come in contact with to do the same!

Featured image: Freepik

Mitch Tulloch

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Published by
Mitch Tulloch

Recent Posts

Incremental backup vs. differential backup: What's the difference?

Incremental backup and differential backup are two popular backup strategies. In this article, we'll see…

15 hours ago

VMM agent deployment issues? Try these solutions

There are several reasons why a Virtual Machine Manager (VMM) agent fails to install properly.…

19 hours ago

Microsoft 365 administration: Get your SharePoint settings right

An important part of Microsoft 365 administration is configuring SharePoint. Getting these settings right will…

22 hours ago

Using VMware Horizon to connect to remote computers without a VPN

If you are already a VMware shop, a safe remote work solution may already be…

2 days ago

Azure security: Building a secure subscription with Azure DevOps

Creating a resource group with some essential components for your security team will be a…

2 days ago

COVID-19 speeding digital transformation

The upheaval engendered by the COVID-19 pandemic has spurred executives to brush away their concerns…

5 days ago