It has a steep learning curve, not because the product is hard to use but because to actually deploy application visibility control, you need to have a fairly in-depth understanding of networks, network flows, and application visibility control. In my case, it was an NBAR deployment, which is the Cisco Layer 7 DPI. You need to understand quality of service and how that actually all ties in. To be able to use the product effectively, you need to be a fairly advanced network engineer.

Once you've got it set up, you can then give that information to the service desk and the service desk can immediately see what's happening, without having to annoy me. Once it was set up and deployed, we were able to give it to everyone within the IT infrastructure, and the service desk, and they were able to find the problems on their own, straight away, without having to deal with the network team.

The initial deployment to get it set up was a matter of a change to include NetFlow export on all my WAN routers and my internet routers. The deployment of the appliance took about half an hour. But it was the going around and configuring all the routers that took up most of the time. With all the configuration it took a very long time. In a production environment, you can't just go around and make changes on devices. I had to go and present the change to the change advisory board. There was all the paperwork associated with a particular change. And then rolling it out across the entire production environment, where I had 80 branch sites that were dual MPLS, and 40 or 60 non-MPLS Ethernet-based connection sites, it took about 100 hours. But that is not a reflection on the Plixer solution, that was a reflection on the way that my system internally works with change and the time it takes to actually do things.

The strategy was that once we got it up and saw flows in there, we then went and deployed it globally on all our routers. Over the years we gradually made changes. Once a year, we sit down and have a look at our quality of service and application visibility control. That's a pretty intensive process of understanding what sort of applications are running in the environment and then categorizing them through the quality of service side of the house. We then look at what we want to be monitoring in detail — in particular, with response time for applications or real-time flows in the environment, and fine-tuning our IPFX policies that are deployed on our Cisco routers. That's a little bit time-consuming, but again, that's not a reflection on the Scrutinizer.

The initial setup for Plixer Scrutinizer is pretty straightforward, particularly if you know what you're doing because you need some knowledge about networking and NetFlow.

Basic deployment can be completed within one day, so you can see what traffic is coming into your network, then you can also start using the filters and the reporting. You can see basic results within a few days, and good results within a few weeks.

The initial setup was fairly straightforward. I did engage their engineers during the setup to make sure that I was following their best practices. Overall, it's fairly straightforward, not only for the installs but for their updates which are very consistent as well. I don't even think updating takes it offline, except for whenever you have to do a reboot. You're online 24/7 and 365, unless you have to reboot for an update. And then it takes about 15 to 20 minutes to reboot it. It checks itself all over the place.

The full deployment took me about a week and that also involved the configuration and acquiring the sensors. Fixing up the base unit for Scrutinizer took a very short time. I did that in almost an afternoon, four hours or less. What did take some time — and if you do go with Scrutinizer, I will tell you to allocate the time — was that I had 60 devices that I had to go around and configure and get working. It took me a week to get it all dialed in, but that was just making sure that everything was recording correctly and working.

Our deployment plan was to first get the Scrutinizer base unit installed, up, and operating. We tested that by having one device report into it, a device that we were pretty familiar with what it was doing. Once we got that one base unit up and running, we configured the one device so that it was reporting JFlows, because we're using Juniper. Once we were satisfied that the unit was up and was accepting traffic and that we could do what we wanted, I had a total of 63 other devices that I went around to within my organization and pointed them at it.

The initial setup for Plixer Scrutinizer was very, very straightforward. As long as you could export flow data off the switches, and point and direct that flow, the only manual process you have to do is set up the switch to export the data. It was a pretty easy process, once everything was aligned. The client was pretty happy with it.

The deployment time for Plixer Scrutinizer was pretty quick. From the time it was delivered and it was set up, it took two weeks, but that was really on the client. Once the client had all the information needed to set up the solution, it was a very smooth and very quick process.

I rate the initial setup of Plixer Scrutinizer an eight and a half on a scale of one to ten, where one is a difficult setup, and ten is an easy setup.

The initial setup was straightforward because I've used the product in a number of other companies. I'm very familiar with NetFlow. For me, it was rather easy. Then again, it could have been really complex and I would have thought it was easy.

There was really not a lot to get it setup. I would give its construction of maps a bit of a ding for complexity. Trying to get maps and lines to show up so people can look at it and understand what they're seeing was a little on the complex side because their little drawing manipulator is not exactly the greatest. It's like using crayons.

It wasn't a hard product to set up. The hardest part was getting the resources out of VMware to get it set upon. But, that's not their fault. A product like this comes in, and says, "I need this much storage." Then, the people that run VMware freak out, "Why would anything need that much storage?"

We had some challenges with the configuration — that's one of the reasons why we stopped using it.

It was a pretty straightforward setup. I wouldn't call it complex.

The deployment took about four hours. We still expanding on it though.

This is an appliance. It's pretty straightforward. It came already implemented and installed. Our deployment took a couple of hours. The plan was to place it in a location where we could see all the traffic.

The first time the initial setup happened with an integrator, and it was very easy because we just implemented on Windows. After that, we changed to the new version of Scrutinizer, then we just call Plixer in order to do it because there are too many things to take into consideration, especially if we don't want to lose data. This also has room for improvement.

They set it up for us. It was straightforward. Start to finish, we were done in two days because that's how long they were onsite.

The product, Scrutinizer, was simple and straightforward to set up. Where we had trouble was not with the actual Plixer product, but with the sFlow sending. Although the issue wasn't with Scrutinizer, the support was able to help us resolve the issue.

The deployment took two weeks, start to finish. We had a test environment. A large part of those two weeks was setting a test environment up, having to play around with how we send data to Scrutinizer, and the NetFlow data. When we did a pilot, it resolved any problems with Scrutinizer directly. Then, we deployed into the live environment.

The initial setup didn't seem to be that complicated. I found it already implemented, but we did a lot of migration steps. It seems to be quite easy to implement.

If I would have to implement it again, Scrutinizer is not that difficult to implement versus any other appliance. It is more complex to configure the exporters, but there is a lot of current, good documentation on the Plixer site for this.

The initial setup was very straightforward. There's a script that creates the Scrutinizer. It creates the network management tool. They have what you would call it a Wiki page, a set of enthusiasts, which tells you exactly how to configure each of the different types of devices to report to Scrutinizer. All you do is create the application, set up each of your devices to report to Scrutinizer, and then you sit back and wait for the data to flow in. The analysis tool then analyzes that data as it comes in.

Deployment time depends on how many end devices there are. In terms of building up the management station, I can do that in half-an-hour. It takes a couple of minutes to add the relevant config lines to each end station.

The implementation strategy was to get information from the core and distribution devices. That covers pretty much all of the traffic associated with our network. All our core and distribution devices are reporting on the traffic they see and then we analyze that data as it comes in.