NETSCOUT nGeniusONE Reviews

We use it for a lot of VoLTE monitoring and network monitoring in general. Most of our services are being monitored via NG1.

It gives us increased visibility while conducting an IT deployment. For example, once we launched VoLTE, we had other tools in the network that we were using for some other use cases, but in terms of MOS scoring and general monitoring of how the VoLTE calls were doing, we were using the Media Monitor.

We're not really using it to proactively capture outages, like Zero-day outages for example, when there is something completely new. But once we detect an outage, we can then use the tool to understand what it was and create an alarm, and that can be used for future similar outages so we can avoid them in the future.

It also helps us get to root cause quickly. We had an Rx Diameter issue at some point in IMS, and without the product it would have taken us more time to be able to troubleshoot and figure out what was happening. With the product, we were able to use Universal Monitor right away to figure out the actual error code and understand the issue from there.

In terms of unified communication, that's the VoLTE modules and the MOS scores. We used it heavily when we launch VoLTE. Currently, we have monitors set up per region so that we can monitor VoLTE. We also have it per event, so when we know something is happening on a big scale and we really need close-up monitoring, we set it up specifically for that area or region or the particular cells, to monitor that particular event.

The solution has cut our overall troubleshooting time and has helped to increase our network uptime.

The most valuable feature is VoLTE, for sure. The VoLTE modul, call search and Media Monitor were essential when we launched VoLTE. We're relying heavily on them to troubleshoot our VoLTE calls.

There is a lot of the VoLTE, voice, video MOS, and customer experience that we'd like to do. There's a lot of throughput analysis where we're trying to understand, with the vendor, whether it's accurate or we need more work on it. Those are our top priorities.

NG1 has been stable for a while in our environment - at least we have what we needed. But with nBA, there's a lot of room for improvement.

Stability is a tricky question. It is stable, but the way we use it, we have a lot of tweaks and a lot of specific and detailed configurations on the InfiniStream. It's a very manual process to configure it right now. We're also looking into ways to automate that and, hopefully, eliminate the human error.

So it's stable, but once you start doing more and more with it, there is always something happening in the background that we're not sure of, that fails or something happens, and we have to troubleshoot it and understand it.

So far, on the NG1 side, it's been very easy to scale. We just go into InfiniStream if we need to and we can very easily link it to our same NG1.

In terms of actually needing to add new InfiniStream, this has been a challenge because we'd like to reduce costs. However, there are a lot of use cases where we absolutely have to have new hardware, which we don't like, but it is what it is.

Technical support is great. We have a dedicated team. We have two SEs onsite who work with us, plus the support engineer. With those three, we have great support.

I wasn't part of the initial setup, it was set up before my time. But I helped set up the NG1 part and it was fairly straightforward because we have very good SEs on site, plus the support team. Whenever we need something we reach out, and they support us right away.

Get a demo. The guys at NETSCOUT have been super-helpful. Any time we ask for something they simply say, "Let's show it to you." They come onsite, give us a demo, show it to us, and if we like it we deploy it. We also have a sandbox, where we get our real traffic into the product in the early stages. We do all of our testing and all of our new builds in there before rolling to production, and that really helps.

Regarding the single pane of glass view, we have different views because we use different tools for different use cases. We can't really say that we have it in our network yet, but if we can work toward that, it would be good.

We have not used the Dependency Mapping the solution provides because our connections and relationship are way too complex. It's hard to see it on a visual screen.

The solution helps us with network uptime. It helps with user experience to some degree. We still have some caveats that we're trying to work on with NETSCOUT. We're using nBA now for user experience and there's some cool stuff coming up. We're looking forward to it.

I would rate nGenius at eight out of ten, because of the support and all the feedback we get. And at events, we get direct contact with their executive.

Troubleshooting our LTE network - any situations that come up in our cellular network. We also use the solution for proactive monitoring of remote sites, as we use it to monitor all the towers in our cellular network, as well as our core applications.

We're still in the beginning stages, learning how to use it.

It's a great monitoring tool. At a glance, we can get an idea of what's going on in our network.

Also, while I don't track it personally, I know that time to repair has been reduced and that it has cut our overall troubleshooting time.

