Partager via


UR7 for SCOM 2012 R2 – Step by Step

 

 

KB Article for OpsMgr:  https://support.microsoft.com/kb/3064919

KB Article for all System Center components:  https://support.microsoft.com/en-us/kb/3069110

Download catalog site:  https://catalog.update.microsoft.com/v7/site/Search.aspx?q=3064919

IMPORTANT Be aware that the SCOM Web Console package for UR7 includes an important security update (https://technet.microsoft.com/en-us/library/security/MS15-086)

*** Take notice – this update is HUGE with LOTS of fixes, and also has an important security update for a vulnerability in the web console. I’d recommend giving serious consideration to getting this through lab testing and in production to your environments.

 

Key fixes:

  • Security Issue:   The home page link in the Web Console Noscript.aspx file is vulnerable to cross-site scripting (XSS)
    A security vulnerability exists in the Web Console for System Center 2012 R2 Operations Manager that could allow elevation of privilege if a user goes to an affected website by using a specially crafted URL. This fix resolves that vulnerability. For more information, see Microsoft Security Bulletin MS15-086.

  • Report Fix: Agents by Health State" report shows duplicate entries and inconsistent data
    Sometimes a single agent has multiple entries displayed in the "Agents by Health State" report. The fix for this issue makes sure the most recent state of the agent is displayed in the report.

  • Grooming fixes:   Dependent tables are not groomed (Event.EventParameter_GUID table)
    The following issues are fixed:

    • In a database, the grooming of certain MT$X$Y tables were missed because of the filtering logic. Therefore, the tables were never groomed. There were scenarios in which lots of unwanted data was stored in these tables. This issue is now fixed, and data is groomed data from these table. This results in performance gains because there is less data from which to query.
    • In Data Warehouse, the grooming of certain tables was missed occasionally because current logic expects the rows to be returned in a certain order. This issue is now fixed, and the grooming of these tables will not be missed. In some scenarios, millions of rows were stored in these tables. This issue is now fixed. Data is now groomed from these tables. This results in performance gains because there is less data from which to query.
  • Management Packs do not synchronize between management servers
    In a SQL AlwaysOn setup, the SQL in the times of failover does not acknowledge the notifications that are registered by SCOM. This leads to inconsistent data in the environment, and the changes in management pack are not reflected in the whole environment. This update resolves this issue.

  • Grooming fixes:   Leaked transaction causes over 100 SPIDs in SCOM database to be permanently blocked by the "p_DataPurging" stored procedure
    Sometimes, because of a leaked transaction in the p_DataPurging stored procedure, the SPID becomes stuck. This causes other SPIDs to be blocked, and SCOM is brought to a standstill. This issue is fixed in this update. The fix prevents other SPIDs from being blocked.

  • Operations Manager SDK crashes because of SQL errors when QueryResultsReader.Dispose is called
    The Operations Manager SDK could potentially crash when it disposes of a database connection in some scenarios. Additionally, you receive an error message that resembles the following:

    Exception object: 00000004058197a0
    Exception type: System.Data.SqlClient.SqlException
    Message: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
    InnerException: System.ComponentModel.Win32Exception, Use !PrintException 0000000405819050 to see more.

    This update handles these scenarios gracefully.

  • You can't view dashboard performance counters that are created by using the TCP Port Monitoring template
    When you use the TCP Port Monitoring template to monitor network connectivity and the availability of local and remote assets, the template is missing a write action to the data warehouse. With the update, you can present this information on dashboards.

  • Dynamic inclusion rule is added to a group definition unexpectedly if an explicit member instance of the group disappears
    If all the explicit member instances of the group disappear, a dynamic rule is added to the group unexpectedly. With the update, no dynamic rule is generated in these situations.

  • You can't create group by using the SQL Server 20XX Installation Seed
    On the Dynamic Members tab of the Group Creation wizard, if you have a host class of your desired class, and if you try to select the inherited property of the host class, group creation fails. For example, if you select the Display Name(Object) property of Host=Windows Computer of the Management Server class on the Dynamic Members tab, group creation fails, and you receive the following exception:

    Processing the template failed. See inner exception for details.
    Verification failed with 1 errors:
    -------------------------------------------------------
    Error 1:
    Found error in 1|StressCollectPerformancecounterMP|1.0.0.0|UINameSpaceb2240e1340254758bc3a0f1bd0082f4d.Group.DiscoveryRule/GroupPopulationDataSource|| with message:
    The configuration specified for Module GroupPopulationDataSource is not valid.
    : Cannot find specified MPSubElement DisplayName, on MPElement= Windows!Microsoft.Windows.Computer, in expression: $MPElement[Name="Windows!Microsoft.Windows.Computer"]/DisplayName$

    This update resolves this issue.

  • Add MPB support to the SCOM online catalog
    The Management Pack catalog supports only those management packs that have the .mp extension and not the .mpb file-name extension. When this feature is implemented, the Management Pack catalog now supports MPB files.
    This update helps include management packs such as Azure Management Pack and SQL Management Pack on the Management Pack catalog that were not featured because of the .mpb file-name extension.

  • Active Directory Integration in Perimeter Network fails when there is only an RODC present
    When Active Directory Integration is enabled, the SCOM agent cannot talk to an RODC to obtain SCP information and instead looks for a RW domain controller. With this update, the Agent obtains SCP information from the RODC if information is available.

  • Subscriptions that use the filter to search for specific text in the description (of the message) do not work
    When you create a message subscription by using a criterion that contains specific text in the message description, no alerts were received through notifications. With this update, you receive notifications when the message description has specific text.

  • CLR load order change
    The current behavior for agents is to choose a CLR version based on the operating system version. For Windows Server 2012 and newer, the .NET Framework 4.0 is loaded. For operating systems older than Windows Server 2012, the .NET Framework 2.0 family is loaded. On management servers, the .NET Framework 2.0 family is loaded. This essentially maps the .NET Framework version used to the version available out-of-box on the server. The problem with the current behavior is that even if the Management Pack author knows that .NET Framework 4.0 is present on the system, it cannot be used.
    In the new behavior, the agent loads the .NET Framework 4.0 if it is available else it falls back to the .NET Framework 2.0.

  • Problems in obtaining monitoring objects by using "managementGroup.EntityObjects.GetObjectReader"
    In large System Center Operations Manager installations, when entity objects under a management group are retrieved by the object reader by using buffered mode, the object reader sometimes encounters System.Collections.Generic.KeyNotFoundException messages. With this update, the object reader ignores the invalid objects if they are not available.

  • The "Threshold Comparison" setting in the consecutive-samples-over-threshold monitor cannot be configured
    Although you configured the Threshold Comparison setting in the consecutive-samples-over-threshold monitor, the conversion of the Threshold float value from the management pack was incorrect for the German locale and caused monitor configuration failures. This issue is now fixed in this update for every supported locale.

  • Agentless Exception Monitoring (AEM) causes the Health Service to crash because the maximum path length of 248 character is exceeded
    When AEM client monitoring is turned on, sometimes the Windows error reporting file is created in a large file hierarchy. In scenarios in which the path is longer than 248 characters, AEM monitoring was causing the Health Service to crash. This issue is fixed.

  • After you update management packs, the newly added default (visible) columns to view are not visible automatically
    The first time that a view is opened on the console, registry keys are written in the HKEY_Current_User hive. The customization settings for the user are written in the registry. If the default view changes, the customization settings in the registry are not updated to reflect the new defaults. This update adds the newly added default column in the view.

  • Branding update
    Updates the "Operational Insights" name to "Operations Management Suite" in the System Center Operations Management console.

 

Xplat updates:
  • In some cases, Unix and Linux agents report incorrect CPU Processor Time
    The Unix and Linux agents use Percent IO Wait Time when calculating the Percent Processor Time for a CPU object. The agents no longer include the IO Wait Time in the calculation when they return Percent Processor Time.

  • Updates that are included in this update rollup

  • The following files are updated to support the following manageable operating systems.

Debian 8 (x64)  Microsoft.Linux.UniversalD.1.mpb

Debian 8 (x86)  Microsoft.Linux.UniversalD.1.mpb

 

 

Lets get started.

From reading the KB article – the order of operations is:

  1. Install the update rollup package on the following server infrastructure:
    • Management servers
    • Gateway servers
    • Web console server role computers
    • Operations console role computers
  2. Apply SQL scripts.
  3. Manually import the management packs.
  4. Update Agents

Now, we need to add another step – if we are using Xplat monitoring – need to update the Linux/Unix MP’s and agents.

       5.  Update Unix/Linux MP’s and Agents.

1. Management Servers

image

Since there is no RMS anymore, it doesn’t matter which management server I start with.  There is no need to begin with whomever holds the RMSe role.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I can apply this update manually via the MSP files, or I can use Windows Update.  I have 3 management servers, so I will demonstrate both.  I will do the first management server manually.  This management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location:

image

Then extract the contents:

image

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note: You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator (SA) role to the database instances that host your OpsMgr databases.

My first server is a management server, and the web console, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

image

This launches a quick UI which applies the update.  It will bounce the SCOM services as well.  The update does not provide any feedback that it had success or failure.  You can check the application log for the MsiInstaller events for that:

Log Name: Application
Source: MsiInstaller
Date: 8/17/2015 1:17:39 PM
Event ID: 1036
Task Category: None
Level: Information
Keywords: Classic
User: OPSMGR\kevinhol
Computer: SCOM01.opsmgr.net
Description:
Windows Installer installed an update. Product Name: System Center Operations Manager 2012 Server. Product Version: 7.1.10226.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2012 R2 Operations Manager UR7 Update Patch. Installation success or error status: 0.

You can also spot check a couple DLL files for the file version attribute. 

image

Next up – run the Web Console update:

image

This runs much faster.   A quick file spot check:

image

Lastly – install the console update (make sure your console is closed):

image

 

A quick file spot check:

image

 

 

Secondary Management Servers:

image

I now move on to my secondary management servers, applying the server update, then the console update. 

On this next management server, I will use the example of Windows Update as opposed to manually installing the MSP files.  I check online, and make sure that I have configured Windows Update to give me updates for additional products:

image29

This shows me three applicable updates for this server:

NOTE:  Because the web console fix is a security vulnerability – it will show up in “Important” as opposed to “optional”

 

image

image

 

I apply these updates (along with some additional Windows Server Updates I was missing, and reboot each management server, until all management servers are updated.

 

 

Updating Gateways:

image

I can use Windows Update or manual installation.

image

The update launches a UI and quickly finishes.

Then I will spot check the DLL’s:

image

I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

image

2. Apply the SQL Scripts

In the path on your management servers, where you installed/extracted the update, there are two SQL script files: 

%SystemDrive%\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups

(note – your path may vary slightly depending on if you have an upgraded environment of clean install)

image

First – let’s run the script to update the OperationsManager database.  Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file.  Make sure it is pointing to your OperationsManager database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

image

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.  I have had customers state this takes from a few minutes to as long as an hour.  In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.

You will see the following (or similar) output:

image47

or

image

IF YOU GET AN ERROR – STOP!   Do not continue.  Try re-running the script several times until it completes without errors.  In a production environment, you almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.

Technical tidbit:   Even if you previously ran this script in UR1, UR2, UR3, UR4, UR5, or UR6, you should run this again for UR7, as the script body can change with updated UR’s.

image

Next, we have a script to run against the warehouse DB.  Do not skip this step under any circumstances.    From:

%SystemDrive%\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups

(note – your path may vary slightly depending on if you have an upgraded environment of clean install)

Open a SQL management studio query window, connect it to your OperationsManagerDW database, and then open the script file UR_Datawarehouse.sql.  Make sure it is pointing to your OperationsManagerDW database, then execute the script.

If you see a warning about line endings, choose Yes to continue.

image

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation.

You will see the following (or similar) output:

image

3. Manually import the management packs?

image

There are 26 management packs in this update!

The path for these is on your management server, after you have installed the “Server” update:

\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups

However, the majority of them are Advisor/OMS, and language specific.  Only import the ones you need, and that are correct for your language.  I will remove all the Advisor MP’s for other languages, and I am left with the following:

image

The TFS MP bundles are only used for specific scenarios, such as DevOps scenarios where you have integrated APM with TFS, etc.  If you are not currently using these MP’s, there is no need to import or update them.  I’d skip this MP import unless you already have these MP’s present in your environment.

The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service, (Previously known as Advisor, and Operation Insights).

However, the Image and Visualization libraries deal with Dashboard updates, and these always need to be updated.

I import all of these shown without issue.

 

 

 

4. Update Agents

image43_thumb

Agents should be placed into pending actions by this update (mine worked great) for any agent that was not manually installed (remotely manageable = yes):   One the Management servers where I used Windows Update to patch them, their agents did not show up in this list.  Only agents where I manually patched their management server showed up in this list.  FYI.

image46_thumb

If your agents are not placed into pending management – this is generally caused by not running the update from an elevated command prompt, or having manually installed agents which will not be placed into pending.

In this case – my agents that were reporting to a management server that was updated using Windows Update – did NOT place agents into pending.  Only the agents reporting to the management server for which I manually executed the patch worked.

You can approve these – which will result in a success message once complete:

image

Soon you should start to see PatchList getting filled in from the Agents By Version view under Operations Manager monitoring folder in the console:

image

 

 

 

5. Update Unix/Linux MPs and Agents

image

Next up – I download and extract the updated Linux MP’s for SCOM 2012

https://www.microsoft.com/en-us/download/details.aspx?id=29696

7.5.1045.0 is current at this time for SCOM 2012 R2 UR6. 

****Note – take GREAT care when downloading – that you select the correct download for R2. You must scroll down in the list and select the MSI for 2012 R2:

image

Download the MSI and run it.  It will extract the MP’s to C:\Program Files (x86)\System Center Management Packs\System Center 2012 R2 Management Packs for Unix and Linux\

Update any MP’s you are already using.   These are mine for RHEL, SUSE, and the Universal Linux libraries. 

image

 

You will likely observe VERY high CPU utilization of your management servers and database server during and immediately following these MP imports.  Give it plenty of time to complete the process of the import and MPB deployments.

Next up – you would upgrade your agents on the Unix/Linux monitored agents.  You can now do this straight from the console:

image

image

You can input credentials or use existing RunAs accounts if those have enough rights to perform this action.

Mine FAILED, with an SSH exception about copying the new agent.  It turns out my files were not updated on the management server – see pic:

image65

I had to restart the Healthservice on the management server, and within a few minutes all the new files were there.

Finally:

image

 

6. Update the remaining deployed consoles

image

This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.

Review:

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

image

Known issues:

See the existing list of known issues documented in the KB article.

1.  Many people are reporting that the SQL script is failing to complete when executed.  You should attempt to run this multiple times until it completes without error.  You might need to stop the Exchange correlation engine, stop all the SCOM services on the management servers, and/or bounce the SQL server services in order to get a successful completion in a busy management group.  The errors reported appear as below:

------------------------------------------------------
(1 row(s) affected)
(1 row(s) affected)
Msg 1205, Level 13, State 56, Line 1
Transaction (Process ID 152) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Msg 3727, Level 16, State 0, Line 1
Could not drop constraint. See previous errors.
--------------------------------------------------------

Comments

  • Anonymous
    August 17, 2015
    The comment has been removed
  • Anonymous
    August 18, 2015
    @Naveen -

    I get asked that a lot in previous posts. The answer is No, this is not a mandatory step.

    There are many capabilities exposed by an update. You should only make changes when you are impacted and need the resolution provided.

    The same goes for the "Bulk Insert Command Timeout Seconds". I see customers setting this value in the registry and bumping up the numbers on this item. That is WRONG. It should NEVER be adjusted unless the customer is impacted. The only way to know if you are impacted is to get UR5 or later installed - and then see the events that specifically call out a bulk copy failure.

    In general, I am not a fan a tweaking ANYTHING unless it specifically solves a problem the customer is having. In general, I recommend defaults, with the exception of staying current with the latest UR (after testing for 30 days) and then this:http://blogs.technet.com/b/kevinholman/archive/2014/06/25/tweaking-scom-2012-management-servers-for-large-environments.aspx

  • Anonymous
    August 18, 2015
    Hi Kevin, I've noticed with any UR I apply to SCOM, following your steps (i.e. running the msp from Powershell as administrator), my agents have never been placed into pending management. Any idea why this may be? When the agents are in pending management, do you run the agent update executable on all managed servers?
  • Anonymous
    August 18, 2015
    @Gurdeep -
    If you were following my steps to the letter - you would not be running the MSP from powershell. :-) I don't do that and have seen issues. I run it from a command prompt. When you run a cmd within Posh you are still running from the powershell environment and that might be breaking our post-install process.

    Agents will be placed into pending, ONE time, when you run the "server" upgrade - at the end of the process. Only agents that are assigned to the management server, AND are set remotely manageable = true will be placed into pending.

    Every single time someone tells me theirs didn't work, I always find they were not following these steps exactly as they are written. You can review the verbose logs created for the update, and in the logs you can see the pendingaction request - and see why it failed. 90% of the time it is because the user didn't run the locally copied MSP file from an elevated CMD.
  • Anonymous
    August 18, 2015
    Ah, that would be it! I will be picking this up again to try. I assume agents installed via the discovery wizard are default to be remotely manageable. I am going to rip out my SCOM environment lab and do all this again. ) I didn't appreciate the fine differences between cmd/posh.
  • Anonymous
    August 19, 2015
    Thanks Kevin

    Kind Regards | Naveen Kumar B
  • Anonymous
    August 20, 2015
    Thanks, you rock!
  • Anonymous
    August 24, 2015
    Hi Kevin,
    Could you please confirm whether SCOM 2012 R2 supports sql 2014 sp1 cumulative update 1. We have SCOM 2012 R2 installed with SQL 2014.
    Regards,
    Naresh
  • Anonymous
    August 24, 2015
    @Naresh -
    The latest support statement for SQL and System Center support is here: https://technet.microsoft.com/en-US/library/dn281933.aspx

    We generally don't comment un cumulative update levels for SQL, unless a specific one is required. On major service packs, there is no support until it is tested and announced.

  • Anonymous
    August 24, 2015
    Thanks Kevin,
    We have memory leak issue on our current SQL 2014 environment, Microsoft SQL support engineer suggested us to go for SQL 2014 SP1 + CU1. The link says that it is still not supported, looks like we have to wait until is tested by Microsoft :(.
  • Anonymous
    August 27, 2015
    Hi Kevin!
    Is the installation requiring downtime of the system?
  • Anonymous
    August 31, 2015
    Hi Kavin,

    Can I Installing the management servers + Gateway First and Tomorrow Installing the SQL Script ?
  • Anonymous
    August 31, 2015
    The comment has been removed
  • Anonymous
    August 31, 2015
    The comment has been removed
  • Anonymous
    August 31, 2015
    "Bulk Insert Command Timeout Seconds" what's the default timeout?
  • Anonymous
    September 01, 2015
    For information - the TechNet article has now been updated to show support for SQL 2014 SP1. There is no minimum update roll up required for this to work with SCOM 2012 R2.
  • Anonymous
    September 01, 2015
    The comment has been removed
  • Anonymous
    September 02, 2015
    @ Sergei - on "Bulk Insert Command Timeout Seconds" what's the default timeout? The default timeout is 30 seconds I believe. This SHOULD NOT be modified unless directed to do so by Microsoft support. This need to modify is a very rare condition and only applies to very unique or large environments. Just because we expose something to be able to be changed in the registry - does not mean it should be.
  • Anonymous
    September 02, 2015
    @SchalkV -

    Yes - you could update the consoles at a later time if needed.
  • Anonymous
    September 02, 2015
    Thank's Kevin, i suggest to add this text to future UR KB's regarding "Bulk Insert Command Timeout Seconds": This SHOULD NOT be modified unless directed to do so by Microsoft support
  • Anonymous
    September 04, 2015
    Hello Kevin!

    There are no agents in Pending Management although they're remotely manageable and I've full elevated permissions. How can I troubleshoot this?
  • Anonymous
    September 04, 2015
    Hi Kevin,

    call me stupid, but where can i download the whole Update Rollup 7 for System Center 2012 R2 Operations Manager?

    Under the provided link KB Article for OpsMgr: https://support.microsoft.com/kb/3064919 is only the
    Security Update Rollup 7 for Microsoft System Center 2012 R2 - Operations Manager Web Console (KB 3064919)
    available. That's the same as under the update catalog link: http://catalog.update.microsoft.com/v7/site/Search.aspx?q=3064919

    I'm also not able to find the UR7 parts for the Server, Agent, Gateway, etc.... directly in the update catalog....

    So where can i download them to get the file KB3064919-AMD64-Server.msp you mentioned?

    Thanks, Rainer
  • Anonymous
    September 04, 2015
    Hi Kevin,
    We have patched our SQL 2014 Database for OpsDB with SP1 +CU1, where it improved SCOM performance a lot and it is very fast in processing the information.
  • Anonymous
    September 07, 2015
    like Rainer wrote before, I can't find the UR7 parts for the Server, Agent, Gateway, etc.
    Is the UR7 retired already??
  • Anonymous
    September 07, 2015
    It looks like the UR7 has been removed from MS Update Catalog for some reason. The only update left is the Security Update for Web Console. Is there any information of why the rest has been removed? Could we expect that it would be available again soon? We would really like to have a look at this update in our lab environment.
  • Anonymous
    September 08, 2015
    Yep... same here... the download catalog only has the Web Console update available....
  • Anonymous
    September 08, 2015
    The UR7 download catalog site is not showing all the UR7 packages due to an issue internally. We are working to get this restored ASAP. It was NOT intentionally pulled.
  • Anonymous
    September 09, 2015
    UR7 files are available now!:)
  • Anonymous
    September 11, 2015
    Hi Kevin
    I know it's a strange question :) but can I first update manually agent scom to ur 7(I mean use sccm) then update SCOM servers ?
  • Anonymous
    September 11, 2015
    @Tom - yes that's fine. We recommend getting everything to the same UR level as soon as possible, but they are still compatible at different levels.
  • Anonymous
    September 17, 2015
    My question may be stupid one.you have any best suggestion to install client agents to updated ur7 patch,for me servers not showing in pending mangement .
  • Anonymous
    September 21, 2015
    Hi Kevin. Does the Upgrade Sequencing, decribed at: https://technet.microsoft.com/en-gb/library/dn521010.aspx, apply to Update Rollups? Or can we upgrade SCOM to UR7 prior to SCVMM or Orchestrator (bearing in mind that there is integration between SCVMM and SCOM in some environments)
  • Anonymous
    September 21, 2015
    @Ollie - I am not aware of any upgrade sequencing requirements or integration testing between UR's. While we always recommend upgrading all deployments to the latest UR, there should not be interdependency requirements.
  • Anonymous
    September 21, 2015
    Is anyway to verify what Update Rollup I'm currently running on my management server? I can't seem to find any easy way to verify this.
  • Anonymous
    September 21, 2015
    @Scott - it is easy!

    You verify the file versions for each update role as shown above.
    You can also look in the management packs that should have been updated and see what versions you have.

    If you aren't sure if it was implemented correctly - then best bet is to just install the latest update and make sure you do the SQL scripts and MP's. I make that as as simple as possible in these posts.


  • Anonymous
    September 24, 2015
    Thanks for the post Kevin. We have now successfully implemented UR7 in our production environment....so far so good.
  • Anonymous
    September 28, 2015
    Hi Kevin,

    SCOM now supports SQL 2014 SP1 without a UR requirement. Do you know if this now includes support for In-Memory OLTP?

    http://blogs.technet.com/b/momteam/archive/2015/08/29/scom-2012-r2-now-offers-additional-support-for-sql-server-2014-sp1.aspx
  • Anonymous
    September 28, 2015
    @J: It has been (and continues to be) investigated, and this is not simple. There are very strict requirements for a database to leverage InMemory OLTP. The current database designs of the OpsDB and DW do not support this new feature - they would have to be designed/resdesigned to leverage this. Therefore - there is NO SUPPORT for In-Memory OLTP in SCOM infrastructure databases.
  • Anonymous
    September 28, 2015
    The comment has been removed
  • Anonymous
    September 28, 2015
    I meant to ask "Can I roll back from RU7 to my previous RU5 update level without a world of trouble" in my previous post... thx
  • Anonymous
    September 30, 2015
    Kevin please keep going with your blog. best SCOM blog in the world :)
  • Anonymous
    October 07, 2015
    Kevin or anybody in the same situation... We are in the planning stage of upgrading SCOM 2012 SP1 to R2 then to UR7. We have 10 MS, 4 GWs, a separate Reporting Server, and more than 8,000 agents. My question is, should we upgrade everything first to R2, including the agents, then apply UR7? Or can we upgrade all SCOM2012 SP1 servers to R2, apply UR7, then upgrade the agents later from SP1 to R2 UR7? We developed an agent installer package that can be deployed by SCCM, and has the capability of uninstalling previous agent version prior to installing a new agent with UR package. Been searching the net similar to this scenario but no luck. Thanks in advanced.
  • Anonymous
    October 08, 2015
    Kevin, I noticed the same as you that our agents updated but still show the same version of 7.1.10184.0 instead of the "226" but does show "UR7" in the description and on the agent host side. Is this because they didn't update the agent version itself? I'm curious why the agent doesn't show the 226 in its version number as well.
  • Anonymous
    October 14, 2015
    >> I'm curious why the agent doesn't show the 226 in its version number as well.
    same problem
  • Anonymous
    October 16, 2015
    Did they remove x386 for this UR? I see it in all of the previous UR's, but not this one.
  • Anonymous
    October 16, 2015
    That should be x86, not x386, sorry
  • Anonymous
    October 17, 2015
    This is updated as of 10-17-2015 In general - you should evaluate all hotfixes available, and only apply
  • Anonymous
    October 17, 2015
    The comment has been removed
  • Anonymous
    October 18, 2015
    Hi Kevin,

    We have done the UR7 on the Management servers and now all the agents in "agent Required update". We have used Windows update to upgrade all the agents to Ur7 as well. When I am trying to approve the agents via power shell, its not doing it.

    Get-SCOMPendingManagement | where {$_.AgentName -eq " Computer01"} | Approve-SCOMPendingManagement

    When I manually try to approve it, it works. since I work in a huge environment manually approving update is not an option.

    any idea why is this?

  • Anonymous
    October 19, 2015
    Kevin,

    Do you recommend disabling subscriptions during upgrade to prevent email noise?
  • Anonymous
    October 19, 2015
    Hi Kevin,
    We have done the UR7 on the servers and I pushed agent update using sccm 2012 r2 software update. Agents coming to "Pending update" . when I try to approve them using PS it's not working. If I manually approve it it works, but then I can see Monitoring agent installed again in programs and feathers. If this is the case what's the point of patching the Agents using sccm Software update?
  • Anonymous
    October 19, 2015
    Whoever working in a huge scom environment wants to approve all the agents via PowerShell use this command:

    Get-SCOMPendingManagement | where {$_.AgentName -eq "YourComputerName"} | Approve-SCOMPendingManagement -ActionAccount (Get-Credential)

    Hope this helps
  • Anonymous
    October 19, 2015
    @Jon -
    If you patched your agents with SCCM - then you should NOT approve pending agents. You should reject them. Pending is simply an easy way for smaller environments to update their agents via SMB push.
  • Anonymous
    October 19, 2015
    @Fantom -

    It depends on how much noise this generates. Normal well tuned environments - there is no noise so it is a non-issue. Only in really large environments or poorly managed ones - will you see a large amount of heartbeat failure alerts regenerated when bouncing the management servers. But this is the same for anytime you reboot a MS, and not specific to a UR.
  • Anonymous
    October 19, 2015
    @Jon -

    I have customers with large environments that still use the console to update agents. You can mutli-select these, and we only recommend patching about 200 at a time, because this is SMB activity and can have significant network impact depending on your agent layout and network bandwidth, and it is a big impact on SCOM to have that many agents sending data like that all at once. Even a large environment with 5000 agents, 200 at a time is only 50 console operations over time. Certainly PowerShell is the way to go, and this is documented several places. However, you should still limit the number of agents updated at the same time. SCCM is certainly the best way.
  • Anonymous
    October 21, 2015
    The comment has been removed
  • Anonymous
    October 22, 2015
    I updated to UR7 yesterday and I'm having an issue with my xplat agent upgrades. In the Admin console I select "Upgrade Agent" and it instantly hangs the console.
    I have installed the latest UNIX/Linux MPs, upgraded the consoles that will be updating the agents. There doesn't appear to be anything written to the SCOM log.
    I've just opened an incident with MS and I'm waiting for a call back. Has anyone else run into this issue?
  • Anonymous
    November 02, 2015
    Hi Kevin
    I have just setup a new SCOM environment in my company and was about to install UR7 when I just read that UR8 is already out last week. I was wondering will you be posting a similar step by step for UR8 or should I follow the steps mentioned above and replace the UR7 files with UR8 to do the upgrade. Thanks in advance for your response.
  • Anonymous
    November 02, 2015
    @Nirmal -

    I will, but I always recommend waiting at least 30 days after a UR comes out to deploy it, unless this is a lab environment. So I recommend UR7 at this moment.
  • Anonymous
    November 09, 2015
    Thank you Kevin, I have follow this for my production and completed successfully.
  • Anonymous
    November 12, 2015
    Hi Kevin,
    "your account must also have System Administrator (SA) role to the database instances that host your OpsMgr databases" - is it necessary for the whole update proccess or just for running sql scripts? In my infrastructure it will be rather problematic to get thouse rights for the sql instance.
    Thanks for the post and response
  • Anonymous
    November 25, 2015
    When will MS get the SCCM maintenance mode integration to ACTUALLY WORK????

    so Frustrated.....

    And if its working please explain how?
  • Anonymous
    November 25, 2015
    @Justin -

    It doesn't work and SHOULD NOT be used. It has been broken since MOM 2005. I have done all I can internally.... I would not expect anything soon. There seem to be very little interest in fixing this, and not a lot of customer demand driving it on the ConfigMgr side.
  • Anonymous
    November 29, 2015
    Thanks for the confirmation Kevin. Its a shame really. As it would be so usefull during patch management. Well put me down for it to be fixed and HP Australia as well. Its actually a great selling point for getting either SCOM or SCCM into an Environment.
  • Anonymous
    November 29, 2015
    HP Australia? Adelaide? The old EDS?
  • Anonymous
    November 30, 2015
    Hi Kevin, UR7 upgrade completed successfully, Thanks to your Guide. Just 2 issues. 1. Getting Event ID 31569 logged against DataWarehouse Sync Service - Description in health explorer shows as "Report deployment process failed to request management pack list from SQL RS Server. The operation will be retried. Exception 'WebException': The request failed with HTTP status 404: Not Found. One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.DataWarehouse.Deployment.Report Instance name: Data Warehouse Synchronization Service" 2. Report pane is empty in SCOM console no matter which server or workstation I login to. Your help is much appreciated. Thanks in advance.
  • Anonymous
    December 10, 2015
    Hi Kevin,
    Bit off topic....I see there is a UR8, but it doesn't appear under Automatic Updates. Is there a problem with UR8?
    Thx
    JB
  • Anonymous
    December 14, 2015
    Good day. Thanks for the article. Tell me, I have SCOM 2012R2 version, recently updated with SCOM2012SP1. I did not set any UR. I want to install UR7. Based on the Microsoft articles, I can't immediately install UR7, after installing R2. What should I do?

    https://support.microsoft.com/en-us/kb/3096382

    Do not install this update rollup package immediately after you install the System Center 2012 R2 server. Otherwise, the Health Service state may not be initialized.
  • Anonymous
    December 14, 2015
    @John Bradshaw -

    It is there when I look. I don't know about the policies for WU. Are you sure WU didn't automatically apply it?http://catalog.update.microsoft.com/v7/site/Search.aspx?q=3096382
  • Anonymous
    December 14, 2015
    @ Vitaliy -

    Generally we recommend you wait one day in between a fresh install or major version upgrade, to be sure it is fully deployed and healthy - before applying a UR.
  • Anonymous
    December 17, 2015
    Hi Kevin,
    One quick question, can we install this patch on SCOM 2012 R2 Eval license?
  • Anonymous
    December 22, 2015
    Hi Kevin,

    We are running SCOM SCOM2012 SP1 UR6 and planning to upgrade to R2.
    After upgrade to R2, can we directly install R2 UR7?

  • Anonymous
    December 22, 2015
    @Avijit - I don't know. You tell me. :-)

    @Abhishek - Yes - you can. I'd simply wait a few hours after the upgrade to SCOM 2012 R2 to make sure it is working well. I prefer to wait 24 hours to ensure everything is working well by reviewing the OpsMgr event logs on all management servers.

    I'd also implement these registry settings BEFORE the upgrade, and then go back and re-set them or make sure they got preserved after the upgrade
    http://blogs.technet.com/b/kevinholman/archive/2014/06/25/tweaking-scom-2012-management-servers-for-large-environments.aspx

    Especially:

    reg add "HKLMSOFTWAREMicrosoftMicrosoft Operations Manager3.0Data Warehouse" /v "Deployment Command Timeout Seconds" /t REG_DWORD /d 86400 /f

    This reg key is critical for a successful R2 upgrade.
  • Anonymous
    December 31, 2015
    Hi Kevin,
    i have scom 2012 r2 with the following environment:
    2 mgmt servers
    1 web console
    1 ACS
    1 Reporting
    800 agents (All of them windows)

    i applied UR7 and i have an issue which more than 300 agents(no one of them is manually installed) not placed in pending management and this not occurred when i applied the previous rollup UR5.

    regards,
    Ahmed Rabie
  • Anonymous
    January 04, 2016
    @Ahmed -

    I have heard this complaint - but not experienced it. If you run the "server" update on a management server - any agents ASSIGNED to that specific MS will be placed into pending at the end of the update process. It sounds like it worked on one of your management servers, but not the other? If so - you can re-run the update if you want to try again - there is no harm in running just the server update multiple times. Make SURE you run this from an elevated command prompt ONLY. If it doesn't work - no big deal, just run a "repair" on these agents as that does the same thing.
  • Anonymous
    January 05, 2016
    Hi Kevin

    Do you have a guide yet for UR8? Or can we follow the same steps with the new files?

    Thanks

    Luke
  • Anonymous
    January 05, 2016
    You can use the same steps. I plan on writing the UR8 guide today.
  • Anonymous
    January 06, 2016
    Thanks!
  • Anonymous
    January 11, 2016
    KB Article for OpsMgr: https://support.microsoft.com/en-us/kb/3096382 KB Article for all System Center
  • Anonymous
    January 18, 2016
    @Kevin

    Repair Agents solved the problem.

    thanks Kevin
  • Anonymous
    February 13, 2016
    the windows updates are not downloading .