The SP1 Cumulative Update 1 (CU1) for OpsMgr 2007 SP1 has shipped
Get it from the download Center:
The KB article describing the fixes, changes, and instructions:
If you are running OpsMgr 2007 R2 – disregard.
This is for those users who support OpsMgr 2007 SP1, and cannot upgrade to R2 for licensing reasons. I strongly suggest upgrading to OpsMgr 2007 R2 if you can. However, if you are required to stay on SP1 – the CU1 cumulative hotfix for SP1 has shipped.
This hotfix, while “cumulative” moving forward, does have a prerequisite: You must apply the previous OpsMgr 2007 SP1 rollup hotfix FIRST. The previous rollup is discussed HERE. That is the expected baseline for all further SP1 Cumulative updates.
So – to be clear – the expected base platform for this CU1, and all future CU’s for SP1 will be OpsMgr 2007 SP1 + 971541. Once you are SP1+971541, you can apply any cumulative update you want and it will always be cumulative.
Ok – hope that clarifies that. 🙂
- The Active Alerts report from the data warehouse includes auto-resolved alerts that are no longer active in the Operations Manager Console.
- The Generic performance report consumes significant amount of temporary database space, and can fail in some instances
- Agents being taken out of maintenance mode revisit old entries application log in certain cases, causing incorrect alerts to be generated
- Setting up AEM with Sharepoint blocks Watson reporting
- Reports for Operation Manager 2007 SP1 fail when using a shared date warehouse after upgrading a Management Group to R2
- The SDK service hangs in certain cases due to a thread locking issue
- The color of the chart lines do not match the legend in Performance views when using the Web Console
- ACS stops collecting data when the event log uses auto-backup
- The Alert View link in the notification emails shows the list of active alerts, as opposed to the detailed alert description
- The Allow Anonymous discovery property in the Internet Information Services (IIS) Management Pack is incorrect in the console.
- Management Pack discoveries fail when a double-byte character exists in string data being returned.
I do recommend that all OpsMgr 2007 SP1 users apply the previous rollup and this CU1. These together will resolve the majority of issues present in OpsMgr 2007 SP1.
The release notes in the KB article above cover the fixes that are included. I have added it to my Recommended Hotfix page.
So – first – I read the KB article and develop a plan. http://go.microsoft.com/fwlink/?LinkID=2028594
So from the KB article – this update includes steps for the following roles:
- Root Management Server
- Management Server
- Manual SQL script execution (against Operations database)
- Manual SQL script execution (against Warehouse database)
- Stand alone consoles
- Web Console servers
- ACS Collection Servers
- MP import
I build my deployment plan based on the release notes (KB article). My high level plan looks something like this:
- Backup the Operations and Warehouse databases.
- Apply the hotfix to the RMS.
- Apply the hotfix to all secondary Management Servers.
- Run the SQL script update against the Operations Database.
- Run the SQL script update against the DataWarehouse Database.
- Import the updated Management pack provided.
- Apply the hotfix to my Gateway Servers.
- Apply the hotfix to my agents by approving them from pending
- Apply the hotfix my dedicated consoles (Terminal servers, desktop machines, etc…)
- Apply the hotfix to my Web Console server
- Update manually installed agents…. well, manually.
****IMPORTANT – as a best practice, you should log on to your SCOM role servers using a domain user account that meets the following requirements:
- SCOM administrator role
- Member of the Local Administrators group on all OpsMgr role servers (RMS, MS, GW, Reporting)
- SA (System Administrator Role) 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 OpsMgr Administrator role on the OpsMgr 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 OpsMgr 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).
Ok, let’s get started.
1. I run a fresh backup on my OpsDB and Warehouse DB’s – just in case something goes really wrong. Since I haven’t grabbed my RMS encryption key in a long while – I go ahead and make a backup of that too.
2. Update RMS:
Close any open console sessions you may have.
***NOTE: If applying this update to a cluster – FIRST see: How to apply a SCOM hotfix to a clustered RMS
If my RMS is running Server 2008 – I need to open an elevated command prompt to install any SCOM hotfixes. That is just how it is. So I launch that – and call the MSI I downloaded (SystemCenterOperationsManager2007-SP1-KB2028594-X86-X64-IA64-ENU.MSI). This will install the Hotfix Utility to the default location. Then – a splash screen comes up:
I choose Run Server Update, and rock and roll.
***NOTE – it is critical to run the server update from this splash screen that is launched by executing the downloaded MSI. You CANNOT close this splash screen once you kick off the update process. You CANNOT reopen this splash screen later by manually running the hotfix from the extracted location. You need to ALWAYS install the hotfix from the downloaded MSI, and immediately execute the update from the screen above. ANY other actions will result in a failed update, or failure to copy over agent update files, or other post-install procedures. Don’t get “clicky” and things will always work 100%.
Setup finishes very quickly – and I am presented with the final setup dialogue.
Always MAKE SURE you READ this screen. If there is an error, or if setup is interrupted prior to completing with success, it will often be on this same screen, which you might overlook, and assume the install completed ok.
Then I click finish, wait around 30 seconds, and click “Exit” on the splash screen.
IF you ever get prompted for a REBOOT – ALWAYS choose NO.
Now – it is time to validate the update applied correctly. I can see the following files got updated on the RMS in the standard install path: \Program Files\System Center Operations Manager 2007\
**note – this isn’t all the files included in the hotfix package, just a spot check to make sure they are getting updated.
Next I check my \Agentmanagement folder. This is the folder that any agents will get updates from. I check the \x86, \AMD64, and \ia64 directories:
Here – I expect to see the new CU1 KB2028594 msp file, AND the SP1 rollup 971541 files, and an updated MomAgentInstaller.exe.
3. Time to apply the hotfix to my secondary management servers. On a 2008 OS Management Server, I open an elevated command prompt to apply the hotfix utility MSI. Once the splash screen comes up I “Run Server Update” These all installed without issue. I spot check the \AgentManagement directories and the DLL versions, and all look great. REMEMBER – you can sure patch all your management servers at the same time, however, your agents WILL fail over during this time because we stop the MS HealthService during the update. Keep this in mind. It is best to update management servers one at a time, synchronously, to keep your agents from failing over to the RMS and overloading it, or causing massive Heartbeat failures because they have nowhere to report to.
4. Time to run the SQL script against the OperationsManager (OpsDB) database. This is simple enough – the script is located on the RMS in the \Program Files\System Center 2007 Hotfix Utility\KB2028594\Manual Sql Scripts\ folder, named “CU1_Database.sql”.
I simply need to open this file with SQL management studio – or edit it with notepad – copy the contents – and paste it in a query window that is connected to my Operations Database instance, and targeting the OperationsManager database. I paste the contents of the file in my query window, and run it. It takes about 5 seconds to complete, and returns “Command(s) completed successfully”.
5. Time to run the SQL script against the OperationsManagerDW (Warehouse) database. This is simple enough – the script is located on the RMS in the \Program Files\System Center 2007 Hotfix Utility\KB2028594\Manual Sql Scripts\ folder, named “CU1_DataWarehouse.sql”.
I simply need to open this file with SQL management studio – or edit it with notepad – copy the contents – and paste it in a query window that is connected to my Warehouse Database instance, and targeting the Warehouse database. I paste the contents of the file in my query window, it takes about 5 seconds to complete, and returns “Command(s) completed successfully”.
6. Next up – import the MP update. It is located at \Program Files\System Center 2007 Hotfix Utility\KB2028594\ManagementPacks\ and is named Microsoft.SystemCenter.DataWarehouse.Report.Library.mp. It takes a few minutes to import.
7. I would patch my Gateway machines here. Remember to spot check your DLL and \AgentManagement directories. Previous hotfixes did not copy the hotfix MSI to the \AgentManagement directories, and so you might have to do that manually.
8. I check my “Pending Management” view in the console – and sure enough – all the agents that are set to “Remotely Manageable = Yes” in the console show up here as “Agent Requires Update”. I approve all my agents (generally we recommend to patch no more than 200 agents at any given time.)
After the agents update – I need to do a quick spot check to see that they are patched and good – so I use the “Patchlist” column in the HealthService state view to see that. For creating a “Patchlist” view – see LINK
9. Now I can apply this update to any stand alone console servers, like a terminal server that hosts a console, or my desktop machine. There are binary updates to your console itself that must be applied. Simply apply the update just like you do for a management server, choose “Run Server Update”. You might consider removing the agent if it is installed before performing this step – then reinstalling the agent and CU1 afterwards, if you have any issues.
10. Next up is updating the Web Console server. If your web console server is the RMS or a MS – you don’t need to perform this separately as the Web Console components would get updated at the same time as the Management Server components. Only if running the web console on a stand alone server.
11. Manually installed agents. I have a fair bit of these… so I will do this manually, or set up a SCCM package to deploy them. Most of the time you will have manually installed agents on servers behind firewalls, or when you use AD integration for agent assignment, or when you installed manually on DC’s, or as a troubleshooting step for an agent that has trouble installing via the normal methods.
Now – the update is complete.
The next step is to implement your test plan steps. You should build a test plan for any time you make a change to your OpsMgr environment. This might include scanning the event logs on the RMS and all MS for critical and warning events… looking for anything new, or serious. Testing reporting is working, check the database for any unreasonable growth, run queries to see if anything looks bad from a most common alerts, events, perf, state perspective. Run a perfmon – and ensure your baselines are steady – and nothing is different on the database, or RMS. If you utilize any product connectors – make sure they are functioning.
The implementation of a solid test plan is very important to change management. Please don’t overlook this step.