Ghostbusting in Real Time for Remote Offices
You’ve just gotten to work when a new support ticket comes in from your company's San Francisco remote office (you’re at headquarters in Boston). Office 365 was running very slowly yesterday. It’s their third help desk ticket this week, and the others are still unresolved in ServiceNow. Your first move is to call the user, only to hear that everything is now fine, leaving you to wonder if this is an isolated incident or a bigger systemic problem. Given that it’s the third ticket this week, you strongly suspect the latter. But how do you find the root cause?
This is a typical support scenario for remote offices, each of which has a different infrastructure. Users at those offices access business-critical applications that are hosted in a wide variety of places, from internal data centers to public clouds to SaaS providers. The other challenge is the intermittent nature of the issue. This ghost issue comes and goes, leaving you unsure how to trap it without knowing its cause or when it occurs.
Most importantly, you’re not there to see what they’re experiencing with these applications. These kind of situations happen every day in enterprise IT, and most of them never get resolved. IT just can’t see the entire application performance path because they no longer control the infrastructure that delivers that application. Applications are now mostly delivered via the WAN, creating a huge dependency on network performance.
Troubleshooting Remote Offices, Then and Now
Here’s how you would typically troubleshoot a situation like the one described above.
- First, try to access the application yourself.
- If it appears fine, check the Office 365 status page for outage reports and history. This page is just reporting the status Office 365 infrastructure, which is critical but not representative of the application’s user experience. It can’t tell you much about the status of the service from San Francisco. The two offices might be accessing different infrastructures or are served up from different clouds.
- Without details from Microsoft, you check your own infrastructure. You log into the firewall to make sure the ISP service is up, which it is.
- You check the status page for the ISP service—Comcast, in this case—and everything looks OK there.
- You test the availability of Office 365 using webpagetest.org, which produces synthetic traffic data from computers around the world, but it’s showing that Office 365 was up the whole time.
- Next, you use a remote desktop or desktop-sharing tool to go into a machine in the San Francisco office to duplicate the issue. Everything looks fine there, too. You run a bandwidth test using Ookla Speedtest, but find no issue.
- Having exhausted your tool set, you leave the ticket open. But after lunch, you get another ticket from a different user in the San Francisco remote office with the same issue.
This is how unresolved tickets pile up. And this is how users get frustrated with IT as a whole. From the user perspective, the lack of clear answers is infuriating. But using legacy application and network monitoring don’t enable IT and Network Ops personnel to answer the pressing questions users have about their spotty applications. Traditional monitoring tools gather data from devices in your infrastructure (usually via SNMP), but when applications are delivered over the WAN, you can’t access that information.
Because these issues are sporadic, it is unlikely that the person troubleshooting the problem will access the same system as the user at the exact time the problem is occurring. You need continuous monitoring running so you can trap the ghost issue. Continuous monitoring provides other benefits, such as separating app and network issues and holding vendors to their SLAs.
Application and network performance are essentially location-specific problems. You need a tool that monitors performance from where your users live and work. That’s why we designed AppNeta specifically for these issues. For remote locations, AppNeta proactively monitors the actual end-user experience. AppNeta customers deploy hardware or virtual Monitoring Points at locations where users are accessing business-critical applications.
Once a Monitoring Point is up and running, it instantly starts recognizing applications in use and provides details about who is using which applications and what they’re experiencing. You can then set up active network monitoring to key applications to get continuous data on performance from where your users actually are.
Finding the Root Cause of Remote Office Issues
Let’s troubleshoot our Office 365 problem with AppNeta. First, you would have been notified about the problem at the remote office when performance thresholds were exceeded—before the user put in a ticket. And rather than checking app status, you’d log into AppNeta Performance Manager via a web browser and check out the San Francisco office in the Usage analysis. There, you’d see the applications in use, and see in the history which applications were in use when the user reported the problem. You might see, for example, that a large backup that shouldn’t be running during the day was kicking off. Or you’d see that there was a user uploading to DropBox and absorbing the bandwidth.
If Usage doesn’t show anything, you’d move on the actively instrumented applications. You’d see the synthetic application and network tests you’d set up—what we refer to as Experience and Delivery analysis, respectively—from the AppNeta monitoring point to Office 365.
AppNeta’s patented TruPath technology allows you to measure network performance for every step of the application delivery path, whether you own the infrastructure or not. That means you can see issues with your ISP, such as if you aren’t getting the bandwidth you contracted for.
With AppNeta, you can also monitor the performance of each internet connection you’ve attached to an SD-WAN device, along with the performance of the SD-WAN optimized network path. All this means faster resolution of problems and happier users. So if you’ve moved to SaaS-delivered applications, or are planning to, make sure you’ve got the tools in place to maintain visibility.
Filed Under: performance monitoring