Paths to Success with Web Application Proxy


Hi everyone,

We’re pleased to introduce our new guest blogger, Mark Grimes from Microsoft Consultancy Services. Mark’s been involved in some pretty complex Web Application Proxy deployments and has put together some great hints and tips we wanted to share. Over to Mark…..


In this posting I want to share with you some of the fundamental rules that you need to follow when publishing applications in Web Application Proxy. 

Perhaps a more accurate title for this might be, “paths that work and those that don't”?  No matter what the title, if you learn some simple rules to follow, you will improve your paths to success when publishing applications in Web Application Proxy. 

Web Application Proxy is a new role in Windows Server 2012 R2 that allows an administrator to publish access to an internal web application for external users. 

If you do not follow these paths to success, then you will often be politely asked to stop what you are doing right before you think you are done with your publishing. In this blog, we’ll show you some examples of those GUI stop signs, which will be presented to you as you attempt to do something that is simply not allowed and we’ll also explain the reasons why.  In some cases you may receive a warning just as soon as you enter your external and internal URLs. But sometimes you will just have to wait a few clicks before receive your surprise announcement declaring that you cannot do what you just thought you could do. And as administrators, we do not like surprises. 

Knowing these rules in advance will help you plan your Web Application Proxy deployment and avoid unforeseen issues when you’re right in the middle of your deployment. 

Let's summarize these "paths to success" to help you be successful in publishing applications through Web Application Proxy. Then we'll break them down one by one with examples for each.

1. External publishing through HTTPS only

2. Web Application Proxy can translate the host portion of the fqdn names but not path names

3. The absolute path must have a “/” suffix

4. Web Application Proxy supports wildcard certificates, but not wildcard host names for publishing

5. Nesting is for the birds, not Web Application Proxy


1. External publishing through HTTPS only

For publishing of web sites, port rules are simple. Externally, Web Application Proxy only currently only supports secure external publishing with HTTPS. This is to be secure by design.  Web Application Proxy supports connecting to the internally published server over either HTTP or HTTPS URLs. The only thing that will stop this from happening is if you do not follow the rest of the rules after this one.  Here is the example warning you will get as soon as you currently try to type HTTP for the external URL.


So you say, “Hey, what about all of those HTTP only sites we have that we need to publish?”

As you’ll no doubt have seen from Meir’s recent blog support for HTTP publishing along with a ton of other great new functionality is being added to Web Application Proxy in Windows Server vNext :-

In the interim, one example of an easy work around, which many of our customers do, is to implement something like an F5 load balancer iRule, which does a simple URL rewrite from HTTP for inbound requests to the network, to HTTPS traffic heading to Web Application Proxy.


2. Web Application Proxy can translate the host name portion of the published path but not path names

Web Application Proxy supports different internal and external FQDN’s e.g. externally, but with an internal server name of With an internal name like that, we surely do not want to share that name with the world. Note, in this example, the external URL is HTTPS and the internal URL is HTTP and it’s worth just noting this as although we currently only support external access over HTTPS we can bridge to HTTP internally. There is no path after the host name portion (which would have to match), so this will work and apply to all paths under the FQDN. Here is what it looks like:


Note: a warning dialog box does come up, but it is just noticing that the host names indeed are different. 
After clicking Publish in the Publishing wizard, you will get a successful confirmation.
To simplify the second part of this rule with an example, which is “Web Application Proxy cannot translate path names”, we’ll keep the external and internal host portions of the names the same but only change the path names following, to make them different.

In this first example, let’s try to publish (externally) to (internally).


You get the same warning as above, but you can still click through this and will not be blocked until the very end once published Sad smile


To fix this, match the path following the FQDN host name portions for BOTH the external and internal names.

Following are successful examples with the same hostname and pathnames and then publishing apps with different host name portions of the fqdn, but the same path names following the hostnames.


If you have not done publishing with Web Application Proxy yet, the first scenario in the picture above is how the Web Application Proxy wizard assumes by default that you will publish the apps.  This means that as soon as you type in your application’s external name, it auto-fills in the application’s internal name to be the same.  This is by design and helps to fully mitigate any host translation issues.


3.    The absolute path must have a “/” suffix

