By Tom Kearns 
The entire idea of having a CMDB is to have a single, definitive resource for the configuration of all IT assets. The concept is great but the unfortunate reality is that many times we don’t have a single CMDB and it is not always up-to-date and accurate.
So what happens if the CMDB is not accurate? Well, if the CMDB is not accurate then it could deliver information that would provide access to the wrong asset and I can assure you that no matter how hard (or long) an admin works on the wrong device, the problem will not be fixed. Don’t laugh. It happens, and when it does the experience can be extremely frustrating and costly to the business.
Remember, the CMDB stores information – the information that is entered into it. Much of the information is entered manually by people in many situations and it is very easy to make a mistake. There are also a lot of changes happening that need be recorded in the CMDB and when changes occur, the CMDB is usually updated after-the-fact. That leaves an information accuracy gap that gets repeated over and over again.
I know of one situation where a server was misnamed in the CMDB – sending the admin to the wrong server to fix a problem that didn’t exist there. It was a frustrating experience for everyone involved. This is a classic case of people responding appropriately to a situation based on the information that is available; but because the information is not accurate, the outcome is unsuccessful. When that happens on a critical asset, the frustration (and business impact) starts to escalate quickly.
ConsoleWorks resolves these kinds of issues because it is used to make the connection to servers and other IT devices. Once the connection is made the first time, ConsoleWorks “remembers” how to make that connection from that point forward. This resolves the issue of the out-of-sync CMDB problem. The naming convention in ConsoleWorks requires unique names for each connection eliminating the name issues that can lead to frustration and negative business impact.
