Serio Blog

Friday, 04 Aug 2006

(or why do you need one?)

Well this is subject I’ll probably come back to a lot!

If you work on a Service Desk/Helpdesk, what is it you do? Hopefully you’ve not answered ‘we fix things’ but have said something like ‘we provide the IT infrastructure and IT services on which our business depends to operate efficiently’.

Here’s a question then: where is the IT infrastructure you have to provide documented? If it isn’t documented, how do you assess the impact of Changes you wish to perform? If it isn’t documented, how do you assess the effect of Incidents on the business?

This is the role of the CMDB: to document the IT infrastructure to the benefit of the Service Desk/Helpdesk. It’s job is to provide a logical picture of how the infrastructure fits together, the interdependencies between Configuration Items (CIs), the services that we offer to users and how those services are provided.

This means (of course) that the entries in the CMDB (Configuration Items) are not machine generated (though you can kick start your CMDB that way). Instead, CIs and the information in the Configuration Database are maintained by people, as part of Configuration Management.

I’ll continue this subject in my next post.

Wednesday, 02 Aug 2006

[Posted by site admin in George's absense, filled by email] My previous post on Monday referred to what should be in the CMDB, and in particular I mentioned virtual Configuration Items.

When starting with a CMDB, a lot of Service Desk/Helpdesk professionals seem to focus on ‘tangibles’ – server hardware, network devices such as routers, and network links such as ADSL and MPSL. Whilst worthy, these may only tell half the story.

Suppose that you have a server computer called ‘ROMA’ on your network that runs a SQL Server database and a web server running a .NET application. This computer ROMA is recorded in the CMDB – namely, you record what type of machine it is, how much memory is has, it’s maintenance details and so on. However, you need to address in a structured way the question ‘what does this machine do’ or ‘what is it’s business role’.

All too often, this is recorded in comments. A better approach, particularly with ITSM systems like Serio that display the CMDB graphically, is to create virtual Configuration Items (I’ll post a definition of the CMDB shortly). These are Configuration Items that you can’t touch, but do exist and add business value.

In the case of ROMA, you might create 3 new Configuration Items (CIs).

CI for the SQL Server database instance

CI for the Web Server

CI for the .NET application

What you would then do is link these together (the quickest way to do this in Serio is via copy & paste). The SQL Server CI is linked to ROMA, the Web Server CI is linked to ROMA, and the .NET application is linked to the Web Server. Of course, you can add additional links and dependencies onto the CMDB if that is how you perceive the interdependencies.

Doing this adds real value to the CMDB in many ways. For instance, looking at ROMA you can now see information about the components in provides into wider IT systems, and your new virtual CIs can themselves carry richer information such as recovery procedures.

Monday, 31 Jul 2006

Well I though I would start my first blog entry with a question – what should go into your Configuration Management Data Base? (I’ll leave the question of why the Service Desk needs a CMDB for another time.)

There are lots of valid ways of approaching this for Service Desks/Helpdesks using ITIL. One of the best ways of approaching this is to say:

Q: What is a Configuration Item (CI)?

A: It’s something that we may wish to subject to Change Control.

So, what do you want to subject to Change Control procedures? It’s almost certainly going to be enterprise level entities – servers, network switches and so on. It does of course imply that you have some leeway in terms of desktops and desktop level equipment. I always like to remind people that ITIL is not prescriptive its approach, and the real skill in implementation is to fit it correctly to your own business.

You can take this to mean that, in my view, it is sometimes OK to exclude some or all desktop equipment from the CMDB.

Considering the CMDB in this way also leads us to consider the fact that not all CIs need to be physical – virtual CIs can also be included (personally, I would always advise that they should be). Virtual CIs might include web servers, database servers, or even entire systems.

I’m going to post more about the CMDB later in the week, and will come back to this question then.

Friday, 28 Jul 2006

As I mentioned in my previous post, the Command Center now has a Script Builder.

This is a tool for those building their own Device monitoring Scripts (as opposed to using the standard Scripts that Serio provide). Rather than having to build a new Script from scratch, the Script Builder can be called on at any time to build a Script for you, that works on either SNMP Scalars or SNMP Tables.

What you tell the Script builder is what type of variable or table you are applying validation to. By this, I mean is the value a ‘gauge’ type (for instance, like the rev counter on a car) or is it something different (for example, a status flag). From here you supply other criteria such as what constitutes an error, and how you want the error to be handled (the full range of options is available to you), wether you want auto or manual reset and so on. At the end, you get a Script that will compile, run, and do the job you’ve requested.

In fact, the Script that comes with the Command Center for Microsoft Exchange Server 2003 monitoring was built entirely using the Script Builder.

Thursday, 27 Jul 2006

As I have the honour of writing our first blog entry, I thought I’d start by saying we have an upgrade coming within the next four weeks. As usual, we’ll issue upgrade instructions to all customers with a support contract when the upgrade is ready, along with full info on what is new and how to upgrade.

One of the most significant changes is to our Command Center tool. This product is used for monitoring servers, network links, printers and so on, and is part of our Availability Management offering.

We’ve added quite a few new features, one of the most important of which is Device Properties. These are associated with Validation Scripts, but allow you to attach data directly to the Device within the Command Center set-up – obviating the need to use Value Sets. You can also display Device Property values on the improved status web page displays. So now, for each of the variables you are monitoring, you can see both the target (or threshold) value, and the observed (or current) value in a single place.

Those of you using Value Sets for your own Scripts will be fine – Value Sets still exist and work the same way.

In addition a lot of improvements have been made to the Script editing interface, including a ‘Validation Script Wizard’ that produces finished Validation Scripts for you. I’ll post more on this subject shortly.