UR13 for SCOM 2012 R2 – Step by Step

Article
05/27/2017

KB Article for OpsMgr: https://support.microsoft.com/en-us/help/4016125

Download catalog site: https://www.catalog.update.microsoft.com/Search.aspx?q=4016125

Updated UNIX/Linux Management Packs: https://www.microsoft.com/en-us/download/details.aspx?id=29696

NOTE: There is a serious bug in the UR13 Web Console update. Because of this, you should not apply it, but instead apply the UR12 update to the web console. This is documented in the “Known Issues” at the bottom of this page.

NOTE: I get this question every time we release an update rollup: ALL SCOM Update Rollups are CUMULATIVE. This means you do not need to apply them in order, you can always just apply the latest update. If you have deployed SCOM 2012R2 and never applied an update rollup – you can go straight to the latest one available. If you applied an older one (such as UR3) you can always go straight to the latest one!

Key Fixes:

After you install Update Rollup 11 for System Center 2012 R2 Operations Manager, you cannot access the views and dashboards that are created on the My Workspace tab.
When the heartbeat failure monitor is triggered, a "Computer Not Reachable" message is displayed even when the computer is not down.
The Get-SCOMOverrideResult PowerShell cmdlet does not return the correct list of effective overrides.
When there are thousands of groups in a System Center Operations Manager environment, the cmdlet Get-SCOMGroup -DisplayName "group_name" fails, and you receive the following message:
- The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
When you run System Center 2012 R2 Operations Manager in an all-French locale (FRA) environment, the Date column in the Custom Event report appears blank.
The Enable deep monitoring using HTTP task in the System Center Operations Manager console does not enable WebSphere deep monitoring on Linux systems.
When overriding multiple properties on rules that are created by the Azure Management Pack, duplicate override names are created. This issue causes overrides to be lost.
When creating a management pack (MP) on a client that contains a Service Level (SLA) dashboard and Service Level Objects (SLO), the localized names of objects are not displayed properly if the client's CurrentCulture settings do not match the CurrentUICulture settings. In the case where the localized settings are English English, ENG, or Australian English, ENA, there is an issue when the objects are renamed.
This update adds support for OpenSSL1.0.x on AIX computers. With this change, System Center Operations Manager uses OpenSSL 1.0.x as the default minimum version supported on AIX, and OpenSSL 0.9.x is no longer supported.

Lets get started.

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

Install the update rollup package on the following server infrastructure:
- Management servers
- Audit Collection servers
- Gateway servers
- Web console server role computers (which we will skip in this update because of a known issue)
- Operations console role computers
- Reporting
Apply SQL scripts.
Manually import the management packs.
Update Agents
Unix/Linux management packs and agent updates.

1. Management Servers

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 2 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:

Then extract the contents:

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 role to the SQL database instances that host your OpsMgr databases.

My first server is a Management Server Role, and the Web Console Role, and has the OpsMgr Console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

This launches a quick UI which applies the update. It will bounce the SCOM services as well. The update usually does not provide any feedback that it had success or failure.

You *MAY* be prompted for a reboot. You can click “No” and do a single reboot after fully patching all roles on this server.

You can check the application log for the MsiInstaller events to show completion:

Log Name:      Application
Source:        MsiInstaller
Date:          5/25/2017 9:01:13 AM
Event ID:      1036
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 UR13 Update Patch. Installation success or error status: 0.

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

Next up – run the Web Console update:

This runs much faster. A quick file spot check:

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

A quick file spot check:

Additional Management Servers:

I now move on to my additional management servers, applying the server update, then the console update and web console update where applicable.

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:

The applicable updates show up under optional – so I tick the boxes and apply these updates.

After a reboot – go back and verify the update was a success by spot checking some file versions like we did above.

Updating ACS (Audit Collection Services)

You would only need to update ACS if you had installed this optional role.

On any Audit Collection Collector servers, you should run the update included:

A spot check of the files:

Updating Gateways:

I can use Windows Update or manual installation.

The update launches a UI and quickly finishes.

You MAY be prompted for a reboot.

Then I will spot check the DLL’s:

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

***NOTE: You can delete any older UR update files from the \AgentManagement directories. The UR’s do not clean these up and they provide no purpose for being present any longer.

I can also apply the GW update via Windows Update:

Reporting Server Role Update

I kick off the MSP from an elevated command prompt:

This runs VERY fast and does not provide any feedback on success or failure.

NOTE: There is an RDL file update available to fix a bug in business hours based reporting. See the KB article for more details. You can update this RDL optionally if you use that type of reporting and you feel you are impacted.

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 or clean install)

First – let’s run the script to update the OperationsManagerDW (Data Warehouse) database. Open a SQL management studio query window, connect it to your Operations Manager DataWarehouse database, and then open the script file (UR_Datawarehouse.sql). Make sure it is pointing to your OperationsManagerDW 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.

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

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: “Command(s) completes successfully”