The most valuable feature of this solution is being able to drill down into any kind of troubles that are reported to us, by use of identifiers.

Some of the filters could be easier to see and to set up. That's the only thing that I've ever had any trouble with. The ones that I've seen here, at NETSCOUT Engage 2019, are part of a newer version that we don't have yet, and it looks better. So, it may already have been fixed.

It's 100 percent stable.

The scalability is great.

I'm sure it's great, but I haven't had to deal with technical support. I'm a technician.

I assume the setup was straightforward. I'm a telecom tech. The engineers did all the setup and I only use the tool. I didn't help set it up.

I would recommend it. It's the best tool that I've used as far as troubleshooting quickly, at a glance, and for being able to drill down into any issues, any complaints we might have from customers.

I do know that we would like to get TrueCall, but we don't have that yet. We're working on it.

I would rate nGenius a nine out of ten because I don't rate anything a ten. There's always room for improvement.

We use it mainly for north-south, and soon to be, again, east-west: Troubleshooting, visibility into the VoLTE cloud that we've designed. Initially, it was very small, baby clouds, per se, but now as we redesign and go to scale, so that we have the visibility we need, we need better tools. We have the infrastructure, but we need to take the next step into the virtual lane.

We use the solution for proactive monitoring of remote sites. We have 29 data centers where these clouds are built and we're moving out to edge and we will have even more.

It has provided us with increased visibility, not during deployment, but downstream, once we actually turn up services, whether it's microservices or a VNF.

During outages, and in terms of visibility into VNF and container behavior across the various versions of our cloud, it has helped our organization.

nGenius also helps us get to root cause quickly. Signaling is one example. We have challenges between applications that share the same baby clouds but that utilize storage differently than the network. We don't have that visibility now in some of our deployments. Our new deployments will have that visibility because we're not using copper for a lot of the east-west traffic in the cloud. We're actually moving to fiber so that we have that visibility. The next step will probably vSTREAM.

In addition, I believe it has cut overall troubleshooting times for the OSS and DevOps teams, and it has increased uptime. I'm not in the operations lane, but I know that is something that we have to have.

The most valuable features are visibility, real-time, on-demand.

I need more details on the vSTREAM and how that scales from a CPU perspective. I know that we can start with one virtual CPU, but at the same time, our clouds are still limited by compute nodes. That's an ongoing question and it's part of why we're here at NETSCOUT Engage 2019, to see how we architect that out.

I'd like to see improvement in scalability and the CPU perspective on the actual cloud nodes. It would be good to have a roadmap of what impact to our underlying cloud we will see as we add vSTREAM vCPUs.

We haven't had any problems with stability.

The scalability needs some work. From a probe perspective, we are limited to a certain amount of throughput on the devices themselves. Without having actual hooks into the bare metal hardware for the solutions, it's a bit of a "thumb in the air" as to when we hit our capacity or when our high watermark is. I'm not sure if our operations teams have that capacity under control. So when we have to scale, it's a very large expense.

I'm not aware of whether the initial setup is straightforward or complex. We have a standard template when we build them out.

A lot of it was internal or direct with NETSCOUT.

We've had ongoing RFPs back and forth for multiple years. As far as new solutions for our visibility needs go, as we're right in the middle of our cloud journey from an LTE to NFV to 5G, we're trying to get a grasp. We're always on the cusp, looking for the next set of roadmaps and how we integrate that into our network to provide for our customers.

Our shortlist included the usual culprits: Empirix, Gigamon, all of them in the same build with NETSCOUT. We still have a very vast mix of everything.

We can't ever walk into our builds or our support models blindly. This solution is one of many options, but it's obviously one of the better ones that we've worked with for years, and it's an integral portion of our architecture upfront.

"Single pane of glass" is a very overused cliche in our business for the past couple of years, same with "Agile." I like the idea of being able to stitch it all together. Our operations team definitely insist on it.

I would rate NETSCOUT a seven out of ten. Not to be a detractor, but I don't have the hands-on experience from an operations standpoint, so that's why I rate it a seven.

