Network Node & Maps 2.0

k1gaudineer - the Contextual Map sub-views are dynamic and updated for you. This is so that users can understand what NPM sees as far as connected entities and topology without any intervention necessary.

Are you hoping that when you build a custom map, that map is then automatically added to any node details pages that are a part of that map? Would you be ok with manually having to update those map on occasion?

Would you have any situation in which certain nodes exist on multiple maps?

Do the contextual maps which are already in place not work for you? Why?

Would love to hear a bit more detail around this scenario - looking forward to your feedback.

jblankjblank- Thank you for the response.  The Contextual Map sub-views don't populate in our Orion environment.  the reason for this we are always told is because our environment is very large and the NPM topology can't run.  (We are hoping this will be addressed in future update to Orion.)  Here's the scenario:, 

An engineer is viewing a list of switch stacks in Orion Network Manager...  Next the engineer will click on a switch stack that he/she is interested in viewing....  Once the switch stack is selected the screen will refresh wit the 'Node Details' view for that switch stack....  The last sub-view in the left hand navigation pane is the "Maps 2.0 Contextual Map'.  When viewing this contextual map there will be only one device (the switch stack) and no other connected devices listed.   ---> For this there is a limited work around....  I can go into the 'Map Editor' and add the 2 L3 core switches that the uplinks from this switch stack connect to (Making sure to select the proper radio button so that this connection(s) is visible in all widgets for this node)  This part will work.  Any other engineer that selects this switch stack will see this 'Custom' connection I just built.  However, my question is centered around the other edits I also make in the 'Map Editor'  I set the text for the 2 core switches to be above the node icon so the connection line doesn't pass through the device name.  I like to make the 2 icon's for the core switches slightly larger than the icon for the switch stack and finally I like to have a different icon than the default icon for the 2 L3 Core switches because its more meaningful to have the correct icon there.  I can save this view and give it a unique name but the only one who can see this complete view is myself.  If I ask another engineer on my team to view that switch stack The can see the custom connection(s) I've built but everything else is not there and the display looks kinda bad.

We have close to 16 engineers on just my team, and we support just over 2000 switch stacks for just this scenario,  There is still the WAN area and all of the data centers as well. Since the NPM topology isn't running in our environment and the 'Maps Subview has been added to all of our existing views I am in the position where I need to go out and manually create all of the connections the teams would normally see in the 'Contextual  Map' subview.  I don't see why each of the 16 engineers should be expected to create the same Map that I am creating for the same switch stack.  Why can't there be just one map that all the engineers see instead of 16 copies of the same map. 

Or would a better solution be to remove the 'Contextual Map' subview from every view we have and go back to using Network Atlas and static links to maps to accomplish the same thing.  (Just thinking out loud here)....

Edit...  Forgot to mention our Orion Environment..  We ar currently using the NAM Licence...  16 APE's 2 additional we servers 1 HA server to back Primary polling engine and we are running Orion 2020.2 HF1

jblankjblank - Thank you for the response.  The first part of my scenario is that my world (In Orion) is spinning out of control and the root cause is Maps 2.0.  So far in our 20 year history with SolarWinds this is the worst thing I have seen the developers bring to the table.  Maps 2.0 doesn't work it doesn't work any better than the first roll out of Maps and I'm getting very frustrated having to field non stop questions from all levels in our organization on why it doesn't work.  The videos from SolarWinds on the Maps 2.0 have been seen by many in our organization and they have come away from those videos very enthusiastic and looking for the same maps in our environment. But SolarWinds leaves out some very key information in those videos and that key information is the severe limitations of Maps 2.0 in the fully meshed network environment which is 90% of my environment.   We standardized on LACP and port channels for everything.  Every edge switch every WAN office ect.  everything has multiple paths back into the network.  But SolarWinds can't show topology for LACP, VLANS, LAG's, HSRP,  or other protocols where member ports are used and that's 90% of my environment.  So now imagine the shock a person has after watching the video, and they are excited to see their network in the Maps 2.0 tab that was just demonstrated, but when the click the tab and the screen refreshes the screen is blank.  All of that excitement turns into disappointment, which then becomes a whole plethora of questions and explanations from support.  To makes things even more difficult, the Maps tab can't be deleted or removed, and if it is removed the next time someone runs the config wiz the tabs is put back again....  Sometimes 1/3 of my day is responding to people wanting to know why the Maps tab is blank and why it is there if it is blank.  

