Usage guide: Slow PC troubleshooting
Last updated
Was this helpful?
Last updated
Was this helpful?
The Slow PC troubleshooting workflow pack enables EUC teams to:
Save L1 support time from the automation of simple L1 issues
Automate incident management to save time and record performed actions
Prevent future tickets by performing a general health check of common issues.
In addition, this library pack offers preconfigured remote actions, self-healing, campaigns, and ITSM ticket updates to take action and record progress
Jump to Use cases on this page to see relevant scenario applications.
Use the library pack content for the following purposes.
The Slow PC troubleshooting workflow pack contains a live dashboard that serves as the starting point of this library pack. It provides visibility into your device landscape to easily identify devices that are potentially running slow.
These devices can then be targeted to receive the workflow, which will guide the affected employee through the troubleshooting process.
In addition to the relevant use cases covered below, you may uncover other troubleshooting scenarios specific to your environment.
The first step is an introductory campaign where the user is asked to confirm that their device is running slow and that checks can be made. If permission is granted, then an ITSM ticket is raised against the device, and troubleshooting will commence
Check the device location. If the device is on site, 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 to 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 to advise the user to troubleshoot their connection.
Above -0.70 dBm, the connection is considered OK, and the workflow continues.
The system launches the "Disk cleanup request" campaign and asks the user 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 temporary internet files.
If permission is denied, the workflow continues.
The next step is to check the device's operating system. The workflow branches as the troubleshooting process is different for macOS and Windows devices.
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 titled “Memory Pressure Advisory” is launched, and the user is advised to close some applications to improve the device's performance.
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 a restart is pending following updates or the device has not been restarted in the last 14 days, 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 will continue.
The ServiceNow ticket is updated with the amount of disk space cleaned and the memory pressure percentage. The ticket is then resolved.
The system launches the "Self help complete" campaign and informs the user the process is complete. They are advised to log a ticket in case their device is still slow.
The first stage of the troubleshooting process involves checking for and fixing corrupted Windows system files. File corruption is checked in two locations: the Windows system folder and the "WinSxS" folder (which contains Windows Component Store files used to support the functions needed for customizing and updating Windows).
The remote action "Invoke system file checker" is run on the device.
The results are checked to determine if WinSxs files have been corrupted.
For both branches (true/false) the results are then checked to determine if Windows system files are corrupted.
If no file corruption is found the workflow continues on the next step.
The remote action is then run again, with parameters configured within the workflow to try and fix either Windows, or WinSxs file corruption, or both.
The remote action "Invoke system file checker" is now run again on the device, and the checking process for WinSxS and then Windows corruption is repeated.
The ServiceNow ticket is then updated. Depending on the result of the checks that follow the second execution of the remote action, this update will either report that file corruption was detected and fixed or that file corruption was detected but could not be fixed.
The workflow will now continue
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 a restart is pending following updates or the device has not been restarted in the last 14 days, 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.
The system launches the "Self help complete" campaign and informs the user the process is complete. They are advised to log a ticket in case their device is still slow.
Nexthink provides out-of-the-box dashboards to diagnose common IT issues.
Select Alerts and Diagnostics from the main menu.
The dashboards appear under the Diagnostics section of the navigation panel.
