UR14 for SCOM 2012 R2 – Step by Step




KB Article for OpsMgr:  https://support.microsoft.com/en-us/help/4024942/update-rollup-14-for-system-center-2012-r2-operations-manager

Download catalog site:  http://www.catalog.update.microsoft.com/Search.aspx?q=4024942

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


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!


NOTE: There is an issue with the UR14 Web Console update for client connectivity.  This is the same issue that existed in UR13.  Because of this, you should only apply it if you have first mitigated the certificate issue created by the update for your clients.  This is documented in the “Known Issues” at the bottom of this page.



Key Fixes:



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
    • Audit Collection servers 
    • Gateway servers
    • Web console server role computers
    • Operations console role computers
    • Reporting
  2. Apply SQL scripts.
  3. Manually import the management packs.
  4. Update Agents
  5. Unix/Linux management packs and agent updates (if required)



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 recommend using the manual approach and not using Windows Update, for several reasons.  Windows Update applied patches will not put agents into pending updates, and is more difficult to precisely control.


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
Event ID:      1022
Product: System Center Operations Manager 2012 Server - Update 'System Center 2012 R2 Operations Manager UR14 Update Patch' installed successfully.


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, just like 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 files:



I can also spot-check the \AgentManagement folders, 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.



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.  So I spot check the files:



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.



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 MOST 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 Microsoft Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.  So prepare for the outage accordingly.

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.




Manually import the management packs



