Zoho Banner September 2011

Archive for the ‘Web Application Proxy’ Category

Recently I set up Web Application Proxy (WAP) instances for a customer to support remote access to several on-premises web applications.  I was looking for a cheap and effective means of ensuring the service continued to be available to clients in the event that one of the WAP instances went down.  Someone recommended using Azure Traffic Manager (ATM) for this.  ATM is cheap, especially compared to an external geo-load-balancer and, also being a Microsoft service, allows you to use Powershell to get things up and running as well as for ongoing administration.  I found some useful on-line information on how to integrate ATM with WAP, but not all in one place and some of the information was out of date.  Hopefully this article will help those to want to do the cut out the noise and simply get up and running quickly.

The first step is to create an ATM Profile.  In this example I have used the DNS name wap.fish-eagle.trafficmanager.net. The wap prefix obviously refers to Web Application Proxy, while fish-eagle is my company name.  The trafficmanager.net suffix is fixed and is common for all ATM DNS names.


Note that if you use the Azure Portal to create the ATM profile (as opposed to using Powershell), the routing method will default to Performance.  This is fine if you have endpoints configured in different geographical regions and you want client requests to be directed to the nearest endpoint (WAP instance).  In my case the WAP instances are both in New Zealand and share the same geographical region (from an Azure global perspective), so I changed the routing method to Weighted with an equal weighting.  This means that neither instance is preferred and ATM will direct 50% of client requests to one instance and 50% to the other under normal circumstances.  ATM monitors the endpoints and will stop directing clients to an endpoint it has detected as being offline.  For a more in-depth discussion of the available routing methods, see this helpful article.

If you don’t already have public DNS A records for each of your WAP instances then this is the time to create them, as you will need them when configuring the ATM endpoints.  In my example, I have created two records:

north.fish-eagle.net A

south.fish-eagle.net A


You will also need to create public DNS CNAME records for each of the web services pubished via the WAP and have these point to the DNS name of the ATM profile you created.  In my example, it looks like this:

mywebapp.fish-eagle.net CNAME wap.fish-eagle.trafficmanager.net.

The ATM will not be able to furnish client requests with a suitable IP address until the endpoints have been configured, which is the next step.

When ATM was first made available it was only possible to configure Azure endpoints, i.e. those that existed in either Azure PaaS or IaaS. Recently, Microsoft has made it possible to also monitor endpoints outside Azure.  These are referred to as external endpoints.  Currently, external endpoints can only be configured using the Azure Powershell module.

After you have downloaded and installed the Powershell module, you need to log in with an account that has permissions to the Azure Resource Group in which the ATM profile has been created.



Choose the Azure subscription to use.

Set-AzureRmContext -SubscriptionId 578039e9-a84e-4e7a-8797-dbbd991cc6b0


Create a one-time registration to use the Microsoft.Network service provider.

Register-AzureRmResourceProvider –ProviderNamespace Microsoft.Network


Get a list of your Azure Traffic Manager profiles (in my case there is only one).  Note that currently no Endpoints are configured.


Get-ATM Profile

Retrieve the existing Traffic Manager profile object, set the MonitorPath and commit the changes.  Note that the default monitoring path “/” has been known to have issues when monitoring WAP endpoints, i.e. ATM incorrectly detects them as Offline at times.  The built-in “/adfs/probe/” path on the WAP servers can be leveraged to correct the aberrant monitoring behaviour.

$profile = Get-AzureRmTrafficManagerProfile –Name wap-fish-eagle -ResourceGroupName fe-production

$profile.MonitorPath = “/adfs/probe/”

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile


Change the routing method from Performance to Weighted (if you didn’t already do this in the Azure Portal during creation of the ATM profile), and commit the changes.

$profile.TrafficRoutingMethod = “Weighted”

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile


Create the external endpoints and commit the changes to the profile.  Note that the value of the Target parameter in each cmdlet corresponds to the DNS A records we established earlier.

Add-AzureRmTrafficManagerEndpointConfig –EndpointName wapnorth `
–TrafficManagerProfile $profile –Type ExternalEndpoints `
-Target north.fish-eagle.net –EndpointStatus Enabled


