This is updated as of 5-18-2012 

In general - you should evaluate all hotfixes available, and only apply those applicable to your environment.  However, some of these below I have seen impact almost every environment, and should be heavily considered.

This list is nothing official.... this is just a general list of the recommended hotfixes I end up proactively applying to most environments.... it is not a complete list of ALL hotfixes, and you may be affected by other issues.

Common OpsMgr 2012 updates:

This list ABSOLUTELY assumes you are at OpsMgr 2012 RTM level as a base (7.0.8560.0).

Common OpsMgr 2007R2 hotfixes:

This list ABSOLUTELY assumes you are at OpsMgr R2-RTM level as a base (6.1.7221.0).   

Common OpsMgr 2007SP1 hotfixes:

This list ABSOLUTELY assumes you are at OpsMgr SP1 level as a base (6.0.6278.0).  These DO NOT APPLY these to OpsMgr R2. 

Common related Windows Operating System Hotfixes:

This list is not sorted by OS or anything special – just a collection of OS related hotfixes that SCOM might require, or might fix an issue with the OS that impacts OpsMgr.  These can apply to OpsMgr 2012, 2007R2, or 2007SP1 environments.  

Some general guidance on hotfixes to make you more successful:

ALWAYS - on Server 2008 OS, run the hotfix MSI from an elevated command prompt window. This will launch the install of the hotfix, and then launch the boot-strapper window in an elevated process – which is required. Do this regardless of the UAC configuration of the 2008 OS.

ALWAYS - make sure you read the instructions to understand if the hotfix is a SQL update, installed to the RMS, MS, and/or Gateway, AND/OR applies to agents as well.

ALWAYS - make sure you double-check the DLL version of the updated files to make sure the hotfix successfully applied after installing.

ALWAYS - make sure you double-check the \AgentManagement directory of the management servers and gateways, to make sure if there is an agent update, the x86 and x64 MSP was copied over correctly.

ALWAYS – when installing a hotfix/cumulative update on an OpsMgr server role, run the downloaded MSI, such as “SystemCenterOperationsManager2007-SP1-KB954049-X86-X64-ENU.MSI” – and install the “System Center 2007 Hotfix Utility” to the DEFAULT location – and then kick off the update FROM THE UI that comes up by clicking “Run Software Update”. This is critical and not following this process is the cause for many failures to apply the hotfix DLL’s, or failure to copy the agent MSP update files to the \Agentmanagement directory. NEVER run the MSP files manually on a SCOM server role… because the additional steps run by the boot-strapper will not execute if you do that. The only exception to this – is running from the command line. See: http://blogs.technet.com/b/kevinholman/archive/2010/10/12/command-line-and-software-distribution-patching-scenarios-for-applying-an-opsmgr-cumulative-update.aspx

ALWAYS check the language version of the hotfix, and make sure it is the same language version as your SCOM base install. For instance – if you have a English base SCOM install – do not download a localized German version of a hotfix and apply it – or it can break the English SCOM base install.

ALWAYS log on to your OpsMgr role servers using a domain user account that meets the following requirements:

• SCOM administrator role
• Member of the Local Administrators group on all SCOM role servers (RMS, MS, GW, Reporting)
• SA privileges on the SQL server instances hosting the Operations DB and the Warehouse DB.

These rights (especially the user account having SA priv on the DB instances) are often overlooked. These are the same rights required to install SCOM, and must be granted to apply major hotfixes and upgrades (like RTM>SP1, SP1>R2, etc…) Most of the time the issue I run into is that the SCOM admin logs on with his account which is a SCOM Administrator role on the SCOM servers, but his DBA’s do not allow him to have SA priv over the DB instances. This must be granted temporarily to his user account while performing the updates, then can be removed, just like for the initial installation of SCOM as documented HERE. At NO time do your service accounts for MSAA or SDK need SA priv to the DB instances…. unless you decide to log in as those accounts to perform an update (which I do not recommend).

Make sure you see these additional posts on the subject of hotfixes:

http://blogs.technet.com/kevinholman/archive/2008/06/25/a-little-tidbit-on-hot-fixes-for-opsmgr.aspx

http://blogs.technet.com/kevinholman/archive/2008/06/24/how-do-i-know-which-hotfixes-have-been-applied-to-which-agents.aspx

http://blogs.technet.com/kevinholman/archive/2008/06/27/a-report-to-show-all-agents-missing-a-specific-hotfix.aspx

http://blogs.technet.com/kevinholman/archive/2009/02/25/applying-an-opsmgr-hotfix-to-a-rms-cluster-node-some-things-to-be-aware-of.aspx

Several of these updates require agent updates as well, so be prepared to deal with those.