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

Command line and software distribution patching scenarios for applying an OpsMgr Cumulative Update

Command line and software distribution patching scenarios for applying an OpsMgr Cumulative Update

  • Comments 23
  • Likes

I recently wrote about my experience installing CU3.  The CU3 download is 1.2GB in size.

The primary reason for this, is the integration of the Cross Platform CU3 with the core OpsMgr CU3.  Previously, this shipped separately.  Since the cross platform components are integrated in R2, it is a good idea to make sure a Cumulative update encompasses all aspects of the product, and not just parts.

However, that 1.2GB patch does pose a challenge.  The first challenge, is the network impact, just trying to copy this update out to each location that you need to patch manually, like the management servers, gateways, dedicated consoles on operator desktops, and I won’t even talk about sending out a 1.2GB file to patch manually installed agents!

The second challenge, is running a 1.2GB MSI.  This requires 1.2 GB of available memory, just to open it.  If you have less than this available, it will take a VERY long time.

 

This article will focus on a way to create a new package, which can be MUCH smaller, depending on what components you need to update.  This handles both issues, of large package size impact to the network, and memory consumption trying to execute the large single file.

 

Here are the most common scenarios for updating that I run into for updates:

  • Update the RMS/MS/Gateway servers, Cross Platform monitoring is in use.
  • Update the RMS/MS/Gateway servers, Cross Platform monitoring is not used.
  • Update the dedicated consoles only.
  • Update the manually installed agents, or to create a package for manually installed agents for software distribution to use.

 

Let’s start with each scenario, and cover the package size, and the potential command line you would execute.  You will first need to INSTALL the 1.2 GB MSI somewhere, like on a test system.  This will extract the 1.2GB of update files to your C:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2251525 folder.

 

1.  Update the RMS/MS/Gateway servers, Cross Platform monitoring is in use.

For this scenario, you can simply copy the folder, KB2251525, and all subfolders, to each server to be patched, or copy it to a network location and map a drive from each server to these files.  This package will be 1.16GB in size.  While this still requires moving around 1.2GB of data, the benefit will be we will execute the update from a command line, and this will go much smoother as we won’t have the huge memory requirements to start the update.  The biggest files here are the 4 update files for SCX, to update the RMS, MS, and GW.  IF all of your servers are x64, you could consider removing the two x86 update files here, and this will remove over 500MB from the package size!

image

Here is a sample command line to use (run from elevated command prompt ALWAYS):

SetupUpdateOM.exe /x86msp:KB2251525-x86.msp /amd64msp:KB2251525-x64.msp /ia64msp:KB2251525-ia64.msp /x86locmsp:KB2251525-x86-ENU.msp /amd64locmsp:KB2251525-x64-ENU.msp /ia64locmsp:KB2251525-ia64-ENU.msp /Agent /noreboot

 

 

2.  Update the RMS/MS/Gateway servers, Cross Platform monitoring is not used.

For this scenario, it assumes you do not use any type of cross platform monitoring, and do not plan to in the near future.  You start by copying the folder, KB2251525 (and all subfolders and files), to a new location.  I will rename this folder to “UpdateServerNoSCX”.  From here, we can delete the \SCX-Gateway folder and the two SCX MSP files in the root folder, which are KB2251525-x86-SCX.msp and KB2251525-x64-SCX.msp.  This will remove over 1GB from the package, and create a new package of only 172MB!

image

 

Here is a sample command line to use, which is the same as above (run from elevated command prompt ALWAYS):

SetupUpdateOM.exe /x86msp:KB2251525-x86.msp /amd64msp:KB2251525-x64.msp /ia64msp:KB2251525-ia64.msp /x86locmsp:KB2251525-x86-ENU.msp /amd64locmsp:KB2251525-x64-ENU.msp /ia64locmsp:KB2251525-ia64-ENU.msp /Agent /noreboot

 

 

3.  Update the dedicated consoles only.

For this scenario, we will create a package to update user consoles for their desktops.  Assuming you have 50 operators in your company with the console installed, you don’t want to have to send them a 1.2GB file each!  You start by copying the folder, KB2251525 (and all subfolders and files), to a new location.  I will rename this folder to “UpdateConsole”.  From here, we can delete the following folders:

  • ACS
  • Agent
  • Gateway
  • Management Packs
  • SCX-Gateway
  • SQLUpdate
  • SupportTools
  • Update

And the following files:

  • KB2251525-x86-SCX.msp
  • KB2251525-x64-SCX.msp

image

 

This will create a package that is only 136 MB!

Here is a sample command line to use (run from elevated command prompt ALWAYS):

SetupUpdateOM.exe /x86msp:KB2251525-x86.msp /amd64msp:KB2251525-x64.msp /ia64msp:KB2251525-ia64.msp /x86locmsp:KB2251525-x86-ENU.msp /amd64locmsp:KB2251525-x64-ENU.msp /ia64locmsp:KB2251525-ia64-ENU.msp /noreboot

 

 