We use it for when an app team or somebody comes to us and tells us that we have a problem with a server, that they're experiencing slowness, or latency, or the like. We like to take two IPs end-to-end. It will give us a server IP and the client IP, and we can plug that into nGeniusOne to hopefully give us some kind of error codes or a breakdown of what's going on from the packet level of the transaction. Hopefully, it gives us an idea of what's wrong.

The solution gives us increased visibility while conducting an IT deployment, depending on what the deployment is. As long as it's still monitoring in places that we're deploying something - for example, if it's in the DMZ, and it's going over a firewall - we have sniffers and tasks with this product deployed. In that case, we should be able to use it.

Another example would be when we're in the process of doing a lot of backups to the cloud. The teams come to us and they want a certain amount of bandwidth and a certain amount of resources, and they constantly ask us whether it's too much or too little, or can they use more overnight or at certain times. I can go back to my NETSCOUT reports and find out whether they're in trouble or actually have more capacity so they can ramp up their operations. It provides a view into that.

When we actually can use the product, we can see a measurable decrease in mean time to know or mean time to repair. It definitely has been something we wouldn't do otherwise, especially for capacity planning. We will get there when we have more proactive alarming and monitoring in place. It can greatly cut overall troubleshooting time once you know how to use it and it's properly and fully implemented.

Its troubleshooting capabilities are the most effective because we have it deployed in and out of our data centers, with our servers on-prem. And even now, going off-prem with Azure, we want to have visibility. For example, if one of our network pipes is getting plugged up by somebody using too much bandwidth, we can use the NETSCOUT tool to examine and find out what is going on.

I like the Dependency Mapping the solution provides, as long as it works. If you have it properly deployed it will. Being able to have dependencies is very critical in figuring out any path, and the more we can have that functionality it's nice because we can see if something's talking to multiple devices. We can see if one is actually the cause, rather than just "seeing blindly."

In terms of the single pane of glass view, when we build it out in the nGeniusOne platform, there are multiple tiles and, depending on what we're trying to examine, it doesn't all fit in one single pane of glass. It would be nice to have that functionality, but you really do have to categorize things because there is so much data.

The biggest thing is being able to provide net path. One of the products we use is SolarWinds, and it provides a very cool mapping of an agent from end-to-end. If NETSCOUT could somehow implement that into their design, whether it be sniffer-to-sniffer, or that kind of thing. I know they have some functionality along those lines, but if they could make it quicker and easier to get those net paths, it would be huge. I could quickly plug in problem IPs and get a full hosted view of where it's going from end-to-end. That would be really useful.

Finally, the GUI, the interface, has room for improvement. It's user-friendly to a degree, but when comparing it to other products, such as in the Cisco environment or SolarWinds, I found that I could just fumble my way through those tools very easily without training. Whereas with NETSCOUT, I need training in order to set stuff up because I would never figure that out on my own.

The stability has been pretty good. I haven't had any issues with the hardware, for the most part. It's a little tricky working with if you don't go through NETSCOUT for the packet flow switching. Right now, we use Gigamon, which we've had some older iterations of and some issues with. But as far as the hardware from NETSCOUT goes, we've had no issues.

The scalability is huge because certain ISPs have hundreds of these things out there monitoring their deployments, versus our having a few. It's very scalable.

Tech support started off poorly a few years ago, when we first implemented this, but I don't think we had the right resources on hand. In the last year, my company has worked directly with an OSC onsite, and the support has been much better.

We've actually had NETSCOUT for a long time, but originally it was implemented as a security tool, pre- and post-firewall, to just monitor traffic that way, to see how effective it was.

Now that firewalls have improved, and we use Check Point for that, it's been transitioned to the network team - to where I am - and now we're just using it as an NPM-type solution. It didn't really come in as a replacement. It was more, "Here are some assets that we want to use for network performance," so we're learning how to use it and deploy it better.

I don't know how they came to the decision to use NETSCOUT five years ago, but we kept it because we've had an investment with them.

The initial setup has been very complex. Just understanding our own environment, we definitely needed a dedicated resource, an OSC, to really figure out where we needed to deploy these things, what the capacity we needed to build out was, and what we needed to spend; what we currently had versus what we need. It has definitely been complex.

