KB Article for OpsMgr:
https://support.microsoft.com/kb/3051169 KB Article for all System Center components:
https://support.microsoft.com/en-us/kb/3051171 Download catalog site:
http://catalog.update.microsoft.com/v7/site/Search.aspx?q=3051169 Key fixes:
- The "Remove-DisabledClassInstance" Windows PowerShell command times out without completing
The cmdlet takes lots of time to complete in large SCOM installations and sometimes times out without completing its work. This is fixed by optimizing the query that is used for deletion.
- Duplicate closed alerts
The Find option in a message view sometimes gives results of the current search together with the results from previous searches. This occurs because of an update issue in the grid and is fixed so that values are displayed that correspond only to the current search.
- Topology widget objects lose location when they are opened in a console that has a different locale and decimal format
Topology widgets that are created in one locale but are viewed from another locale display an incorrect location because of the widget's inability to interpret locale-specific formatting. This issue is fixed, and users can now create and view topology widgets from different locales.
- WebConsole Details widget does not display anything
When you click a message in the Alert widget, the details of the message are not displayed in the details widget on WebConsole. This issue is fixed by fixing the XAML page of the details widget. The XAML page was preventing the data from being displayed on the page.
- Top 10 Performance widgets (WebConsole) are sometimes empty
The Top 10 Performance widgets (WebConsole) are sometimes empty because of a performance issue. This issue was fixed in Update Rollup 3 through an MPB file that requires a manual import. Because many users missed importing the MPB, a fix is included in this update rollup as an SQL query update.
- Problem with decoding SCOM trace log files
Sometimes Operations Manager trace logs do not decode but generate the error "Unknown(X ): GUID=XXX (No Format Information found)." This occurs because the latest TMF files that contain formatting information for the related traces are missing. All TMF files are updated to make sure that traces are formatted correctly.
Xplat updates:
- JEE: WebLogic 12.1.3 servers on Linux or Solaris are not discovered
WebLogic 12cR1 Rel3 Java Application Servers that are installed on Linux and Solaris are not discovered.
Note The UNIX or Linux agent must be updated after you install the Management Pack update to resolve this issue.
Relevant log messages:
/var/opt/microsoft/scx/scx.log
2015-02-04T15:28:18,797Z
Trace [scx.core.common.pal.system.appserver.appserverenumeration:379:15739:139715041470400] Weblogic process does not contain the 'platform.home' or 'weblogic.system.BootIdentityFile' commandline argument.
2015-02-04T15:28:18,797Z
Trace [scx.core.common.pal.system.appserver.appserverenumeration:462:15739:139715041470400] Merging previously known instances with current running processes
- In rare cases, lots of omiagent processes may be observed on a UNIX or Linux computer
If a single instance of data that is returned by an OMI provider is larger than 64 kilobytes (KB), the omiagent process becomes unresponsive, and additional omiagent processes are created. This issue can occur on a managed UNIX- or Linux-based computer if a rule or monitor returns an instance of data larger than 64 KB. This is most likely to be seen when a custom shell command or script rules return lots of data in StdOut.
Note After you upgrade the Operations Manager UNIX/Linux agent to the version that is contained in this Management Pack update, an instance that exceeds 64 KB will be truncated and will generate the following message in the scx.log file. You can use the log message to identify and change the workflow that is returning too much data.
ExecuteCommand: Exceeded maximum output size for provider (64k), output truncated. Monitoring will not be reliable! Command executed: "
- The SSLv3 protocol cannot be disabled in OpenSSL as used by the UNIX and Linux agents
With this update, you can now disable the SSLv3 protocol for the Operations Manager UNIX and Linux agents. You can do this by adding a property to omiserver.conf (/etc/opt/microsoft/scx/conf). If SSLv3 is disabled, the UNIX and Linux agent will reject connections that cannot be negotiated by using TLS encryption. If SSLv3 is enabled (this is the default configuration), SSLv3 will be used only if TLS encryption cannot be negotiated.
omiserver.conf options for configuration SSLv3
NoSSLv3=true|false
Enable/Disables use of SSLv3
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
- Gateway servers
- Web console server role computers
- Operations console role computers
- Apply SQL scripts.
- Manually import the management packs.
- 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 
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:
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 (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:
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: 5/11/2015 12:39:05 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 UR6 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:
Secondary Management Servers: 
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:
This shows me three applicable updates for this server:
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: 
I can use Windows Update or manual installation.
The update launches a UI and quickly finishes. 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:
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)
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.
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:
or
IF YOU GET AN ERROR – STOP! Do not continue. Try re-running the script several times until it completes without errors. In a large environment, you might have to run this several times, or even potentially shut down the services 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, or UR5, you should run this again for UR6, as the script body can change with updated UR’s.
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.
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:
3. Manually import the management packs? 
There are 25 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, 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:
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 System Center Operational Insights (Previously known as Advisor) services. 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 (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.
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:
Soon you should start to see PatchList getting filled in from the
Agents By Version view under
Operations Manager monitoring folder in the console:
5. Update Unix/Linux MPs and Agents 
Next up – I download and extract the updated Linux MP’s for SCOM 2012
http://www.microsoft.com/en-us/download/details.aspx?id=29696
7.5.1043.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:
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 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. 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:
I had to restart the Healthservice on the management server, and within a few minutes all the new files were there. 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.
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.
--------------------------------------------------------
Kevin Holman
