Minor Release: i-doit open 1.10.2

The i-doit open release 1.10.2 is now available!

As usual, the new release is also full with improvements and bug fixes.

You reach the i-doit download section right here.

System requirements

  • i-doit now supports PHP from 5.6 to 7.0
  • The controller is now using the symfony console

It is still backward compatible, but deprecated. Please check our Knowledge Base on how to change your cronjobs by using the new Controller console.

A comprehensive guide to IT-documentation Step 1

A comprehensive guide to IT-documentation Step 1

(Guideline for the System Administrator)

Our users often ask what things to document and how to start an IT-documentation. The answer is pretty easy: Ask yourself what documentation you need and reduce it to this needs.

This sounds easy in theory, but is hard in practice. Why is that? Because you tend to document too much and sometimes the wrong things. Documentation wakes the hunter-gatherer in the system administrator. You might end up collecting stuff that you write into your documentation but never use.

This guide should help you ask the right questions and find your way to your IT-documentation.

It does not raise the claim to give you complete coverage about the way IT-documentation works – but it should be enough for you to set your goals and get started.

Some fundamental IT-documentation thoughts first


IT-Documentation starts with politics

The number one reason for a dying IT-documentation…is when either you or your coworkers lose their trust in the accuracy of the documentation. And this happens either when they find old/incomplete information or when they don’t have any trust in the documentation in the first place.

Saying politics is maybe a little bit exaggerated. The goal is: You want your IT-documentation to be accepted and used in daily business. How can you achieve that goal? Involve your coworkers and boss as early as possible and try to not only cover your, but also their needs.

IT-Documentation needs to be consistent and central

This is the most important mantra to always repeat when writing your documentation.

1. Define a level of information depth. When you document one piece of information for a single item (e.g. an IP-address of a server), you should document it for all other items as well (all IP-addresses of all servers).
What happens if you don’t? Documentation isn’t just for you, it’s for all the people you are working with. People rely on the information and expect it to be complete. If your coworker finds the IP-address of server A in the documentation, he expects the IP-address of server B also to be documented. If it’s not, he loses trust in the documentation. See “IT-Documentation starts with politics”. Set yourself small goals and try to reach them step-by-step. Yes, it is enough to just document the IP-address and hostname of all servers as a first step – as long as you cover all servers completely.

2. Documentation needs to be up-to-date. If you don’t update the IP-address of a server in the documentation, the same thing applies as in point A: Your coworker finds out it’s the wrong IP and loses trust.

3. Documentation has to follow guidelines. If you describe your printers as “HP Printer X” and the helpdesk guy documents them as “Hewlett-Packard printer X”, you will have a hard time reporting data about your printers. Set some rules for naming schemes!

4. Documentation needs to be placed in one central place. Documentation comes in different shapes and sizes and if your platform can’t handle some files or graphics, just link it. You don’t need .ISO backup files in your Wiki, but you need a link to the place where these files can be found.

Step 2

A comprehensive guide to IT-documentation Step 2

A comprehensive guide to IT-documentation Step 2

IT-Documentation needs to fit your needs

Don’t fall for the hunter-gatherer trap! Try to consider what your needs are in the daily business, what questions you want to have answered and define a set of information that you need. Set this information as a baseline that is known not only by you but also your coworkers. If you document too much, you will never be able to keep the data up-to-date. Another drawback from collecting too much information is that important information might get lost within useless information, and you simply don’t find the information you want.


IT-Documentation needs to be planned and organized

Here are also two things to consider.

  1. Documentation takes time. So plan the time needed ahead and make this fact accepted in all your coworkers and bosses minds. There should be no arguing about extra time needed for documentation.
  2. Include your documentation in your processes and projects. There is a guide on how to set up new servers? Include the necessary documentation as a must do. New Exchange servers are being set up by third-party consultants? Inform them how to include these in your IT-documentation. Let them know the exact requirements you have.

Technical and Operational documentation

These two belong together. Have one place where you document both kind of information. Technical information is the minimum, but why and how something was installed should also be there.

Keep these information asset- and/or service-centric. If you are looking at an E-Mail server, do not explain the MX DNS records in the E-Mail server context, explain it in the DNS server context. If configuration information like this is connected, have an additional service documentation that explains how and why these configurations belong together.


But now hands-on

Let’s get the hands on the practical side. We start with different aspects that your IT-documentation can cover. After reading about the different parts below, you should be able to decide which aspects should be covered in your IT-documentation or not.