Reviews OBM 2020.05 and SCOM Connector 2020.05
Upgraded a few non-productive environments to OBM 05.2020. Found already defects in new HTML5 UI.
when customer starts working with OBM 2020.05 in production environment i expect to keep MF Support busy for a while.
Also new HTML5 UI lacks some usability. functions are missing or are moved to places that needs several clicks to get.
really annoying is that search field in HTML5 browser needs several clicks.
So i am personally not happy with it. hoped that replacing flash the developers come up with something with more usability and reacted on the customer feedback they collected of our customers last year.
but i remebered that customer satisfaction is no buisnes case but share holder value is to respect. so we have to learn to life with it.
Already started to edit opcle polices with raw editor as its faster and avoid some yet unfixed defects.
Please note that the search field in the HTML Event Browser provided with OBM 2020.05 can also be quickly accessed via the keyboard shortcut Ctrl+F (which also works for the Flash version), then no mouse click is needed at all.
In general we tried to take up the feedback we got from customers and make it much clearer which filters are actually applied to the Event Browser. Therefore the toolbar in the browser just shows those elements for which a filter was actually selected.
Still all elements appear automatically if a filter is e.g. passed from a Monitoring Dashboard or a View Explorer component and the browser also remembers the filters which were applied on the next launch.
I installed OBM 2020.05 classic (Windows 2019/Combined Single Server w/ Embedded PostgreSQL) on a Test VM and am not having good results.
I am having issues with 2020.05 classic in that the wde process JVM Heap Utilization leaks memory until it hits 100% and then the agent on the server buffers until I restart OBM and then it starts all over again where wde eventually gets to 100% HeapUtil which in turn causes the agent to time out reaching the server and the agent starts buffering. Right after a new installation and Config Wizard, it is fine and wde does not grow until it hits 100%, however, after I made some tweaks to the Infrastructure Settings and then set the Downtime Behavior, now wde JVM HealUtil is growing until 100% causing the agent to buffer due to timeouts.
Has anyone else experienced this behavior in OBM 2020.05 classic?
Already some of my customers upgraded most test and one production Environment to OBM 2020.05 and no such issue is there.
but all run on linux. so with windows your milage may differ.
did you install the available hotfixes? some of them are available on ITOM Marketplace.
I just completed the update of OpsCx SCOM from 2018.05 to 2020.05. It went well. Everything seems to be working. The process was very long, time consuming, and some steps that needed more detail but it did work.
1. No mention on what to do with the connected server entry already in place in OBM. Should it be removed? Also no instruction to add a connected server entry for the 2020.05 OpsCx SCOM just installed.
2. If doing an update, is this step required during uninstall: Remove the Microsoft SCOM Built-In Diagnostics Loader Stub.
3. If doing an update, is this step required during uninstall: Remove the Microsoft System Center Operations Manager SDK assembly files.
4. I did not see instructions to create and assign an event policy for each SCOM server OpsCx is collecting events from. The OpsCx config file lists the URI it is trying to post events to and I created and assigned a policy with that source. (config file scom_2016_event_2_integration.conf)
a. Log file indicated there was an issue, scom2016e2.2020-09-30.log.
b. Errors logged: ERROR genint::ws_plugin::concurrent_sink_node - Failed to send messages! HTTP error code returned: 404 - Not Found
As i understand with the new version of BSMC the procedure to deploy polices changed.
With each Integration package comes an installable zip file that will install the necessary policies, views and dashboard in OBM. Instead of deploying the policies direktly of the BSMC on itself it is now necessary to deploy policys from OBM server to BSMC. of corse remove the old ones before deploying.
This is , i think, part of the flash free initiative. So there is no longer an UI needed on BSMC and so is the flash . 😉
After upgrade, the app runs and remote actions are possible, but we are still unable to get any incoming event from agents. There seems to of been some database changes (remote Oracle 12.1 setup) from the upgrade (from 10.63 IP4) that cause field mismatches in the ROOT_1 table. There has been a case opened for over a week now, but still so hotfix has been forthcoming to resolve the database issue.
Yes I installed all the 2020.05 HotFixes and the symptoms still exist where the agent on the OBM server buffers after the wde process HeapUtil grows to 100%. Restart of OBM gets the agent healthy again but within hours the wde process HeapUtil grows to 100% causing the agent to buffer.
I did some troubleshooting where I uninstalled OBM, then did a new install and then waited for several hours to verify the wde HeapUtil looked "normal" and did not grow to 100% before proceeding. Indeed, the wde process acted normal and did not grow to 100% after waiting over night.
I then made Infrastructure Setting customization's one at time and waited between changes to try to find the exact setting which is triggering this issue. I found the following setting has triggered the issue - My recommendation is to make sure your current/old OMi/OBM version has this setting as default before upgrading to 2020.05:
Platform Administration - Audit Log \ Clear Audit Log
I changed the this value to 350 (Default=90) (Requires restart of OBM). I restarted OBM and after I cycled OBM the wde process HeapUtil started growing until it reached 100% and then the agent on the server started buffering.
I do have a ticket open with support but this ticket has been open for a very long time (over a month) and they are kind of slow to respond but have contacted the developers. I have submitted many log grabbers and log files and outputs and traces and perf graphs, etc. but they have yet to find the issue or resolve it.
Yes, the ultimate fix for the WDE Java HeapUtil growing to 100% issue is found at the following link:
It was an Infrastructure Setting but not the one I thought it was initially (they said that was coincidental)
It turns out this is caused by a setting that instructs OBM to send license data, but receiver of such data is not yet implemented and thus produces errors.
To avoid the issue, just clear the “Server Name" setting in the LICENSE REPORTING SETTINGS section of the infrastructure settings.
The change takes effect immediately, but you might want to restart the OBM processes to free up all the memory wde already consumed.