How To Configure SharePoint 2013 On-Premises Deployments for Apps

Summary:   Chris Whitehead , Microsoft Certified Master (SharePoint 2010) and Premier Field Engineer based in the UK provides us with pointers to the best content and additional information that IT Pros need which is not well documented in one place. It serves as an end-to-end guide and reference point to all the information you need in order to configure SharePoint on-premise deployments for Apps. A great and comprehensive read. Enjoy!


SharePoint 2013So now that you know what SharePoint Apps are, you will likely want to configure your own on-premises deployment(s) to provide support for Apps.  Of course if you are using Office 365, a lot of this is already done for you.

There are a number of configuration steps that you’ll need to complete, along with a number of additional considerations to be aware of.  This article will speak through these.

Configuration Steps for Deploying SharePoint Apps

At a high level the configuration steps are as follows:

  • Infrastructure Configuration:
    1. Determine your App Domain.
    2. Configure domain name in DNS.
    3. Create a new wildcard SSL certificate.
  • Farm Configuration:
    1. Create SharePoint Service Applications and enable services.
    2. Configure App settings in SharePoint
  • ·App Auth Configuration:
    1. Configure SharePoint for low-trust Apps
    2. Configure SharePoint for high-trust Apps

Rather than provide a step-by-step guide for each of these steps (and repeat much of TechNet and what is already blogged about out there), I am going to provide you with pointers to the best content and additional information that you may need which is not well documented in one place.  This will hopefully serve as an end-to-end guide and reference point to all the information you need in order to configure SharePoint on-premises deployments for Apps.

Infrastructure Configuration

Part 1 of this post covered the architectural design decisions implemented in SharePoint 2013 to support Apps, and ensure that each App instance is self-contained with a unique URL in order to enforce isolation and prevent cross domain JavaScript calls through same origin policy in Web browsers.  It also covered the format of this URL. As a reminder, the App domain shown in red below is the domain name portion of the URL that we must configure along with the App Prefix (shown in orange):


Determine your App Domain

One App domain is used per farm and, once configured in DNS, it is configured in the App Settings for the farm. When choosing your App domain for each farm, you have 2 options:

  1. Create a new unique domain to host your SharePoint-hosted Apps in, or
  2. Create a sub-domain of the existing domain.

The recommendation is to create a new unique domain such as rather than a sub-domain such as  The reason for this is that use of a sub-domain could lead to cookie attacks (depending on the browser in use) on other non-SharePoint Web based applications in the same domain namespace.  A malicious SharePoint App developer could write an App that could read or set cookies across other websites such as a PHP site hosted at, provided the developer of that site hasn’t protected the cookies correctly.

Therefore the recommendation to create a new unique domain is a ‘belt and braces’ approach to prevent other websites from potentially being attacked by using a SharePoint App as the attack vector.  If you have audited all other websites in the domain and are happy that they are suitably secure, then you may choose to take the sub-domain approach.

Configure domain name in DNS

Once you have determined your App domain, it will need creating in DNS (obviously if your farm is externally facing, you will also need to purchase and register this domain name).  Since all App webs have a unique host name (App prefix and App ID above), a wildcard DNS entry is required.  Without this, you would need a new entry in DNS for every App instance, this would not scale and is not a feasible solution. There is also no way of determining what the App ID would be in advance of creating an App.

Create a new wildcard SSL certificate

Further to this, you will of course need a wildcard SSL certificate for your app domain if you are using SSL for your SharePoint environment.  Which of course you should be, especially when implementing Apps since OAuth access tokens for Apps will be in plain text otherwise and could be replayed by a malicious user or code.

If you have multiple farms that you would like to configure to host and consume Apps, then yes you will need to do this for each one, along with all the steps below.

Farm Configuration

Before you can use Apps in your farm, you will need to complete some farm configuration steps, the first of which is creating Subscription Settings and App Management service applications, and enabling the relevant services.

Create SharePoint Service Applications and enable services

The Subscription Settings service application is historically only relevant for multi-tenancy scenarios, but it is a prerequisite when implementing Apps because it is used to generate and keep track of the App IDs (shown in green above).  The internals of how this is generated is not important, but without this service application, the steps required to generate these App IDs cannot occur.

