I work for different clients and of course all of which have different mechanisms for change management. In the eyes of change management all changes are a change and therefore require a change request. The degree of what constitutes a minor/major service impacting change etc varies from client to client. Where there is a change board and changes are discussed it can be a time consuming and resourceful experience. My experience is that in some cases Change management can also be a bit draconian and often hinders delivery. The change can also be rejected if the change requester fails to articulate the service impact.
So this post is a reminder to self to detail and acknowledge the inherent difficulties associated with Change Management and SCOM which often impedes the progress of performing day to day operational tasks.
Where a client site might have a SCOM/Monitoring team it is important that all are aware of what constitutes a SCOM change ‘on the fly changes, Minor changes, Break/Fix changes and Major’ There is a problem that the details that follow can be construed as an informal agreement amongst the team and comes across as a bit of a nudge nudge wink wink approach.. after all a change is a change and if a change goes wrong we do not have anything to fall back on. So a bit circular issue this one…
Below is a bunch of criteria that I believe is useful and offers guidance determining what change types are allowed under what circumstance.
Change ALWAYS required
1) Adding / removing SQL Cluster and RMS Nodes
2) Adding / removing DR RMS servers
3) Adding / removing Management Servers, SQL Reporting and Web Console servers
4) Adding / removing Gateways
5) Adding / removing Agents
6) Adding / removing sealed or Override Management Packs
7) Adding new Monitors and Rules to Override Management Packs
8) Cluster failback/failover.
9) Amending AD Integration Assignment Rules
10) Modification to Administration settings:
Changing Global Heartbeat Interval
Adding User Roles, Run-As Accounts & Profiles
Modifying User Roles Members
Adding/Modifying a Run-As account to Target a computer
Adding/Modifying notification Settings
Adding/Modifying Connected MG’s
Adding/Modifying to TEC Connector
11) Console: Adding/Modifying New Console Views which are ultimately stored in MP’s. Encourage use My Workspace.
Internal Peer Review ‘ On the fly change’
Any ‘on the fly change’ Perform after some sort of internal peer review.
1) Changing Discovery timers and other criteria
2) Disabling or enabling Monitors or Rules in Override Management Packs
3) Modification to Administration Settings:
Changing Agent Proxy Security
Changing Agent Heartbeat Interval
Changing Proxy Agent
Modifying User Role Views & Groups Only.
Changing Agents Primary Management Server (Should be auto but where not configured)
4) Creating – Scheduling Reports
Break Fix – Retro Change?
1) Changing existing Monitor or Rule parameters and values – message text, trigger values, severity, priority, etc
This is of course the contentious subject. Most client sites I work on I find the SCOM operational staff make these changes anyway. The problem is the MP deployment lifecycle breaks down. Once on the fly change are made the MPNaming convention, Version controlling lifecycle, decision tree ect should be followed. All changes on the fly must be detailed in the Override modification description text detailing name, Date, Description of override, Version increment etc, The MP must then be synced back into any development testing environments the client may have. Often overlooked
2) Fix a Cluster Resource Offline
This is not a complete list so feel free to add to post.