Idea Details

Radical idea for Releases  - Make sure they are stable and stop releasing so many!

Last activity 06-13-2019 10:13 AM
Anon Anon's profile image
04-02-2015 10:52 AM

I spend a lot of time updating robots/ probes/ hubs because when i log a case i get told that another release has been made.?I recently upgraded to version 7.0 on hubs, umps and all robots got an update too. After a few weeks i am told that another update (7.1) has been released and this is supposed to fix some other issues?I was having with FQDNs in the UMP.


I have found that the support team do not always know the details of new features across the product as there seems to be little handover from the development team.


If releases were more stable then there would be less releases made generally available, the last solid release would?have more time with the?support team before being rolled out so they would know more about how they work and customers would spend less time updating software all the time.


11-29-2018 05:34 PM

Or the double plus secret "level 6". 


CA should be in the business of selling storage, along with monitoring it.

11-29-2018 05:12 PM

You mean log level 5... ha ha...

11-29-2018 02:00 PM

Not to resurrect an old idea but "Delivered" is funnier yet.

07-25-2017 02:08 AM



let me say what i think as a developer : 


"Nimsoft" is a very good product at start (the original design is still seriously one of the most efficient today). 

And the work around latest versions are pretty cool (Less bugs, Better stability etc...).


On others side as a developer i have to survive and make everything by my self. We have to be honnest, how developer could make something right with this code base ?



- No official documentation on how to build.

- PDF API... (YES and i write my code on Notepad with green and yellow color)


Not acceptable at all... We need a real step to step documentation for this with a manifest, makefile etc...



- No official documentation on how to build. (Splitted ressources every where). 

- Some parts of the SDK are broken (like logger).

- Poor API object design.

- The documentation UI/UX has been created by a 10 years old kid or ? Sorry but my eyes are bleeding.

- Lack of examples on the API too.


No comments.


Perl SDK 

- Perl5 is broken.

- The SDK API is broken.


It's a Foreign function interface of the C SDK. So why the SDK is not open-source ? (A little bit to late now i think...). He should be at least updated on a safe production version of perl (5.16 etc...).


etc... etc...


Take example on the NAS API and lua. Perfect, 10/10!


I'm working full time on all of this until end of 2017 (in mind my Node.JS SDK Alpha for Junuary 2018). And i dont forget PerlUIM5 first beta stage (end of november).


A rework of NodeUIM (Pu interface) is in preparation too (with nimAlarm.exe and nimQoS.exe support).


Best Regards,


06-08-2017 04:17 PM

Well, I have same problem with you. Even worst, sometimes they insist me to upgrade otherwise, they will not process to troubleshoot the issue. 


Sometimes, it is easy for CA Support to propose the upgrade. But CA Support did not understand the pain and time that we need to go through by upgrading the probe such as:

1. Customer do not allow internet connection. Hence, I need to download the software from my office and then burn the DVD. Best part, I cannot claim the DVD to CA Support.   --> it took one day to perform this step

2. I need to pass the DVD to Customer, customer need to scan the DVD --> it took one day to perform this steps

3. We need to upgrade on development env first --> another one day wasted 

4. Then finally, we can upgrade the probe on production env --> another one day wasted.

Total 4 days for me to upgrade the probe.... And best part, it does not resolve the issue, CA Support again ask the log files from latest probe when we noticed no different the log files from old probe and new probe.

06-08-2017 03:28 PM

+1 2 year later and still getting the same response from support, "oh, I see that you a behind on your version, you should upgrade as the new release has many fixes." My response, "Please show me in the release notes where my issue has been addressed.".

10-28-2016 11:57 PM

Support this idea ....

03-28-2016 03:18 PM

I think the main thing here is choice. If you prefer to stay a release or 2 behind, then fine. If not at least you have the option to upgrade. Whilst I do believe some basics should be tested a bit better first, not all people think like you/me - at least give the customer the choice. Personally I prefer that there are more releases in a year. This lets us have more up to date software with more security and bug fixes. If you don't like updating 4 x a year then just don't do it.

01-27-2016 02:05 PM

Maybe we all just missed their intent - now the CDM GUI works just like the Logmon GUI. The Logmon GUI has behaved this way for years....

01-27-2016 01:59 PM

I see the CDM probe version 5.61 now prompts every time when closing the probe with the Warning message "Do you want to restart the probe to reflect the changes?", whether changes were made or not.  This Warning message should only pop up when changes were made.  That is how it worked in previous versions.

