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.

http://blogs.technet.com/b/kevinholman/archive/2011/08/03/opsmgr-2007-r2-cu5-rollup-hotfix-ships-and-my-experience-installing-it.aspx

 

 

--------------------------------------------------------------------

The KB article describing the fixes and changes:

http://support.microsoft.com/kb/974144

 

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:

image

 

I choose Run Server Update, and rock and roll.

Setup finishes very quickly – and I am presented with:

 

image

 

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:

image

 

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:

 

image

 

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 Microsoft.SystemCenter.DataWarehouse.Report.Library.mp.  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:

 

image

 

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:

image

 

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:

 

image

 

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

image

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”

 

image

 

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.

Comments
  • Kevin,

    i followed the above procedure everything worked fine. but when i m trying to upgarde the agents manually i m getting the below error while installing.

    Error 25352.Failed to Start -2147023843 service.

    regards

  • Azam,

    Had the same thing happen on a couple of servers; can't figure out what the difference between servers is. I just restarted the service and then went back to the Console and waited a minute or so and they showed up in the patch list.

  • Kevin,

    Are there any issues with the Reporting Server needing to be updated? I'm getting an error now the the "content type of 'text/html; charset=utf-8', but expected 'text/xml'.

    I've rebooted, restarted the service, gone thru Reporting Services Configuration....everything looks good.

  • All,

    Never mind about the RS problem...other issues involved.

  • Q:   Are there any known issues with upgrading the backend, then taking a couple of weeks to upgrade agents? Or does it need to be done as soon as possible?

    A:  We recommend upgrading the agents as soon as possible - but there is no issue with a patched infrastructure and taking longer to deploy the patches to agents.

  • Q:   did anyone find that the MOMBidLdr.dll file did not match the documentation?  the first one in the documentation for x64 was 5.2.3790.1289 but the file installed was version 5.2.3.3790.1290.  I'm happy to see it a higher number than a lower number but didn't know if this was an issue or not.  I assume if it was breaking something all grief would be on the table at this point.

    A:  The release notes state 1290.  I will ask to have the KB article updated.

  • Q:  My agents are showing that CU1 is installed in the patch list but not the MS and RMS, do you see the same thing?

    A:  This is by design - the RMS and MS and GW do not inventory the patchlist column.

  • Thx Larry,

    When I try to start the service (which is stopped), I get Could not start the SCOM service on Local Computer. Error 1053: The service did not respond to the start control...."

    Shall un-install and try again....

    Given that the environment is CU1, which is the correct file to run on Windows Server 2003, 64bit, for a new manual agent install?

    Is it (from the updated RMS)......  \Program Files\System Center Operations Manager 2007\AgentManagement\x86\momagent.msi

    And secondly, how do u start the install Splash screen now, POST update? The SetupUpdateOM.exe just brings up an information screen.

  • To reinstall the agent - just get a fresh copy of the MOMagent.msi from the RMS or MS \AgentManagement directory correct for the platform and processor, and then also copy the hotfix MSP file.

    Thats it - run the agent first - that will be R2 native.  Then - if that works - add the CU1 fix.

  • Has anyone developed a script to interrogate the server for processor type and architecture so we can push the update to all of our servers? Manually updating is killing me.

  • Um - when you PUSH the agent update from the console - this automatically detects the artchitecture and deploys the correct update - like when you run a "repair" action from the console.

    Also - for manual agent installs - you create a package.

    I already documented the package requirements above in my response to you - simply bundle this in SCCM or software distribution mechanism.

    Or - push from the console.

    If you dont see them in pending - then run a repair on any agents that need the update.

  • As new Servers are added (say a few weeks after the CU1 upgrade), will the Discovery process automatically install the correct agent, or will each one need to have the update applied manually?

    Ta,

    John Bradshaw

  • Yes - hence the importance of checking the \Agentmanagement directories.

    This is discussed here:

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

  • Dear all,

    Can anyone tell me where can i find the patch list?

    Regards

  • Larry - do you just need a script to check 32bit or 64bit then install the correct patch?

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