Monitoring DirectAccess with Kemp


DirectAccess is a wonderful remote access solution highly appreciated by end-users, happy they are to do not have to understand how it works, it just work. On the other side, we have the network team that is not really happy when they discover that monitoring DirectAccess can become complicated, especially for HLB deployments.

From an HLB point of view, DirectAccess gateways are only HTTPS endpoints. If they respond with an HTTP 200 response code, it means that it’s up and running. In reality it’s much more complicated. DirectAccess rely on multiple components. If a single one come to be unhealthy, DirectAccess is no longer able to operate properly. In many deployments, customers of mine chosen to deploy DirectAccess in HLB scenario such as F5 or Kemp. Those appliances are able to check DirectAccess gateways availability by checking IPHTTPS endpoint. Not easy to monitor.

How to monitor DirectAccess health?

It’s a good question. Microsoft provide the Remote Access Management console, some Powershell Commandlets and a Management Pack. From HLB solution vendor hey only have HTTP response. It appear to be complicated because many network teams consider that they have to discover information by their own way.

It’s time to consider another approach. If HLB solution cannot evaluate the health status of a DirectAccess gateway maybe DirectAccess gateway can provide this information to the HLB solution. Have a look at Exchange 2013 Managed Availability. Exchange 2013 generate probe pages to be used by load-balancer solution. If they can reach the probe page, status is OK. It’s a very interesting approach.

Let’s start see how we can develop the same approach with DirectAccess. If we have a look at the Get-RemoteAccessHealth Powershell commandlet, we got almost all we need. In example bellow, I just filtered relevant components to be monitored :

Get-RemoteAccessHealth -Verbose | Where {$_.HealthState -ne « Disabled »} | Format-Table -Property Component, HealthState – AutoSize



That was only the beginning. While writing this article, a valuable MVP colleague pointed out that we don’t need to consider Network Location Server availability because if it’s not available, it does not disrupt service offered to end-users located outside company building (it’s another problem for users located on corporate network). So we will exclude this component from the tests. Here is the test we will be using to monitor DirectAccess :

Get-RemoteAccessHealth -Verbose | Where {($_.HealthState -ne « Disabled ») -And ($_.Component -Ne « Network Location Server ») -And ($_.Component -Ne « Server »)}



Note : Server was excluded from the list because it does not provide a relevant information for monitoring / troubleshooting.

Once we have relevant monitoring information, next challenge is to provide this information in a comprehensive form for a HLB solution. It’s too complicated to write rule to parse this content, that’s why I was considering the Managed Availability feature of Exchange 2013. As I’m not a dev-guy, I know I could not develop a solution like this. My approach was a little bit more basic :

  • Status is OK : Create a probe page to be monitored by the HLB solution
  • Status is not OK : Delete the probe page to be used by the HLB solution

This approach worked, but it was not as elegant as the Managed Availability feature of Exchange 2013. After some discussions with a colleague of mine, he pointed out the availability of a Powershell commandlet for Kemp load balancers. While reading the Kemp documentation, I discovered how easy it was to query and change configuration in Kemp LoadMaster appliance with just some PowerShell commands. If Kemp cannot consume monitoring information my DirectAccess gateway produce, maybe just more simple to change Kemp load balancer configuration.


The Kemp Approach

Kemp provide a pretty good Deployment guide for DirectAccess. I would like to thanks Richard Hicks, valuable MVP working like me on DirectAccess for this excellent contribution. So it was very easy to build an HLB lab in less than two hours. Diagram bellow only focus on high availability for DirectAccess deployment, you can also use Kemp solution to provide high availability for the Network Location Server.



When we setup DirectAccess in HLB scenario, up to height DirectAccess gateway will share a common configuration and some network information :

  • A virtual Address for the external interface managed by the External load balancer
  • A virtual Address for the internal interface managed by the Internal Load balancer

In Kemp, load balancing is managed with virtual services. That’s the object I will be looking for in my configuration. But first I need to configure the Web Administrative Access in Kemp as illustrated bellow to enable Kemp API access from the Internal network interface.



Now we can start using PowerShell to authenticate against the Kemp appliance with the Initialize-LoadBalancer Powershell command. We just need to build a secure string for the password. Once authenticated, we can test if communication is established with a Test-ServerConnection command.

$KempAPI =″

$KempPort = 443

$KempAdmin = « bal »

$KempPassword = « Password123 »

$SecureString = ConvertTo-SecureString -String $KempPassword -AsPlainText -Force

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $KempAdmin, $SecureString

Initialize-LoadBalancer -Address $KempAPI, LBPort $KempPort -Credential $credential

Test-ServerConnection -ComputerName $KempApi -Port $KempPort



Note : Watch-out, account is case sensitive!!

It’s time to explore virtual services with the Get-VirtualService Powershell Command :

$VirtualServiceName = « DirectAccess-IPHTTPS »

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}




We have here some valuable piece of information. First, we know that external VIP is running and directing HTTPS network traffic to some Real Servers. In my environment, I have two DirectAccess gateway configured in a single HLB configuration. So it’s logic to have two real servers behind the external VIP. Let’s have more details about real servers by exploring the Virtual Service Object :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize



We just need to be more precise, what is the status of the Real server linked to a specific DirectAccess gateway. We just need to know the external IPv4 address of our DirectAccess gateway. Too easy :

$InternetInterfaceName = (Get-DaServer).InternetInterface

$InternetIPAddress = ((Get-NetIPConfiguration -InterfaceAlias $InternetInterfaceName).IPv4Address).IpAddress



Now the magic trick

We know the status of our DirectAccess gateway, we know how to query the status of the external VIP and related real servers. Now we just need to be able to change the status of the real server linked to our DirectAccess gateway. In case bellow, I will be considering that my second gateway is no longer able to service end-users. I will be using the Disable-RealServer Powershell Command to disable the linked real server :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

Disable-RealServer -IpAddress $InternetIpAddress

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}


$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize



Related real service is now disabled on Kemp external load balancer.


Envision the big picture

Before starting developing the big thing, here are the guideline I used to develop my script :

  • Each DirectAccess gateway will be responsible to evaluate its own status (So script will be running on all DirectAccess gateway composing my HLB deployment)

  • Each DirectAccess gateway will be updating only linked real server (We’ve just seen how to get it)

  • Each gateway must manage a « maintenance flag » in order to close service (for patch management for example)

  • All activity must be logged in event logs in order to keep trace of information in monitoring solution such as SCOM

  • Keep the script as simple as possible

  • Script will be relying on Powershell wrapper provided by Kemp

Script is available at this location. It was designed to run as scheduled task on each DirectAccess node involved in an HLB configuration. Script accept the following parameters :

  • KempAPI : Mandatory parameter that must contain name or IP address of the Kemp LoadMaster with Web Administrative Access enabled

  • KempPort : Not mandatory parameter, default value is 443

  • KempAdmin : Mandatory parameter that must contain account with administrative access to Kemp LoadMaster. Watch-out, Kemp is case sensitive for account!!

  • KempPassword : Mandatory parameter that must contain the password to be used with the KempAdmin parameter

  • VirtualServiceName : Mandatory parameter that must contain name of the virtual service for the External VIP of DirectAccess

Let’s see some situations. Script detect that DirectAccess node is not healthy and reconfigure real server status to do not forward network traffic to that failing node.



In Kemp management portal, we see that real server corresponding to status is now disabled.



When problem was fixed, script detected that DirectAccess node is now healthy, Real server status for is updated to forward network traffic to restored node.



In Kemp management portal, we see that real server corresponding to status is now Enabled.



So it’s not so complicated to monitor DirectAccess after all.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)


Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.