12-22-2015 09:27 AM

Very good! Thanks

10-16-2015 06:49 PM

Thank you for your input and comments on this Idea.  The product management team has taken this input to heart.  We have made changes in our release process, and those changes are now in place.  Notably, we made the decision to extended a release this year solely to make sure it met our quality standards.  We used this extension to harden the product, and reduce the number of open defects. 


Additionally, we now perform regular training sessions on each release for the support team.  These training sessions are recorded so they can refer to them as necessary at a later date. 


We can’t claim perfection, but we do recognize that status quo is not necessarily the best option.  Everyone on the UIM team is committed to creating great software with improved simplicity, elegance, and ease.  We will make whatever improvements are necessary to reach that goal.


The UIM Product Management Team

07-03-2015 05:35 AM

Speaking of QA, it seems the QA team have been earning their pay again (or not):


"Factory Templates" are the new 'in' thing - For all other probes i've seen that now include these templates they are always placed in the path as the probe files.

Now the probes files for ntservices are stored in 'probes/system/ntservices' so logically, the template files should be there too (just like the other probes):

What the ...

07-02-2015 06:33 PM

Hi Opnet as an MSP we have experience of implementing and supporting management products from many vendors and IMHO in Spectrum you have the best by far, nothing else provides the same intelligence, scalability, ease of use or customisation opportunities.  It's just a shame that there aren't decent application/server agents available to use natively, this should have been addressed years back.

Reading this thread has further increased my dread of Spectrum going EOL at some point. My reservations have been around losing the USPs of Spectrum but now the possibility of having to deliver managed services on a flaky platform, as UIM is being painted here, adds to my concern.

Re IMC it's an interesting product if you have an HP network and, with a wide range of optional modules, does some really cool stuff in a number of areas that Spectrum, CAPC, PM, NFA, UIM don't cover but in the areas of functionality covered by the CA products you would soon miss the depth and  functionality of the CA products big time.

07-02-2015 03:36 PM

On the plus side of that comment, you can be fairly sure that it reflects the truth. Grin....



07-02-2015 03:30 PM

Backline support has requested that you update to the latest version of the probe that was just released, we have no idea if this was fixed in this version so let us know how it goes.

06-17-2015 02:23 AM

...and send us unrelated .cfg files. In 1-2 weeks when you tell us the case you have logged for "Intermittent Tunnel issue for ALL hubs" has now changed to "Intermittent Tunnel issue for ALL hubs, EXCEPT one which seems to be working" then we will press you to close the case and open a new one as your issue is now a different one.

06-16-2015 10:24 PM

Please raise your log levels to a 4 and increase your size and we will get backline support to update us shortly

06-16-2015 04:55 PM

I feel from the support side we could definitely benefit from a more consolidated "permanent" version of UIM. This is one of the reasons we need to constantly verify probe versions and logs (and probably still will). Nonetheless, the "one version" to rule them all might might be great advancement in building a more perpetual solution with solid features.





06-01-2015 10:22 AM

So this would have greatly effected me as well so I complained


Created By: Support  (5/29/2015 2:07 PM)

Hi Brandon - got some great news straight from the heads of development.


Basically the cfx file will be modified back to the original pre-5.30 state for alarm severity levels for DiskWarning so no impact for new deployments of CDM and no change in behavior from what has been there for the previous years. For those who have already upgraded to 5.30, 5.31, or 5.40 and have had a new severity put in place we will provide a config probe to overwrite that change to reset the behavior, if desired. Also, it will be documented in the release notes so it is clear what is happening.


We expect this to be in the next CDM probe release - we're following up with HCL for when we can expect this release date.

05-15-2015 04:40 AM

during the last 1.5 years of UIM 6.5, 7.0, 7.5 and now 8.2 I've created 132 issues. Wouldn't call that "no problems".

05-14-2015 02:45 PM

Following this thread is reminding me a lot of what played out in a relatively recent CAPC/CAPM thread:


Re: Top reasons you have thought about leaving CAPC (to go back to whatever you had)

05-14-2015 09:11 AM

I've reached the point where I would put up with the work of moving to another platform, one recent UIM probe I have had the joy of working with - 'ecometer', you start off with a portal app that allows you to build your template, at this time you have no idea whether it will work or not, you export this, then import it into the probe archive, then deploy it... Now you find out whether it works once you assign devices to the template.. If you need to edit it, back to the portal app to rebuild the template, and then repeat export, import, deploy, if you rename the template whilst, you can delete it in the portal app you cannot on the deployed probe... total madness. Nimsoft prior to CA, deploy probe, edit probe, job done.

