Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

OpsMgr 2007 R2 CU1 rollup hotfix ships - and my experience installing it

OpsMgr 2007 R2 CU1 rollup hotfix ships - and my experience installing it

  • Comments 81
  • Likes




****NOTE OpsMgr 2007 R2 CU5 is now shipped and this is an old article.




The KB article describing the fixes and changes:


There are MANY fixes in this update for R2 – and I am not going to go through each one.  Just understand – I will recommend applying this to any customer running OpsMgr R2 as soon as your formal testing and change window cycles allow it.  I have added it to my Recommended Hotfix page.


So – first – I download it, and extract it.  I always install to the default location when it comes to a hotfix like this.  Then I STOP – and go find in the installed path – the README file.  Open it up – and use it to formulate your deployment and testing plan.

Based on the Readme notes.. my plan looks something like the following:


  1. Backup the Operations and Warehouse databases.
  2. Apply the hotfix to the RMS
  3. Run the SQL script update against the OpsDB
  4. Import the updated Management pack provided
  5. Apply the hotfix to all secondary Management Servers.
  6. Apply the hotfix to my agents by approving them from pending
  7. Apply the hotfix my dedicated consoles (Terminal servers, desktop machines, etc…)
  8. Apply the hotfix to my Web Console server
  9. Apply the hotfix to my Audit collection servers
  10. Update manually installed agents…. well, manually.


Ok – looks like 10 easy steps.  This order is not set in stone – it is just a simple recommendation in the release notes.  For instance – if you wanted to update ALL your infrastructure before touching any agent updates – that probably makes more sense and should be fine.

Ok, Lets get started.


1.  I run a fresh backup on my OpsDB and Warehouse DB’s – just in case something goes really wrong.


2.  Since 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.  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.

Setup finishes very quickly – and I am presented with:




Which is odd – because typically in the past our hotfixes didn't require a restart.  Anyway - I hit yes – and saw a short error message about something failing to apply.  Ugh.  Probably a post-hotfix bootstrap process that updates something.  The more I think about it – there more I realized that hitting NO here would be the right thing to do.  This will allow the setup splash screen to finish all the post-hotfix processes that it runs.  Then – when I close all the screens and I am sure the hotfix applied, I can manually restart the OS.  So DONT restart.  Say NO.  Then – when you are all done and happy – you can bounce the server/nodes that required this.


I can see the following files got updated on the RMS:



Next I check my \Agentmanagement folder.

Oops – it looks like I didn't get my agent hotfix files copied over.  Most likely because of the reboot I said “yes” to.

