So I figured I'd start a new UIM 9.x Defects/Bugs/Gotchas thread as the other one has 11 pages so far.
Just so we can all track known bugs and defects since the Announcements page is not used on the old support site still.
If you find any 9.x related bugs, defects, gotchas, tips please share in this thread so we can all be in the know.
If you have questions then please start a new thread and just this thread for sharing discovered bugs/issues with 9.x.
11 pages ...looks strange to hear this.
When deploying the latest processes probe, the new VC 2017 libraries are pushed.
When that occurred the following happened:
The process C:\Program Files (x86)\Nimsoft\vs2017_vcredist_x64\vs2017_vcredist_x64.exe (XXXXXXXDB01) has initiated the restart of computer XXXXXXXXDB01 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Application: Installation (Planned) Reason Code: 0x80040002 Shutdown Type: restart
So, with the newly installed processes probe you get an immediate test of the "check for down processes" monitors. Oh, and if you have SLAs to deal with, you also get conference calls and upset customers.
Ugh - this is just too silly
So beware - you might get bit.
Wow so this is the same situation that happened when they started using, upgraded to the 2010 Visual Studio 2010 SP1 Re-Distributables. I updated a processes probe and later on got a call asking why the primary Exchange server rebooted. It was b/c the vs2010_redisk_x64 package. It will cause your OS to initiate a reboot.
UIM just doesn't learn. They need to add the /norestart option to the Miscellaneous tab arguments to this package or your going to get un-expected reboots.
This is the 2010 SP1 packaged v1.01 fixed:
This is the current vs2017_vcredist_x64 GA 1.0 package: MISSING THE /NORESTART
CA UIM dev folks you better UPDATE ASAP....
Thanks for this info Daniel! I came here to post this workaround but you're way ahead of me I see!
I've filed a defect at high priority for the development team to address this ASAP.
A KB article is created to remediate this problem - Windows OS reboot after probe deployment - CA Knowledge
i hope this issue came earlier with cdm probe , not sure why the same issue came with other probes now ,seems to be there is some lack.
Upgrading cdm probe to version 5.70 or later may c - CA Knowledge
There are new VS2017 packages for both x86 and x64. version 1.01 which addresses this.
Please remove the original packages from the archive, download and import the new ones to avoid this issue.
Terrifying - but at least the solution is readily available and there's no need for a level 5 log of the failure....
Seems to be some defect in ems 10.20. When there is HA probe running on HA hub, the ems is not able to start at all on primary server. Shutting down HA probe and ems runs nice.
Wow! It's worked!
How strange! Thank you so much for this tip.
Looks like new HA (v1.46) probe has been released now, and that should work with current ems version also.
I upgraded to HA 1.46 but the EMS probe still doesn't play if the HA probe is active. Works fine if HA is deactivated though, just need to enable after EMS.
I still have an issue with EMS not starting - Max Restarts reached error.
This happens immediately if I have the HA probe (v1.46) deactivated, and the EMS probe fails to find an address and constantly restarts with a different PID until it errors with a Max restarts reached error.
Any ideas anyone?
Have you put ems probe in under HA probe configuration ?
No, I just connected it up to the right system, I'll try adding it in.
As a test, I've removed all HA probes from the envionment and the EMS probe still fails to load..
Also tried the following but it didn't work
deactivate the ems probe rename the ems\db folder redeploy the ems probe activate the ems probe
Please open a support case.
Kind of Gotcha, works as designed, but good to know.
When using Operator Console for setting alarming rules, please note that those rules are totally separated from those settings that you create with MCS. When using MCS, you actually configure each probe's config file as you have always done (well, except when using admin console and bulk mode) but when using Operator Console you actually start using the new concept for threshold settings, these setting go to spooler.cfg and spooler probe is then actually the one who launches the alarm, original probe (like cdm) is that getting the QOS data from the system. So you probably end getting alarms from both systems.
So keep in mind that. I think that is not too well explained in documentation. This was the thing I was asking in wrong place here earlier.
And yes, I really like that new interface for alarming rules. And miss the monitoring setup part (the one that we still have to use USM+MCS) that was in SaaS version's HTML5 interface.
And one additional nice thing is that when you set up monitoring rules in Operator Console, then those settings are also captured in audit log, at least that someone has changed thresholds.
Operator Console? Where do I find that? There's nothing new appearing in my Actions drop down.
But I do have 3 probes failing to start..could be to do with that maybe:
Operator Console is from the Actions drop down menu, if you have ACL Operator Console Basic enabled for your user.
Ah interesting! I do have those permissions but nothing is appearing. Perhaps it's due to the probes that are currently refusing to load due to "Max restarts"
I've managed to get these probes running (they hadn't upgraded during install) - but still missing this new Operator Console..
Do you have the ump_operatorconsole webapp deployed on ump server
Please also check if CABI is installed as operator console has dependency for dashboards in CABIDashboards in Operator Console (including the Home (Home View Icon) view) require installation of CA Business Intelligence (CABI) JasperReports Server to view graphical presentation of data on groups and alarms
Gotcha, thanks Franklin.
I deployed ump_operatorconsole but didn't realise CABI was a pre-req.
I'll get it installed
Has anyone else gotten a fix for this. We have CABI installed and we installed the Operators_Console on the UMP and when we log into the UMP and choose the Actions Dropdown in the USM there is no choice for Operators_Console. Also when looking through the ACLs I do not even see an option to pick Operator Console Basic enabled. Any ideas?
I had the same problem and raised a ticket with support. Unfortunately we got so far through troubleshooting it and then I got carried away with my day to day business duties so the case was closed due to lack of response, but, whatever we did through the troubleshooting fixed the issue!
I've just looked up the closed tickets and here are some tips:
The above notes are from the ticket I raised, it may help you. Something we did made the operator console button appear, but I'm not sure what.
Hope it helps,
So I was able to get the Operators Console ACL to show up by performing an update to the ACL list in the IM (suggested by support). However when I open the operators console this is what I see, and if I try to open any of the dashboards this is what I see.
If I click any of the dashboards I see that as well. However if I go into CABi itself and click on a dashboard the dashboard loads in CABi. So Little bit of progress but now no dashboards are views in the Operators console.
Ah ok, nice tip!
You've got further than I have.
I've been asked to uninstall Cabi and try a reinstall. Keep me posted on how you get on. Always good to learn from others!
I'll do the same.
So I just went thru a cabi worst case scenario last week in my lab but basically upgraded from 8.51 cabi 3.20 to the latest 9.02 UMP then tried applying the UMP HF2 zip #2 contains the newest cabi 3.40 version. It did not work. No matter what I did the bundled cabi robot I had running both the cabi & wasp probe were broken after trying to apply the HF2. In the end I followed this page and blew away both the CABI probe and the wasp probe on the dedicated robot that is for running CABI.
So the clean up and re-install KB page here was very helpful:
You can follow this page for 9.02 cabi clean up as well.
I hit issues also trying to re-install on my cleaned up robot. I had to try 3x before it worked correctly. Each time the robot was in the same clean state but on the 3rd time it finally deployed nicely. The 1st two tries the wasp probe would not start and if that happens cabi won't install.
So finally running cabi 3.40 which is part of the HF2 zip file...
Not specifically a 9.0 defect but one of the pushes in 9.0 is to move to the latest VS 2017 runtimes.
One of the nifty features of that is that the vs2017_vcredist_x64/32 package failed to include the /norestart option so if you deployed this package, you were at significant risk of it rebooting the system being deployed to.
CA then releases version 1.01 which fixes that defect.
Problem is this:
Handily, the cdm package forces the selection of the version 1.00 package.
So if you just downloaded the fixed package and then imported it assuming that the latest version would be used, you would be sorely mistaken. And you'd still be rebooting servers randomly as you deployed CDM.
And if you deleted the old version, like you should have, then the CDM package is broken. The equality requirement can't be satisfied.
The fix is obvious, just change the dependance to ge instead of eq but this should never have gotten out the door in the first place.
Ugh. CA, you need to do better than this.
We do apologize for this. Yes definitely we agree that we should have done better.
We are aware of this issue and today we detected 2 probes still refers to 1.00 (with eq)
Robot 7.96 (come only with 9.0.2 install)
We plan to replace those archives not let happen unwanted OS reboot.
So Here is quick action list
(*) Mandatory for all UIM 9.0.2 users and UIM 8.X users those who imported these packages already.
vs2017_vcredist_x86 version 1.00
vs2017_vcredist_x64 version 1.00
(*) Mandatory for all UIM users.
vs2017_vcredist_x86 version 1.01
vs2017_vcredist_x64 version 1.01
[win64] - [Dependencies]. Double click vs2017_vcredist_x64. Change [dependency type] from [eq] to [ge]. Press OK
[win32] - [Dependencies]. Double click vs2017_vcredist_x86. Change [dependency type] from [eq] to [ge]. Press OK
(*) Mandatory for all UIM 9.0.2 users only.
[win64] - [Dependencies]. Double click vs2017_vcredist_x86. Change [dependency type] from [eq] to [ge]. Press OK
Recently we issued
- cdm 6.34
- robot 7.97
VS2017 dependency of those have been modified with "ge", so it works with 1.01 version of VS2017
Any probe that is getting deployed to robots through MCS profiles, which probe does MCS use to deploy? The latest one in the list or the old one which is set to default?
The version of the probe deployed depends on the MCS template you are creating and which ones are active in the SSRV2Template table. The following query will identify the probe versions that the corresponding MCS templates will deploy to the robots in a monitoring group:
select templateName, probe, probeversion from SSRV2Template where production = 1;
For NULL probe versions, the latest version of the probe in the archive will be deployed. If you have a newer version of a probe in the archive, and the active template is associated with an older version of the same probe, MCS will deploy the older version of the probe if the probe has not yet been deployed to the robots in a monitoring group. Please also note that, by design, if you have an older or newer version of a probe deployed to a robot in a monitoring group, MCS will not update the version of the probe to match the version associated with the template created for the group.
I had a support case open for this