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