05-14-2015 08:00 AM

As a Spectrum/CAPC user I can honestly say I wish CA had one Network Management platform  regardless of the size of your network. I've been tempted to test UIM but now I am not so sure I want to.  If I was not so up to my neck with CA with all the time I have spent on their products I think I would seriously look at HP's Intelligent Management Center

05-14-2015 07:42 AM

Sadly I fear not, 6 months ago I would have happily recommended the product, today I doubt it, the fact that my Infrastructure Manager can no longer get archive updates is one more nail in the coffin.

05-14-2015 07:15 AM

I was told recently that no one else has problems with UIM/ Nimsoft and they can’t understand why we have so many issues.


This forum seems to indicate that my issues are not unique!





05-14-2015 06:59 AM

Pretty much everyday I find something that CA has 'upgraded' in UIM to find it fails to deliver what it's predecessor did, CA need to wake up and smell the coffee or they will find their customer base disappearing from under them, and I have been a Nimsoft user for around 8 years. Letest for me is clicking on 'Help' in any probe and being taken to a WiKi article that is worse than useless.

05-02-2015 07:25 AM

After reading these comments I am so glad we stuck with Spectrum and CA Service Assurance( CAPC, ADA, NFA) instead of switching over to UIM like I had this CA Sales rep kept teliing me how UIM was so great.  So great he could not get me a demo unless it was installed by an engineer. CA you need to get your your developers in gear and quit sending out programs with bugs or you should expect your customers to leave. 

04-24-2015 04:45 PM

So after bringing this up every chance I get to CA, I am have been effectively told this will never happen, which is probably why we have not seen any meaningful reply on this topic. "under-review" - hardly.  After spending ~30 hours this week and probe defects, random hub restarts, messages being incorrectly dropped at the AE probe, discovery_engine not keeping up, etc I am so frustrated with the direction of this product.

04-21-2015 12:26 PM


I support the ideas above as well as the training issues.  I paid for a UIM course when my company first purchased the product only to find out that the training was a few releases behind what we were installing so it did not cover any of the new features.


Please get probe version numbers aligned with the current release and improve documentation about new features/bug fixes and other requirements for installtion.

04-08-2015 05:17 AM

"under review" is kind of funny

04-03-2015 09:02 AM

I see the CDM probe version 5.31 is changing the alert levels for the Windows servers.  They changed the alert levels for the UNIX servers a while back.  We have had NimBUS since 2004.  The alert level for "DiskWarning" was always minor.  The new version is set to overwrite the minor level to a warning level.  I guess somebody saw the label "DiskWarning" and thought the alert level should be warning instead of minor.  So after 10 years on this level being minor it is being CAified.  This affects Auto Operator profiles that send alerts. Extra work for me to delete the overwrite sections in the new probe version.  Another change was the boot alarm level from warning to informational.  There were others also, but those are the two that bothered me the most.  These new releases need to be thoroughly tested before being released. 

04-02-2015 07:17 PM

Hi Robert,

I think I can provide you with a second example that demonstrates current problems:

I upgraded all ntevl probes to the newest version 4.01. After that I got calls from a lot of people because ntevl.exe was eating up all CPU cycles. I found this mentioned in the forums (known defects thread) but support did not know about any known defect.
I downgraded all ~500 machines to version 3.90 and today noticed that the probes eats up to 3GB of RAM on our domain controllers (obviously a memory leak as this grows over time). I created a second call for this issue (now against version 3.90) and was told this is a known one, I should downgrade even further to 3.84...

I want to stress here, that you can download both versions from the archive and the errors are not listed in the release notes under the "known issues" section (or any other section as far as I know). One core problem that I see here: Even if you as CA find out about a problem, you make it very hard to let us know about your findings. Instead you make it very easy for other customers to fall into the same trap. This of course reflects pretty badly on the perceived quality of the nimsoft "solution".

04-02-2015 07:17 PM

Hi Robert,

I've tried to upgrade to UIM 8.0 but the upgrade failed with oracle errors due to undocumented additional grants you have to perform before the upgrade (salesforce case 00150892). This is not really what I expect to be QA tested (you obviously also don't care to update your release notes and happily wait for other customers to fall into the same trap). After support provided additional SQL statements our DBAs told me that the SQL statements don't work because they contain "*.*" where a specific grant is expected. The support could not tell me what I have to execute exactly and instead asked ME what I think should be executed. This not really what I expect from well informed staff.

