How to use PowerShell to troubleshoot Windows desktops
When IT uses remote access to troubleshoot a user's desktop, it prevents the user from working. PowerShell, however, allows IT to fix a problem without disturbing the user.
As an IT professional, it is common for you to use remote connection tools such as TeamViewer to connect to end-user devices and troubleshoot issues. This is a fine way to address problems that stop users from performing necessary and time-sensitive tasks.
A remote connection, however, is invasive to end users and typically forces them to stop working to let you investigate the issue. As a result, if end users encounter issues they can continue to work through, it may be preferable for you to connect to a user's device using a Command-line interface (CLI), such as PowerShell, to troubleshoot an issue.
Using a CLI allows users to continue to work while you troubleshoot. If you know how to use PowerShell, you can troubleshoot a Windows desktop either locally or remotely using native cmdlets.
How to use PowerShell remoting
The most common PowerShell commands are Enter-PSSession and Invoke-Command. Both use Windows Remote Management in the background to connect and run commands or scripts.
For instance, to check if chrome.exe is running on a remote machine, you can run:
Oftentimes, when troubleshooting client machines, it is necessary to view and kill Windows processes that are running.
For instance, a user may need to kill outlook.exe because the window is not responding. Those who know how to use PowerShell to do this will enter Stop-Process -Force.
PS C:\> Stop-Process -Name outlook.exe -Force
If you must find processes that a particular user is running, you can filter through the UserName property. In this example, you want to find any process running under Dan:
Imagine a client machine has an issue connecting to a specific web application on port 8080. One easy method to find out if that machine can connect to that port is to use the cmdlet Test-NetConnection. This cmdlet tests the connection against specific ports to see if they are listening on remote endpoints.
The test failed on port 8080 for the hostname testserver. This cmdlet also performs a ping test to see if the Internet Control Message Protocol can reach the port. This helps ensure the machine is accessible on the network.
Work with software installations
When you use the Windows graphical user interface, you can view installed applications with the Add and Remove programs function. In PowerShell, you can do this with the Get-Package command.
To view any software installed containing the name Adobe, run this command on machines running PowerShell Version 5 or above:
PS C:\> Get-Package -name *Adobe*
Name
Version
Source
Provider name
Adobe CS6 64-bit
1.2.0
C:\Program Files (x86)\Adobe\...
Msi
In addition, you can uninstall software with the Uninstall-Package command.
The Windows event log allows you to see the events logged on a given system. In PowerShell, the Get-WinEvent cmdlet is the best way to do this. Even better, with a CLI, you can search for what you want easier and faster than you would using Windows Event Viewer.
With a CLI, you can search for what you want easier and faster than you would using Windows Event Viewer.
In the following example, you are trying to find any errors in the application log for events in the last hour for Group Policy Services. To do this, you can use a hash table with the logname -- application -- providername -- Group Policy Services -- and the start time. You only want to see the time the event was created and the message in it, so you use the Select-Object cmdlet.
TimeCreated : 12/4/2018 2:36:07 PM Message: The computer 'test' preference item in the test {69F49340-0D18-434D-A112-F82A688D1E42}' Group Policy Object did not apply because it failed with error code '0x80070424. The specified service does not exist as an installed service.' This error was suppressed.
Performance counters
When it comes to troubleshooting performance issues in Windows, counters have long been the method for getting the data you need to fix an issue. If you know how to use PowerShell, you can not only view what counters are available, but you can also start them with the cmdlet Get-Counter.
To view all the possible counters on a local system, run:
One interesting counter is User Input Delay per Process, which provides the number of milliseconds a system takes to respond to a user interacting with an application.
\\TestMachine\user input delay per process(0:6980 <outlook.exe>)\max input delay: 0
\\TestMachine\user input delay per process(0:2992 <networklicenseserver.exe>)\max input delay : 0
\\TestMachine\user input delay per process(0:3992 <svchost.exe>)\max input delay : 0
Now you can find the counter sample -- process name -- to use for your counter. In this example, you use outlook.exe and a PowerShell object to make viewing the samples easier: