Basic troubleshooting with the remote worker agent

Playbook & Use-cases
1

Overview
In this post, I want to provide some basic troubleshooting steps to figure out remote end-user experience. I will simply list the series of steps that needs to be followed to identify the root cause. Should one step help identifying the root cause, then you can stop at that step. If that step doesn’t provide evidence of that being the root cause, then go to the next step. Also, this procedure covers most of end-user complaints that tend to be related to WiFi, ISP, VPN, and LAN. There may be some other cases not covered here.

Situation
Let’s assume that you receive complaints from a remote user and you were assigned a ticket to investigate the root cause. We also assume that your NetBeez dashboard was not setup to send alerts and notifications when an incident is detected, so you are mostly relying on a reactive type of support. We also assume that the remote user is running a NetBeez remote worker agent.

Procedure

  1. Go to the NetBeez dashboard in the Agents section and locate the user based on their laptop name or some other scheme you implemented to name your users on the NetBeez dashboard.

  2. Click on the agent and inspect the status of the tests running. Here there are three possible cases:

  • Case 1 - Only one test is red or yellow and corresponds to the application or service that the user complained about; if so go to the Targets tab and confirm that there’s an incident open for that application; if that’s the case, escalate the ticket to the application team, in case of internal application, or provider, in case of SaaS.

  • Case 2 - Most of the tests are orange or red, the user is connected with WiFi: make sure that the signal quality is at least more than 85% (Windows) or the MCS is more than 5-6 (Mac). Check also the signal strength and make sure that is at least less than -70 dBm.

  • Case 3 Most of the tests are orange or red, the user is connected via Ethernet and/or WiFi is not the issue: Check the gateway test, and make sure that there’s not packet loss or high latency; if it does, then ask the remote user to reboot the gateway; if the gateway test is clean, then check the speed test data and make sure that the user didn’t see a sudden drop in download/upload; if needed also run an ad-hoc speed test to verify current speed; in general speed test should report at least 2 Mbps for upload and 10 for download.

  1. If the problem is with applications that are accessed via VPN, then check the tests that are configured to go via the VPN tunnel, and make sure that they are green. If those are the only tests red or orange, then compare the results with other VPN users, to verify if it’s only located to this user or to all VPN users. Share the information with the team that supports the VPN.

  2. If you still haven’t found the culprit, then review the CPU and Memory usage real-time and historical and make sure that the remote workstation/laptop is not overwhelmed; as a good heuristic, make sure that the CPU is not on average more than 80% of utilization.

2 Likes