header image

Troubleshooting #2

Posted by: | April 27, 2018 Comments Off on Troubleshooting #2 |

Last time I covered the PowerShell Troubleshooting pack. This time in Troubleshooting #2 I want to show you how to use Pester when troubleshooting.

 

When you’re troubleshooting you ideally want to follow a repeatable process so that you can do it again if necessary and teach others to do the same task.

By wrapping the troubleshooting tests as Pester tests you achieve these aims.

 

If you’ve not used Pester its a PowerShell module that was originally conceived for performing unit tests on your code. You can use Pester for testing your infrastructure is correctly built and configured as well.

 

I created a set of Pester tests for various scenarios where remoting has gone wrong. For example

Describe ‘Listener’ {
## tests listener available
It ‘Listener is available’ {
Test-Path -Path WSMan:\localhost\Listener\listener* |
Should Be $true
}
}

 

tests if the remoting listener is available

and

Describe ‘Port’ {
## tests listening on correct remoting port
It ‘Remoting Port is 5985’ {
Get-Item  “$path\Port” |
select -ExpandProperty Value |
Should Be ‘5985’
}
}

 

tests the port that remoting is using.

 

I wanted the troubleshooting script to stop when it hit a problem so I used a second script to execute the tests. Normally  Pester would execute all tests in a file.

$tests = ‘WinRM’, ‘Listener’, ‘Listener Enabled’, ‘Transport’, ‘Address’,
‘Port’, ‘EndPoint Exists’, ‘EndPoint Enabled’, ‘Firewall Enabled’, ‘Firewall Allows’,
‘Remoting Enabled’

$data = foreach ($test in $tests) {
$result = $null
$result = Invoke-Pester -Script @{Path = ‘.\RemotingTests.ps1’} -PassThru -TestName “$test” -Show None #-EnableExit

$props = [ordered]@{
‘Test’ = $result.TestResult.Name
‘Result’ = $result.TestResult.Result
‘Failue Message’ = $result.TestResult.FailureMessage
}
New-Object -TypeName PSObject -Property $props

if ($result.FailedCount -gt 0) {break}
}

$data | Format-Table -AutoSize -Wrap

 

List the tests I want to run and foreach test run it. Output the results of the test and if the test failed break out of the loop and dump the results to screen.

 

if everything works you see something like this

PS>  .\Test-Remoting.ps1

Test                        Result Failue Message
----                        ------ --------------
WinRM should be running     Passed
Listener is available       Passed
Listener is Enabled         Passed
Transport is HTTP           Passed
Address is *                Passed
Remoting Port is 5985       Passed
End Point Exists            Passed
EndPoint is Enabled         Passed
Firewall rule is enabled    Passed
Firewall rule set to Allow  Passed
PowerShell Remoting Enabled Passed

 

If at any stage the test fails the testing process stops and you get a display showing the tests that passed and a message explaining the test that failed.  You can fix that and then rerun.

 

The code is available at

https://github.com/RichardSiddaway/Summit2018TroubleShootingRemoting

 

There are also a number of scripts that break remoting so you can test the methodology. For each breaking script there is the corresponding fix. The demo script I used in the talk is also available.

 

Its currently a proof of concept for the Summit talk but I think the approach has strong possibilities as troubleshooting methodology that could be applied to many troubleshooting scenarios.

 

Enjoy, use and adapt to meet your needs

under: PowerShell

Comments are closed.

Categories