We've always gone straight through NETSCOUT in terms of the support and the hardware. We have never gone through a reseller.

We have seen some initial return on investment, on a small scale. We definitely hope to get more out of it once we implement it properly with the OSC. We're in the early stages.

We were looking at some of the Cisco stuff, and LiveAction, and SolarWinds, but NETSCOUT has its own little deep-dive triage packet part of the market that no one really, that I know of, touches. There is definitely still value there when considering.

If you want deep-dive, triage, packet-capture-type data, rather than just using Wireshark, it's very effective for that. It's definitely good for complex troubleshooting. There are other solutions, going into the cloud with the thin clients, and the vSTREAMs and vSCOUTs are definitely good, as is the nGeniusPULSE - I really like the PULSE product. We're not currently using that.

I think nGenius is very useful. You have to know your own environment, and see if it's good for you or not. My recommendation is mixed, to be honest. Depending on what you're looking for would determine whether I'd recommend it or not, which I actually have, to a colleague.

The solution can help us get to root cause more quickly, but not always. It is definitely a good stepping-stone, and when we have the visibility and the deployment properly implemented, it definitely can quickly get to a root cause.

We use the solution for proactive monitoring of remote sites to an extent. We have all of our sniffers, and all the stuff that's TAP-ed is in our central areas that get reported back from remote sites. As long as it crosses over one of those TAPs, it works. We're currently in the process of actually redefining and restructuring our build so that it does give baselines and some proactive monitoring, but we're not there yet.

For responding to issues, it can help the network uptime, especially when it comes to capacity, but as far as actually helping the stability of the network, I don't think it's really done that.

nGeniusOne is a seven out of ten, but improving. Originally, about a year or two ago, it was like a four out of ten for us because we weren't using it properly. When it's implemented properly, and the training is there to use the interface and have it work in your company, and people understand it, it can be very effective. As we do more and get it properly implemented, I think that score can even go up.

Visibility into the network is our primary use case.

We're just starting to use the solution for unified communication application performance, but we're not there yet.

The solution provides us with increased visibility while conducting an IT deployment.

It also helps us get to root cause quickly. We've had some voice issues, unified communication issues, over the last few months, and it gave insight that the voice team didn't have. We could actually pin it down to the point that we had a bad DSP box.

It has cut our overall troubleshooting time. It's taken the complexity of having to do SPAN sessions from the core and other places, by just going straight to this tool and applying the proper filters and getting the information.

The details it provides are among the most valuable features; the ability to drill down and get to the packet level.

I like the Dependency Mapping the solution provides. I wish there was a better way to show large groups, greater than 500, instead of just not displaying anything.

I would like to see it closer to more of an APM-type, or at least have that availability to compete with APM - the AppDynamics and solutions like that. I feel it's a natural step to at least have that available. 

Also, some integrations with ticketing systems like ServiceNow would be helpful.

Overall, it seems to function really well. We've only had one issue, but that was due to a power outage. It seems to perform well in a virtualized environment and I don't have anything bad to say about the stability.

I haven't had to use technical support yet.

The sales engineer helped me, and I got a lot of help from the website itself.

Be prepared to invest a lot of your own personal time to get the best use out of the system.

Regarding the single pane of glass view, you've got to have a lot of time on the console. Even though it's single pane, you've got to be able to at least get all the phrasing and catch stuff located properly.

I would give nGenius a seven out of ten. I think it could have an easier to understand interface. Other than that it would be a 10.

The solution helps to troubleshoot and put our hands on the weak points of customer networks. 

NETSCOUT nGeniusONE's pricing is higher compared to the competitors. It is more than 15-18 percent of competitor costs. It also needs to add AI features. 

I have been working with the solution for eight to nine months. 

NETSCOUT nGeniusONE is stable. 

NETSCOUT nGeniusONE's tech support is good. 

Positive

The tool's installation is straightforward if you are familiar with the product. It is complex if you don't have user training. 

The solution suits enterprise customers. Small businesses will find the cost high and the tool's capability unsuitable. I rate it an eight out of ten. 

We use the product to monitor infrastructure devices and troubleshoot application behavior if there is any issue.

The solution helps me understand the issues and troubleshoot.

