SCOM 2016 UR6 released

As stated in my previous post System Center 2016 products (SCOM, DPM, VMM, Orch) came with SCOM Update Rollup 6.
For SCOM this means a number of things got fixed, See the excerpt from the KB article below:

Improvements and issues that are fixed

  • Application pool crashes and SharePoint application crashes because of APM agent and the profiler are now fixed. These occurred because the profiler was always on. This issue is fixed by disabling the profiler by default and enabling it only when APM is configured.Note If you’re using APM, restart IIS after you deploy the patches.
  • Improved logging to display error messages and suggest that you check performance counters when PdhExpandWildCardPath fails.
  • Fixed: Session Events tab in Application Diagnostics web console doesn’t display any data.
  • Fixed: Scheduled Maintenance Mode doesn’t work in an availability group that uses SQL Always-On configuration. In case of a failover to a secondary node, the Maintenance Mode Schedules that are created on the primary node don’t run. This has now been fixed. For details, see the “Enabling Schedule Maintenance Mode with SQL Always ON” section.
  • Updated fix: The Get-SCOMGroup cmdlet is slow to query large (more than 2,000) groups. A previous fix has been improved for faster querying of any number of groups.
  • Fixed: Users could not edit the Maintenance Schedule in the SCOM console if all the objects were removed. The schedule can now be edited. However, it cannot be saved unless it contains at least one object.
  • Fixed: SCX cannot connect with Linux machine if the KEX algorithms are configured as any of the following: ecdh-sha2-nistp256diffie-hellman-group-exchange-sha256, or diffie-hellman-group14-sha256.
  • Fixed: Using MI APIs causes MonitoringHost.exe to crash. This event is logged in the Application log, but no crash events are reported in the Operations Manager event log. After this fix, MonitoringHost doesn’t crash even if the useMIAPI registry key is enabled.
  • OMS (now Azure Log Analytics) connection onboarding wizard is updated to communicate with the new APIs. This is because the OMS services were moved to the Azure Portal (link), and also because of the planned retirement of the OMS portal. This change will not affect any existing connection to OMS. However, for new connections or to reconfigure existing connections, the relevant management packs that are bundled together with this update rollup must be imported.
  • From this release onwards, customers have the option to install only scxagent. After scxagent is installed, there will be new “nologin” user and “omi” group.
  • XPlat support matrix changes:
    • SLES 10 is not supported.
    • CentOS 5 is not supported.
    • AIX 6.x is not supported.

Some remarks about all this from my side:
A) The APM issue is said to have been fixed now. Of course in the first place by not loading the profiler by default, which is a management pack entry problem (because it also caused SCOM 2012 R2 agents to enable the profiler when you upgraded from that version to 2016 SCOM backend). I am happy this should get rid of the last group of issues. If it doesn’t please contact me, because it might earn me a dessert.
B) Scheduled maintenance mode when running your SCOM SQL backend on ALways-On sometimes did not work. This was because when creating the maintenance schedule it was saved to the SQL Agent running on the currently active machine. When a failover on SQL happened the schedule would not run correctly. This has been addressed in SCOM 2016 UR6 now. Please refer to the KB article for the exact steps to perform!
C) In 2016 a Linux/Unix monitoring feature was released whereby you could switch the communication API between the SCOM management server and the cross-plat agent to use the MI API through a registry key. This would enable a management server to be able to run twice as many agents in its monitoring workflows. However some bug caused the monitoringhost.exe on the management servers to crash in some cases which would kind of result in the reverse. Anyway, this has been fixed now.
D) Because the classic OMS portal is being retired and the Log Analytics connection to the Azure Portal is being used instead, this also meant a change in the communication method to move the data across new API’s. The updated management packs in this UR6 will take care of the change.
The update rollup installation is the same story as with the previous Update Rollups, except for some additional steps mentioned in the KB article. Please make sure to rread the article:
Lots of monitoring fun!
Bob Cornelissen