Add-AzureRmTrafficManagerEndpointConfig –EndpointName wapsouth `
–TrafficManagerProfile $profile –Type ExternalEndpoints `
-Target south.fish-eagle.net –EndpointStatus Enabled

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile


Now when you run a DNS query for your web application(s) published through WAP, ATM should provide you with the IP address of one of the available (i.e. Online) endpoints.  Here’s how mine looks.


As you can see from the screenshot, ATM has provided the DNS client with the IP address (, which corresponds to one of my WAP instances (south.fish-eagle.net).

At this point the configuration is complete.  If both WAP instances are up and the monitoring is working successfully, you should see the monitoring status showing as Online in the Azure Portal.


Note that you will need to allow inbound traffic on TCP Port 80 (HTTP) on your external firewall and WAP Windows Firewall configurations for the monitoring to be successful.

The setup of the ATM monitoring component should you take less than an hour.  ATM provides a cheap and effective way to provide a seamless client experience for the web applications published via your WAP infrastructure.

Good luck and be careful out there!


The other day one of my customers was testing remote access to a web application via the Web Application Proxy (WAP). Everything seemed to working except some reports. These generated “HTTP Error 400. The request URL is invalid”. Given that the reports worked well inside the corporate network it pointed to an issue with the WAP.

Further investigation revealed that the requested URL for that generated the error was unusually long (approximately 500 characters).

The WAP uses HTTP.sys under the hood. HTTP.sys is a kernel-mode device driver that first drew breath in IIS 6.0 (shipped with the now unsupported Windows Server 2003).

As it turns out HTTP.sys imposes a 260 character limit on URLs. Fortunately, this limit is configurable by modifying the registry, as described in the following KB article:


The steps to increase the limit are:

  1. 1. Create a UrlSegmentMaxLength DWORD value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters and set it to 600 (decimal)
  2. 2. Reboot the WAP server.

This resolved the issue for my customer. I hope it helps you too!


I recently helped a customer to set up a Web Application Proxy (WAP) service to do pre-authentication to a SAP CRM system. Within the network everything was working well via ADFS and authentication was just fine.  Coming through the WAP however I got a 404 error.  The SAP CRM debug log showed a difference in the URLs when accessing internally versus externally, as follows:

Internal connection bypassing WAP (working) crm.contoso.com – - [23/Nov/2015:15:15:45 +1300] HTTPS 302 “GET /saml2(bD1lbiZjPTMwMCZkPW1pbg==)/bc/bsp/sap/crm_ui_start/default.htm?sap-sessioncmd=open HTTP/1.1″ 0 83 h[-]

External connection via WAP (failing) crm.contoso.com – - [23/Nov/2015:15:34:15 +1300] HTTPS 404 “GET /saml2%28bD1lbiZjPTMwMCZkPW1pbg%3D%3D%29/bc/bsp/sap/crm_ui_start/default.htm?sap-sessioncmd=open HTTP/1.1″ 1819 52 h[-]

The difference appeared to be simply that the special characters in the URL have been transformed/replaced when coming through the WAP.  I couldn’t find a configuration option within WAP that addressed this behaviour.

After posting to a couple of forums, someone from Microsoft came back with a suggestion to apply the hotfix mentioned in the following KB article (KB3042127):

“HTTP 400 – Bad Request” error when you open a shared mailbox through WAP in Windows Server 2012 R2

Apart from not seeming (from the title at least) to be remotely relevant to my issue, this KB wins the award for the most thinly worded article in the world. Ever….

“This issue occurs because Web Application Proxy (WAP) is encoding the reserved characters incorrectly.”

There, that’s the entire “Cause” section of the KB article. :-)

You have to request the hotfix (i.e. it’s not delivered via Windows Update) and also have to have the April 2014 update rollup for Windows Server 2012 R2 (KB2919355) installed as a prerequisite.

Anyway, after installing the hotfix and restarting the WAP server, everything worked like a charm. Issued resolved.

Interestingly, it also appeared to resolve an unrelated issue with another application using the WAP. From my experience at least this seems like an important hotfix and one that should be given more publicity.