- Stefan

04-02-2015 07:17 PM

So here is a thought - CA take a look at how many of your top 25 Nimsoft Customers run N or N minus of your current version of NMS. Then ask - does four releases a year still make sense??

04-02-2015 07:17 PM

If you ever look into this idea again please note that saying "let us know how we're doing!" and then not responding for a month pretty much describes one of the core problems many people have with this whole "ideas" th

04-02-2015 07:17 PM

Really seems like nothing changed for 8.x. All these new components that interact with each other, even the alarm/qos flow deviates signicantly from what it's used to be (snmpcollector, dynamic treshold etc.).

Just... forget the quarterly releases and do good releases with good documentation and support ready to actually support these releases. However long it takes.


04-02-2015 07:17 PM

and ntevl 4.01 is still availabe for other customers to download...

04-02-2015 07:17 PM

we encountered high memory utilization on monitored servers with 7.1 robots, Nimsoft support suggested us to upgrade 7.05(7.5). after upgrade, high memory utilization issue did not happen

04-02-2015 07:17 PM

Of course it is hard to turn a failing product into a working product again, but why not start with proper release notes? Still today I have to manually(!) ask support if a new version that I've found on the archive contains a fix for an open call. Then support tells me "as per the feedback from the backline team, this should be resolved with the latest version of the probe. Can you please retest with that version and confirm?"

So the release notes are incomplete and fixes that enginieering provide seem to have no link to the issue database whatsoever (or at least you are bad at linking them).

