I’ve recently been researching into what exactly is needed for implementing the App Model in SharePoint 2013. Notably the environment into which we would be deploying SharePoint 2013 doesn’t support creating multiple IPs on a single box, so I had to get creative with the IIS bindings and instead use port separation.
The issue with this is that this isn’t a documented use case by Microsoft, so time to dig under the covers.
The app domains that you configure for a farm are essentially root domains for automatically generated hostname based site collections (HNSC). You give SharePoint an app domain of myspapps.com and SharePoint dynamically generates HNSCs with each app “install”.
This is why the Site Subscription service (which powers HNSCs) is required to enable apps. So we set up a wildcard DNS entry, point it at some sort of reverse proxy or load balancer, and direct it at our servers on a custom nonstandard http/https port.
It would be great if this worked out of the box, but for any redirect URLs that get sent back to the browser client, we see that the custom port number is sent back. If you don’t have your proxy or load balancer configured to take this into account, you end up with 404s. This is most evident in the out of the box defaultcss.ashx. Your app will load but the out of the box stylesheets will fail.
In normal site collections/web applications this is not an issue as we can set up alternate access mappings. Public = reverse proxy URL, internal = URL on custom port, or in the case of an HNSC, the commandlet you use to create the site collection also allows you to specify the port.
Microsoft already recognized a limitation in that apps could not support multiple auth zones, or HNSCs and provided a solution in the March PU They added a few new commandlets for generating per web-application app domains with support for multiple zones as well. The new commandlets take advantage of more of the HNSC functionality and as a side effect it now allows for specifying a port for an app domain mapping. While the documentation covers configuration at a per zone/HNSC app domain, it does go far enough to state that a single app domain can be shared so long as the authentication scheme and app pools match.
This gives us the ability to have the same exact functionality with the ability for SharePoint to properly resolve and regenerate URLs with the proper public URL format regardless of the IIS binding. Follow the link at the source for instructions on how to leverage the new commandlets if you’re running into challenges enabling Apps with a separate listener URL and public URL. You’ll want to pass the app domain and port for the public URL along to the commandlet and make sure your reverse proxy/load balancer passes on the Host: header to match.
*Note, the new commandlets are not yet in the commandlet reference since those haven’t been published since July 2012.