UIM 8.2 First Impressions.....

[Daniel Blanco]

Hello, as UIM 8.2 was released today, if anyone hits any issues or big "WOAH's" please throw it into this thread. We we looking to upgrade to v8.2 but need feedback from everyone with the bugs, or gotchas...

Thank you!!!

Dan

[Anon Anon]

-Installer will fail if you have custom probes that do not have 'description' field filled on your primary hub

-message routing seems to be somewhat broken with robot 7.70

-I had an issue where a lot of probes were inactive for a while on my primary hub, claiming unknown socket errors. had to do some stuff to get past that. I'm not crediting this to any update, could just be windows bug too.. but it's the first time this ever occurred for me

-Apparently policy based configuration is not included even if the release notes might suggest so. Only the health_index is currently included in the policy based management

-Verification of succesfull installation had some invalid probe versions

 

UMP went pretty much just fine, except for bad bad documentation and release notes.

 

Altogether I'd say this release doesn't seem worth the trouble. It really feels to me like this was forcibly rushed so it could be released within Q1.

 

I'm disappointed.

 

-jon

[Anon Anon]

Jon,

 

I am in the Technical Information group within CA.

 

Would you please provide specific information regarding your comment on the UMP documentation? If you provide us specific comments we can update the documentation.

 

I updated the release notes around lunchtime (MST) today and we are still adding late breaking items.

 

You can also leave comments on our DocOps site (CA Unified Infrastructure Management - 8.2 - CA U...). We monitor the comments and publish updates.

 

Regards,

 

Jacki

[Anon Anon]

Hi Jacki,

 

My general issue was with the release notes that lead one to believe that policy based management (other than ehealth) is included. This lead me to try to chase it down in the UMP for some time. There was also a diagram which included the templates and a set of instructions that referred to them - but as search doesn't seem to turn them up now, I guess they might have been taken down.

 

-jon

[becph01]

PBM is in controlled release state right now - I believe they wanted a smaller test group to focus on issues before releasing it for general availability. From what I understand, it's a fairly big complex thing that they do not want to rush.

 

Regards,

Philip B.

[Anon Anon]

The problem with message routing is not directly a routing problem: with 7.70, it seems actually some new ports are used and therefore it seems to be a firewall issue. This is, however, a changed behaviour from 7.63 and seems like a bug to me, since it's using wrong ports for this sort of communication.

 

It's also partly about selinux, it seems 7.70 doesn't like restrictive setting anymore in this context, whereas 7.63 had no problem with it.

 

-jon

[becph01]

I believe Jason discovered this same issue - we made a KB article about it. I believe Jason is forwarding the issue to development ASAP.

 

Here is the KB pasted below.

 

In some environments, after upgrading to hub 7.70, tunnel connections may appear unstable.  Downgrading to 7.63 appears to restore stability.

 

First, the following article should be checked -- the hub upgrade may have reset some of the settings if you have previously changed them:

 

https://na4.salesforce.com/articles/FrequentlyAskedQuestions/hub-and-tunnel-connection-settings-in-7-x?popup=true

 

Additionally, there has been a change in the way internal tunnel ports are allocated, which could have implications in highly "locked down" or secured environments.

 

In such environments, it may be that a customer has internal firewalls which block communication even between hubs and/or robots except for the normal Nimsoft port range, e.g. 48000+  so that the robots and hubs can only communicate with each other on that specific range.

 

In hub 7.63 and prior, a tunnel client/server connection would allocate internal ports to use for the tunnel connections which would fall into the 48*** range unless the "First Tunnel Port" option was explicitly set to "ignore first probe port from controller" and a specific tunnel port designated.

 

In 7.70, the behavior has changed -- now, if a specific First Tunnel Port is not explicitly set, the internal ports used for the tunnel connections will be on randomly allocated ports instead of automatically falling into the 48*** range.  

 

This change may cause tunnel connections or communication across tunnels to appear to fail, sometimes intermittently. 

 

To resolve this you should set "Ignore first probe port from controller" in the hub GUI under Tunnel->Advanced and set the first tunnel port to 48004.

Regards,

Philip B.

[Anon Anon]

Hi Philip,

 

To me the problem actually seems to be the controller, not the hub. I also tried altering that setting in the hub it didn't seem to fix this issue for me. At times this can be a hard thing to test since it really does seem to allocate them randomly within a larger range.

 

Also, I wonder if this might psoe an issue with IM connectivity to the hub? Yesterday I also noticed that my connections from my laptop to my hub were being unsuccesful. These two are in different networks and there's an actual firewall between them. Unfortunately I was too busy troubleshooting the issue in general and didn't have time to take a closer look into that issue. At least rebooting the hub server didn't solve that issue.

 

I also have a case open regarding this issue.

 

-jon

[becph01]

What's the case #

 

Sent from my Verizon Wireless 4G LTE DROID

[Anon Anon]

it's 00160141

 

I'm describing it briefly for everyone's benefit here:

A <- no tunnel -> B <- tunnel -> C