4.  Update agents only.

For this scenario – we need a package that can be used to update manually installed agents.  This can be done manually, or via a software distribution.  Assuming you have 100 manually installed agents (or possibly all agents, if you are using AD integration), you don’t want to have to send them a 1.2GB file each!  You start by copying the folder, KB2251525 (and all subfolders and files), to a new location.  I will rename this folder to “UpdateAgent”.  The goal here will be to create the smallest package possible.  From here, we can delete the following folders:

  • ACS
  • Gateway
  • Management Packs
  • SCX-Gateway
  • SQLUpdate
  • SupportTools
  • Update

And the following files:

  • EULA.rtf
  • KB2251525-x64.msp
  • KB2251525-x64-ENU.msp
  • KB2251525-x64-SCX.msp
  • KB2251525-x86.msp
  • KB2251525-x86-ENU.msp
  • KB2251525-x86-SCX.msp
  • ReadMeKB2251525.rtf

    image

     

    This will leave you with a package that is only 14 MB and contains only the following:

     

    image

     

    Here is a sample command line to use (run from elevated command prompt ALWAYS):

    SetupUpdateOM.exe /x86msp:KB2251525-x86.msp /amd64msp:KB2251525-x64.msp /ia64msp:KB2251525-ia64.msp /x86locmsp:KB2251525-x86-ENU.msp /amd64locmsp:KB2251525-x64-ENU.msp /ia64locmsp:KB2251525-ia64-ENU.msp /UpdateAgent /silent /noreboot

    The above will run, detect the correct OS architecture, and apply the correct agent update.  I have added the /silent to this to let this complete with no user interaction required.

    Comments
    • Excellent...Has saved me hours of time!!

      Thankyou again.

      John Bradshaw

    • I updated all consoles in the same way (after read your first post).

      Think, this post will be very usefull.

      Thanks.

    • Superb work once again. Many thanks Kevin

    • I have up to 200 manually installed agents and YOU save my life!

      I do this:

      net use x: file share

      run a bat remotly (I use psexec)

      net use x: /delete

    • Kevin, Thanks!

    • Kevin,

      Thanks a lot for this post! A few days ago I tried running the complete msi package to update a dedicated console. pfff :-)

      Another thing that's required (when you run the full MSI package) is that you have at least (about 2.4GB) free space on your C:\

      Not every Client/Server has that much space available on their C:\ (also they should have :-) )

    • Hi Kevin

      Thanks for the post. I do have a question. My R2 environment does not monitor Unix/Linux servers, but does use the Universal Connector Interop Provider to pass alerts to a Unix system. Should I apply the Cross Platform version or none Cross Platform version from your scenarios above?

    • Connectors are patched with a different update cycle.  

      blogs.technet.com/.../opsmgr-2007-r2-connectors-cumulative-update-2-shipped.aspx

      It will never hurt to go ahead and include the xplat in your update - even if you arent monitoring unix machines.  But if the package size is an issue, you can choose to exclude it.

    • Hi Kevin,

      is there any other reason for using SetupUpdateOM.exe but detecting the right platform to install on? In other words, if I have another way of detecting the correct platform can I trim this down to only the corresponding .msp files?

      So for the x86 platform I only execute:

      KB2251525-X86-Agent.msp /quiet /norestart /l*+ %TEMP%\agent.log

      KB2251525-X86-ENU-Agent.msp /quiet /norestart /l*+ %TEMP%\agent.enu.log

      and for the X64 platform I only execute:

      KB2251525-X64-Agent.msp /quiet /norestart /l*+ %TEMP%\agent.log

      KB2251525-X64-ENU-Agent.msp /quiet /norestart /l*+ %TEMP%\agent.enu.log

      Marc Klaver

    • @Marc -

      For AGENTS ONLY - that process is fine.  No issue.

      For servers that would nto be recommended - because SetupUpdateOM.exe calls several post-install processes which are specific to server roles.

    • Kevin,

      As usual, very relevant information.  Thanks,

      What are the issues with using this method to update even the console installed agents?  SCCM is better at distributing and installing software.

      Ted

    • @Ted - nothing wrong with using SCCM to update agents - no matter how they are installed - if that is your preference.

    • Really helpful.

      I encounter the following error when running the Gateway withouT SCX.

      At the end of installation there's a popup message : "the program failed to apply the Software Update, etc."

      When searching the files not up to date : version 6.1.7000.256 instead of 6.1.7000.277

             MOMSCXLogModules.dll

             scxcertconfig.exe

      Cause : my gateway does not need the SCX part but it was previously installed so I guess the CU3 checks the installed files, finds the SCX files then tries the SCX update and fails.

      I don't think there's any consequences.

      Regards

    • Thanks Kevin.  Would these steps be similar for CU4?

      Thanks,

      -Tom

    • @Tom -

      Identical - only the names of the MSP files would change.

    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