There are 60 management packs in this update!   Most of these we don’t needso 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 the OMS cloud service, (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 above without issue.



Update Agents


Agents should be placed into Pending Management by this update for any agent that was not manually installed (remotely manageable = yes):  

One the Management servers where you used Windows Update to patch them, their agents did not show up in this list.  Only agents where you manually patched their management server show 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, from an elevated command prompt.




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 *strongly* recommend you take a look at this community MP, which helps see the “REAL” agent number in the “Agent Managed” view console:




And my SCOM Management Group Management mp (updated for UR14), which will help show you REAL UR levels based on a better discovery.  This has long been a pain point in SCOM:






Update Unix/Linux MPs and Agents


The current Linux MP’s can be downloaded from:


7.5.1070.0 is the current SCOM 2012 R2 UR12-UR14 release version.  

Obviously – you skip this if you don’t use xPlat monitoring.  If you already have this version applied, then also skip it.

****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.







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:







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 UR14.


Once you apply the UR14 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.


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 webserver which 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 UR14, and these were signed with the latest MS Code Signing certificate (Expiring 8/11/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 or UR14.  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:

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 or the SilverlightClientConfiguration.exe file:

To work around this issue, follow these steps:

  1. Click Configure in the dialog box.
  2. When you are prompted to run or save the SilverlightClientConfiguration.exe file, click Save.
  3. Run the SilverlightClientConfiguration.exe file.
  4. Right-click the .exe file, click Properties, and then select the Digital Signatures tab.
  5. Select the certificate that has Digest Algorithm as SHA256, and then click Details.
  6. In the Digital Signature Details dialog box, click View Certificate.
  7. In the dialog box that appears, click Install Certificate.
  8. In the Certificate Import Wizard, change the store location to Local Machine, and then click Next.
  9. Select the Place all certificates in the following store option and then select Trusted Publishers.
  10. Click Next and then click Finish.
  11. Refresh your browser window.


This will install the correct certificate on the client cert store, to be able to use the SCOM web console


Comments (20)

  1. andyinsdca says:

    That’s it? Just TLS 1.2 support? Doesn’t seem to be a compelling reason to deploy UR14.

    1. Kevin Holman says:

      Since SCOM 2012R2 is no longer in mainstream support as of July 2017, it will only be security updates in most cases that you’d see anything released for a product in Extended support lifecycle phase. So for customers who need to run SCOM 2012R2 for a longer time, and are being mandated to disable TLS 1.0 and 1.1, this is a critical update. 🙂

      1. Jamie Bennett says:

        I’ve been trying to find information on the support lifecycle for SCOM 2012R2 but struggling to find any reference.
        Could you supply a link for the SCOM2012 R2 support lifecycle?

  2. Fedor says:

    after reading https://support.microsoft.com/en-us/help/4055768/tls-1-2-protocol-support-deployment-guide-for-system-center-2012-r2 the question arose

    there in the notes ”
    Install the latest update rollup for all System Center components before you apply Update Rollup 14.

    •For Data Protection Manager, Operations Manager and Virtual Machine Manager, install Update Rollup 13. ”

    the question arose Nedd install UR13 before UR14? now installed SCOM 2012 R2 UR12

    1. Kevin Holman says:

      That’s really odd to me. I have asked the Product Group why they recommend that and will report back here.

    2. Kevin Holman says:

      I got confirmation – this is documentation bug and not accurate. It is being fixed now. There is no requirement to apply UR13 before UR14.

  3. Piotr says:

    When I setup my SCOM 2012R2 environment to use only 1.2 TLS, would it still be compatible with SCOM agents, that supports only TLS1.0? Almost 99% of all agents are setup to use 1.0 in my SCOM environment.

  4. sanjay Agrawal says:

    Hello Kevin,

    In my SCOM 2012r2 environment UR13 undated to UR14 with the help of SCCM patched cycle , would i need to Apply the SQL Scripts manually.

    1. Kevin Holman says:

      Yes, absolutely. You would need to review ALL the steps in this article. SQL scripts and management packs.

      You should not use SCCM to update your SCOM management servers with SCOM UR’s.

      1. sanjay Agrawal says:

        Thank you so much Kevin , i will tack care for that.

  5. Bassma Zaki says:

    Hi Kevin,

    i faced the below error when trying to install the Operations console KB

    The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.

    1. Kevin Holman says:

      That means you don’t have the console installed on this machine, or you are using the wrong version, or wrong architecture patch (amd64 vs i386)

      1. Vicky says:

        Hi Kevin,

        I see the same error, tried installing both the KBs (i386, x64) on multiple 2012 R2 Standard servers but see the same error.

  6. Manju Raju says:

    Hello Kevin,

    Am just facing some issues after upgrading SCOM to UR14. Console users with Operator level of access facing long delay with State views values. State views values are taking too long time to load the requested values. But being as admin, i don’t see that delay. With Admin level access there is no issue. Users are trying to access MS via jump server. We have installed console on jump server. Request your assistance if you have faced this issue.

    1. Kevin Holman says:

      I have not seen or experienced that issue with my customers.

  7. Pat Kerley says:

    We have two issues we are facing with this update:
    1.) Some of the agent updates we ran manually required a restart. I don’t know if I’ve ever seen this requirement. Do you know why this is occurring so that we can prepare our application teams for an expected reboot ahead of time?
    2.) We have a deployment of several thousand agent updates coming up after all of our environments have been updated to UR14. How can we incorporate the UR14 agent update in the deployment? We will be using bladelogic for the rollout, but don’t want to have to install two separate packages.

    1. Kevin Holman says:

      On 1: Agent updates sometimes recommend a restart. This isnt really new, if there is something that cannot be updated, we do that at the next restart. Most customers just suppress that, and wait for the next planned restart in monthly patching, or they would include the agent update within their monthly patching.

      On 2: My first question would be – why are you updating the agents? Just because we issue a UR that applies to agents, does not mean you have to choose to deploy it. My customers were often many UR’s behind with their agents, because updating agents can be difficult, and the majority of fixes in a UR apply to the infrastructure, not always the agent healthservice. I’d ask – what version of UR level are your agents running now? What specifically is included in an update rollup, that applies to agents, are you wanting? It might be very valid, but that question should be answered before applying UR’s to agents – which is one of the most costly parts to manage for a lot of customers.

      No – directly on your question – I don’t understand the issue. why would you need two packages?

      1. Pat Kerley says:

        Thank you for answering the first question, we can certainly suppress the reboot. The second question is targeted more for new deployment of agents. My question might sound dumb, and I make no claims being an expert, but why would I deploy RTM momagent.msi if I am running UR14?

        1. Kevin Holman says:

          Ahh – so now I understand.

          We do not have a single agent installation with a “slipstreamed” patch level. You must deploy agents, and you must patch agents. Those can be done in a single customized script, otherwise they are separate deployments.

Skip to main content