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


 

 

 

****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 (81)

  1. Anonymous says:

    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.

  2. Anonymous says:

    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

  3. Anonymous says:

    If you run it against master DB – it will likely drop some stored procs in there.  If you arent handy with SQL – best to leave it alone…. you could do more damage than good.

    Make sure when applying hotfixes this way – you follow the KB article or release notes STEP BY STEP…. the instructions on the KB article tell you:

    "From the SQL Editor toolbar, use the Available databases option to select the Operations Manager database. For example, the "OperationsManager" database."

  4. Anonymous says:

    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.

  5. Anonymous says:

    No – this should not be the case.  This typically means the RMS or MS you are pushing the agent from did not get the MSP agent update files dropped into the AgentManagement directories – did you validate this?  I call this out as a step.  This is where new agents get the update from.  It should not be a manual process.  

    They will only show up in pending actions if they are:  

    1.  Not manually installed agents.  Manually installed agents will never show up in pending.

    2.  The agents are moved to pending actions ONLY immediately after the management server they are assigned to gets a SCOM hotfix applied to them that also applies to agents.  They will not just "show up" in pending actions just because they need this update.

    I’d say you either have manually installed agents, or you did not get the hotfix applied correctly to the management servers and the agent files are not present.

  6. Anonymous says:

    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.

  7. Anonymous says:

    1.  You just continue the install – this is normal for any MP that is being *upgraded* and CU1 is a hotfix/upgrade.

    2.  You do NOT approve in both locations.  Placing agents into pending actions is just flipping a switch on the management server – there is no magic.  All it will do when you "approve" the agent is run a repair on the agent – which will reinstall the agent MSI, plus any hotfix MSP files present on the management server.  So simply reject one side – approve the other….  then after a few hours check on the versions using Patchlist and go fix any that failed to update.

  8. Anonymous says:

    Did you run this against the correct OperationsManager database?

  9. Anonymous says:

    Larry – have you tried using the UI for the hotfix installer – and choosing "Run Agent Update" ?

    That is what I would do – or simply run the correct MSP file on the agent:

    KB974144-x86-Agent.msp

    KB974144-x64-Agent.msp

    KB974144-ia64-Agent.msp

    SetupUpdateOM.exe is meant only for the larger MSP files – not these extracted files.  If you need to run this as a command line – the correct syntax should be:

    SetupUpdateOM.exe /x86msp:KB974144-x86.msp /amd64msp:KB974144-x64.msp /UpdateAgent

    You use both MSP’s in the command line – SetupUpdateOM.exe will detect the OS version and apply the correct one.

    You CANNOT simply copy the MSP files and SetupUpdateom.exe over to a new system to patch it – there are other files which are necessary which get extracted to the default location of C:Program FilesSystem Center 2007 R2 Hotfix UtilityKB974144

    The absolute minimum would be a "package" with the two MSP files and SetupUpdateOM.exe in the root, with the Agent and Image folders also copied from the hotfix installer path listed above.

  10. Anonymous says:

    Brian – no script should be necessary.  Our typical method is to create a package as I discuss above – using SetupUpdateOM.exe, which will perform the detection and apply the correct patch.  I will repost it:

    ————————

    That is what I would do – or simply run the correct MSP file on the agent:

    KB974144-x86-Agent.msp

    KB974144-x64-Agent.msp

    KB974144-ia64-Agent.msp

    SetupUpdateOM.exe is meant only for the larger MSP files – not these extracted files.  If you need to run this as a command line – the correct syntax should be:

    SetupUpdateOM.exe /x86msp:KB974144-x86.msp /amd64msp:KB974144-x64.msp /UpdateAgent

    You use both MSP’s in the command line – SetupUpdateOM.exe will detect the OS version and apply the correct one.

    You CANNOT simply copy the MSP files and SetupUpdateom.exe over to a new system to patch it – there are other files which are necessary which get extracted to the default location of C:Program FilesSystem Center 2007 R2 Hotfix UtilityKB974144

    The absolute minimum would be a "package" with the two MSP files and SetupUpdateOM.exe in the root, with the Agent and Image folders also copied from the hotfix installer path listed above.

  11. Anonymous says:

    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 FilesSystem Center Operations Manager 2007AgentManagementx86momagent.msi

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

  12. Anonymous says:

    Kevin, 2 queries Re the CU1 update:

    1. In step 4 of your guide, appying the MP update, when I select it to import it has blue information icon beside Microsoft Generic Report Library 6.1.7221.13 and details say Microsoft Generic Report Library 6.1.7221.0  is alreadt installed.  Do I just continue to install – there is a whole list of dependant MP’s if have to remove this first!

    2. I have multihomed agents for Production and PreProduction.  After update is applied the agents appear in pending Mgmt as requiring update in both Preprod AND Production – do I have to approve the agents in both (if they exist in both).

    Thanks

  13. Anonymous says:

    Thankyou Kevin.

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

    Thx,

    John Bradshaw

  14. Anonymous says:

    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

  15. Anonymous says:

    Hello,

    Anyway to change "Remotely Manageable" from No to Yes?

    Reinstall Client?

    Command Line?

    Thanks,

    Dom

  16. Anonymous says:

    Guido – this is by design.  We should not change the version of the AGENT for a specific DLL hotfix.  I am sorry you disagree.  Your comments on my blog WILL NOT go to the "dev team".  If you feel strongly about this – I recommend you open a case and file a DCR… that is how to engage with microsoft and get things changed.  Complaining on someones blog will do nothing.

    A hotfix does not update the version of the entire agent – only specific files.  I have heard this feedback from a lot of poeple, however, that we dont have something in the same view where we can repair agents, to see which ones need to be updated.  I do think there is opportunity to improve here.  But if you dont open a case and file a DCR, or at LEAST open a bug/feedback on connect.microsoft.com – your feedback will do nothing if it doesnt actually get to the people who can change it.

  17. Anonymous says:

    Yes – you executed this against master – that is incorrect.  It must be executed against OperationsManager

  18. Anonymous says:

    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.

  19. Anonymous says:

    Q:  "Can i only change the 3 *UI*dll files and reboot the Desktop without running "run server update" on every desktop?"

    A:  No.

  20. Anonymous says:

    Yes – you cannot update an eval copy.  If you looked in the setup MSI log you would probably see the evidence of that.

  21. Anonymous says:

    Q:  Gateways – I copied the KB974144-x86/x64.msp files to the gateway servers and lunched it to update them, is that enough?

    A:  No.  You should NEVER run the MSP manually on a SCOM server role.  This is listed in bold red in my hotfix post.  You should install the update on a Gateway just like any other server role, using the hotfix installer, splash screen, and click "run server update".  The only thing special you do with a GW, is you have to manually copy the .msp files over to the AgentManagement directories – IF you push agents from the GW – to ensure they will get the updates as required.

    Q:  Agents – isnt it enough to just copy the msp file in the agent folder into a server which needs a R2>R2 cu1 update?

    A:  No.  The update, like any hotfix, must be installed.  Copying an .msp file to an agent wont do anything.  You must install it.  You can do this from the console by approving an update, or running a repair.  You can do this manually on the agent by running the full hotfix installer, or by copying the .msp file locally then installing it.

  22. Anonymous says:

    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.

  23. Anonymous says:

    Patchlist has always showed all patches for all agents – it gets this from a discovery that runs on the agents.

    Patchlist was changed to collect less data in a post-SP1 MP update, and this was included in R2.

    For filtering and reporting on which agents are missing, or have a hotfix:

    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/2008/06/24/how-do-i-know-which-hotfixes-have-been-applied-to-which-agents.aspx

    You can even run a custom configuration report – add the HealthService objects, and then tick the Patchlist box.  🙂

  24. Anonymous says:

    Your notes are much appreciated Kevin!

    Many thanks

    Can someone confirm that the following files are the only ones updated on an ACS server?

    – C:WINDOWSsystem32SecurityAdtServerAdtServer.exe (v6.1.7221.13)

    – C:WINDOWSsystem32SecurityAdtServerAdtSrvDll.dll (v6.1.7221.13)

  25. Anonymous says:

    Agent version WILL NOT change.

    We do not increment the agent version number in hotfixes – only in major releases (RTM, SP1, R2)

    Incrementing agent version with hotfixes was a major ordeal in MOM 2005 – because not all customers applied all hotfixes, and not all hotfixes were cumulative… so a customer implementing the ".55" version of a DLL hotfix, would not necessarily implement older hotfixes… which update other DLL’s.  The only way you could logically increment the agent version with a hotfix, is if you ONLY have cumulative hotfixes that apply to agents and management servers.

    I would like to see that path taken as well, because agent version is such a simple, sortable field to see who needs a hotfix – and available in the "agent managed" section of the console – but since cumulative hotfixes just started in OpsMgr – I would not expect that anytime soon.

    If you desire this capability – you should file a bug under feedback on connect.microsoft.com for OpsMgr.

  26. Anonymous says:

    Thanks Kevin

    Excellent documentation as always you do.

    Some questions:

    – Any updates for Unix Agents?

    – Remotely Manageable: for us it is a huge deal as the servers AND desktops are communicating only to the server but never from the server, so we have a lot of manual upgrades which could even not be done by SCCM as it is the same blocking steps from the Network team. I made the requests SCCM in May 2009 and SCOM in July 2009 and nothing has been done yet!!!

    – I noticed also on the Agent the Installation date did not changed? is it correct?

    – The HealthService State View with Patch List is a custom View, isn’t it? I did as is but would like to confirm I did not duplicate a default view?

    Servers are ok, Console are ok so the next steps will be prod next week…

    Thanks for this huge efforts to document.

    Dom

  27. Anonymous says:

    Hello,

    I forgot this:

    MOmBidLdr stays 5.2.3790.1289 for x86 machines

    isn’t it?

    Thanks,

    Dom

  28. Anonymous says:

    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?

  29. Anonymous says:

    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

  30. Anonymous says:

    andyinsdca

    If an agent isnt getting the hotfix – two things to check:

    1.  Look at the MS or GW you deployed the agent from – in the AgentManagement folder.  If it is missing on a MS – you didnt install the hotfix correctly.  If it is missing on a GW – you must manually copy it there.

    2.  Look int he application event log of the agent – for the msiinstaller events – and see if the patch is failing.

  31. andyinsdca says:

    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?

  32. Larry says:

    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?

  33. AlanZ says:

    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 ?

  34. Andrew says:

    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

  35. Pete hanson says:

    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?

  36. Jarrad says:

    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

  37. Brian Hansen says:

    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

  38. andyinsdca says:

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

  39. Brian Hansen says:

    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.

  40. jkhemker says:

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

  41. Tim LJMU says:

    Hi Larry,

    Have a look at http://blogs.technet.com/kevinholman/archive/2010/01/17/opsmgr-2007-r2-cu1-rollup-hotfix-ships-and-my-experience-installing-it.aspx

    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.

  42. Larry says:

    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?

  43. andyinsdca says:

    For some odd reason, the CU1 isn’t being automatically sent to newly console-deployed agents. Is it supposed to be? I’ve tried with 3 new deployments in the past couple of days and none are getting it.

  44. andyinsdca says:

    I got it, it just took a few min for the patch to pop into the list. I’m stupid 🙂

  45. Larry says:

    Re: Kevin

    The goal is to successfully complete the CU1 and validate that it has been done.

    Server (RMS and MS) and desktops that are running the Console seem to update fine, but running the same process for individual servers to update the agents isn’t.

  46. Drew Van Order says:

    Hi Kevin,

    As always, superb stuff.

    We too had unpredictable results (.msp’s not copying to(AgentManagement) with a number of our R2 environments. We even found a number of GW’s and MS that still had old SP1 hotfixes, not to mention outdated asp, msxml, and oom files). Opened a call with support and just heard acknowledgement that this has been reported by other customers, and is being looked into. Nice to know MSFT’s remediation steps were what we already did to correct 😉

  47. Larry says:

    Kevin

    Last set of instructions was perfect. Then followed up with steps 6-8 to confirm; all is well. NOW, as you pointed out, how to roll the agent update installer to the rest of the manually installed agents of mixed architecture…or I could spend all night here getting it done.  =-(  I suppose I would miss an opportunity to learn some more Powershell code!!

  48. Brian says:

    Perfect – the patchlist shoes the CU1 patch. I swore in pre R2 it only showed patches that were deployed via the console.

    One other quetion. While I can filter to show agents with CU1 I cannot filter and show Agents without CU1. Anyone know how to do this?

  49. tom says:

    Just wanted to confirm that this hotfix will update the agent version from 6.1.7221.0 to 6.1.7221.13

    Thanks,

    Tom

  50. Brian says:

    No it does not update the agent version. Agent version will stay .0

  51. Brian says:

    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?

  52. Craig Pero says:

    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.

  53. AlanZ says:

    Thanks Kevin, I had a similar experience and I’m now running CU1. My agents are showing that CU1 is installed in the patch list but not the MS and RMS, do you see the same thing ?

  54. azam says:

    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

  55. Larry says:

    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.

  56. Larry says:

    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.

  57. Larry says:

    All,

    Never mind about the RS problem…other issues involved.

  58. Larry says:

    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.

  59. azam says:

    Dear all,

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

    Regards

  60. Brian says:

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

  61. Guido5 says:

    Thanks kevin so far but what I miss: How do I check the correct version of the "new" opsmgr agent? I only see 6.1.7221.0 at my console – what dll version does the updated agent has ??

    Thanks in advance!

    Guid

  62. Brian says:

    90 minutes after running the hotfix on all SCOM servers my alert notifications stopped dead.

    Any ideas??

  63. Guido5 says:

    Notice to the Dev Team: Totally bullshit of the agents still reporting at console with 6.1.7221.0 although the healthservice.dll reports 6.1.7221.13 !!!!

  64. Ani.Ani says:

    Getting this message in SQL Mgmt Studio when i ran the stored procedure update for the Database server..

    The module ‘p_TypedManagedEntityInsert’ depends on the missing object ‘dbo.p_BaseManagedEntityUpdateLastModified’. The module will still be created; however, it cannot run successfully until the object exists.

    What does this mean ? I cannot find any references to this message

  65. Ani.Ani says:

    Yes I did Kevin. And actually I got the message twice..

    Here is the complete message

    —————————

    The module ‘p_TypedManagedEntityInsert’ depends on the missing object ‘dbo.p_BaseManagedEntityUpdateLastModified’. The module will still be created; however, it cannot run successfully until the object exists.

    The module ‘p_BaseManagedEntityInsert’ depends on the missing object ‘dbo.p_BaseManagedEntityUpdateDisplayName’. The module will still be created; however, it cannot run successfully until the object exists.

    —————————

    Additionally in the bottom part it says

    "Query executed successfully" "DBinstanceName (10.0 SP1)" "domainuserid(62)" "master" "00:00:01" "0 rows"

  66. Ani.Ani says:

    Could it be that i executed it against the master db and not my opsmgr db instance ? I am not very good at SQL Mgmt Studio so i am not sure if i had to change something here.

    I am running SQL 2008.

  67. Ani.Ani says:

    DOH !! I reran it against my correct database instance now and it came back saying "Command(s) completed successfully"

    Dumb question … Do i need to go to my master database and clean it up ?

    (my knowledge of SQL procedures and tables is very limited… and if you are asking why I am running this on my OpsMgr database I am in the process of deploying OpsMgr and just getting started with the DB servers, RMS and couple of gateways but no agents anywhere)

    Thank you very much Kevin.

  68. Ani.Ani says:

    Very good. I will heed that advice and get help from my DBA’s to look and advise on what needs to be done.

    *As for why my DBA’s could not do it.. they are overworked like me 🙂

    Thank you very much Kevin.

  69. Sam T says:

    Great notes on the installation Kevin!

    Many thanks!

  70. Dominique says:

    Hello,

    Thanks again for all excellent stuff you are providing on SCOM. The RMS and two MS are now okay. It remains an ex server installed on Gateway and recycled on MS. As there are a lot of comments about the GW I will try to rebuild clean this server to be sure, except if there is a way to identify which function(s) is(are) used by the server.

    So far this server did not have the AgentManagement updated and also the DLLs are not updated.

    Thanks,

    Dom

  71. Lehugo says:

    Should the CU1 be installed ob all SCOM Consoles ?

    When yes, with Run server update ??

    Thanks

  72. Lehugo says:

    Oh, i see. You have to run "Run server update" on all consoles.

    Can i only change the 3 *UI*dll files and reboot the Desktop without running "run server update" on every desktop ?

    Thanks

  73. Shawn Metcalf says:

    After installing the hotfix utility, when running the server update, it stops before finishing and says "The setup wizard was interrupted before System Center Operations Manager 2007 R2 could be installed."

    The server is Windows 2008 R2 Standard.

    The SCOM 2007 R2 installation is an evaluation copy. Could that be causing this problem?

  74. Shawn Metcalf says:

    Okay, fixed it – although I was using an account with local Admin rioghts, it was not a SCOm administrator. Switching to my MSAA did the trick.

    Thanks for the CU1 walkthrough.

  75. Pixel says:

    Hey Kevin,

    Thanks for your help with this article, really helped me.

    I got many manually installed agents, and now im planning on how to install them, and i got a few questions on that and gateways. I saw you writing to larry, but i still got some unanswered questions.

    1. Gateways – I copied the KB974144-x86/x64.msp files to the gateway servers and lunched it to update them, is that enough?

    2. Agents – isnt it enough to just copy the msp file in the agent folder into a server which needs a R2>R2 cu1 update?

    I saw you write we need the msp in the root, the setup*.exe and agent/images dire, is that necessary?? It could make this whole manual installation thing very annoying.. and time consuming, basing on that usually servers that need manual installation are being many restrictions (DMZ)

  76. cornasdf says:

    Thanks for the post Kevin, I ran into an issue w/ the gateways not being updated so several of my approved updates failed. I copied the msps to the agentmanagement folders on the agents and psexec the update based on your and other posts.  

    I put together a post about it at: <a href="http://cornasdf.blogspot.com/2010/04/systems-center-operations-manager-r2.html">http://cornasdf.blogspot.com/2010/04/systems-center-operations-manager-r2.html</a&gt;.

  77. cornasdf says:

    hrm… I guess trying to put a link didn’t work.  here is the link more simply.  

    http://cornasdf.blogspot.com/2010/04/systems-center-operations-manager-r2.html

  78. Sean says:

    Kevin, thanks for the article.  I was able to update with success.  My one issue is:  After the update, when I deploy a new agent from the console, it installs the base R2 agent.  Should that be the case?  

    Is the process of updating every new agent that is installed to CU1 a manual process?  The agents that I have installed do not show the CU1 update in the Agent Version column and they do not show up in Pending Actions for update.  I have been running the .msp after the fact and was wondering if this was the only way to update new agents.  Thanks!

  79. Krish says:

    Servers Used for SCOM Application:

    SCMIP01 – Cluster Node 1 – Windows 2003 Enterprise 64 bit edition (Physical Server)

    SCMIP02 – Cluster Node 2 – Windows 2003 Enterprise 64 bit edition (Physical Server)

    SCMIPV2 – Virtual Name

    SMQIP01 – SQL Cluster Node 1 – Windows 2003 Enterprise 64 bit edition (Physical Server)

    SMQIP02 – SQL Cluster Node 2 – Windows 2003 Enterprise 64 bit edition (Physical Server)

    SMQIPv2 – Virtual Name        

    SCRIP01 – Reporting Server – Windows 2003 Enterprise 64 bit edition (Physical Server)

    (Also serving as Certificate server for monitoring workgroup servers and servers outside the domain and outside firewalls)

    SWCIP01 – Web Console server – Windows 2002 enterprise Service Pack 2 ( Vmware Server)

    1. I know that the hotfix KB974144 need to install in RMS and Reporting servers. I need to know Whether this patch needs to be installed in SQL cluster.

    2. Whether we need to install the patches one by one in all the servers or to install all the patches in one server before moving to the next one.

    3. I have 174 nodes in which the agents had already been installed. I have no idea whether the agents were installed manually or by push method. Please let me know if i need to logon to each server to update the agent.

    Note: We do not have access to any of the nodes, only the customers have access to it.