This one is a quick and simple rule.  What this means, is to always end any application path with a trailing “/”. In the example below, is attempted to be published (and not Once Publish was clicked, the interface complained once again with the dialog box below.


But here is a little twist even to this one! My customer had some paths that did not have a trailing slash. We’ll use the failed publishing attempt above as a requirement. Well no worries mate! If you publish the customer needs (sans slash), this will still work as it is implicitly allowed by design.


4.    Web Application Proxy supports wildcard certificates, but not wildcard host names for publishing

There will be other blog posts covering certificates, but we just want to differentiate these two “wild” examples.
As shown below, wildcard certificates such as * are used to quickly publish any application without having to make a new certificate for every name. This means that for any host name that start with, this certificate will work for just the one level beyond the dns name of  We’ll stop right there to save the rest of the certificate tips and tricks for another later blog post.


Next, we’ll try this using wildcard HOST names and see what happens.


The warnings in RED let us know that this is not valid to use wildcard HOST names.

This is an important requirement especially for publishing Apps for SharePoint where each application has a GUID FQDN under the app namespace e.g. and is another feature that is added in the vNext release:-

To complete the set, if you are thinking about wildcards in the URL path, well this is just simply implied and allowed.  So if you publish internally and externally. Then ANY sub-path beneath that will work as well e.g.


…will ALL be allowed to pass through the gateway if you published 

In one customer scenario, they have many sub paths for different apps or fedlets within their Java applications.  In this case things like:

• is equivalent to*
• is equivalent to*


5.    Nesting is for the birds, not Web Application Proxy

This final scenario we’re going to look at is what happens when you combine overlapping or nested path publishing.
Nesting paths in Web Application Proxy  is a situation where there is one path published initially, which is then later published later with the same initial fqdn followed by an overlapping path.  As an example, if you tried to publish the following internal URLS:


…here is the warning you will get.


Besides trying to avoid these “nestings”, how else can you avoid this?   One option would be to use alternate DNS host names.  If you published the following:


..this WILL work.  Why? Remember rule #2 above?  Web Application Proxy can translate host portion of the path but not pathnames between the internal and externally published URLs.

We do recognise that this is a requirement for a number of scenarios and it’s something the Product Group are evaluating for vNext.



There you have it. Five rules for “paths to success” in publishing applications in Web Application Proxy. If you follow these rules, may your publishing be successful ever after! And I do hope that these rules help you to avoid the common errors as shown above. Just like anything we do, practice makes perfect, or at least makes fewer mistakes.

Till the next time – Mark @ Microsoft

Comments (14)

  1. KC_Craig says:

    Great article – Actual Use Cases!
    Using this to front end our SP2013 WWW, OWA and ADFS all over port 443. Perfect.

  2. @Some Guy and Frustrated Engineer. We do have some limitations in the current release and there’s work going on in terms of WAP vNext to fill a lot of the holes. Some of this is detailed in the following blog although there are other improvements coming
    in addition to this:-
    If you have specific publishing areas which you are limited by in the current release please let us know the details so we can feed this back into the PG to try to cover as much as we can in the next release.

  3. John B. says:

    I enjoy the article. I must say I have found much success using "no hands proxies" as a reliable service. I recommend their service. Thanks again for your insight!

  4. Some Guy says:

    Argh, this article could be called "reasons to stick with TMG for publishing." Nice to see WAP’s shortcomings listed in a concise fashion, but it doesn’t make it any less frustrating.

  5. Frustrated Engineer says:

    I agree with ‘Some Guy’ I was hoping that WAP would be a replacement for TMG….MS has really dropped the ball on the death of TMG and a roadmap that leads to the edge of a cliff.

  6. Anonymous says:

    Welcome to this custom Quick Reference Guide. The purpose of this guide is to provide you with the latest

  7. Jerryy says:

    This is useful information.. Interesting post.. Thanks for sharing..

  8. Another Guy says:

    Thank you for the useful information.

    I have one question that from my understanding can not be fully answered from the information in this post.

    Will it be possible with WAP 2012 R2 to publish two different appliactions with distinct paths but different internal FQDNs to the same external FQDN?

    Internal URLs

    To be published external URLs:

    (knowing that this would create an error, when someone accesses without specifying /appone/ or /apptwo/ )

    Thank you in advance for any answer!

  9. @Ian Parramore: There seems to be a wee disconnect between what MS is offering in WAP and what ex-TMG administrators want (perhaps need?) to see. For example some of the following use cases:

    * Publishing multiple public DNS names to the same backend server (in the simplest case, consider perhaps and both need to go to the same backend server). “Error: Add-WebApplicationProxyApplication : The following backend server URL cannot be used because a published web application is already configured to use it.” So you can’t have two names for the same server, without every public name being defined in internal DNS. You also can’t push both http and https URLs to the same backend HTTP server (there are scenarios where forced redirection can’t be supported)! Other examples are hosted namespaces in Exchange – and end up needing different backend servers so now you have name resolution and assignment problems in Exchange.

    * URL translation and rewrite (IIS ARR Rewrite Rules did this and still does. TMG did this. ISA 2006 did this twelve years ago. WAP is still living in 2003.) –> http://server3/products/groupX/. All of the other platforms in the space can probably do it, but the brand new Microsoft one can’t.

    * Editing of server configurations without diving into the raw configuration files or deleting and recreating. It’s 2016, why can’t I change the configuration of a server – name, port etc – without Notepad?

    * Editing of published web applications without deleting and recreating them or using PowerShell (while I’m OK with PoSH, many administrators are not yet up to speed – in my world there’s a whole generation avoiding the command line like a plague).

    * Different themes/logon pages for different URLs or domains ( users see branding, while users see branding). We have SNI and multiple themes, but no way to separate out namespaces to brands or separate themes without multiple farms, as far as I can tell?

    * Path blocking – allow* but return 401 or another customisable error for

    * Customisable error pages (e.g. should return a branded 404, not the plain HTML it presently does.

    Thank goodness you did manage to solve one of the previously outstanding use cases – unified web publishing – –> server1, but –>server2. Problem in 2012 R2, thank goodness this is now workable (albeit with a warning). If only you could solve some of the other outstanding problems.

    (I hope my formatting works!)

  10. Sys_Admin_EB says:

    I have a strange issue. We have our sharepoint server out on the web. We moved it from a MS TMG server to the WAP. Https:\\ The backend rule is set to go to http:\\ When we hit the site for sharepoint and it asks for login, we login and then it forward to the internal DNS entry of just bufsps01/default.aspx. and the page stalls out and says teh site cant be reached”bufsps01 server DNS address could not be found.

    1. Harley says:

      Please check AAM it’s configured or if you are using Host named site collection.

  11. Rohini says:

    Great blog! thanks for sharing, also visit

Skip to main content