If the connection doesn’t work, the product provides us with a code, for example, 5000. Then, we have to search the internet to understand what this number means. It would be better if the product gave us a code and its meaning while identifying issues.

The solution needs enhancements. We need to reconfigure the tool if we have a connection with dissimilar ports. The tool should ideally capture all traffic. However, it is unable to analyze unknown ports. I have to reconfigure and refine the tool to monitor the connection. This process is a waste of time.

I have been using the solution for six months.

I rate the stability a six or seven out of ten. The product crashed a few times within six months of implementation.

The solution is scalable. It works the same when we add more components. I rate the scalability a ten out of ten. Almost 50 employees are using the solution in our organization.

We need regular support from the vendor. The support is good.

Positive

The solution is not easy to install.

It took us three to four hours to deploy the tool. We needed only one engineer to deploy it.

The product is too expensive compared to other products.

We also use SolarWinds. We are trying the tool because our organization needs multiple monitoring solutions. Overall, I rate the solution a seven out of ten.

It's deployed at a customer in the banking environment and it monitors the perimeter edge in the data center. It's used for visibility inside the environment as well. The traffic is only being sent via TAP data currently. We don't have any NetFlow data to the system, as yet. We have the NETSCOUT TruView system in and that performs for TAP data and NetFlow to monitor the branches.

For some of the applications we've managed to drill down and get more granular data, because it provides such small granularity — a microsecond or a millisecond of data — that you can actually get finer response-time detail out of it. That helps a lot.

It has improved some of the visibility of some of the unified communications with the ability to drill down into finer time increments in the packet data. We are able to search through those and get those Wireshark-types of views, with some extra flexibility and visibility on packet data or wire data.

The quick drill-down views are similar to Wireshark views. Those are quite nice, with the views on how you interpret some of the data. The granularity of how far you can drill down into milliseconds or microseconds is a very nice feature. It actually stores quite a lot of data in its database. It enables drilling down for reporting.

The solution transforms packet wire data into real-time data that is ready to act on. We've set some of the alerts to alert on it. We can look at that packet data, or we'll use scenario-based alerts, to then further drill down and see what the system has picked up as an anomaly or a scenario that's being analyzed by the system. We can investigate it further and see how we can resolve the issue or alert on it for the client.

We received some documentation to integrate it with ServiceNow. We're busy looking at that for the near future to integrate into that or another vendor's ticket system, and then alert on things in real-time, so there's less delay from our interpreting of data first. And then we can act on it.

They can improve still on the workflows, document their workflows that are commonly used.

Also, if you do backups of the system or try to do configuration changes, there are a lot of different formats that you need to separately interpret. It doesn't flow nicely. With config backup, for example, there are a few variants that you have to collect. Otherwise, you have to use the system backup, which we haven't restored yet, so I don't know exactly how that process works.

There are one or two things for the grids that would be nice to have. And it would be nice to be able to change some of the metrics, here and there, on the normal overviews.

Currently it's working. We had a lot of issues in the beginning with patches that we had to load, but that was more of the teething and learning how to configure the system as well. It's not quite the same as the TruView which has end-user response metrics. The nGeniusONE doesn't quite do the same thing.

It's a more technical tool compared to what we're used to, or what the client is used to with TruView. For some of the stuff we've seen we have had to build multiple sections or multiple pages to get a view of the environment or branch or application.

On a scale of one to 10, the solution's ability to transform packet wire data into well-structured, contextual data is a seven. There is room for improvement. It goes back to the workflows. We don't know some of the workflows yet, and it's not something that you can just read up in the manual. There is some stuff in the help manual and online, but it's to a point where you need to purchase extra training and services from them. You can't just go and read up on it yourself and learn from A to Z and then, if you require extra training or certification, you could go further in-depth into that. That's part of the business model, I assume.

Also, it's not always the case that the solution provides the right people in our organization with the right information in a single pane of glass view. There are times where we would want to get a different view on some of the service dashboards. We can't really get all the views that we would want on a single pane of glass.

Overall, there is room for improvement, but so far it is a useful system.

We deployed NETSCOUT nGeniusONE last year around April, so it's just over a year now.

