CSDM - Dynamic CI Groups use in Change Mgmt vs Change Management - Mass Update CI

[Mary Vanatta]

Pre-Paris there is the Change Management - Mass update CI plugin. -  which allows change requesters to propose and apply updates associated with a change request to one or more configuration items in scope for a change.

However with the advent of Dyanmic CI groups will this eliminate the need for the above plugin.  
I can select a "Dynamic CI Group" from the Change Record - Configuration item field.  What would I need the plugin for? 

[spriisholm]

listening in on this one too 🙂

[Richard Nelson1]

Hi Mary/All, I have been looking into this also.  As a former Change/now CMDB Manager I think you would struggle to evidence sufficient control of the change process to an auditor using Dynamic CI groups.

The contents of the Dynamic Group may well have changed since the CR was created, approved, implemented, etc. 

From the target Server CI point of view there will not be a link to the Change Record, something that we are often challenged on during audits.

Your engineers would still need to attach a spreadsheet list of all target servers etc, which is the issue I was hoping this feature would remedy.

Ideally the Dynamic Group would be used to pull the target CI's though to the Change record or create a permanent link of some kind.

On the point of using the Mass update feature to reflect the new patch version etc then deploying discovery to update your target CI's would be a better method if it's an option.

Regards  

[Barry Kant]

Hi Richard, 

that can be done quite easily, but it might indeed be a mix of different classes. So the governance needs to be on the quality of the Dynamic CI group to be able to rely on that.

The CSDM idea of linking Dynamic CI Groups between Technical Offerings and CIs is that this way CIs are managed. Does that automatically means that if you register a change on a Dynamic CI Group that all related CI's are scoped for that change? (by default)

If yes, then you need to fill the affected CIs related list based on the Dynamic CI Group. (That part is not ootb, but quite easy to do)

If no, then you can only take the total list of CIs within the Dynamic CI Group as suggested list. This is also not ootb, but relative easy. The reference qualifier of the affected CI related list must by based on the 'svc_ci_assoc' table, where the parent is the Dynamic CI Group. 

Cheers,

Barry

[Kristine Naess]

Hi all,

we are exploring the solution on this, but haven't started yet. Our plan is to show dynamic CI groups in the change form. When you choose a DCI-group, our plan was to script so that all CIs in this group turns up in the Affected CIs-field. From there, we also planned that you could edit the list to remove CIs that isn't part of the change, even though they belong to the DCI-group. 

For example: if you want to patch all your Linux servers of a certain version, you choose the right DCI-group, go through the Affected CIs related list and, if needed, remove those that you need to patch later. 

But is it impossible to make the connection between the Affected CIs and the change record?

[Richard Nelson1]

Hi Kristine, As Barry kindly pointed out above, it is not possible OOTB however it could be developed using the following approach...

If no, then you can only take the total list of CIs within the Dynamic CI Group as suggested list. This is also not ootb, but relative easy. The reference qualifier of the affected CI related list must by based on the 'svc_ci_assoc' table, where the parent is the Dynamic CI Group. 

Regards