Usage guide: Slow PC troubleshooting

Introduction

This workflow will automate the process of troubleshooting common causes of percieved slowness on a device. Using a combination of remote actions and campaigns this guided walkthrough will perform checks on a target device and give advice to the user if an issue is discovered. Where possible, remediation remote actions are run on the device, after requesting permission to proceed. An ITSM ticket is logged against the device at the start of the process, and it is then updated with the actions taken and measurements recorded, before being closed at the end of the process.

Ensure your workflow is properly configured by following the steps highlighted in its configuration guide:

Configuration guide: Slow PC troubleshooting

Workflow Structure

This section describes the key steps in this workflow. The first step is an introductory campaign where the user is asked to confirm that their device is running slow and to confirm that checks can be made. If permission is granted then an ITSM ticket is raised against the device. The first check is for the device location. If the device is onsite then the next step is skipped. If the device is remote it is likely to be connected via Wi-Fi and if the connection is poor this could be a contributing factor in the perceived slowness of the device.

  • The remote action “Get Wi-Fi signal strength) is run on the device and the “WiFi strength in dbm” output is checked.

    • Below -0.70 dBm the connection is considered poor and a custom campaign “Wi-Fi self help” is launched advising the user to troubleshoot their connection.

    • Above -0.70 dBm the connection is considered OK and the workflow continues.

  • A customized campaign “Disk cleanup request” is now launched and user is asked for permission to clear temporary files from their device.

    • If permission is granted, then the remote action “Disk Cleanup” is run with a “Deep clean” parameter to clear the Recycle Bin and also temporary internet files.

    • If permission is denied, the workflow continues

The next step is a check for the device operating system. At this point the workflow branches as the troubleshooting process is different for macOS and Windows devices.

macOS

  • The remote action “Get macOS memory pressure” is run on the device and the “Memory pressure” output is analyzed.

    • If the memory pressure is above 70 a custom campaign “Memory pressure advisory” is launched and the user is advised to close some applications to improve the running of their device.

    • If the memory pressure is below 70 the workflow continues

  • The remote action “Get macOS updates and restart information” is launched and the outputs “Days since last restart” and “Pending updates need restart” are checked.

    • If there is a pending restart following updates, or the device has not been restarted in the last 14 days then a custom campaign is run asking for permission to restart the device.

      • If permission is granted then the remote action “Restart macOS device” is run on the device

      • If permission is denied, the workflow continues

    • If a reboot of the device is not necessary the workflow continues.

  • The ServiceNow ticket is updated with the amount of disk space cleaned, and the memory pressure percentage. The ticket is then resolved.

  • A campaign “Self help complete” is launched to advise the user that the process has now been completed. They are advised to log a ticket if their device is still slow.

Windows

  • The remote action “Get battery status” is run on the device and the “Power plan” output is analyzed.

    • If the power plan in use is not “Balanced” then a custom campaign “Power plan advisory” is launched the user is advised to change their power plan to potentially increase the performance of their device.

    • If the “Balanced” power plan is in use the workflow continues.

  • The remote action “Get default browser” is run on the device.

  • The remote action “Get browser tabs” is run on the device using the “Default browser” output from the previous RA.

    • A browser tab count of over 30 is considered bad, in this case a custom campaign “Browser tab advisory” is launched and the user is advised to close some tabs to improve the performance of their device.

    • A browser tab count of under 30 is considered acceptable, in this case the workflow continues.

  • The remote action “Get Windows disk information” is run on the device and the output “Disk type” is recorded

  • The remote action “Get disk health” is run on the device and the outputs “SMART status” and “Write errors uncorrected” are recorded.

  • The remote action “Test pending reboot” is run on the device and the outputs “Days since last boot” and “Pending reboot” are checked.

    • If there is a pending restart following updates, or the device has not been restarted in the last 14 days then a custom campaign is run asking for permission to restart the device.

      • If permission is granted then the remote action “Restart Windows device” is run on the device

      • If permission is denied, the workflow continues

    • If a reboot of the device is not necessary the workflow continues.

  • The ServiceNow ticket is updated with the amount of disk space cleaned, the disk type, the SMART status, and the number of uncorrected write errors. The ticket is then resolved.

  • A campaign “Self help complete” is launched to advise the user that the process has now been completed. They are advised to log a ticket if their device is still slow.

Related topics

Nexthink provides out-of-the-box dashboards to diagnose common IT issues.

  1. Select Alerts and Diagnostics from the main menu.

  2. The dashboards appear under the Diagnostics section of the navigation panel.

Last updated