How do you go about troubleshooting a problem?
There are two ends to the spectrum of solutions to troubleshooting a problem. At one end you have the click and pray brigade who will manically click round all the menus on all the tools they can think of using to try and find something that will fix the problem. I’ve watched people like this in action and while it looks like they’re working incredibly hard in reality they are achieving nothing – in fact less than nothing because their manic activities get in the way of actually discovering a solution to the problem.
At the other end you have the people who have a process – usually manual – to work through solving the problem. In this case they methodically work through the process eliminating possible issues until they arrive at the cause of the problem. The classic problem solving routine for network connectivity is a classic example:
– ping the loop back adapter 127.0.0.1
– ping the local IP address
– ping the default gateway
– ping one or more routers
– ping destination address
You find out where the problem lies and can then address how to fix it.
One problem with the second approach is that it requires experience. Experience in administration and troubleshooting and keeping calm and methodically working through the process when people are shouting at you for a solution. Junior admins usually don’t have this experience.
For a number of versions (I can’t remember when it first appeared) Windows PowerShell has carried a Troubleshooting module – its NOT available in Powershell v6.
There a number of troubleshooting packs in C:\Windows\Diagnostics\system\
Name
—-
AERO
Apps
Audio
BITS
BlueScreen
Bluetooth
Device
DeviceCenter
HomeGroup
Internet
Keyboard
Networking
PCW
Performance
Power
Printer
Search
speech
UsbCore
Video
WindowsMediaPlayerConfiguration
WindowsMediaPlayerMediaLibrary
WindowsMediaPlayerPlayDVD
WindowsUpdate
You can view the individual packs – for instance
PS> Get-TroubleshootingPack -Path C:\Windows\Diagnostics\system\BITS | fl
Path : C:\Windows\Diagnostics\system\BITS
Id : BITSDiagnostic
Version : 3.5
Publisher : Microsoft Windows
Name : Background Intelligent Transfer Service
Description : Find and fix problems that may prevent background downloads from working
MinimumVersion : 6.0
PrivacyLink : https://go.microsoft.com/fwlink/?LinkId=534597
SupportsClient : True
SupportsServer : True
SupportsX86 : True
SupportsAmd64 : True
SupportsIA64 : True
RequiresElevation : True
Interactive : True
RootCauses : {Service registration is missing or corrupt, Check for missing or corrupt files, Some security
settings are missing or have been changed}
FoundRootCauses :
Interactions : {Check for missing or corrupt files, Restart your PC}
ExtensionPoint : #document
And you can fire off the troubleshooting pack
PS> Get-TroubleshootingPack -Path C:\Windows\Diagnostics\system\BITS | Invoke-TroubleshootingPack
Initialising the diagnostic -1
Check for missing or corrupt files
:
Checking security descriptor… -1
Starting Bits service -1
No problems were detected
In this case the BITS service was stopped and the troubleshooting pack restarted it to solve the problem.
The major issue with the TroubleShooting module is that there are only a very limited number of troubleshooting packs as you’ve seen. There’s no documentation that I’ve been able to find that deals with writing new packs.
One of my recent talks at the PowerShell Summit was about troubleshooting Powershell WinRM based remoting. I wanted to show how to automate troubleshooting as well as how to actually troubleshoot remoting issues.
I eventually had the idea to use Pester – the code testing module. I’ve used it to test code and infrastructure but I’d never seen anyone talk about using it as a general troubleshooting tool.
Next time I’ll show you how to use Pester to create an expandable troubleshooting tool that can be adapted for almost any scenario.