Next – let’s run the script to update the OperationsManager (Operations) database. Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file (update_rollup_mom_db.sql). 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.

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:

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 with lots of activity, you will 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 any previous UR deployment, you should run this again in this update, as the script body can change with updated UR’s.

3. Manually import the management packs

There are 58 management packs in this update! Most of these we don’t need – so read carefully.

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 MP’s for other languages (keeping only ENU), and I am left with the following:

What NOT to import:

The Advisor MP’s are only needed if you are connecting your on-prem SCOM environment to Microsoft Operations Management Suite cloud service (OMS), (Previously known as Advisor, and Operations Insights).

The APM MP’s are only needed if you are using the APM feature in SCOM.

The Alert Attachment and TFS MP bundle is 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.

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

Agents should be placed into pending actions by this update 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. The experience is NOT the same when using Windows Update vs manual. If yours don’t show up – you can try running the update for that management server again – manually.

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.

I manually re-ran the server MSP file manually on these management servers, from an elevated command prompt, and they all showed up.

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

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

I recommend you consider the following MP which will benefit the Agents by version so you can see the agent version *number* under Agent Managed in Administration:

https://blogs.technet.microsoft.com/kevinholman/2017/02/26/scom-agent-version-addendum-management-pack/

5. Update Unix/Linux MPs and Agents

The current Linux MP’s can be downloaded from:

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

7.5.1070.0 is the SCOM 2012 R2 UR12 release version.

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

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.

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 – you need to restart the “Microsoft Monitoring Agent” service on any management servers which manage Linux systems. I don’t know why – but my MP’s never drop/update the UNIX/Linux agent files in the \Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits folder until this service is restarted.

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

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

Finally:

6. Update the remaining deployed consoles

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.

You can use Help > About to being up a dialog box to check your console 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.

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.
——————————————————–

2. The Web Console update breaks the Web Console Silverlight in UR13.

Issue:

Once you apply the UR13 Web Console update, the initial web console connection prompts constantly to “Configure” Silverlight. You can run configure, but this repeats…. And the web console is not useable for the customer, as you cannot get past the configure prompt. If you choose “skip” then the web console will not be useable.

Cause:

When we initially connect to the Web console, we check to ensure the client has a code signing certificate that matches the .XAP files that are part of the web console. If we detect that the client does not have the correct certificate, we will prompt to Configure this. We include a file silverlightclientconfiguration.exe on the webserverwhich basically does two things: (1) modifies the registry to AllowElevatedTrustAppsInBrowser, and (2) installs the Microsoft code signing certificate that was used to sign the .XAP files.

We included an updated set of .XAP files for the Web Console in UR13, and these were signed with the latest MS Code Signing certificate (Expiring 2/17/2018)

When we update the cert for signing, we are SUPPOSED to include this cert in the silverlightclientconfiguration.exe file. However, this file was not updated with the new cert in UR13. It contains the same certs that worked in UR12.

The result it that users are prompted to “Configure” the Silverlight plugin, but even after running Configure, they continually get re-prompted because they do not have the correct certificate, which allows for Silverlight Elevated Trust Apps in Browser.

Known Workarounds:

Uninstall the UR13 web console update. Revert to the previous version or apply UR12 Web console update after you uninstall UR13.
1. Instructions to uninstall a specific patch are in the UR13 KB article. For US/English example: msiexec /uninstall {9B15724B-02A8-4783-95AB-648F7B74F228} /package {B9853D74-E2A7-446C-851D-5B5374671D0B}
2. If the customer was not previously on UR12, install the UR12 Web Console update (after uninstalling UR13 above) which has XAP files signed with the same certificate delivered in silverlightclientconfiguration.exe
Manually handle the certificate distribution. Either via registry file, or import the cert into the trusted publishers. You can export this cert by viewing the digital signature configuration on either of the XAP files.

clip_image002

Generally speaking, option #1 will be the least customer impacting and simplest to resolve the issue.

Comments

Anonymous
May 30, 2017
Hi Kevin,The update seems to change the column, "Update Rollup" (on your recent Agent Management Pack) to be the same as Agent Version.Before Update 13, the column showed 2012 R2 UR12, now it shows 7.1.10302.0.Thx
- Anonymous
  May 31, 2017
  John - I updated the agent management MP. It will have to be updated each time a UR comes out if we want to show the text UR Level, because the script has a case statement based on numerical version. If you look at this script you can see how to maintain it just in case I didn't
  - Anonymous
    June 07, 2017
    Easy...Thx again.
Anonymous
July 05, 2017
I updated to UR13 earlier today. I ended up importing the new 'Advisor' MPs simply because they were already there. We're not doing any kind of cloud connection, so I don't believe them to be needed. Is there some way to tell if the Advisor MPs are being used?
- Anonymous
  July 05, 2017
  If you aren't using OMS, and connecting SCOM agents to OMS via SCOM - you don't need them. https://blogs.technet.microsoft.com/kevinholman/2016/03/26/how-to-remove-oms-and-advisor-management-packs/