The next scenario.....  I do have a partial work around....  I can go into the Map editor select an edge switch and a core router.   the I can manually build the connection between the 2, select the option to make this relationship available to all widgets where this device might be shown then exit the editor.  The next time a executive or engineer views the node details page for that switch the Maps tab will show that relationship I just manually created but it is missing some of the other elements that they were shown in the video.  Like setting the node name above the node, so that the line for the connection doesn't go through the node name, and the core routers they were set to be slightly larger than the edge switch that isn't carried forward.  While you can set that for your own view why have every person who sees this page make the same come view. why not just have one view that is available to everyone.  Then there is the NPM Topology widget that is on the node details page.  If you manually create a connection then that widget shows 'CUSTOM' for the connection properties instead of L2, L3 ect....  The other side of the coin with this work around is that I have to create a connection for every edge switch stack  We have just a little more than 2000 of those and any other ad hoc or WAN connection we have.  that can take a considerable amount of time and still won't look as nice as something I can create in Network Atlas.  

If you are still with me this far into this rant I thank you for sticking it out.  Today has been one of the more stressful days dealing with this issue and I am hoping that SolarWinds can get this resolved.  Until then a huge step in the right direction would be to have who ever does the Maps 2.0 videos qualify the network they are mapping and the types of interfaces they are mapping.  This would go a long way in setting a viewers understanding and expectations with the Maps 2.0

Thanks for the added detail k1gaudineer . There is a lot to unpack here. First, I am very sorry this is generating any sort of frustration as we work very hard to try and build tools that address a wide variety of customer needs and make their lives easier. 

As you indicated in your reply - the Orion Maps project and where it stands today, is not something that was even feasible to produce in a single release. Unfortunately these things take time, effort, research, planning, and we did a lot of that. Where we started were the maps that are available on Entity Detail Pages. We started here because we needed a general foundation, and one of the most often heard complaints was that users/administrators didn't want to build maps. They still want a map, but wanted a solution that builds the map for them. Now that sounds nice, but in reality, when you show users automated maps, they are never what that user expects. If these maps are to truly be dynamic, it is very difficult for us (SolarWinds) to get everything right for each and every customer we have. For example, specifying the desired layout or icon that makes the most sense for customer A vs customer B. Regardless, this was still a good starting point, but the contextual maps, or the map sub-views are meant to be dynamic, built for you, and designed to show you immediate relationships relevant to the "seed" entity you selected. 

Now if you are not seeing those, the Orion Maps project did not build the topology engine, as this is a function of the Network Performance module. If you are not seeing a specific connection present in the NPM Topology Widget, then that connection won't be present in the map either. Obviously maps care about topology to build the connection, but my point is rather than troubleshooting a map issue with support, the focus should really be on troubleshooting topology that eventually feeds the map. We have many customers that are very pleased with what they see from topology. For example I have seen plenty of successful maps showing off LAG ports/connections, but in all fairness, these same users tend to request a feature in which they can see all the connections between the two entities on the map, rather than a single connection which is how we represent this today. Beyond that we are constantly working diligently to keep pace with changes in technology, how information is exposed or captured, and across many different vendors, models, and more. This while also trying to improve other facets of our product as well. We are always interested in doing better and there is never a shortage of an area in which we can improve. Topology detection does take some back and forth with support, if you happen to have any case numbers I would be interested in looking at those to see what took place.

Next, entering a contextual sub-view map should never be blank... At a minimum the seed entity should be there. If you are experiencing this issue, I would very much appreciate a support case raised so that our Dev Team can take a look. I have not heard of this issue occurring. If you expect more than just a single entity to be there, then what relationships did you expect to be present? If that expectation consisted of connected entities through topology, then again, we should validate against the NPM topology widget and if they are not there, then we need to investigate that issue... likely nothing to do with the map itself.  