A is my primary, B is tunnel proxy and C is customer.

with 7.70, A can access B, but not C. B can access C and C can access both A and B. This is with ports 48000-48050 allowed between A anb B

with 7.63, every hub can access all the other hubs.

 

It seems to be that when accessing C from A (7.63), B takes connection from A in port 48005 (this is what it looks like, I could be wrong). With 7.70, B takes this connection from A in random port (looked like it could go as low as 35000 and as high as 55000, at random testing)

 

-jon

[Scott Stuessi]

At this rate we'll never migrate off of NMS server version 7.1

[Anon Anon]

To be more precise about the problem: the port that is in too low a port is assigned to hub, but everytime I'm running controller 7.63 it works, but 7.70 doesn't.

 

-jon

[Nicholas.Thayer]

Hello jonhcw,

 

Can you expand on the comment:

 

-Verification of succesfull installation had some invalid probe versions

 

What probes had invalid versions?

 

Thanks

[Legacy User]

Hi,

 

First Nimsoft 7.0 release was unable to work with AD authentication for SQL DB connection

First CA UIM 8.0 release was unable to work with AD authentication for SQL DB connection

 

... So I am not surprised that my upgrade to 8.2 release on our sandbox UIM configured with AD authentication failed !!

 

fortunately, moving from AD to SQL authentication and restart upgrade solved the issue (the basic of Nimsoft are still quite reliable and upgrade van be restarted as many times as needed with less impacts)...But that means that my customers will not be able to migrate quickly !!! 90% of them use AD authentication for standard security policies !

 

Some people would cry regarding this lack of lesson learned !! i am one of them !!!

 

I also tried to find how the subsysid filtering capability was reintroduced in alarm console (major defect identified as solved in 8.2)... so far i did not find the way to filter on this attribute and the documentation does not indicate that this attribute can be used as filter... Maybe in release 8.3.... Frustation

 

Guillaume

[becph01]

What version of SQL Server?

What was the last version that had SQL DB connection was working for you?

When you say SQL DB connection - you are referring to Windows Authentication within Data Engine?

Do you have a case that is open for it; can you PM me the case #?

What is the Nimsoft service running as? (Is it the same as the Windows Authentication?)

 

Philip B

[Legacy User]

Hello,

 

Standard SQL 2008 R2 latest SP

it used to work with release 8.1.

 

yes i am talking about Windows authentication in data_engine (integrated security SSPI), using the service account associated to nimbus robot watcher service on Nimsoft main server.

 

Case 00160264 has been raised by my colleague.

 

We did not make further investigation on that topic since the move from AD authentication to SQL authentication temporaly solved the issue, making the upgrade works at last . To be honnest, it is not a surprise for us as we are aware of the lack of Quality Control on UIM releases (but how to make a complete Quality Check when releasing 4 versions a year !!!)

 

Guillaume

[becph01]

So; it seems to have failed during the installation - is that correct?

 

What about post installation? If you change the following would it connect?

 

On NMS Server:   - Change Nimsoft Robot Watcher service's Log on to the Windows/domain user - Restart Nimsoft Robot Watcher service - Open data_engine probe and add "Integrated Security=SSPI" to Parameters, so it will look like following:   Network Library=dbmssocn;Language=us_english;Integrated Security=SSPI   - Restart data_engine probe - Verify from logs and Status section of the probe that data_engine is connected to database and working correctly

 

For full instructions; Take a look at this

 

https://na4.salesforce.com/articles/HowToProcedures/Switch-From-SQL-Server-Authentication-to-Windows-Integrated-Authenti…

[becph01]

That's for older UIM instructions; I haven't tested AD on 8.2; just a suggestion since this is a dev environment.

[Legacy User]

Funny discussion !!!

Yes it happened during upgrade Process... As i told you, i am near 100% sure AD athentication is not tested before release becomes GA... This is the third Time we experienced such issue... This is dféminité ly not serious.

Well i know how to move Back to AD authentication but this is not a scenario we can accept, in most cases, DBA doesn't provide SQL credentials. I do hope support will Identity issue and Provide hotfix soon.

Guillaume

[Nicholas.Thayer]

Hello Philip,

 

We test Windows Authentication (AD) mode in our lab.  Thanks for adding the SF case #.  We'll review your installer log and data_engine.cfg to see what differences might exist to give unsuccessful installation results.

 

Thanks

[Anon Anon]

The Subsystem ID is filterable from the named alarm filters in 8.2.

[Legacy User]

Hi thimothy,

 

Do you mean using alarm filters in dashboard ? Or directly in USM alarmconsole ??

 

My need is to define custom alarmconsole portlets with multiple SID based filters (uusing regex)

 

Guillaume

[Anon Anon]

In the USM alarm view there's a new ability to create and persist complex alarm filters which can include the subsys id.

 

For your use case we have also exposed the subsysid as an option on the URL for standalone or in the portlet preferences for a portlet.

 

Here's an example that could be used in the portlet preferences for USM:

{'filters':['sid=1.1']}