Anonymous
July 05, 2017
For anyone who updated to UR13 - see the workaround for the broken web console silverlight issue.
- Anonymous
  July 11, 2017
  Hello Kevin,After I updated SCOM 2012 R2 to IR 12 and UR13, my performance reports seems to be reporting no data. Please help -- I'm looking for a solution with the least impact. Thank you in advance
Anonymous
July 06, 2017
Hi Kevin, we have the SilverlightClientConfiguration issue with the Web Console at UR11. We also have the issue with My Workspace dashboard views that I raised a case about and spoke to Microsoft Support yesterday who recommended UR13 to fix the My Workspace dashboard issue. Will applying UR12 fix both of these issues? Ironically, I printed this guide yesterday evening after speaking to Microsoft Support and thankfully revisited this morning to discover your latest update..! Many thanks, Michael
Anonymous
July 13, 2017
Hi Kevin,Thanks for the useful article. Tell me, please, what if UR13 is already installed on the management server using WSUS? It appears that made only 1. and 4, since the updates are rolled to all servers. Besides, I've already done 3, 5 and 6. Is it possible now to pass step 2 - run the SQL scripts? Or will now have to wait for the next UR and do everything according to instructions?
- Anonymous
  July 13, 2017
  If your management servers got a UR from WSUS/Windows Update, then I'd absolutely just continue with applying the other items in the blog post, such as the SQL scripts. The order isnt super critical - but you want to get to a "supported" configuration as soon as reasonably possible. So yes - apply step 2 as soon as you reasonably can.This is why I hate that we put these updated for server roles in Windows Update. In my opinion, that is a mistake and causes problems, since there are additional requirements. We should only publish agent updates to WSUS/WindowsUpdate, not servers role updates, as they have additional requirements. :-(
  - Anonymous
    July 14, 2017
    Thank you for your response. Then the next question is about the SQL scripts. Last UR, I bet the instructions were 11. And scripts are in the %SystemDrive%\Program Files\System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups. So, these scripts are equally suited for all updates or for each update different scripts? If each update is another script, can you please tell me where to get scripts for UC13? Thank you.
  - Anonymous
    July 14, 2017
    I have files:Name = Size = Dateupdate_rolluo_mom_db.sql = 250920 = 23.08.2016UR_Datawarehouse.sql = 150755 = 14.01.2016Is it right?
    - Anonymous
      July 14, 2017
      Both files should have 8/23/2016 date. To be sure you have the latest:1. delete or rename those files you have.2. manually reinstall the UR13 management server update on one of your management servers.3. this will drop new files in that folder for you to use. There is no problem re-installing a UR on a MS.
      - Anonymous
        July 14, 2017
        ok, i move it to folder .\ur13then i run KB4016125-AMD64-Serfver.msp (wich is unpacked from .cab, which i downloaded from http://www.catalog.update.microsoft.com/Search.aspx?q=4016125)now i have the same files, but date created is: ‎26 ‎April ‎2017 ‎г., ‏‎00:17:24 and ‎26 ‎April ‎2017 ‎г., ‏‎00:30:00.Is there something wrong?
      - Anonymous
        July 14, 2017
        No, all good - just use those files. Apparently it must not update the files if they exists at the same version.
      - Anonymous
        July 25, 2017
        Kevin, thanks for your help!
Anonymous
July 26, 2017
The comment has been removed
Anonymous
August 09, 2017
Hi Kevin,"When we update the cert for signing, we are SUPPOSED to include this cert in the silverlightclientconfiguration.exe file. However, this file was not updated with the new cert in UR13. It contains the same certs that worked in UR12."This sound like something easy to be fixed. Do you think Microsoft might come out with a hotfix with an updated silverlightclientconfiguration.exe file?We are deploying UR13 to fix the workspace webconsole issues. For now we did leave the web console on UR12 because we noticed your warning just in time.
Anonymous
September 12, 2017
Thank you for the updates.
Anonymous
September 14, 2017
Thanks for this! I have a question about the SQL scripts.The first script to update the datawarehouse finishes in under a second, is that normal? The second script is still running for a while though ...
- Anonymous
  November 17, 2017
  Thanks for this, all is fine now :)
Anonymous
September 26, 2017
Hi Kevin,Thanks for the in-depth post as always, just a note, i have a few servers with agent version 8.0.11049.0, as they have been installed with the OMS agent. My question is with each UR that is released, do we patch these 8.0.11049.0 servers with the KB patch for UR13 as well? Will it reflect UR13 in the Agents by Version tab?Best Regards
Anonymous
October 05, 2017
Hi Kevin,I recently applied UR13 in my environment but the agents aren't appearing in pending management for update. I have mix of console pushed and manually installed agents but none appears in pending management. Update is applied correctly on management servers and dll files version is also updated.
Anonymous
October 25, 2017
On the MS website it now states 'To enable the web console fixes'...add to the web.config file.Does this mean we can install the rollup 13 for web console and apply the fix, rather than install the rollup 12?
Anonymous
February 06, 2018
Hello. I presume this guide is valid for UR14 as well? Except the file version numbers of course.

Partager via