So – time to start over.  From the elevated command prompt – I have to run the MSI again – this time choosing to UNINSTALL the hotfix utility.  Next – run it again to reinstall it, and choose “Run Server Update” again from the menu.  This time – I wasn’t even prompted for a reboot (and I would have said “NO” if I saw one.  It completes, and the splash screen comes back up.

Now – I got check \AgentManagement folders – and they are perfect:




In the AMD64, ia64, and x86 directories – I can now see the hotfix update for agents present there!  Time to move forward.


3.  Time to run the SQL script against the OperationsManager database.  This is simple enough – the script is located on the RMS in the \Program Files\System Center 2007 R2 Hotfix Utility\KB974144\SQLUpdate\ folder, named DiscoveryEntitySprocs.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 OpsDB.  I paste the contents of the file in my query window, it takes about 10 seconds to complete, and returns “Command Completed Successfully”.


4.  Next up – import the MP update.  That's easy enough.  It is located at \Program Files\System Center 2007 R2 Hotfix Utility\KB974144\ManagementPacks\ and is named  It takes a few minutes to import.


5.  Time to apply the hotfix to my management servers.  I have 3 secondary MS servers, one is Windows 2008 and the other two are older, they are running Windows 2003.  So on the 2008 server I open an elevated command prompt to apply the hotfix utility MSI, and just run it directly on the older servers.  Once the splash screen comes up I “Run Server Update”  These all install without issue, and thankfully don’t prompt for a reboot.  I spot check the \AgentManagement directories and the DLL versions, and all look great.


6.  I check my pending actions view in the console – and sure enough – all the agents that are set to “Remotely Manageable = Yes” in the console show up here pending an agent 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:




Looks good.  Note I will have to formulate a plan to go and update my manually installed agents (Remotely Manageable = No)


7.  I have a few dedicated consoles which need updating.  One is a desktop machine and the other is my terminal server which multiple people use to connect to the management group.  So – I kick off the installer – and just choose “Run Server Update as well.

Once again I was prompted to reboot the server.  I choose NO this time, and then this pops up:



I hit OK – and all is well.  I will plan a reboot at some point in the future or once my updates are all complete.

I do a spot check of the files – and see the following was updated on the terminal server:




8.  Next up – Web Consoles.  I actually have two – and both are running on management servers, which I have already patched.  So – I will simply just go check their DLL files to ensure they got updated:

From:   \Program Files\System Center Operations Manager 2007\Web Console\bin


Looks good!


9.  I don't have ACS set up at the moment – but at this point if I did – I would go hit those Management servers that have already been patched – but this time run the update and choose to “Run ACS Server Update”




10.  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 agents behind firewalls, or when you use AD integration for agent assignment, or when you installed manually on DC’s, or as a troubleshooting step. 



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.

  • Thankyou Kevin.

    When running the Manual Agent update, did u experience any issues?


    John Bradshaw

  • My gateway server is in an untrusted domain (from my RMS/MS) and I ran the gateway update on it fine, however, the hotfixes didn't wind up in the AgentManagement directory like they did for the management server & RMS. Should they have?

  • Yes - this is being reported.  If you are going to use the GW to push agents - you should manually copy these files over to it to ensure agents behind the gateway get patched accordingly.

    If the agents behind the gateway are manually installed - then you will need to manually patch them - as any other manually installed agent

  • When trying to update the agents, I continue to get an error message that says..."The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded is missing...". I've used several variations of the following command from an elevated Command Prompt.

    SetupUpdateOM.exe /amd64msp:kb974144-x64.msp /UpdateAgent

    If I use

    SetupUpdateOM.exe /amd64msp:kb974144-x64-agent.msp /UpdateAgent

    then I get "The patch package could not be opened....."

    What am I doing wrong?

  • Hi Kevin, we are in the middle of migrating our agents to R2. Do you know if a SP1 agent can be migrated directly to R2 CU1 ?

  • I know it's early but you think it will be slipstreamed into installation media at all ? Just got our test environment up to R2 and am about ready to go to production, wondering if it would be wise for me to wait

  • I updated our test environment to CU1 but I dont see the updated mps in the environment - they are all still at 6.1.7221.0 with the exception of the manually imported generic report library - is there some step I missed or some other way to import them?

  • We also experienced the GW not getting the updated agent files, was resolved by manually copying these over.

    were there any performance fixes in this CU? our admin consoles are a lot more responsive since the update was applied

  • It does not appear that the agent version number changes in the console with this update. Still shows 6.1.7221.0. I checked the reg where it pulls this from and it indeed shtill shows 6.1.7221.0 even though appropriate files were updated.

    Is this what you have experienced as well

  • Yes, the version numbers didn't change. This is the "correct" behavior for it according to MSFT.

  • Wow, dissapointed to hear that. When using SCCM to deploy in an environment with 6000 agents it would really help to see who didnt get the upgrade using the version number in the console. SCCM is great but there is always a small percentage of clients with broken SCCM agents.

    Oh well, will just build a script monitor to check the DLL version.

  • Brian, in any "Agent" view, select "Personalize View" and then both "Version" and "PatchList"; or let "Discovered Inventory" show "Agent"s

  • Hi Larry,

    Have a look at

    That is the fix I discovered. You'll need to uninstall the hotfix tool and then re-install it in a very specific way - i.e. use an elevated command prompt to call the hotfix installer MSI, don't just click on it.

  • Hi Tim,

    I did run it from a Command Prompt, rt click "Run as Administrator". I said that in my previous post.

    Also, my agents are not being upgraded. As I stated before, I get an error trying to run the installer from a command prompt. I don't understand why, if they are being upgraded, that the file version gets updated but doesn't get translated into the SCOM Console? What files are we supposed to move if the installer doesn't work?

  • Re:  Larry

    What are you trying to do?  What is the goal?

    Are you simply trying to come up with a command line package that will update manually installed agents?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs