And how do you guys usually label SW CIs? This is usually a problem, because people tend to name the same thing differently (OFFICE, MS-OFFICE, Microsoft Office...)

ITIL Support book says we should use a "Copy or Serial Number: The number that uniquely identifies the particular instances of this CI - for example, for software the copy number, for hardware the serial number."

There is numeric increment version for a lot of software and a m arketign sales version which comes out

Windows NT, 2000, 2003, etc

but when you look at the version on the tool there is a numeric version - regardless of what the marketing sales version sales

I would have a table for the vendors - software owner - MS etc, the retail/wholeseller, the software product (w/version),

I would link the physical devices to an instant of the software with another record which would have the license details for that specific instance

that way

server 1 is linked to legit s/w for O/S linked to w/ license details for that version
and that server may be linked to appliication - web exchange etc as well which is linked to a license record

and when I want a list of all servers which have Windows NT 4, lo and behold ... if the database details have been updated properly and validate on a periodic basis. (Cfg mgmt process), then I can get that report rather easily

same also applies to patches and service packs. I would have created tables for the patches and the susequent service patch / major releases for the CIs

Granted it is a lot of work in design
granted it is a lot of work in detail gathering, data entry, update and verify
and time and money

If you are doing this from a licensing point of view or patch mgmt point of view, then the types of tables, the validation cycle amd the related processes would have to match / adjsust_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

This is kind of a "dumb question", but I will post it anyway... I hope you do not flame me too much!

Our servers are all known by their hostnames. We are now trying to establish a nomenclature for servers CIs. As hostnames can change from time to time, I am thinking of creating a new nomenclature for them, instead of calling them in the cmdb by their hostnames.

But they are complaining that they will actually have two names for each server (hostname and "cmdb name"). As everybody (even customers) already know servers by their name, they say there will be a lot of confusion each time someone need to refer to a server in the cmdb. As a result, they want to keep calling each server by its hostname in the cmdb.

I know that each name in the cmdb must be unique and not "changeable". So, the dumb question is: How do you guys deal with it? Don't you get the same arguing in your sites? Should I let them win?

Sigh. This is not an ITIL issue but I will explain something to help you

For a device - servers for one, there are several piece of information that are static

Machine name - this gets created when the device has the O/S installed
Asset Tag - this is usually linked to the DC / facility / company where it is. Financial / accounting type want all assets of a company identified.
IP address, subnet & gateway (initial) for the first NIC card - if you want a server on the network, you usually have to set a static IP. Dynamic IPs for servers are not a good idea (IMNSHO)

Hostnames are usually associated w/DNS and other services

So a server is called - w2kLondon00001 - for its machine name. It is located in the company DC. The DC policy is to put a asset tag to identify it. The IP Address is set when the O/S is installed

Once the machine is live, then the various IT O/S and service wonks add more stuff to it... system level services - exchange, iis etc

Once that starts to happens, Change Management should be applied to making changes to the naming of machines - especially if the machines are in production

NOW to your issue. If the system people are changing the server names - host names - quite often....are they going through change management and if not why ?_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

So you mean that as long as it goes through change management, a CI name can actually change, without becoming a whole new CI?

I mean, if one changes a hostname, he will have to go through change management in order to change the hostname attribute of the server CI. But I think that the CI name should never change (I can be wrong, of course) so that's why it should not be the hostname.

So it would be:

CI Name: SRV001 (unchangeable)
attribute: hostname (changeable through change management, as well as all other attributes)

As guys here are complaining for not using hostname as CI name, I am searching for other implementations to see who is on the right path, me or them.

BTW, a naming convention suggestion would be very much appreciated.

RT,

That's exactly the situation I am thinking of. One fixed CI name for each server (e.g. SVR00x) and a hostname (and other things) as changeable attributes.

There should be an Unique Identifier for every piece of kit that you control / manage etc

This is usually the Machine name (my other post), the asset tag, IP address

Then other names can be added into things like DNS, WINS etc etc as the use of that machine increases

For example

I have a web server call webunixlondon00001. asset 1, ip 1.2.3.4

I have created a website called sales so there is a hostname of the website along with the name above called sales. webserver.company.co.uk
I then add a new name called presales etc and add an IP address of 1.2.3.5
etc etc
until I have 200 web sites that actually point to the same damn server webunixlondon00001.

When the web sites were created, I hope they passed through change management as the project progressed from started tio the final release

So if some of the web hostname get added, changed, deleted, this would be at least a DNS change or a web service change etc (again CM)

But the underlying machine is stil webunixlondon00001. IF that one changes or the IP address changes, that may or may not have a major impact on the aliase that are connected

now to your issues

1 - why are the servers having their name changed. The constant changing of names will impact on incident mgmt, monitoring etc and also shows that there is NO Control of your system engineers

1 - why are the servers having their name changed. The constant changing of names will impact on incident mgmt, monitoring etc and also shows that there is NO Control of your system engineers

2 - what kind of name changes are these - DNS, WINS, hostfile.. etc ....

They are not changing. But the problem is that they CAN change, even if they never actually do.

That's why I argued that we should not use their hostname as the CI name, because a hostname CAN change, even if they never actually do.

I always thought that "a CI name never change. If it changes, it is a new CI".

So what happens if someday, for some reason, there is a need to change a server hostname, if this same hostname is used for the CI name in the cmdb? We will be obliged to change the CI name. But what about the rule "a CI name must never change. If it changes, it is a new CI"?

So the point really is: They think it is OK to change the CI name if necessary, and I think it is not.

Am I right? Or the CI name can actually be changed? If it can, then I have no other arguments to prevent them from labeling CI servers with their hostnames...