This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Some issues

1.  I'm going to keep harping on this one - being unable to search on subnet fields (like location and comment) is a really "Bad Thing (TM)".  Since we don't allocate IPs, we allocate subnets, that's where we put our information.  Finding out after the fact that all that work doesn't do us any good when it comes to looking customers up is making it hard for us to use this tool as we need to.

2.  When a supernet in the tree is collapsed, and I click on a subnet on the right, expected behavior is for the tree to expand and the subnet to be viewed.  As it currently stands, the only thing that happens is the box next to the subnet becomes checked.  On the other hand, if the tree on the left is already expanded and I click on the subnet, I get the expected behavior - the subnet becomes selected in the tree view and I'm shown the contents of the subnet on the right.  Is this the designed behavior or a bug?  I use the most current version of Firefox (currently 3.5.3).

3.  When I shrink a subnet, the last (broadcast) IP in the block doesn't get set to reserved.  Is this to avoid loss of data issues or is it a bug?

In case you missed it the first few times, #1 is really important to me.

Thanks again for all your hard work.

  • #1 - understand, this is something I have up on my priority list

    #2 - What version are you on?  Maybe I am not doing the right set of clicks as you, but with 1.5 in IE I click on the top level folder then in the right pane select supernetA, it opens the supernet in the tree and then I select a subnet in the right pane and it highlights it in the tree

    #3 - ok I see this too, looks like a bug I will get this filed

  • Hi Brandon,

    Regarding #2 - I'm on 1.0.1 because I'm just not ready or willing to upgrade to 9.5 yet.  I was mildly disappointed (but not surprised) to see that I couldn't upgrade IPAM until I upgraded Orion.

  • Sorry, we don't do it on purpose or to put you in a weird spot, IPAM 1.5 required some changes to Orion in order to enable alerting functionality we added to the 1.5 release.  What is your hesitation on moving to 9.5?

  • Some of it has to do with the large number of upgrade issues I've seen, and some of it has to do with not wanting to make changes in the software while we're working on changing the infrastructure.

    Also (since you asked), I have a personal issue with being forced into changing interfaces for what, from the outside, looks like no good reason.  Too many Microsoft years under my belt to appreciate those kind of heavy handed tactics.  Perhaps if I had been expecting it to happen, I'd be more favorably inclined toward the change, but if there was an announcement pre-release that you were taking away my existing tools, I didn't see it, so I really wasn't prepared for it.

  • Can you expand on this item please? 

    Also (since you asked), I have a personal issue with being forced into changing interfaces for what, from the outside, looks like no good reason.

  • I'm referring to the move from System Manager to the web interface, which up to this point has been slower for me.  Also, by its very nature, it's a less usable interface overall.  Obviously, you folks have made the decision that portability and a single interface are a more important target than usability, so I just have to deal with that.  The only way I have to deal with that is by making my own decision on when I'm going to upgrade to that version.

    Hopefully that covers everything.

  • This is good, thank you for the info Justin.  In SP4 we added paging control to web node management, which has helped a lot of people with performance, but we recognize we need to do more there.  I disagree with your statement that we are not focused on usability there.  We do care about this and have been listening to the community feedback on this topic and working on how we can make this better.  Any ideas and feedback on what we can do, what use cases are hard to do or clunky, please let us know.

  • FormerMember
    0 FormerMember in reply to justinh

    by its very nature, it's a less usable interface overall.

    Can you elaborate?  Other than speed (which as Brandon said, we've addressed in SP4), what's less usable?

  • Hi

    I fully agree with Justinh about the system manager. The web console is slow, and it just not feels right when managing a node - One is the renaming of interface / nodes (yes.. Know you can do that in the webconsole), another is the poll this node (yes.. know i can get that in the web interface also) and stuff like changing snmp strings, IP addresses, SNMP version etc - i´s simply more "native" to manage in the system manager for this stuff. (and... MORE FAST!)

    Now, if the web console ALSO provided some "user access rights" lige user x is allowed to manage devices within this range or with that attribut (property) I could have seen the added value = i could have delegated responsebility to manage certain devices in certain areas of my network to someone else.

    Same goes btw for IPAM :)

    at the moment, i haven´t seen one single comment in Thwack that anyone "loves" the webconsole. ... Well.. We do! But not as a replacement of the system manager. It should be an add-on.

    Personally i fear for the day where all management of solarwinds is done in the webconsole - Especially in an enterprise environment, it will (based on the performance of today) un-doubtly be painfully slow

    For me, it would bring much more value to the environment, if you used energy on creating a "network atlas" kind of feature where I from MY desktop were alloved to connect to the SQL server, to manager the network. (as i´d imagine this could be programmed in "slightly better performing" code than the webconsole (?)

    Now, it´d not all bad.. even it might sound like that. I still think that you guys are delivering 1. class solutions to our (many) requests. My primary consern with that, is as justinh said, that in  the past, there has been a lot of upgrade issues.

    (I´m able to say past, as the upgrade to IPAM 1.5 went without one single issue needing support)



  • by its very nature, it's a less usable interface overall.


    Can you elaborate?  Other than speed (which as Brandon said, we've addressed in SP4), what's less usable?



    I want to stress that by "usability", I don't mean functionality.  I mean usability from the UI point of view.  "...it's a less usable interface overall" is in reference to the browser-style interface.

    First, the lack of menus.  Granted, this can be done these days in web apps, but for now, I don't see any menus.  No menus means that all functions either have to have a button in the initial page, or you have to bring the user to a separate page and provide an interface for all functions there.

    Second, in a single application like System Manager, the app loads and it's in memory.  With the exception of loading external data, all functions are directly available.  In a dynamic web app, you continually have to keep requesting and loading pages.  When working with more than a few devices or multiple functions, the extra amount of time involved can begin to add up.

    Third, by removing the interface from the server, you're adding more to each function.  By more, I mean now I need to communicate and transfer data to/from the server.  Also, a web app is several abstraction layers higher than a natively compiled app.

    Of course, the trade off is portability, the ability of more than one user to access it at one time, and putting all functions into a single interface instead of having them spread over multiple applications, to name just a few.  Somebody at some point made the decision that the pluses and minuses weighed more towards putting the interface in a web app.  Based on the information I have, I choose to respectfully disagree.