A little tidbit on Hot-fixes for OpsMgr

When you apply a hot-fix to a RMS, or Management Server, or Gateway server... a couple things will happen.  First... it will update the server itself with whatever the hot-fix is supposed to fix... registry, DLL's, database updates, etc.  Next, if the update needs to flow down to all agents... it will place a MSP file in the \AgentManagement directory under the OpsMgr installation directory.





Then, it will put the agents that report to the hot-fixed management server, into pending actions for the update.  It will only place the agents reporting to that MS/RMS into pending... not all agents.  For this reason - you really should patch ALL your RMS, MS, and GW's first, before approving any agents.

Then, when you "approve" an agent for the update... what it does is actually reinstall the agent, from its management server, then apply any update MSP's that are present, and that are not already installed.


So - when you apply a hot-fix to a management group - before approving any agents, it is a good idea to check your \AgentManagement directories on all MS/GW roles, and make sure the \x86 and \AMD64  folders have consistent AND CORRECT patch files present.


When you "approve" agents for the update... or perform a "repair", we recommend only doing 200 agents at a time, max.  Phase the updates out in batches.


Then, use the "Patch List" view described in my previous blog post, to ensure all agents got updated.  For agents that still need to be updated, simply run a "Repair" on those from the console, or patch them manually. 


Any new agents that get pushed will automatically get the current hot-fixes applied, as long as the hot-fix MSP's are present in the \AgentManagent directory.  However, manually installed agents must be hot-fixed manually.


Lastly... on the current batch of hot-fixes....  950853 and 951380 BOTH update the SAME file.... mommodules.dll  950853 (memory leak) updates this file to 6.0.6278.11, and 951380 (cluster discovery) updates the same file to 6.0.6278.20.  IF you are planning on applying both of these fixes... technically, you only need the latter, since it includes the previous fix.


Update 10-15-2008

Now - if you are applying 954903.... this contains mommodules.dll 6.0.6278.36 which supercedes BOTH 951380 and 950853....  so if you need all three hotfixes - just apply 954903.  However - note in the picture below, if you apply two hotfixes that update the same file, the management server \AgentManagement directory still keeps the older one.... apparently the hotfix process does not understand that they update the same file, nor does it clean out the older 951380.  The problem with this - is any major agent deployment will get impacted... because we will add to the install time, and impact the network worse.  In this example - an agent push will be copying over the agent MSI (9MB) plus each hotfix in this directory....  while we dont have any direct guidance on this area - I would recommend removing the older hotfixes that no long apply, or are superceded by other hotfixes already in this directory.



Comments (16)

  1. Anonymous says:

      In general – you should evaluate all hotfixes available, and only apply those applicable to your

  2. Anonymous says:

    Uvádím zde seznam důležitých oprav pro SCOM 2007 SP1, které používám a doporučuji nasadit v každém prostředí.

  3. Anonymous says:

    In general – you should evaluate all hotfixes available, and only apply those applicable to your environment.

  4. Kevin Holman says:

    I dont follow you – can you expound?

  5. Kevin Holman says:

    After installing an agent – where are you looking to determine if the agent hot the hotfixes as well?

    Check the DLL version first – that is the most reliable way to ensure it got it.

    Check the application log for Windows Installer events on an agent push – you should see the success/failure of the agent, and any subsequent hotfixes.

  6. Kevin Holman says:

    Why cant they be remotely updated?

    If the gateway has been patched, and has the update files – why cant it be updated?

  7. jkhemker says:

    In reply to

    "Strangest thing is the dll version (mommodules.dll) is version 6.0.6278.36 yet SCOM displays the Agent version being 6.0.6278.0" :

    The patch is a "small update patch"; these patches do not increment the MSI ProductVersion Property in the first 3 positions, but only in the 4th (irrelevant but visible) position. In this case, the patch creator has decided NOT to increment the ProductVersion at all, which is perfectly legal from an MSI point of view.

  8. Kevin Holman says:

    Are your agents all manually installed?

    Look in "Agent Managed" view – add the "Remotely Manageable" column.  Is this "Yes" or "No"?

  9. Kevin Holman says:

    Where are you looking at agent version??

    Please shoot me an email and lets take this discussion there… I’d like to understand where you are looking to get an "agent verion" that is changing, and what actions you take to change it.

  10. Kevin,

    One issue I did notice was that if you use  active directory integration for your agent assignemnt and then you run a repair from the console the agent wil lose its AD integration. Do you know if this is the case for the hotfix install?

  11. Marnix Wolf says:

    Hi Kevin.

    Thanks for the information.

    However, when I push an Agent from SCOM to a new server, it installs well but the Agent has a lower versionnumber (6.0.6278.0) instead of versionnumber 6.0.6278.36.

    When I perform a repair the right versionnumber is being displayed.

    What goes wrong? The hot-fix MSP’s are present in the AgentManagent directory.

    Kind regards,

    M Wolf

  12. Marnix Wolf says:

    Hi Kevin.

    Strangest thing is the dll version (mommodules.dll) is version 6.0.6278.36 yet SCOM displays the Agent version being 6.0.6278.0. So perhaps SCOM is not showing the correct information about the version?

    The app. log is displaying the succesfull installation of the msi files and the updates (msp files) as well.

    However, after a repair all is well: the dll version is still the same as before the repair but the SCOM console displays the correct version of the Agent.

    So my guess is the SCOM gui is not displaying the correct information. A refresh or dumping the cache does not resolve it though, only a repair does.

    Perhaps SCOM reads the dll version once (just before the updates are being applied) and displays that information in its gui. A refresh doesn’t start that proces again. With a repair SCOM looks again at the version of the dll and displays that information.

    Kind regards,

    M Wolf

  13. Shawn Green says:

    I think this might be a problem with applying the patch to Windows Server 2008 SP1.

  14. Ian Zarzuela says:

    After applying the 956240 hotfix and following the SQL process on the RMS, the version of Microsoft.mom.dataaccesslayer.dll is still 6.0.6278.0. Already tried re-applying to no avail.  Any advise?

  15. olaf says:


    i have another question about applying hotfixes.

    What about servers in DMZ, wich are monitored via gatewayserver? The servers are also reported in "pending managment", but cannot be remotely updated.

    When i patch the agent manualy, what about the "pending managment" entries? Do they disapear, must i reject those updates?



  16. Juergen says:

    i just installed R2, but see no Pending Management now. Shouldn’t I get the agent installed computers in the Pending Management?

    I just have 6.0.6278.0 (SP1) but no chance to install a higher version on the servers

Skip to main content