Currently we're running quite stable. There were a few hiccups in the beginning with stuff not working. But currently we're running more or less stable. We are running on version 6.2.2. There are a few useful things in 6.3, but we were advised not to go that route yet because it's not 100 percent stable. Our sales engineer said to hold on, just to see how some of their other clients experience it and see how many issues are still being noted in the system before we move over to that newer version.

We'll probably increase visibility in future because it needs to replace TruView. Currently we are only using packet TAP data. Later on, as NetFlow and those things evolve, we will need to move over to NetFlow collectors on the system as well. Currently we're using them on TruView.

And we need to expand to some of the newer data centers that the client has moved into, as well as the cloud section. We need to expand into those as soon as the client has a bit more budget and they are happy that the system is working and the views and the consolidated views are giving them what they want. Then they'll expand more on the system.

The key thing for us is to get the VAR service up and running, which should be starting from today. They've sorted out their remote access. That took us a few months just to get into the banking environment with all the nondisclosures and security checks. We are quite happy to get that started and to see how they can assist us on the system. We want to do a sanity check on the system to see what we've missed.

We have an account with them and each engineer has an account where they can log TAC cases, and our sales engineer sees some of the stuff that we seldom hear and assists where he can. Otherwise, we work with the guys overseas. It depends which section of the system it is for unified communication. Cases have been escalated, eventually, to assist configuring some of the things.

We've had a few issues with one of the InfiniStream storage units, and that took a long time to resolve. The guys are still learning some of the things on the system themselves, but that eventually got resolved. But that may also depend on the support model we took.

Once you get to the higher-tier support guys, your issue normally gets resolved quite quickly.

We've been using TruView. We've known for a while that we would need to switch because it was an old Fluke Networks product which was bought by or moved to NETSCOUT. We knew at some point in time it was going end-of-life. We need to keep it up and running for as long as possible, at least another two or three years, until the end of the contract, and see how long it lasts after that. Slowly but surely we'll migrate to nGeniusONE as we expand visibility.

The setup was a bit complex, documentation-wise. There is a long list of documentation just to deploy the system, with a lot of variations. There's tons of documentation. Their portals reflect all the documentation and you need to go through various sections of the documentation to find what you're actually looking for.

We managed to get it in in a weekend. It was a relatively short time just to get the equipment in. The InfiniStream we took uses attached storage. It has an IPMI which wasn't mentioned in the original deployment documents. I managed to eventually find out what the base system is, a Supermicro server base. I then managed to get documentation around how to configure it and what the default IP address is for those. I had to configure that, because there are certain things that you can't do if you don't have that to update the firmware of your storage array — shut it down, restart it, those types of things. That wasn't on the original one-page install glossy.

It's a lot different than what we're used to in terms of the various sections that you need to configure. The workflow for some of the stuff could use some improvement. It sometimes feels like the system is silo-based or sectional-based, and that it was then all put in one system. There isn't just one place you can configure your application site or a quick-start "how-to." If you want to configure an application and then get it on your dashboard or your service views, it would be nice if it gave you an auto wizard which would say, "You want to configure an application? Okay, next." You would fill in what is required, click "next" to get you to the next step and keep on following the same workflow so that you can't really deviate. If you know which sections you want to configure, maybe then you would configure it manually, but a wizard-based workflow that's set out to be followed would be good.

As we learn stuff we've transferred the knowledge to our client and they have learned themselves as well, playing with the system. As they run into a workflow issue, then we try to assist or we contact our sales engineer to ask if there is a better workflow for some of this, and how to get to the pane that we would want to be on more quickly. For some of it, there was a quicker way, and for some of them the system is built in such a way that there is not a quicker way to get to some of the views.

It requires quite a lot of staff to set up and manage the tool; there's quite a learning curve. What we normally like to do is load it offsite, deploy the system, prepare it properly, get the base configuration on, and load at least some of the applications, but we didn't have the luxury of that kind of time. It took us a bit of time compared to what we've been used to on the TruView. We tried to configure the applications, but it's not quite the same. In workflows we've missed things here and there, things like going to a different view to associate applications to a site or an interface. We missed that at times. That's where the automated workflow wizard would help a lot, to make it easier for anyone to use the system, to climb in and start configuring it.

We're still busy streamlining and working on our alerting, to get those properly set up. NETSCOUT, from their side, is PoC-ing the VAR service to assist us for three or six months in streamlining the system, see where we're running short, and also to do system checks and see what else they're going to have to improve on the system.

We're not really a proactive system yet because we're still trying to define some of the things. The system is not at a scale where it can monitor each and every thing. There are a lot of things in the environment that we learn and get to know of on a daily basis, as they deploy new things. There are also things that we've not heard of because some of the environments are still silo-based.

I don't know what the client is looking at, because they can acquire from other vendors.  Because we're part of the networks team, we're more focused on the actual network component.

It's not an easy system, it's a very technical system. There are some views that you could get for a management or objective overview. Even our client mentioned that it's more a technical tool. That comes back to the workflows and the drill-down and the amount of time you spend to drill down into a scenario. That sometimes makes it too long in a real-time troubleshooting scenario or focus session. That makes it a bit difficult. If there's an outage in the environment they might start looking at you because they're waiting for you to provide information. I assume that would improve a bit when VAR service comes on board to show us what we're missing and how we can set up scenarios or extra alerting on the system to improve drill-down and the time to respond to or the time to resolve issues.

It does auto-discover some of the stuff. I don't think we've really used everything that's available. We've used some of the auto-discovery for URLs or web-related links, as it picks them up. We've used some of those and then we further define it. I'm not sure if there's another way or extra things that can auto-discover. Normally we'll get an application and environment from the client, and then we'll define it from there, or we'll use TruView to look at the NetFlow data to see what ports, for example, are being used. Then we will interact with the client to further see what is there. Or we can use nGenius' packet data and pull down what ports are being used from there. Then we can go back to the client and say, "You said port 123," for example, "is being used. We see 123 and another port. Is this other port also part of your application, or what function does it have in your applications?"

As for whether nGeniusONE helps us to get to root cause quickly, it's "yes" and "no." It fits in more with some of the workflows that we're still learning or we may not have the correct workflow. We've learned quite a lot over the last year or so but there is some room to improve, or it might be something that we don't know about; how to navigate a bit faster and better. One thing the client did say, if you compare it to TruView, is that with TruView you get to most of your issues in three clicks. In nGenius you need a few more clicks just to get to where you want to be. And sometimes you need to take a different route through the system to navigate to a different view.

When it comes to seeing a measurable decrease in mean time to repair, or mean time to know, there might be some workflows we're missing, that we don't know. We've used the system now for just over a year, and we're constantly learning new ways to configure the system and new workflows and how to improve our troubleshooting time. But compared to our older TruView system, it takes a bit longer to navigate to certain sections of the system or down to where we want to be, to the packet data, or to drill down into some of the applications.

We use nGeniusONE for Microsoft Teams. There is a case that we want the VAR service to take on for us to tie up some of the communications from external to internal Teams calls as they pass through the firewall. We're going to look at that to see what the VAR can assist us with. The client needs to expand on some of its TAP-ing visibility as well when, in the near future, they change their design.

As far as I know the solution has not enabled us to consolidate tools, because our client uses various systems. An example is Dynatrace as an internal banking application that they use for Layer 7 and agent-based monitoring on some of the servers and applications. And we still use TruView. Then they're constantly expanding to see where they can add something to fill in gaps. They're busy PoC-ing ThousandEyes to get some visibility on a different front. On the network side, we monitor the network components to clear that and make sure that it runs, or assist if there are notable response-time issues, to try and resolve where the issue would be located.

From our company, which is from the vendor side, we have about five or six users. In our client's organization we're expanding every now and then, but currently there are about 50 users, maybe more.

Because of COVID, everything is standing still currently. We started building grids and consolidated views to see what we can display on the centralized screens to improve visibility for Office 365, and those types of things. We would like to get that extra NOC-type of visibility, or an overview of the environment for certain sections. The client's strategy was that the more people that have access to the system, the more people will call us to inform us that there's something wrong in the system or in the environment, before that system even alerts us. The user base plays a big role in how the organization runs.