Here is my suggestion to "improve customer perceived quality"
- a commit of a developer should always link to a salesforce case or to an idea
- if a commit is merged, the salesforece case should be updated to "deferred future release" (should be easy because the commit contains the issue ID). Duplicate salesforce cases should be updated as well. Ideally I'd see the target version
- if I raise an issue about a already known issue, my issue should be marked as a duplicate and support should tell me that (I don't have to collect logfiles, if another customer already does it)
- if a new release is created every case should be updated to "awaiting feedback" so the customer knows the new version is out the door.
- the release note should at least contain the most important issues.

04-02-2015 07:17 PM

AND PLEASE consider NT Authentication when testing upgrades !!!

I Just upgraded a QA environment to 7.6 and (deprecated) dashboard designer does not work anymore in a SQL NT Authentication (it works in a SQL authentication)...
It is not the first time Dev Team forgets to test GA NM Server with NT Authentication method (already experienced issue in 6.0).

If only dashboard are successfullx upgraded to new HTML5 (Json File) format...but it doesn't... it fails in migrated alarm datasources... that's quite a huge issue when you have dashboards with hundreds and hundreds of alarmdatasource (i tried to change the JSON file manually and then reimport the dashboard...but during import, the systems fails in importing datasources... what a great dev....).

I use Nimsoft for more than 10 years... i must admit i am really frustrated by the lack of reliability of Nimsoft since CA acquires the product... now i understand why customers were worried about the fact that CA is now responsible for NM developments.


04-02-2015 07:17 PM

Totally agreed!! CA do a better job and QA your products. Customers should not be your QA environment. Insifficient QA and bad documentation leads to loss of $$$ to your customers

04-02-2015 07:17 PM

Anybody else worried about the upgrade to V8 in a couple of weeks?

04-02-2015 07:17 PM

Anyone else notice a new version of the robot get released (7.10) then get disapear a day later? Luckily i managed to pick that day to install it!

When i found it had been withdrawn i immediatly uninstalled it from the one machine i had put it on. After all if they pulled it then it must have some really bad problems.

Luckily this was in a test environment and i had not rolled it out to 50+ machines.

04-02-2015 07:17 PM

+1 from me too

You can also see that the product life cycles are very short too !
about 1 + few months for a major release - this means that you always need to upgrade the infrastructure of Nimsoft.

04-02-2015 07:17 PM

Another anectode: I once created an issue while using the newest version of the probe. I specifically demonstrated were the probe behaved badly but support told me the lab is not able to reproduce the issue with the exact same version. After days of collecting different information about our environment I noticed there is a new version of the probe available, read the release notes and saw my error described. After upgrading I asked why I was not informed about a new release and if the support team may have tested with a version that already included the fix but was not yet released at the time. I was told they probably just did. So +1 for relase notes and +1 for a public bug database or "known issues" section

04-02-2015 07:17 PM

I concur with all the comments above.
The process of application development lifecycle is not a new one. It boils down to process- Plan, Do, Check, Act.

Functional suggestions I would appreciate:
  •   A planned scheduled update ?vs break fix ?and/or?waiting until functions of the probe are no longer viable to what it is monitoring and then start ypur revisions
  •   Confirm that all existing functions are still present in the new packages/updates. ?
It is really disappointing to be told to enter a feature request or to post an idea, when the "feature" existed and functioned in the older version. (it is not always a viable solution to revert the probe and even when it is, I dont want to miss out on the improvements that may have been added

04-02-2015 07:17 PM

I see more an more products adapting sematic versioning:


I'd like to see these in nimsoft, too. Then I know what to expect and test when upgrading.

> Does anyone else feel more like a beta tester than a paying customer? YES. It's a real pain right now.

04-02-2015 07:16 PM

Does anyone else feel more like a beta tester than a paying customer? YES?

In some cases all you have to do is click around the gui to find a bug. We have had this same conversation with our CA reps. I would encourage you to do the same, please.?

04-02-2015 07:16 PM

Does anyone else feel more like a beta tester than a paying customer?

It's also frustrating to report a functional issue only to be told I have to create an "Idea" and rally for support in order to "maybe" get it addressed.
The support team is fantastic but I shouldn't need to communicate with them almost daily to have a "somewhat" stable product.

There have been so many obvious stability issues with recent releases I can't believe they went through any sort of meaningful QA process.? Maybe if Nimsoft slows down on the releases more bugs could be flushed out in the lab before they hit paying customers.

On a positive note, at least the new releases are heading in the right direction.? There have been tons of great enhancements (after weeks or months of bug fixes).

Nimsoft, please take a deep breath and spend some time on quality instead of quantity!

04-02-2015 07:16 PM

All the time

more frustrating is when a bug is fixed then returns in a later release

04-02-2015 07:16 PM

b.vloch: maybe it's like even version numbers are stable releases, and odd numbered ones are betas? That could explain 7.x at least ;)

04-02-2015 07:16 PM


I would love to break the cycle of updgrade -> report bugs in this version -> upgrade to fix those bugs -> report the bugs in the upgraded version - repeat

04-02-2015 07:16 PM


also too many times I have been told nothing is wrong only to find out it is a bug and will be fixed in the next release.
or the next one...
or the next one...
only to give up.

hopefully my qos_###_perc sla bug is fixed in 7.x wh

04-02-2015 07:16 PM

Definately for a +1 for the bug/defect database. I have spent lots of time 'debugging' a problem, raising a case only to be told "It's a known defect". It would be much easier to just go a look to see if it's known before embarking a testing session.

Also seems they are now quoting "it'll be fixed in the next release" for probe defects too (didn't use to be like that).

04-02-2015 07:16 PM

If?I could add a note that if you want any training on Nimbus at the moment you can only do courses for V6.x.

Personally I would expect that when a new version is released the courses and training material?are available BEFORE the product is released, not after another 3 or 4 revisions.

04-02-2015 07:16 PM

The current release method seems to be what is easy, and not what is best for the customer or your support staff.

I would like to see a time based support obligation for at least a subset of versions.? The current method of support for the most recent X number of releases is unpredictable and dependent on your release volocity.? Most vendors commit to support a release for a certain amount of time.? Others, have special LTS/Long Term Support versions which they commit to supporting for a longer period of time than other releases.

You might also consider using an odd/even release pattern for all probes and software where maybe even-numbered point releases add new features, and odd-numbered point releases are bugfix only.? This would allow stabilization releases.

ie: 7.0 new stuff, 7.1 just bug fixes, 7.2 new stuff, 7.4 new stuff.

I also tire of hearing the upgrade response when reporting a bug only to find that the bug being reported was not fixed in the upgrade, but nobody can tell you that without testing due to the lack of adequite change log documentation and a publically accessible bug track database.? Reasonably accurate change logs and a publically accessible bug/defect database would save everyone time and money by making support and the consumer more informed.

The general theme here is that the software release methodology is a pain for you support staff and your customers to follow.? Some well thought out changes could save everyone a lot of effort and make support more effective and efficient.

04-02-2015 07:16 PM

+1 from me as well. Spending far to much time chasing down bugs, that most likely others have spent time debugging before me.
Also, what?Ray Ferguson said. The man makes sense :)