KB Article: http://support.microsoft.com/kb/2904678/en-us
Download catalog site: http://catalog.update.microsoft.com/v7/site/Search.aspx?q=2904678
Issue 1 – An error occurs when you run the p_DataPurging stored procedure. This error occurs when the query processor runs out of internal resources and cannot produce a query plan.
Issue 2 – Data warehouse BULK INSERT commands use an unchangeable, default 30-second time-out value that may cause query time-outs.
Issue 3 – Many 26319 errors are generated when you use the Operator role. This issue causes performance problems.
Issue 4 – The diagram component does not publish location information in the component state.
Issue 5 – Renaming a group works correctly on the console. However, the old name of the group appears when you try to override a monitor or scope a view based on group.
Issue 6 – SCOM synchronization is not supported in the localized versions of Team Foundation Server.
Issue 7 – An SDK process deadlock causes the Exchange correlation engine to fail.
Issue 8 – The "Microsoft System Center Advisor monitoring server" reserved group is visible in a computer or group search.
Issue 9 – Multiple Advisor Connector are discovered for the same physical computer when the computer hosts a cluster.
Issue 10 – A Dashboard exception occurs if the criteria that are used for a query include an invalid character or keyword.
Issue 1 – On a Solaris-based computer, an error message that resembles the following is logged in the Operations Manager log. This issue occurs if a Solaris-based computer that has many monitored resources runs out of file descriptors and does not monitor the resources. Monitored resources may include file systems, physical disks, and network adapters.
Note The Operations Manager log is located at /var/opt/microsoft/scx/log/scx.log. errno = 24 (Too many open files) This issue occurs because the default user limit on Solaris is too low to allocate a sufficient number of file descriptors. After the rollup update is installed, the updated agent overrides the default user limit by using a user limit for the agent process of 1,024.
Issue 2 – If Linux Container (cgroup) entries in the /etc/mtab path on a monitored Linux-based computer begin with the "cgroup" string, a warning that resembles the following is logged in the agent log. Note When this issue occurs, some physical disks may not be discovered as expected. Warning [scx.core.common.pal.system.disk.diskdepend:418:29352:139684846989056] Did not find key 'cgroup' in proc_disk_stats map, device name was 'cgroup'.
Issue 3 – Physical disk configurations that cannot be monitored, or failures in physical disk monitoring, cause failures in system monitoring on UNIX and Linux computers. When this issue occurs, logical disk instances are not discovered by Operations Manager for a monitored UNIX-based or Linux-based computer.
Issue 4 – A monitored Solaris zone that is configured to use dynamic CPU allocation with dynamic resource pools may log errors in the agent logs as CPUs are removed from the zone and do not identify the CPUs currently in the system. In rare cases, the agent on a Solaris zone with dynamic CPU allocation may hang during routine monitoring. Note This issue applies to any monitored Solaris zones that are configured to use dynamic resource pools and a "dedicated-cpu" configuration that involves a range of CPUs.
Issue 5 – An error that resembles the following is generated on Solaris 9-based computers when the /opt/microsoft/scx/bin/tools/setup.sh script does not set the library pathcorrectly. When this issue occurs, the omicli tool cannot run. ld.so.1: omicli: fatal: libssl.so.0.9.7: open failed: No such file or directory
Issue 6 – If the agent does not retrieve process arguments from the getargs subroutine on an AIX-based computer, the monitored daemons may be reported incorrectly as offline. An error message that resembles the following is logged in the agent log: Calling getargs() returned an error
Issue 7 – The agent on AIX-based computers considers all file cache to be available memory and does not treat minperm cache as used memory. After this update rollup is installed, available memory on AIX-based computer is calculated as: free memory + (cache – minperm).
Issue 8 – The Universal Linux agent is not installed on Linux computers that have OpenSSL versions greater than 1.0.0 if the library file libssl.so.1.0.0 does not exist. An error message that resembles the following is logged: /opt/microsoft/scx/bin/tools/.scxsslconfig: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
I have seen *several* customers having issues with the OpsDB grooming/purging process, so that looks like a good one to get implemented, especially if this was affecting you.
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 (see installation information).
- Manually import the management packs.
There are no agent updates in this UR1. Agents will be placed into pending, however there are no updates. You must reject the agents in pending.
Now, we need to add another step – if we are using Xplat monitoring – need to update the Linux/Unix MP’s and agents.
4. 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.
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 Windows Update. I check online, and make sure that I have configured Windows Update to give me updates for additional products:
This shows me two 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.
I can use Windows Update or manual installation.
The update launches a UI and quickly finishes.
Then I will spot check the DLL’s:
2. Apply the SQL Script
In the path on your management servers, where you installed/extracted the update, there is a SQL script file:
%SystemDrive%\Program Files\System Center 2012\Operations Manager\Server\SQL Script for Update Rollups
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.
****Note – at the time of this writing – the KB article says to run this against the DataWarehouse – the KB article is in error
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?
We have four updated MP’s to import (MAYBE!).
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 Advisor services.
However, the Image and Visualization libraries deal with Dashboard updates, and these need to be updated.
I import all of these without issue.
Reject the agent update
Agents are placed into pending actions by this update. HOWEVER – there are no updates for the agents in the Update Rollup. You must REJECT the agents in pending, using the console or PowerShell.
4. Update Unix/Linux MPs and Agents
Next up – I download and extract the updated Linux MP’s for SCOM 2012 SP1 UR2
7.5.101 is current at this time for SCOM 2012 R2.
****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.
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.
I have an environmental issue that caused my Ubuntu server to fail.
5. Update the remaining deployed consoles
This is an important step. I have consoles deployed around my infrastructure – on my Orchestrator 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 UR1 update.
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.
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 the services on the management servers, 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.