We recently deployed Windows DirectAccess for one of our clients and wanted to monitor the deployment. In particular I was interested in the number of active DirectAccess sessions and if any errors were detected. The Remote Access MMC snap-in (in Server 2012 R2) has a great status page that runs down all of DirectAccess’ components and reports any errors that are detected.
You can basically assume that if any of these are red you’re going to have an issue. With PRTG the number of components in an error state could be a channel in a sensor which we could monitor and report on (for instance if the number of errors is greater than 0). Similarly another channel could be the number of sessions.
DirectAccess comes loaded with a few PowerShell cmdlets for monitoring and reporting on its status. In particular Get-RemoteAccessHealth and Get-RemoteAccessConnectionStatisticsSummary will give you a lot of information. In order to make that data useful for PRTG we want to strip that output down from something like this (the raw output of Get-RemoteAccessHealth)
To literally just the number of components with a HealthState of “error”. This gives us our first sensor channel, “error count”. Our second channel is similar, I just want know how many active DirectAccess sessions we have which involves stripping down the output of Get-RemoteAccessConnectionStatisticsSummary
To just the number of TotalDAConnections.
The full PowerShell script is below
This results in a PRTG sensor with the following channel setup
The key lines here that give PRTG its value for the channels are
The first is getting our error count. As we move down the command we’re filtering the output of Get-RemoteAccessHealth for the HealthState column and then looking for any matches on the value “Error”. Both measure and count are needed to just return in integer, measure by itself returns this.
Get-RemoteAccessHealth is returning a table and PowerShell makes it pretty easy to search through it like you might search for something in Excel. Get-RemoteAccessConnectionStatisticsSummary is a little trickier. Its returning a list and if you try to use the same method of stripping its output as Get-RemoteAccessHealth that won’t work. However Select -ExpandProperty will. This took me a while to figure out until I piped the output of each command through Get-Member which reveals the Object-Types being returned. This article was very helpful during that process.
The rest of the script is pretty standard fare for PRTG’s custom XML sensors (a lot of great examples can be found here). The entire script is returning back to PRTG something that looks like this
Which is just the XML formatting that PRTG needs to construct a sensor. The try statement is used to catch any errors since PowerShell can be annoying to get setup for remote monitoring and I wanted to make sure that any issues with the sensor itself were handled by PRTG instead of the sensor silently failing (for instance returning 0 for a channel, which wouldn’t necessarily set off any alarms but might happen if one of our cmdlets failed)