After the installation of the March 2013 PU, new options to assign Alternate Access Mappings for Apps were made available. The update allowed SharePoint admins to add alternate URLs for SharePoint hosted Apps.
This new feature can only be managed via PowerShell:
How does it work?
Let’s suppose you already have a web application working and you are using some apps and these apps use an app web. This means that the app web URL will be something similar to:
<app prefix> – <app id>.<app domain>
Say that your SharePoint farm was being used only in your company’s network with an internal URL but now you want to publish it via a reverse proxy. To do this, you are extending the current web application to a new Zone so you are adding a new public URL to the web application. In RTM, there was no way to configure SharePoint to use several URLs for your Apps which meant that you needed to use a real public App domain.
Now, it is possible to have AAMs for Apps!
My test web application uses http://2013.test.local as the public URL in the Default zone. I have configured the app domain as test-apps.local and I have followed Configure an environment for apps for SharePoint (SharePoint 2013) to configure my farm.
Right now, if I access my test App the URL it uses is the following:
Since this domain uses an internal TLD it won’t be possible to access the App from outside the corporate network.
How do you add a new App domain?
You can find the steps in the following Technet article: Enable apps in AAM or host-header environments for SharePoint 2013
Going back to our test lab, I now want to publish my web application so that my site will now be also available with the URL https://2013.test.net. I will use a reverse proxy to do the SSL termination here. I won’t explain how to do the SSL termination but this are my new AAM collection for this web application after extending:
After extending the web application and configuring my reverse proxy to proxy all requests from https://2012.test.net to http://2013.test.net:81, I got access to the site with the new URL. However, when I click in the App, I still get redirected to http://app-f28aaf39627eed.test-apps.local.
We need to do two things to have a different URL:
- Create the URL/Zone mappings.
- Enable the mapping feature in the ContentService.
1. Creating the mappings
First, we need to use the New-SPWebApplicationAppDomain cmdlet to assign the URLs. We will be adding the URL for the Default zone and then add the URL for the new Extranet zone.
New-SPWebApplicationAppDomain -AppDomain test-apps.local -WebApplication http://2013.test.local
New-SPWebApplicationAppDomain -AppDomain test-apps.net -WebApplication http://2013.test.local -Zone Extranet -SecureSocketsLayer -Port 82
If we now do a Get-SPWebApplicationappDomain we’d get both URLs:
Why did I choose to use SSL and port 82 on the new URL?
- I chose to use SSL because I want every communication in the apps to be secure, no OAuth token flying around unencrypted, but mainly, because I want the URL of the App web to use HTTPS so that it matches my web application URL that it’s also using HTTPS.
- Then, I chose to use port 82 because I’m using SSL. If we don’t specify the port, then it’ll use the same port that the extended web application uses. In my case it would be 81. However, I’m doing SSL offloading so my IIS binding in the Extranet zone is actually HTTP/81. Since I don’t want SSL termination for my Apps, I need a HTTPS binding and for this I need another port to bind to.
This also means that if you use a different port that the zone’s, this cmdlet will actually add the binding to the IIS site. And if you are using SSL, then you’ll need to configure the encryption certificate manually in the IIS bindings. Of course, the certificate should be a wildcard certificate for *.test-apps.net (or whatever new domain you are using for this zone)
After running the cmdlet, these are the bindings in my web server:
2. Enabling the feature
This step is as simple as running these PowerShell cmdlets:
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.SupportMultipleAppDomains = $true
After adding the mappings and enabling the feature, you need to do an IISReset in all your web servers.
Some limitations worth mentioning
- The zone you are adding an app domain to must exist and the web application must be extended to it.
- You can share app domains between web applications, but the web applications must use the same application pool identity, zone and authentication provider.
- If you use SSL in the app domain, then you must use a different port from the web application SSL port. Mainly because you need to have two different certificates, however, you might be able to use separate IPs for different certificates although I haven’t tested this.