DX Infrastructure Manager

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.

Thank you.

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.

Hello All,

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 

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.

Cheers,

Sam

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.

Hi!

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 ?

Hi,

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:

fault_correleation_engine
mon_config_service
relationship_services

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..

Hi 

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 CABI
Dashboards 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?

Hi Robert,

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:

• Is it possible for you from browser run manually /operatorconsole_portlet/overview and check if you are able to visualize the functionalities
• Please could you run this command from the UPM server robot Login into the UMP 9.0.2 page and in the browser, please run /usm/jsp/diag.jsp
• Regarding the CABI entry, please consider the documentation and prerequisites. https://docops.ca.com/ca-unified-infrastructure-management/9-0-2/en/configuring-and-viewing-monitoring-data/operator-console-functions#OperatorConsoleFunctions-Prerequisites Dashboards 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. For instructions on installing CABI, see CA Business Intelligence with CA UIM. Also, can you please ensure that ump_operatorconsole webapp deployed on UMP server

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,

Sam

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.

Cheers!

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:

https://comm.support.ca.com/kb/ca-uim-cabi-how-to-uninstall-reinstall-bundled-cabi/KB000097227

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.

Follow up.

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?

Thank you.

Regards,

Rajashekar

Rajashekar -

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.

Thank you!

I had a support case open for this