SharePoint 2013 Apps and AAM


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:

  • New-SPWebApplicationAppDomain
  • Get-SPWebApplicationAppDomain
  • Remove-SPWebApplicationAppDomain

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:

http://app-f28aaf39627eed.test-apps.local/AppWithWeb/Pages/Default.aspx

Since this domain uses an internal TLD it won’t be possible to access the App from outside the corporate network.

What if you use a reverse proxy that rewrites the URL? Then, you might be able to access the App’s web but other things like Javascript object model might not work correctly.

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:

  1. Create the URL/Zone mappings.
  2. 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?

  1. 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.
  2. 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

$contentService.Update()

 After adding the mappings and enabling the feature, you need to do an IISReset in all your web servers.

Aftermath

After this configuration, now I can access my web application via my reverse proxy and when I open my App, the URL it now uses is the expected one and Javascript CSOM works flawlessly!

 

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.
Comments (3)

  1. SharePoint 2013 Developer Training says:

    I agree with all points you have given to us to create a app domain in SharePoint 2013

    staygreenacademy.com/sharepoint-developer-training

  2. gowtham says:

    if the authentication is claims(kerberos) based then how to going to work??.

    1. This configuration should be agnostic to the authentication provider that you use.

Skip to main content