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.

Before the decade ends, show us your Orion Maps AND answer a few questions about them -- for 500 THWACK points!

Between sharing your Network Atlas maps and Worldwide maps, you've all helped us out as we continue to improve the Orion maps. Which is why we want MORE! Show us your Orion Maps (or at least the ones you cannot live without) OR email it directly to me at AND answer the following questions, then we'll award you 500 thwack points. (You must answer the questions as well as share your maps to get points)

  1. Share your map(s) below or email it to
  2. Are you still using features from Network Atlas that you NEED to have in Orion Maps?
  3. Why is a feature like Maps or Atlas important to you and your organization? What if you didn't have this feature?

Please submit your maps by December 31, 2019 to receive 500 THWACK points.

  • 1) MapExample.png

    2) I think the main things I still use in Atlas that I couldn't do in the new maps are custom labels, custom tooltips, and being able to select and delete connections that I don't want the map to display.  Would be good to just have some kind of "hide this connection" at least.

    3)  I find that the main value add in building these maps is it provides a way for someone who knows how everything comes together to document that and make it accessible to the rest of the team.  I may know all the critical interfaces for my WAN topology but the new hire hasn't learned them yet and it's a lot easier to point them to a WAN dashboard in Orion than to actually sit down and explain all the bits every time.  Similar problems apply to application architectures.

  • pastedImage_0.png

    1.Im still working on it...

    2. I think I am

    3. It shows the network- but can get too busy

  • What we are looking for is clarity around what is necessary to improve your experience with the tool.  If you are still using Network Atlas over the web based Orion Maps, why?  You indicated that you use the tool to show the network but it gets too busy, what would improve that?  It is hard to tell from that screenshot but it appears you are mapping out a ton of interfaces in that example.

  • I love maps for reports and for training new Network Analysts about our sites.  Maps--when kept current--are a visual shortcut to seeing what may be impacted by losing any piece of hardware or circuit.


    I need to have fewer places to reference, to keep current, to use as my sources of truth.  Towards that goal, I need maps to be able to display and filter information from Network Atlas so that I don't need to open/use Network Atlas at all any more.  I'm thinking of things like:

    • Showing Netpath information for anything I hover over--node, site, circuit, etc.
    • Discovering and displaying full L1 connectivity between any site. 
      • Then with overlays, display L2 connectivity that relies on the above L1 maps
      • Provide L3 display overlay options
    • But I don't want to have to see every L2 / VLAN / SVI for my devices.  It's a problem with mapping tools for which I haven't found a work around.  Showing me all the L1 or L2 connectivity ONLY between switches and routers, without making the map ridiculously complex.  Nortel's old Enterprise Switch Manager did it well.  If you're interested I'd be happy to discuss this further in detail offline.

    Maps and Atlas are important for keeping uptime at five or six 9's.  When we have accurate maps, we know what's supposed to be connected.  If we didn't have maps and atlas, we'd have to buy something to do the discoveries for us, or do the work manually.  I'd done both and ended up more satisfied with the output of the manual discovery and tracking.  But it leaves human error as a factor for making the maps stale.  If someone removes or adds a new device to the network and doesn't add it to the map, the information is unavailable for use when planning and troubleshooting.  If someone makes an error when doing manual map modification, your mileage will vary.

    Better still would be having NPM do all the mapping AND automatically learning nodes in the map based on CDP or LLDP information, and then automatically adding them to NCM and NPM monitoring while simultaneously updating the map.  When the map changes due to a node being down, if it had been correctly autodiscovered by the mapping process and added to NPM and NCM, it should stand out like a red light on the front page of NPM, and at the highest level of a map.

    Maps should be nested:

    • Organization overview
      • Regional views
        • Site views
          • Network Room views (within each site)
      • Data Center views
        • Broken down by physical location, row, rack
        • Showing servers AND network connectivity
      • Security view
        • Firewalls
        • Proxies
        • VPN connectivity
      • Monitoring views
        • Splunk connectivity and exposure to any type of reporting device
        • Gigamon connectivity and view information
      • Cloud View(s)
        • Showing every different cloud
        • Displaying physical location resilience (any resource lives somewhere at some point in time--why not have maps able to show where that resource is / was at a specific time stamp?)
        • Displaying connectivity to our organization, from any site, to any cloud resource
  • I emailed 2 maps to Kristin both of the same devices and links. One was in Atlas the other Orion Maps. Orion Maps can get cluttered very quickly in a small space as nato​ has indicated.

    Here's a small snippet. Custom labels in Atlas, I can also choose to have custom labels/description for the links which I can move around (I have none though in the example). These can show me utilization, bandwidth speed etc. Also port channel shows red in atlas but not in orion maps (it was already down before I created the orion map)



    Sorry I have not emailed you since our previous messages on this subject. My 2019.4 upgrade (just for the new Orion Maps features) was a bit of a disaster.

  • mesverrum​ - more on your point 3 - you can share that map with your NOC and that will make those connections obvious (for lots of teams). So when something goes red, its not just noise.

  • pastedImage_2.png

    2: What we're missing is CLICK TO DRAG. I'm sorry, but holding a key to drag is ridiculous and unintuitive. Either have a button for select mode/drag mode, or a button to press to toggle between. I've not seen applications where click to drag is not a standard feature and I find that grinds my gears emoticons_silly.png  That part is a total UX/UI fail. What if someone is one handed or has a disability? Are they supposed to use their nose? There is no accessibility thought of. Same thing with select/multi-select. And I say this as someone without said disability and I can't even.

    3: I find maps super important! They look good, they have great potential value, and they are literally an important showcase of what I want to do with solarwinds for the organization. I think it will become more and more central as monitoring grows at my company.

    If I didn't have this, I'd be looking at some data visualization app immediately like grafana/plotly/highcharts/nodered/catalytic. I still might for certain things when solarwinds doesn't display metrics properly, but for hierarchy/visualization you guys are on a great path.

  • designerfx​ appreciate the feedback - this was absolutely thought of and debated heavily during the design process. This was also never brought up as an issue or concern during any user testing, Beta, RC, or the 2019.2 release.  That being said, it is certainly an option that could always be changed, but what about when you want to perform a lasso or marque selection?  Are you going to want to click a button to be able to do that every time? 

    What is the issue with select or multi-select?