Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ysyduxaru
New Today: 37
New Yesterday: 34
Overall: 231609

People Online:
Visitors: 153
Members: 0
Total: 153



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Labeling CI
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Labeling CI
Goto page Previous  1, 2, 3
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
Senior Itiler

Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Fri Feb 06, 2009 4:49 pm    Post subject: Reply with quote

This is the same question as that of using a surrogate key in database design. No one should make CI naming decisions without understanding data modelling principles - let somebody else make the decisions if necessary.

A CI needs a unique name (I think the need for uniqueness is obvious!) that never changes (so you can track it, so links to it from other tables remain consistent). The OS host name is a natural key, but it has significance outside the database ... and if it can change in your environment, it's no good as a CI name. Plain and simple.

The serial number would be another candidate. Can that change (in an "upgrade")? Would it then be genuinely a new CI?

Otherwise, you need a surrogate key, a CI name which has no significance at all anywhere else, so you can guarantee it won't change.
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: May 25, 2007
Posts: 105
Location: USA

PostPosted: Sat Feb 07, 2009 5:02 am    Post subject: Reply with quote

A unique ID lets you track it from the time it comes in the door until it goes to the recycling center.

Develop your own unique id standard for CIs. You could start with 1 and go until you're done or you could have a complex algorithm. Whatever works for you.

Using hostnames as a unique id could give you MLXNP345XX001 -- or you could just call the poor thing Ted. Our data center includes customer-owned systems. I think we have three CIs with the hostname Michael; all owned by different customers. We have no control of their hostnames.

Replacement equipment taking on the previous hostname is commonplace. Techies know that Snoopy is a major network switch. If you mention Snoopy and Incident in the same breath, you can literally watch blood drain from faces. If we replace Snoopy with a bigger switch, why rename it to Sally?

If you include location in your ID, what happens when that equipment moves across town or across the world?

Just some thoughts.
Back to top
View user's profile
Senior Itiler

Joined: Nov 18, 2008
Posts: 78

PostPosted: Tue Feb 10, 2009 5:48 am    Post subject: Reply with quote

Thank you guys, your help was awesome!

I think we will have a new nomenclature for servers CIs. Their hostname will be just another (important) attribute.

Back to top
View user's profile

Joined: Oct 27, 2008
Posts: 34

PostPosted: Wed Feb 11, 2009 10:19 am    Post subject: Reply with quote

Hi Chasing Sleep,

One thing that I found useful when defining server CIs, especially in light of the recent push for virtual clusters was to have the OS instance separate from the physical machine. That way, when the machine is converted P2V, the OS layer, hostname and all, can just travel across to the Virtual Host or cluster of hosts and all you really need to do is relate it to the new physical layer and change its category to "Virtual Instance" or something similar.

This also helps the server guys - when they're dealing with physical problems they can look at the physical CI by serial number or asset number (i prefer SN coz it's more easily discovered), and if they're looking at OS problems or changes they can focus on the OS CI.

I think this future proofs a little bit for virtualisation. I think it's a pretty good idea to keep the OSI model in mind when defining CIs...


Edit: dumb grammatical error begone!

Last edited by milligna on Mon Feb 16, 2009 11:40 am; edited 1 time in total
Back to top
View user's profile
Senior Itiler

Joined: Nov 18, 2008
Posts: 78

PostPosted: Sat Feb 14, 2009 6:27 am    Post subject: Reply with quote


That's an interesting idea. Thank you!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.