Usage guide: Connectivity assisted troubleshooting

This page outlines various ways to use the pack, including use case examples.

Administrators can refer to the Configuration guide: Connectivity assisted troubleshooting to set up and customize the installed content.

The Connectivity assisted troubleshooting library pack enables EUC teams to:

Improve the resolution of L1 tickets related to common network connectivity issues.
Facilitate L1 troubleshooting with ITSM ticket updates at each stage of the workflow.
Keep employees in the loop with targeted MS Teams messages.

In addition, this library pack offers preconfigured remote actions, self-healing, and direct MS teams messages to take action and drive awareness.

Library pack uses

Jump to Use cases on this page to see relevant scenario applications.

Use the library pack content for the following purposes.

Visibility

The Connectivity assisted troubleshooting workflow is the starting point of this library pack. It provides an out-of-the-box workflow that can be triggered manually through Amplify and/or device view to perform basic connectivity checks on a device and facilitate connectivity troubleshooting for L1 agents.

Use cases

In addition to the relevant use cases covered below, you may uncover other troubleshooting scenarios specific to your environment.

Identifying devices on public remote networks with VPN issues

This troubleshooting process will most likely commence from a logged ticket to a service desk or an active call with an L1 technician whilst creating an ITSM ticket.

The workflow can be launched from Amplify, or directly from Device view. In both cases, the ITSM ticket reference should be entered as a parameter.

The first step in the workflow is to take the ITSM ticket reference and use it to retrieve the ticket system IT from ServiceNow.

If the System ID is retrieved successfully, the user will receive an MS Teams message asking them to confirm their onsite or remote device location. The troubleshooting process for both choices is similar, but the advice that can be provided and the actions that the user can take to resolve issues differ. In this use case, the user is connected remotely.
The user is asked to confirm whether they are at home or in a public space. In this use case, they are in a public space.
The workflow will now determine from the device properties that it is connected via Wi-Fi and the remote action "Get Wi-Fi signal strength" is run on their device.
The workflow will now check the device's Wi-Fi signal strength. If it is OK, the workflow continues. If it is poor, the user will be sent a message advising them to change networks and/or locations if possible. In this use case, the Wi-Fi signal strength is not the issue.
The ITSM ticket is updated.
The results of the remote action "Get Wi-fi signal strength" are analyzed for signal congestion.
If either co-channel or adjacent congestion is discovered on a public network, there are limited options to resolve this issue. However, the user will receive a message asking them to change networks or locations. In either case, the ITSM ticket is updated. In this use case, no congestion is found.

The next step is to run the remote action "Get network speed."
The first check is to see if the Web RTT threshold has been breached. If so, this would indicate a generally slow network at the router level. In this use case, the Web RTT is within parameters.
The next check is to see if the Business Web RTT threshold has been breached. This condition is true in this use case. The disparity between Web and internal network speeds may indicate a problem with the VPN installed on the device.
The user receives a message advising them they may have a VPN issue. They are asked to try reconnecting and/or re-authenticating.
The ITSM ticket is updated with this information.

The L1 agent handling this ticket can now follow up with the user to see if they have resolved their connection issue. If not, they will have the possibility to run the Zscaler troubleshooting workflow on the device.

Identifying devices on remote home networks with Wi-Fi congestion

This troubleshooting process will most likely start with a logged ticket to a service desk or an active call with an L1 technician while creating an ITSM ticket.

The workflow can be launched from Amplify or directly from Device view. In both cases, the ITSM ticket reference should be entered as a parameter.

The first step in the workflow is to take the ITSM ticket reference and use it to retrieve the ticket system IT from ServiceNow.

If the System ID is retrieved successfully, the user will receive an MS Teams message asking them to confirm their device location; onsite or remote. The troubleshooting process for both choices is similar, but the advice that can be provided and the actions that the user can take to resolve the issues differ. In this use case, the user is connected remotely.
The user is next asked to confirm whether they are at home or in a public space. In this use case, they are at home.
The workflow will now determine from the device properties that it is connected via Wi-Fi and the remote action "Get Wi-Fi signal strength" is run on their device.
The workflow will now determine the operating system running on the device. If it runs Windows, the remote action "Get Wi-Fi information" is run on the device to retrieve information to add to the ITSM ticket in Step 7.
The workflow will now check the Wi-Fi signal strength of the device. If it is OK, the workflow continues. In this use case, the Wi-Fi signal strength is poor. The user will be sent a Wi-Fi advisory message with suggestions to try:
- Using a wired connection (e.g., network cable).
- Moving closer to the router.
- Placing your router in an open and central spot.
- Switching between 2.4 GHz and 5 GHz networks.
The ITSM ticket is updated with the information that the Wi-Fi signal strength is poor. In addition, the Wi-Fi band and channel (obtained from the RA 'Get Wi-Fi information') are added to the ticket in case action is taken later to talk the user through making changes to their connection.

The results of the remote action "Get Wi-fi signal strength" are now analyzed for signal congestion.
In this use case, Wi-Fi co-channel congestion is detected. The user is sent a message to advise them of steps that they could take to resolve this.

Your Wi-Fi network seems congested. Are you able to switch off devices (XBox, Alexa etc) that could be interfering with your connection?

The ITSM ticket is updated with this information. The workflow continues with checks for network speed, but this is covered in the alternative use case: Identifying devices on public remote networks with VPN issues.