How Do You Handle Multiple RFC pertaining to Patches?

[Debbie]

We currently require an RFC for patches that may affect 1500 plus servers. How do most people handle this with regard to the number of RFCs that get created? If 1 RFC is created how to you go through your approval process since the business owners and system owners are all different? Not to mention all of the application owners.

Do most people consider these a standard change?

[UKVIKING]

Juan//Debbie

Actually I can see a Standard Change patch - the microsoft monthly patches come to mind.

It also depends on whose ox is being gored by the change.

If it is client workstations - Desk & lap tops machines, yes, I would make accept the change as a standard change. The individual machines patching would only affect the individual user machines if the chaneg fails (maybe lots ofthem)
BUT
If it is servers, no.... you can never tell what happens
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[jeffendy]

Hi Debbie,

Applying patches to more than 1500 plus servers can be considered as a major change with high impact. Unless the servers are not the production servers. You better manage this change using project management methodology (i.e. PRINCE2). How many RFCs are created depend on your justification when you put this change into project. Maybe later on you will find useful to create one RFC for each server or one RFC for each division. One RFC can consists of several work orders. Work order can be assigned to the engineer who will perform the jobs.

Regards,
James Effendy

[m_croon]

Debbie,

How many buss. owners are we talking about? Does your tool provide for automated workflows? In that case, you could structure part of the approval process by these workflows. You'd have to define all your bus. owners or their delegates as virtual CAB members.

[UKVIKING]

Juan

I sort of agree to what you said and with what I said. ISTR that a standard change is a change that has been repeatable, known risk etc....

It all sorts of depends on what kind of patch, how many machines, what of machines, impact of doing/impact of not etc

If the patch is for a small # of machines/services and the risk if the patch failing is minimal, then I would let the change run a standard process

However, like you said...if the change's impact is high enough, buzz.

The most important thing is that

change management process and people need to keep a pulse on the operational system and net work world
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[m_croon]

Just to get my former post clear: with automated workflow, I only refer to getting permission (for a CAB change that is). Actually, it is not 100% automated. It just makes sure that the entire process of getting permision is logged in your tool, and that the (CAB) change cannot be promoted to production without all parties giving permission directly in the change. Many tools such as HP Service Desk provide this functionality. With that many stakeholders involved it can be a usefull tool to have this part "automated". I agree that the actual s/w deployment should not be considered a standard change.

[UKVIKING]

Throwing my hands in the air

What do you mean ... Juan... are not All Microsoft patches identical and perfect in every way

ROFLMAO

True Juan True....

While I would not rate the monthly patches from Microsoft standard changes for the server world.... there are some microsoft patches which are less painful than other patches ... it all comes down to the risk

Myself, I would rate the desktop application and o/s patches lower on the impact than server patches
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[jeffendy]

Sometimes the server needs to be restarted after applying patch(es). I can't imagine if 1500 plus servers are restarted at the same time after the patches are applied. In this case, the change must be carefully managed because service disruptions will be experienced by all users in the entire company.

Regards,
James Effendy