The App Management service application is largely responsible for licensing information, for example its database is accessed each time an app is used to verify the validity of the request.

One key thing to note is that both service applications must be in the same service application proxy group, otherwise the Apps infrastructure will fail to work.

Configure App settings in SharePoint

Finally, you must configure some App settings in Central Administration or via Windows PowerShell cmdlets. These include specifying the App prefix and App domain for the farm; specifying the location of the App Catalog, which is the site used to distribute Apps in our environment; and configuring Store settings such as whether users can install Apps from the Office Marketplace.

Note: TechNet has a good article on configuring all of the above: Configure an environment for apps for SharePoint (SharePoint 2013). Mirjam van Olst also has a step-by-step guide on her blog here:  Setting up your App domain for SharePoint 2013.

Additional Considerations

There are of course a number of key additional considerations that you should be aware of when it comes to SharePoint Apps:

Note: A few of these additional considerations are extrapolated from Steve Peschka’s post here: Planning the Infrastructure Required for the new App Model in SharePoint 2013 and simplified for the sake of this post, go take a look if you need more context and detail.

  1. Apps do not support Kerberos – since each App runs in its own isolated domain, for Kerberos to work we would need to configure SPNs for every App – which is not feasible!  Therefore even with Kerberos enabled for your Web Applications, SharePoint Apps rely on being able to fall back to NTLM.
  2. SharePoint-hosted Apps do not support SAML auth – currently SharePoint-hosted Apps will not be redirected to correctly when using SAML auth.  This is because most identity providers (ADFS 2.0 included), do not support wildcards for return URLs – which would be needed due to the isolated domain model implemented for SharePoint-hosted Apps.  However, Azure hosted, or provider-hosted Apps will work when SharePoint is configured to use SAML auth – but there is some configuration required, which Steve Peschka covers off in quite some detail here:  Using SharePoint Apps with SAML and FBA Sites in SharePoint 2013.
  3. Apps do not support multiple zones – all requests will only ever be served out of the default zone. If you need multiple URLs for SharePoint, you should consider using host header site collections with multiples URLs – a new feature in SharePoint 2013 – rather than multiple zones and Alternate Access Mappings (AAMs). Check out the Set-SPSiteUrl cmdlet for more detail.
  4. A routing Web Application may be needed – imagine the multiple Web application scenario and remember that we have 1 App domain per farm. If we install Apps in each Web application, bearing in mind the separate App domain that will host App Webs for these Apps, how is the request to our App Web going to be routed to the correct hosting Web application? How does SharePoint differentiate between an instance of an App Web that lives in the ‘my sites’ Web application, and an instance that lives in the ‘intranet’ Web Application? The section below explains this in more depth.
  5. Update: One of the feature updates of the March 2013 Public Update for SharePoint 2013 enables you to use multiple app domains in SharePoint 2013 environments with alternate access mapping or host-header web application configurations. Before the Public Update, you could only host one app domain and it had to be in the Default zone. You could not use the app domain on alternate access mappings or host-header web application configurations. The Public Update enables you to configure an app domain for each web application zone and use alternate access mapping and host-header web application configuration. More information about configuring apps in AAM or host-header environments can be found at:

Routing Web Application

Consider the scenario where a request is made to The App Web itself lives in the ‘intranet’ Web application, but how does SharePoint determine that?

A request is made to

In the above diagram, the request for the App Web comes in from a client and a DNS lookup is performed.  DNS resolves to our NLB device which in turn routes to our SP farm.  However, the host header for this request is not matched to any of our Web applications so SharePoint won’t know how to handle this.

To get around this we could try to configure SharePoint and IIS so that application requests go to one of our existing Web applications (and in theory this may work because SharePoint will do some clever routing which is covered in more detail in a second).  But when using SSL, it will break because we can’t have an SSL certificate that contains multiple wildcards such as * and *, and we can’t bind two to the same site.

So to get around this we need an additional Web application that will act as a catch all routing Web application.  This Web application must either have its own dedicated IP address, or must have no host header if sharing an IP address – that way it will serve all requests that don’t match host headers for the IIS sites of the existing Web applications.  Internally the SharePoint HTTP module will know where to route this request by using the App Management Service Application to work out which Web Application hosts the App Web.  This can be seen below:

Catch-All Web Application

This approach allows us to bind our App Domain wildcard certificate to the IIS site for our catch all routing Web Application, and also bind wildcard certificates to IIS sites for our existing Web Applications.

As ever, there is an additional caveat.  The identity that the application pool for the routing Web Application is using, must have rights to all the content databases for all of the Web Applications that are being routed to.  The easiest way to achieve this is to use the same application pool for all Web applications, or use the same identity for all application pools.

App Auth Configuration

The topic of App authorisation and authentication is a vast one, so I will only touch on a few key points here at quite a high level, and provide additional reading for those that want to know more.

In general as an IT Pro, you need to be aware that cloud-hosted Apps (those outside of SharePoint) won’t just work out-of-the-box with an on-premise SharePoint 2013 deployment.  When you think about it, this kind of makes sense, our externally hosted Apps need to be able to call into SharePoint to request data, by default no trust is going to be in place to allow this – so we need to hook that trust up somehow.

In SharePoint 2013, OAuth is used to establish this ‘trust’ – OAuth enables users to grant a third-party site access to information that is stored with another service provider (in this case, SharePoint), without sharing their user name and password and without sharing all the data that they have in SharePoint.  At a really high level, this looks something like the following:

A user signs in to SharePoint 2013 and is authenticated. The authenticated user then uses a cloud-hosted App which uses the SharePoint client object model (CSOM) or REST endpoints with CSOM to make calls to SharePoint.  The App is granted permission by the user to access SharePoint resources on the user's behalf. When the App launches, it loads from another location and calls back to SharePoint to access the resources on behalf of the user by using an access token.

You can read more on OAuth in SharePoint 2013 on MSDN.

The method of generating the access token mentioned above is a key differentiator to the auth flow.  In SharePoint 2013, OAuth is used for Apps that fall in two differing scenarios which are known as “low-trust” and “high-trust.”

Configure SharePoint for low-trust Apps

Low-trust Apps are those that use an authentication provider to act as a common authentication broker or trust broker between SharePoint and the App.  This will be Windows Azure Access Control Services (ACS), and as such will of course require an Office 365 subscription.

ACS is where SharePoint requests a context token that it can send to the location hosting the App. The App then uses the context token to request an access token from ACS. Once received, this is used by the App to talk back to SharePoint. Y ou can read more about the detail of the OAuth flow for low-trust Apps here:  OAuth authentication and authorization flow for cloud-hosted apps in SharePoint 2013.

There is a fair amount of configuration required to allow SharePoint on-premises farms to communicate with ACS.  Josh Gavant (a fellow PFE), has a great post detailing all of the steps, along with some handy PowerShell helper functions here:  SharePoint Low-Trust Apps for On-Premises.

Configure SharePoint for high-trust Apps

High-trust Apps are those where you are not using ACS as the trust broker, so there is no context token.  Instead, you are using a certificate to establish trust and generating your own access token by using the server-to-server security token service that is part of SharePoint 2013. This type of trust is known as a server-to-server trust relationship and is between the SharePoint farm and the App, therefore it must be done for each high-trust App that uses different certificates which a SharePoint farm must trust. High-trust does not mean "full trust", a high-trust app must still request App permissions.  The app is considered high-trust because it is trusted to use any user identity that the App needs, because the App is responsible for creating the user portion of the access token.

When an App is not SharePoint-hosted and requires some server-side processing logic, this is the approach in-house apps should take most of the time.

Configuration of this trust is performed primarily via Windows PowerShell for on-premise deployments and is detailed at length on MSDN: How to: Create high-trust apps for SharePoint 2013 using the server-to-server protocol (advanced topic).  Steve Peschka’s blog is another great resource here if you run into any issues: More TroubleShooting Tips for High Trust Apps on SharePoint 2013.


The new App model for SharePoint is a big paradigm shift that not only affects developers, but also affects IT Pros that manage and maintain SharePoint 2013 on-premise.  Having an understanding of all the working parts and how to configure them will become more and more important as the App model becomes more prevalent.  Hopefully this blog series (including the first post on Understanding SharePoint Apps as an IT Pro) helps you on the way with this – best of luck!

Written by Chris Whitehead. Posted by Frank Battiston , MSPFE Editor