KB Article for OpsMgr: https://support.microsoft.com/en-us/help/4090987/update-rollup-5-for-system-center-2016-operations-manager
Download catalog site: http://www.catalog.update.microsoft.com/Search.aspx?q=4090987
Updated UNIX/Linux Management Packs: https://www.microsoft.com/en-us/download/details.aspx?id=29696
Recommended hotfix page: https://blogs.technet.microsoft.com/kevinholman/2009/01/27/which-hotfixes-should-i-apply/
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 2016 and never applied an update rollup – you can go straight to the latest one available.
Key fixes:
- SCOM console and Service Manager console for PowerShell modules can now coexist on the same server.
Note Both SCOM Update Rollup 5 (this update) and Service Manager Update Rollup 5 (update KB 4093685) must be installed to resolve this issue. - Active Directory Integration rules are not visible or editable in an upgraded 2016 Management Group. This prevents the ongoing management of Active Directory integration assignment in the upgraded Management Group.
- When the UNIX host name on the server is in lowercase, the OS and MonitoredBy information is displayed incorrectly in the Unix/Linux Computers view.
- Active Directory integrated agents do not display correct failover server information.
- Performance views in the web console do not persist the selection of counters after web console restart or refresh.
- The PowerShell cmdlet Get-SCXAgent fails with error “This cmdlet requires PowerShell version 3.0 or greater.”
- During the upgrade from SCOM 2016 to SCOM 1801, if the reporting server is installed on a server other than the management server, the upgrade fails. Additionally, you receive the error message, "The management server to which this component reports has not been upgraded."
- If a group name has been changed through the operations console, the Get-SCOMGroup cmdlet does not retrieve the group data that includes the changed group name.
- Error HTTP 500 occurs when you access Diagram view through the web console.
- When you download a Linux management pack after you upgrade to SCOM 2016, the error "OpsMgr Management Configuration Service failed to process configuration request (Xml configuration file or management pack request)" occurs.
-
The SQLCommand Timeout property is exposed so that it can be dynamically adjusted by users to manage random and expected influx of data scenarios.
-
The MonitoringHost process crashes and returns the exception "System.OverflowException: Value was either too large or too small for an Int32."
- When company knowledge is edited by using the Japanese version of Microsoft Office through the SCOM console, the error (translated in English) "Failed to launch Microsoft Word. Please make sure Microsoft Word is installed. Here is the error message: Item with specified name does not exist" occurs.
- Accessing Silverlight dashboards displays the "Web Console Configuration Required" message because of a certificate issue.
- Microsoft.SystemCenter.ManagementPack.Recommendations causes errors to be logged on instances of Microsoft SQL Server that have case-sensitive collations.
- Deep monitoring displays error “Discovery_Not_Found” if the installation of JBoss application server is customized.
- Adds support for the Lancer driver on IBM Power 8 Servers that use AIX.
- The ComputerOptInCompatibleMonitor monitor is disabled in the Microsoft.SystemCenter.Advisor.Internal management pack. This monitor is no longer valid.
Lets get started.
From reading the KB article – the order of operations is:
- Install the update rollup package on the following server infrastructure:
- Management server or servers
- Audit Collection Server (ACS)
- Web Console server role computers
- Gateway
- Operations Console role computers
- Reporting
- Apply SQL scripts.
- Manually import the management packs.
- Apply Agent Updates
- Update Nano Agents
- Update Unix/Linux MP’s and Agents
1. Management Servers
It doesn’t matter which management server I start with. 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, and I always recommend a manual installation on management servers, I don’t recommend using Windows Update. My first 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, and 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, Web Console server, 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…. but you MIGHT see a reboot prompt. You can choose “No” and then reboot after applying all the SCOM role updates.
You can check the application log for the MsiInstaller events to show completion:
Log Name: Application
Source: MsiInstaller
Event ID: 1036
Description:
Windows Installer installed an update. Product Name: System Center Operations Manager 2016 Server. Product Version: 7.2.11719.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2016 Operations Manager Update Rollup 5 Patch. Installation success or error status: 0.You can also spot check a couple DLL files for the file version attribute.
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:
Or help/about in the console:
Additional Management Servers:
Apply the UR updates for Server, Web Console, and Console roles as needed for all additional management servers. You should only patch one management server ata time to allow for graceful failover of agents and to keep resource pools stable.
Updating ACS (Audit Collection Services)
One of my management servers is also my ACS Audit Collection Server role. I will apply the update for that:
Note the above image states “Operations Manager 2012”. This is a known issue. Ignore it.
Updated files:
Updating Gateways:
Generally I can use Windows Update or manual installation. I will proceed with manual:
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:
***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.
Updating Reporting:
On your server that hosts the SCOM Reporting role, run the update:
2. Apply the SQL Scripts
***Note – this update SQL script DID change significantly from UR4 to UR5. If you had previously applied this file in any other rollup, you MUST re-apply it now. If you are unsure if it was applied previously, you may always re-apply it. Reapplication will never hurt.
In the path on your management servers, where you installed/extracted the update, there is ONE SQL script file:
%SystemDrive%Program FilesMicrosoft System Center 2016Operations ManagerServerSQL Script for Update Rollups
(note – your path may vary slightly depending on if you have an upgraded environment or clean install)
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.
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.
3. Manually import the management packs
There are 36 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 FilesMicrosoft System Center 2016Operations ManagerServerManagement 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.
This is the initial import list:
What NOT to import:
The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service, (Previously known as Advisor, and Operations Insights) and have your on premise SCOM environment connected to the cloud service.
DON’T import ALL the languages – ONLY ENU, or any other languages you might require.
The Alert Attachment MP update is only needed if you are already using that MP for very specific other MP’s that depend on it (rare)
The IntelliTrace Profiling MP requires IIS MP’s and is only used if you want this feature in conjunction with APM.
So I remove what I don’t want or need – and I have this:
#Note: If the “Install” button is greyed out – this means you might already have one or move of these MP’s with the same version installed. In my case, I had already applied an out of band MP hotfix for “System Center Internal Library” version 7.0.8437.10, so I had to remove that to continue. Only do this if it is blocking you from continuing.
4. Update Agents
Agents should be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):
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 by design, OR if you use Windows Update to apply the update rollup for the Server role patch.
You can approve these – which will result in a success or failure message once complete:
You normally can verify the PatchLevel by going into the console and opening the view at: Monitoring > Operations Manager > Agent Details > Agents by Version
I *strongly* recommend you take a look at this community MP, which helps see the “REAL” agent number in the Administration –> Agent Managed view console:
And my SCOM Management Group Management mp (updated for UR5), which will help show you REAL UR levels based on a better discovery. This has long been a pain point in SCOM:
5. Update UNIX/Linux MPs and Agents
The UNIX/Linux MP’s and agents at the time of this article publishing have not changed since SCOM 2016UR3 was released.
You can get the current Unix/Linux MP updates here: https://www.microsoft.com/en-us/download/details.aspx?id=29696
The current version of these MP’s for SCOM 2016 UR5 is 7.6.1085.0 – and includes agents with version 1.6.2-339
Make sure you download the correct version for your SCOM deployment version:
Download, extract, and import ONLY the updated Linux/UNIX MP’s that are relevant to the OS versions that you want to monitor:
This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.
Once it has completed, you will need to restart the Healthservice (Microsoft Monitoring Agent) on each management server, in order to get them to update their agent files at Program FilesMicrosoft System Center 2016Operations ManagerServerAgentManagementUnixAgents
You should see the new files dropped with new timestamps:
Now you can deploy the Linux agent updates:
Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)
If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:
https://blogs.technet.microsoft.com/kevinholman/2016/11/11/monitoring-unixlinux-with-opsmgr-2016/
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:
1. The ACS update shows “Operations Manager 2012” in the UI but is actually for SCOM 2016.
from TechNet Blogs https://ift.tt/2jkiJ9P
No comments:
Post a Comment