65 Replies Latest reply on Jul 26, 2010 12:52 PM by pserwe

    In case you are curious what we are working on post 10.0

    bshopp

      Now that NPM 10.0 is GA I removed the old "what we are working on" post.  We are working on what is coming next and once we have that locked down and can communicate it out I will update this post.

        • Re: In case you are curious what we are working on post 10.0
          bwicks

          hey Brandon any thoughts around a thwack poll/vote on some of the new features that are being
          considered?  Or maybe a rank enhancements by priority

          Example
          Rank your top 3 enhancements in order of importance

          Rank - Enhancement

             - Enhancement a
          3 - Enhancement b
             - Enhancement c
             - Enhancement d
          1 - Enhancement e
             - Enhancement f
          2 - Enhancement g
             - Enhancement h

          • Re: In case you are curious what we are working on post 10.0
            chandruk

            Hi bshopp,

            Is the advance alert dependency feature is part of V10?

             

            I have been looking for this feature for long time and i thought this is going to make it as part of v10

            regards

            Chandru

              • Re: In case you are curious what we are working on post 10.0
                chrissmail

                Hi Brandon,

                Will there be server agents available soon for monitoring? We are finding the SNMP agents on servers to be unreliable, especially on unix and linux platforms.

                When evaluating the profiler product I assumed that agents would be coming soon as the profiler requires agents on servers.

                Thanks,

                Chris.

                  • Re: In case you are curious what we are working on post 10.0
                    Donald_Francis

                    I would disagree with that, I think one of SolarWind's strengths is that it does not need a client and through custom pollers can get almost anything from anyhing.

                      • Re: In case you are curious what we are working on post 10.0
                        jspanitz

                        Chris,

                        We agree with you completely.  A mix of agent and agentless would be ideal and a great selling point.  Agents just tend to work better in our experience and can collect data when the network connection is down, but agentless is good for easy deployment.  I hope your idea is correct!

                        John

                          • Re: In case you are curious what we are working on post 10.0
                            chrissmail

                            The Solarwinds profiler needs agents so that we can talk directly to disk arrays and SANs etc which is why i think Solarwinds will end up using agents.

                            Microsoft SCOM decided to move to agents for unix and linux as we can't rely on what the agents tell us!

                              • Re: In case you are curious what we are working on post 10.0
                                chrissmail

                                Correction - we can't rely on what the SNMP agent tells us.

                                  • Re: In case you are curious what we are working on post 10.0
                                    bshopp

                                    So can you all give me some more info on why the native agents are not working?  Where are you seeing this?  What agent are you using?  What data is not proper?

                                    We have tended to stay away from agents and be agent less based on feedback from the market due to the overhead typically associated with agents (i.e. deploying them and managing them). 

                                    Regarding the other question on post 10 items, the item you referenced is high on our list, but I cannot give any more data yet, I don't want to get peoples hopes up as we go through the planning exercise internally.  Once we have that worked out I will post a larger thread here like we had before.

                                      • Re: In case you are curious what we are working on post 10.0
                                        chrissmail

                                        We have found in the past that linux/unix agents sometimes give some very strange results for CPU and memory and interface values. This can usually be remedied by upgrading the SNMP agents but it seems that SNMP agents are different on different versions of these OSs and in a large server environment it's difficult to get the unix guys to update all of the SNMP versions on each unix platform.

                                        Also if we have the orion platform down for upgrades or maintenance it would be very useful to not have huge gaps in historical data which you get with an agentless system.

                                        • Re: In case you are curious what we are working on post 10.0
                                          jspanitz

                                          Brandon,

                                          Our input on the agents is this:  Done right, the agents can collect data and forward that data to the management server when the network is down.  They eliminate the blind spots.  Remote pollers are the agentless way of doing it but the way they are currently implemented ($$$$$) they are not a feasible option.   And SNMP is still SNMP.  Native agents can usually gether much more in depth information.  Agents, again if done right, can be installed on upgraded right from the management console during normal maintenance windows.

                                          We already deploy endpoint agent on everything already, so adding a monitoring agent to the endpoint compliance baseline would add very little to our overhead.  At a previous employeer, we used NetIQ AppManager which did exactly as I outlined in my emails.

                                • Re: In case you are curious what we are working on post 10.0
                                  firehawk_350

                                  Agents are definatley a need to really complete Solarwinds.. I do like the SNMP, WMI, and Script agent monitoring however when you move towards Win2008, WMI becomes problematic with UAC and the overall inconsistentcy of it. Go figure, its a microsoft product.. In addition in Firewall situations, If you have compliance, you can't utilize WMI because of the securty risk and SNMP doesn't have enough metrics to pull from.. Linux and AIX is a big reason.. IBM doesn't play in the SNMP world and NET-SNMP compiling on AIX is again inconsistent.. A agent with script capability, snmp, wmi, port check, etc ability would be huge.. Make the agent deployable from the main orion web(like NetIQ).  There also need to be a method to mass update and deploy the agent configs, etc.  CA did a decent job on the configs when it worked. 

                              • Re: In case you are curious what we are working on post 10.0
                                pserwe

                                I'm really hoping for: (Not in order of preference)..

                                1)  API Support for adding nodes, users, alerts, custom properties.  We're already starting to pull some reports directly from MSSQL, including some great data on alerts and counts of nodes and interfaces tagged with specific values.  I want to be able to drive the provisioning process via script, because all the pointing and clicking adding 3 nodes a day with 60 custom properties takes up too much time.

                                2)  Better mass alert management tools, could be superseded by the API.  Managing 100 (and ever-growing by average 10 a week) advanced, syslog, and trap alerts in 3 different places is becoming a full time job.  I'd like a really comprehensive way to export all alerts to a CSV with the relevant data for an alert, conditions in human readable format, actions, escalation, targets..  Be able to set targets across multiple alerts, message text notwithstanding, I want to be able to select 20 alerts and point them at a contact list for that "type" of alert.. or even have alerts go to different contact lists based on an alert "type" (Freeform text field like a custom property would be smashing in this scenario).

                                3)  Unified alerting interface.  Historical statistics on traps, like, maybe I want to suppress them for 20 minutes after triggering on the third one in 1 minute, but I still want a count of all of them that came in.  I want SW to be able to tell the difference between traps based on data in the trap.  1 OID can cover 1000 different events, the devil's in the details.  (I heard that's in 10 maybe?).

                                4)  Mass node updates of custom property values.  Select all nodes that match hostname pattern, vendor pattern, and whatever other random selection I want to make, then be able to change custom property value ZZZZ to "foo".  API support would totally remove another annoying and potentially difficult to do in a way that's going to make anybody happy UI problem to solve.

                                5)  Every sub-modules of NPM (APM, Netflow, etc, be respectful of view limitations.

                                6)  Be able to grant users node management rights for nodes flagged with custom property X having the value value "foo", limited node management in other words, limited by view limitation :)

                                7) LDAP auth tie in, including an LDIF/Schema update if necessary for Orion authorized users.  If you wanted to be indispensable, build a solid LDAP server into Orion as an add-on for NPM, that you can split out and run on the standalone webserver using those CPU threads IIS can't seem to manage to use for something useful other than running BOINC for malariacontrol.net ;)

                                8) SW tacacs+ implementation, maybe as a value-add for NCM, which could use some help.

                                9)  Real-time change detection that cannot crush a machine for devices that won't send a config trap (Maybe by a poll of something like the SNMP equivalent of config_version or last_config_write, polling every 1-3 minutes so it will work even if it's not Cisco (Adtran TA/Netvanta devices).

                                I must be off my game.. I can only swing 9 wish list items off the top of my head tonight ;)

                                Peter

                                • Re: In case you are curious what we are working on post 10.0
                                  SLXer

                                  When creating alerts.. not all alerts have the need to be present in the alerts view in the portal or in alert event history for that matter.

                                  Some alerts are simply present for heightened awareness of changes in an environment. For instance if you wanted to be aware when admin status of any interface was changed on a critical device simply to have visibility, creating an alert for currently does two things for you... When the server is recycled your likely going to get an alert for every interface that has a current status of admin down. Second all those interfaces are going to show up in the alert view as an active condition.

                                  There should be a check box option on the alert creation view if the alert should be excluded from the alert view.

                                  • Re: In case you are curious what we are working on post 10.0
                                    extrands

                                    One enhancement I would love to see would be to Network Sonar.  When importing devices, I would like to see an option to only import interfaces that have an active CDP neighbor.  We generally don't care about user ports on edge switches, but do want to import the uplinks.  Today, that is a very cumbersome process.  I can either discover the device only, and import no interfaces, or import all interfaces and manually delete those I don't want.  On a large network, you can spend hours deleting interfaces you don't want to poll.  More granularity on what is imported- beyond generic "ethernet interfaces" would be appreciated, but an additional filter limiting imports to interfaces with a CDP neighbor would solve the majority of my issue.

                                    Steve Extrand
                                    Sr Network Analyst
                                    Tyco Electronics

                                    (1) Orion v10 SLX polling engine & Additional Web Server 12500 elements
                                    (2) Orion v10 SLX polling engine
                                    (3) NTA v3.6 689 interfaces
                                    (3) IPSLA SLAX v3.1.0

                                    • Re: In case you are curious what we are working on post 10.0
                                      unclegio

                                      We are very pleased with the improvements made in v10.  I do have a couple of questions:

                                      1.  Will the future of ESX discover become exclusively through the API?

                                      2.  Will IPAM be able to support DHCP servers other than Windows?

                                      3.  Will APM be able build templates/monitors by selecting individual components?

                                      4.  Will the addition of Tek-tools allow the auto map feature to map all the way to the disk level?

                                      5.  Will there be any expectation to look at integration with ticketing systems?

                                        • Re: In case you are curious what we are working on post 10.0
                                          bshopp

                                          #1 - we are for sure looking at doing this.  There were some complexity I won't go into here and why we did not do in 10.0

                                          #2 - see What We're Working on for Orion IPAM.  If this does not cover you please post on that thread what you would like to see

                                          #3 - you should be able to do this today, what are you trying to do?

                                          #4 - so yes and no.  This may not manifest itself in network atlas maps, but our thoughts are to have the data be readily available going forward

                                          #5 - we are always watching the market for opportunities.  I have done "integrations" with ticketing systems and the problem I have run into is many popular ticketing systems are typically tailored to each customers processes and preferences so having an out of the box integration that just snaps in doesn't work all that well.

                                        • Re: In case you are curious what we are working on post 10.0

                                          I would like to see this move even deeper into a management piece.  I am sure I could craft this into the system, if I felt like it.  But the Idea I would like ot see is add a log field onto the Node Details.  We could then use this to track changes made by individules, on a given device.This would include helpdesk and technician levels.  I am really looking for a change management system for everything Windows, Linux, Mac, Printers, Cisco Devices, UPSes etc....  These fall outside of the NCM area, and its current capabilities.

                                          • Re: In case you are curious what we are working on post 10.0

                                            I just have a question that I have googled and not come up with any viable answers:

                                            What is SWIS API that requires port 17778 HTTPS?

                                            Thanks.

                                              • Re: In case you are curious what we are working on post 10.0

                                                I believe I have answered my own question by looking at the SWA (admin manual):

                                                ..."17778/ HTTPS open to access the SolarWinds Information Service API"...

                                                  • Re: In case you are curious what we are working on post 10.0
                                                    tclaar

                                                    Coming from the HP Openview world, I'm very impressed with Solarwinds ability to easily chart performance.  Were I believe Solarwinds falls short is in the Alert / Event area.  Here are some ideas.

                                                    1.  In a high alert shop, alert panels are utilized to manage incidents to completion.  In order to do this, there needs to be customized alert functionality that allows SNMP alert information to be enriched.  For example, when an aleet comes in there is a need to assign a incident ticket number to the alert.  Then, all subsequent alerts will also need to be associated with the same ticket number as well.  This should be easy to accomplish without having to enter a ticket number for each alert.   Upon doing this, it would be nice to have the ability to have all alerts with the same ticket number grouped together in a thread like fashion.  That way all alerts can be tracked together.

                                                    2.  Not all alerts are associated with troubleshooting.  Some are associated with planned maintenance or test/turn-up.  It would be nice to have custom alert panels were alerts can be parked.  For example, a master alert panel where all alerts come in and a maintenance panel were all maintenance alerts reside.  It would be nice to be able to move alerts between panels until they are cleared.   In addition, Having time-based alerts for these panels would be ideal.  Planned maintenance typically exists between specific time frames (i.e. 12:00am - 6:00am).   It would be nice to park alerts to a maintenance panel with an expiration time frame.  Then have those alerts re-afirm to a problem panel when the time frame expires.

                                                    3.  It would be nice to have an alert show enriched information associated with a device and/or interface.  For example, let's say I create a custom attribute for a node labeled "Support Phone #".  It would be nice for every incoming alert associated with the node to also display the "Support Phone #".  Since this data could change over time, it would be nice for the historical alert information to remain in the database for histocial reports.

                                                    4.  It would be nice to be able to pull enriched data for an alert from an external db.  For example, when an alert comes in, customer contract information could be dynamically pulled via SQL from an external database and shown in a custom alert field.  That info would then be stored in the db for historical reports.

                                                    That's all for now.

                                                • Re: In case you are curious what we are working on post 10.0

                                                  We would love to see a rule based discovery of resources on a device.  I spend a great deal of time removing or adding interfaces on routers that were improperly dealt with.  One of the biggest rules would need to parse descriptions.

                                                    • Re: In case you are curious what we are working on post 10.0
                                                      pserwe


                                                      We would love to see a rule based discovery of resources on a device.  I spend a great deal of time removing or adding interfaces on routers that were improperly dealt with.  One of the biggest rules would need to parse descriptions.

                                                       



                                                      +1 for this feature..  adding and removing interfaces get's tedious.  Custom properties are now my biggest focus in terms of node management tedium though.  I also need a way to do something along the lines of:

                                                       

                                                      for device in device group
                                                      do
                                                               add custom pollers from Custom Poller Group $Vendor to all T1 interfaces on $device that also have the Custom Property "X" with value of "True"
                                                      done 

                                                      Peter

                                                        • Re: In case you are curious what we are working on post 10.0
                                                          DaveStraley

                                                          Two other things that would be an added bonus in NPM would be:

                                                          1. To add a note when you unmanage a node.  That way you can state why that node is unmanaged so you dont have to ask the entire team why.

                                                          2. To be able to add columns to standard views.  For example the to 15 Volumes by disk used, to be able to add actual disk space left to that view.  So you would see the % left as well as weather it has 50MB left or 500MB.

                                                          Cheers!

                                                        • Re: In case you are curious what we are working on post 10.0
                                                          smartd

                                                          Steve:

                                                          I totally agree.  Discovery is broken for big shops.  I now don't act on anything but "Found" devices.  I've requested that sonar have an option to list only devices that have topology data, as these will be the ones with switches connected to the ports.

                                                            • Re: In case you are curious what we are working on post 10.0
                                                              extrands

                                                               Unfortunately, I'm finding that even "Found" devices are a bit unreliable.  Many duplicates are created during discovery of devices like 6509 switches with multiple vlan interfaces, and inexplicably, as I'm finding out this afternoon, existing nodes are re-discovered under their current managed address.  All of the interfaces are listed as new, but you get a "node not processed" when you proceed with the import.  Quite disappointed in the discovery as it is now.   

                                                              Steve Extrand

                                                              Sr Network Analyst

                                                              Tyco Electronics

                                                              (1) Orion v10 SLX polling engine & Additional Web Server 25500 elements

                                                              (2) Orion v10 SLX polling engine

                                                              (3) NTA v3.6 689 interfaces

                                                              (3) IPSLA SLAX v3.1.0

                                                                • Re: In case you are curious what we are working on post 10.0
                                                                  smartd

                                                                  Steve:

                                                                  I agree on the IP addresses.  I suggested that there was a node details resource that would record all the IPs assigned to a node and the interfaces they are on.  Additionally, Sonar should check the IPs in this resource or the device itself, and if any of them are already managed, list as changed rather than found.

                                                                  From discussions, I thought Sonar was supposed to check IPs, but appears to now work reliably.

                                                                  I created a universal poller to create an IP resource, but I can't make it do a join of the interface name to number table and the IP address to interface number table to give a single joined view.  Seems like a trivial thing for Solarwinds.

                                                            • Re: In case you are curious what we are working on post 10.0
                                                              Ralphr

                                                              Brandon,

                                                              While I haven't upgraded to V10 yet, it appears that many of the items in Chris's Syslog/Trap post (Re: Orion Syslog/Trap - what we're working on...)    made it into V10 with the exception of number 6  which of course, would have been #1 on my list ;)   Now I don't see it being mentioned in "what we are working on" post NPM 10.0 GA....  Since I haven't done the upgrade yet , I guess I'm still holding out hope that is actually made it into  V10 but just wasn't listed in the Release Notes......Any Chance ????? 

                                                              Assuming not , just to keep it on the radar screen ...this is seen as KEY to a number of my clients.

                                                                • Re: In case you are curious what we are working on post 10.0
                                                                  DaveStraley

                                                                  So we just upgraded to NPMv10 SP1 and was quite excited to see that in the release notes it stated:

                                                                  "New Core Network Topology and NPM Network Topology resources show direct connections between monitored devices."

                                                                  Hoping that this would correct the issue with having to add every interface on a switch via network sonar to get the uplinks to me recognized properly.  However, this does not seem to be the case.  This is just another place to show what the map already shows.

                                                                  As many other people have stated On thwack it is more of a pain to go through and clean up after network sonar than it is to manage the uplinks manually.  We will soon be upwards of 150K ports in our network and do not want to manage every single edge port.  The best way to manage this in my opinion is that interfaces would be separated on discover like my mock picture here:

                                                                  If we could just have the option to import the uplink ports in our network, this sonar tool would be the best thing since sliced bread. 

                                                                  Thanks again.

                                                                  Dave

                                                                • Re: In case you are curious what we are working on post 10.0
                                                                  SLXer

                                                                  Since wireless does not has its own catagory and i could find an better location to post this i suppose ill just drop this in the bucket.

                                                                  How is development going on the wireless component of NPM? It seems v10 did not introduce any improvements.

                                                                  Take a look at the below illustration. The client count at a glance is rather disturbing. The truth of the matter is the clients are spread over two radios. So how many clients are on which radio? Well thats anybodys guess.

                                                                  Im sure you have had plenty of input on what customers desire from this piece of npm however if you are interested in more feedback or suggestions feel free to hit me up off line.

                                                                  • Re: In case you are curious what we are working on post 10.0
                                                                    jeffnorton

                                                                    I'd like to see a time zone setting for each node or some thing to that effect.  We would like to be able to run reports based on the business hours of the time zone the node is located in.  The same goes for alarms.  We'd like to squelch emailing of some alarms based on business hours for a time zone.

                                                                    • Re: In case you are curious what we are working on post 10.0

                                                                      Hi Bshopp

                                                                       

                                                                      how about support for MPLS topologies in you mapping tools so that poor users like myself can also get maps autogenerated for them.

                                                                       

                                                                      Jag

                                                                        • Re: In case you are curious what we are working on post 10.0
                                                                          sirpaw

                                                                          Hi,

                                                                          I don't know if this already available in version 10, but it would really be great if we can have an option where we can total the interface traffic for certain number of specified interfaces and be shown on a chart. This would be a great help in easing the analysis of summing up overall traffic for a specific node with several interfaces sharing the load.

                                                                          Hope this can come to fruition in the future.

                                                                          Thanks! :)

                                                                            • Re: In case you are curious what we are working on post 10.0
                                                                              pserwe

                                                                              I can add to the pile for this feature, I especially need to be able to total traffic through uplinks, where we run most of them in a Primary/Protect scenario and occasionally have traffic shift.

                                                                              I'm almost positive this is tied to multiple pollers on one graph, because that's basically what it is, these just happen to be SNMP-v2-MIB basic traffic counters instead of some random piece of data.

                                                                              Peter

                                                                          • Re: In case you are curious what we are working on post 10.0
                                                                            timf

                                                                            I can think of two "simple" additions that would be great features...

                                                                             

                                                                            1.  I know it's been suggested already, but a Notes section per node would be great.   The ability to drill into the node and add free-form notes would be great.   That way a technician can see past issues with the node, or see what help ticket # was assigned to it.

                                                                             

                                                                            2.  I would love to be able to modify our lines drawn in Network Atlas to be made into arrows.  It would be nice to size them, and adjust the line width of them.  I would also like to be able to choose if one end or both ends should get an arrow point to it.  I'm thinking something similar to the way vizio handles arrows.  Heck, I'd even like to make curved lines.   It would also be very nice to make sizable circles/squares that aren't necessarily tied to a node, again, just like vizio.

                                                                              • Re: In case you are curious what we are working on post 10.0
                                                                                Myanta

                                                                                On #1 I agree.

                                                                                #2: You can do all of that except have an arrow head on the line. Curved, really bent, lines are available. You can copy and paste a picture into it, you can create a circle, just don't assign a node to it. Yep, it is very like visio right now. Oh and line width is also changable.

                                                                                  • Re: In case you are curious what we are working on post 10.0
                                                                                    timf

                                                                                    Yes, I have copy/pasted pictures of circles and squares into my maps, but it would be nice to create them with native tools.  You are right about the curved lines, I'm not sure why I've never noticed them before, with the countless hours I've spent in Atlas.  Thanks!

                                                                                      • Re: In case you are curious what we are working on post 10.0
                                                                                        pserwe

                                                                                        On  #1, drill down with tickets assigned or even just specific custom property display would be bee's knees.

                                                                                        On #2, I have a novel idea.. rather than bother with building a sophisticated UI for creating a network map, allow people merely to import or somehow convert a visio document.  Create a specific visio shapeset with the ability to populate the data from NPM (Like an export of the nodes table?)

                                                                                        I'm talking about serious dev voodoo here, that will once and for all end all discussions about map editing capabilities.

                                                                                        Peter

                                                                                          • Re: In case you are curious what we are working on post 10.0
                                                                                            Myanta

                                                                                            I think we might need Neo for your suggestion Peter. =)

                                                                                              • Re: In case you are curious what we are working on post 10.0
                                                                                                pserwe

                                                                                                Well, the thing about it, is that if you guys could just figure out how to import a visio diagram, which I'm certain MS will help you out with, including probably a web API, web-display of Visio documents is certainly possible, or a conversion to a format that SW can work with, or wholesale change to doing things a new way.

                                                                                                It might seem like a big deal, but consider the beauty of it:

                                                                                                A.  SW gets no more calls about the mapmaker via support or thwack.  All responsibility is pushed on to MS.  SW gets back dev resources to work on more hardcore core functionality, or gets to reassign mapmaker team to another section of the product.  Knowing SW, I'd expect they might get reassigned to features that I consider fluffy, but I'd hope more time got dedicated to the hardcore core features that vex some of us.

                                                                                                B.  Development of the process to import visio maps has a much higher value and a much lower dev cost than the continued support of mapmaker, network atlas, etc.

                                                                                                C.  Customers instantly have a very polished network mapping/layout product, if they don't have it already.

                                                                                                D.  Tie the existing network discovery in by having it generate a map and then save it to desktop, user generates the map, opens it visio, and edits it.  Able to move stuff around, change parent/child relationships.

                                                                                                E.  Run whatever's left through the web-ui, another transition that's completely in-line with SW's strategy.

                                                                                                F.  Creating visio shapes, exporting a document to visio, and being able to manipulate that data isn't reinventing the wheel.

                                                                                                 

                                                                                                Call me crazy, but I would think it would be worthwhile for SW to blow a few dev cycles on seeing if the approach has merit, rather than dismissing it automatically as too difficult.  Granted, my vision may not be perfect, and while nobody else may agree with me, I believe it's worthwhile to look at that approach from a philosophical/management and technical standpoint.  Maybe it's not possible right now, but if it isn't, maybe it should be.