We have a CMDB that populates all our Configuration Items and we record Config changes when changes to Config are made eg adding memory or installing upgrade software to server.
Does a server reboot constitute a Config change? thanks

Is the physical status of your CI a configuration attribute? If yes - then yes... if not - then no. And if yes, why does it matter? YOu should probably be considering how to control server reboots from the CM process perspective, i.e. so that you don't mess up other CIs or unsuspecting users offline in the middle of an important conf call or something like that.

there are least two major threads that discuss this topic ad nauseam. Plus there are side-swipes at it in various other threads. All within the last two years (there's older stuff as well, but it will not have had the benefit of my prejudiced opinion on the matter.

The bottom line is that I can find people here who will explain in great detail why it absolutely must be a change, and others who will explain that in very few circumstances should you even consider making it a change, and in the end anyone can tell you that you have to decide what is right for you anyway._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

We have a CI attribute of status which shows whether it is in stock, live or retired etc but nothing to show availability whether it's up or not. We are using the process to control this but our tool that we using is the evidence that the actuals satisfy the evidence from the process ie detail within change records.
I am interested to know whether reboots can be automatically calculated somewhere from the CMDB as I don't see any attribute that resembles this measure.
Would you suggest that we had to measure reboots manually through the process rather than measuring some relevant attribute pertaining to reboots within the CMDB?
thanks

in your first post you seemed to be asking about whether reboots were changes, which I interpreted to mean do you need to manage each reboot via your change management process. Now you seem to be talking about counting reboot records.

Quote:

We are using the process to control this

Which process are you talking about?
What is "this" that you are controlling? - the reboot, the reboot data, the "change",...?

Somewhere you will keep a record of when a server goes down or is taken down and a record of when it is rebooted. ITIL doesn't really care if this is in your CMDB or your incident log or your event log or your server log or anywhere else. You care - that is why you are asking the question.

The answer is don't worry about ITIL, worry about practicalities. Keep the information somewhere it is easy to put it and easy to access it for whatever purposes of reporting or analysis you have and in a manner that allows you to control the quality of the information (its accuracy, reliability, completeness, timeliness, auditability)

If your CMDB tool does not lend itself to this kind of usage then you either replace the tool with one that meets your requirements or you record the information elsewhere. The choice is probably a no-brainer unless either the CMDB is useless for other things as well, or you have pots of money and spare time floating around._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

If a server reboot is required to change an attribute of the CI then an RFC is required and linked to the CI in the CMDB ...

If you are changing an attribute of a CI then you should already have a change request in process long before you get ready for the reboot which is just a step in the implementation of the change.

As I think you said, if you reboot to correct a fault then you should already have an incident or problem record open for that fault. The important thing now is to ensure that there are no other consequences of the reboot (perhaps from latent changes), and for this reason I advocate having a formal reboot procedure to follow._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718