If a connection does not exist, you are correct in that as of the 2019.4 release, we provided you an alternative option just in case automated topology detection didn't work. It was as you described, a way to define topology through the new Map Editor, and because we would clearly have torches and pitchforks at our front door if we allowed you to build a connection, but it did not show up in the contextual maps, or the NPM topology widget, or in other maps if those two entities were added to it, we made sure that was a priority for that release. Is it perfect? Of course not. There is no substitution for automatically detecting topology and mapping it out for you, but it seems to be a welcome and appreciated improvement by many users.

Unfortunately the next item you describe is the difference between a custom built map from the editor, vs the dynamically built map through the contextual sub-view. This is working as designed. While one can feed the other, as you can expand a dynamic map and then select the button to open in the Map Editor, these two maps were built with different purposes in mind. Again the contextual maps are dynamic. If user A were to change the map layout, customize icons, etc... and then user B changes them back, which is preferred or persisted? If the map is dynamic, and a specific layout is chosen but a new entity is monitored, where is that placed on the canvas, what icon does it get, etc... There are lots of interesting questions and thoughts on how to solve these challenges, but based on the feedback we were receiving, it was time to invest deeper into the editor and the functionality for building custom maps. So in essence, these are two separate features to some extent and should be treated as such. Believe me, from your feedback in this post I could identify a number of different options which will all be considered. Perhaps as an example, it may be ideal to incorporate a UI that allows you as the administrator to assign a custom map to any details view, versus showing the dynamically built map. That way users see the map you have built for them. The con there is that the custom maps won't automatically highlight a new connection you may not be aware of, or that has changed... just something that is an interesting challenge to try to improve. Feedback such as this is what gives us more data to make informed decisions and consider use cases from thousands of customers. When it comes to maps, there is never a shortage on feature requests. 

When you create a custom map, you mention this is only available to you, but that was the idea behind the Orion Map Widget. Provide a method in which users can share these custom maps. From discussions with other customers, most executives are often times not drilling into a details view. Perhaps there may be some option to create a unique dashboard that includes your map as well as other high level stats which is great for executives to view, but this same dashboard could allow you to drill further down into logical groupings of your entities/ data. Perhaps this is even accomplished by nesting maps... I have demonstrated many different ways of accomplishing this and I am happy to chat further with you on this topic. 

As mentioned previously, we can always improve, and we should take a look at enhancing the usability of creating those custom connections. You mention that takes considerable time, but then you mention that it wouldn't look as nice as something you could create in Network Atlas? Why is that? Part of the constant feedback from a vast majority of Atlas users was the outdated look and feel, and creating a decent looking map. Are you looking for a function to just draw arbitrary lines between entities perhaps? That is another highly requested feature. Do you have an example of what that Atlas map looks like?

I certainly stuck with your feedback, hopefully you have stuck with mine. We work very hard to develop features and functionality to address a wide range of problems, as well as a wide range of users. Unfortunately time and resources is a constant battle but feedback like this makes a huge difference and we are certainly listening. If there is a specific video you find problematic, please feel free to share. I have personally been asked to do many of these videos because of my passion for this project but I unfortunately cannot participate in all of them. I have never shown a custom map added to a details page, so there should be no discrepancy there, but the two features do share functions with each other and I can understand where confusion can occur. 

Perhaps some of my recommendations to build a unique dashboard for your users to drill into might make sense? You could even include links to this dashboard in any alerts for users to have quick access. Orion Maps have addressed many problems Network Atlas maps had in the past, one of those allowing you to alert on the map itself. Perhaps an alert on the "service" or network could be shared with your executives or engineers, and when they click on the shared link, they are dropped into the custom map and can see the issue there. You can of course enable Historical Tracking on a number of maps allowing users to see what was occurring prior to an issue and after. We still have more we would like to do and many requests floating out there that we would like to get to.  

As always - thank you again for your feedback, and we will continue to try and make improvements on all these features moving forward.  

A timeline of maps and what led to some of the decisions can be found through these posts:

Orion Maps - 2018.2

Orion Maps - 2018.4

Orion Maps 2019.2

Orion Maps - 2019.4

Orion Maps - 2020.2