Plan for apps for SharePoint 2013


Applies to: SharePoint Foundation 2013, SharePoint Server 2013

Topic Last Modified: 2016-12-16

Summary: Determine your organization’s policy about how to use and develop governance for apps for SharePoint 2013. Plan the App Catalog, app URLs, and how to monitor and license apps.

The apps for SharePoint provide a new method to deliver specific information or functionality to a SharePoint site. An app for SharePoint is a small, easy-to-use, stand-alone productivity app that solves a specific end-user need. Before you allow site owners to install apps in a SharePoint environment, you must plan how you want to support them. You have to determine your organization's policy around apps for SharePoint, plan your configuration settings, and determine how to manage and monitor the apps. This article discusses key decisions and helps you understand the choices to make as you plan to support apps for SharePoint.

For more conceptual information about apps for SharePoint, see Overview of apps for SharePoint 2013.

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. For more information, see Enable apps in AAM or host-header environments for SharePoint 2013.

The first decision about apps for SharePoint is the extent to which you want to use them in your organization and the policy for using them. The following questions can help you frame your discussion about your policy:

  • Do you want site owners to be able to install and use apps for SharePoint?

    • If so, keep reading and shaping your policy.

    • If not, then you can use settings in the SharePoint Store to control whether site owners can purchase apps from the SharePoint Store. You cannot block site owners from viewing the SharePoint Store. However, you can prevent them from purchasing or downloading apps for SharePoint. If you choose to prevent site owners from installing apps for SharePoint from the SharePoint Store, you should create a policy statement and advise site owners that you have chosen not to support apps for SharePoint. Otherwise, the only message to site owners will be an error when they try to install an app for SharePoint.

  • Do you want to restrict or control the apps for SharePoint that site owners can install and use?

    If so, you can do one or both of the following:

    • Set up an App Catalog to provide a set of apps for SharePoint that site owners can install and use.

    • Use the App Request feature to control the purchasing and licensing of apps for SharePoint.

  • In which environments do you want apps for SharePoint to be available? For example, intranet, extranet, or Internet environments?

    You should decide which environments are appropriate for using apps for SharePoint and configure the settings for apps for SharePoint only in those farms or for those web applications.

  • Do you want to control who can purchase apps for SharePoint?

    No explicit setting prevents a site owner from purchasing an app for SharePoint. However, you can create a request process that requires site owners to submit a request that your organization reviews to make sure that appropriate persons make purchases.

  • Do you want to control who can install apps for SharePoint?

    At the minimum, a user must have the Manage Web site and Create Subsites permissions to install an app for SharePoint. By default, these permissions are available only to users who have the Full Control permission level or who are in the Site Owners group.

  • Do you want to provide specific apps for SharePoint in your environment?

    Add apps for SharePoint for your own organization to the App Catalog.

  • How many and which apps for SharePoint do you want to monitor?

    You must explicitly select the apps for SharePoint to monitor for a farm.

    The ability to monitor apps for SharePoint is not available for SharePoint Foundation 2013.

The following illustration summarizes these governance choices.

Governance choices for apps for SharePoint

Governance choices for apps for SharePoint

These choices change whether site owners in your environment can purchase and install or add apps from the SharePoint Store or the App Catalog. The following illustration shows the results of these choices for site owners.

Flowchart with decisions about purchasing apps

Flow of decisions about purchasing apps

Before you use apps for SharePoint in your environment, you have to configure your environment to support them. If you don’t configure your environment, site owners who try to install and use apps for SharePoint receive error messages. For all apps for SharePoint, you must set up a Domain Name Services (DNS) domain name to provide a host name for the installed apps. By using a separate domain name, apps for SharePoint are separated from SharePoint sites to prevent unauthorized access to user data and to reduce the possibility of cross-site scripting attacks. The use of separate URLs for apps for SharePoint and SharePoint sites is called app isolation. You also need a DNS record so that the domain name can get correctly resolved. You can create one of two of the following types of DNS records for app for SharePoint URLs:

  • A wildcard Canonical Name (CNAME) record that points to the host domain assigned to the SharePoint farm.

  • A wildcard A record that points to the IP address for the SharePoint farm.

Choose the type of record to use to point from the app domain to the SharePoint farm domain.

The following illustration shows the types of records that you can use to point from the app domain to the SharePoint farm domain.

Illustration of a type of record that points from the app domain to a SharePoint farm domain

DNS domain names for SharePoint Apps

In addition to setting up the DNS domain to support apps in your environment, you also have to configure the following:

  • SSL Certificates

    If you are using SSL to help secure traffic, you must create a wildcard certificate to use for all app URLs. Wildcard certificates cost about the same as five individual certificates. So, you can quickly justify the cost of a wildcard if you expect to use more than five instances of apps for SharePoint in your environment.

    Each instance of an app for SharePoint that is installed has its own URL. Therefore, if you only have one app for SharePoint in your environment, but the app is installed on six different sites, then you will have six different app URLs.
  • The Subscription Settings and App Management service applications

    These services support apps in your environment by storing the data needed to run apps in the farm. The Subscription Settings service and the App Management Service store app licenses, app principals, app users, app registrations, and so on.

  • The app URLs to use

    Each app has a unique URL in your environment. You determine the template for that URL, and then app URLs are automatically generated by using the prefix and domain that you specify. For example,

The Configure an environment for apps for SharePoint (SharePoint 2013) article describes how to configure these settings.

Each app for SharePoint has a unique URL, which is made up of the app domain plus a prefix and an Apphash. The format is as follows: The Apphash is an arbitrarily-assigned unique identifier for each app for SharePoint. These URLs are generated automatically depending on the settings that you specify. You do not have to create or manage these URLs separately; instead you configure a wildcard entry in DNS to provide the URLs for all apps.

The examples in this section use an Internet-style domain name for clarity. This does not imply that you must expose your apps to the Internet. Note that for actual hosting environments you must still organize a DNS routing strategy within your intranet and optionally configure your firewall.

When you choose the domain name and prefixes to use for your environment, consider the following:

  • Use a unique domain name, not a subdomain

    For security reasons, the domain name that you choose should not be a subdomain of the root domain name that hosts other applications. This is because other applications that run under that host name might contain sensitive information that is stored in cookies that might not be protected. Code can set or read cookies across different domains that are under the same domain. A malicious developer could use code in an app for SharePoint to set or read information in a cookie on the root domain from the app for SharePoint subdomain. If a malicious app accessed that cookie information, then you could have an information leak. Internet Explorer honors the settings that SharePoint sites use to protect against this issue. However, you should still use a domain for apps that is separate from your other domains. For example, if the SharePoint sites are at, do not use Instead use a unique name such as This is not to say that you should never use a subdomain if you have business reasons to do this. However, consider all potential security risks.

  • The app domain should be in the Internet or Restricted sites security zone in Internet Explorer

    For security reasons, we recommend that you configure the app domain to be in either the Internet or Restricted sites security zone in Internet Explorer options, and not in the Intranet zone or Trusted sites zone. Internet Explorer security settings for the Intranet zone or Trusted sites zone do not provide a sufficient level of isolation of apps from user data in SharePoint sites.

  • For single tenant environments, use the same prefix for all apps

    If your environment is only used for your own organization and does not host SharePoint sites for other organizations, you configure a prefix that all app for SharePoint URLs in your environment use. For example, you can set the prefix to a word like default so that each app for SharePoint has a URL such as

  • For multi-tenancy environments, use unique prefixes for each tenant's apps

    If your environment has multiple tenants (in other words, you host SharePoint sites for multiple clients), you must be able to identify the URLs that each tenant or client in your environment uses. So, you set the URL prefix to indicate the client's name or the client's site's name. For example, suppose that A. Datum Corporation hosts SharePoint sites for Fabrikam and Fourth Coffee under the hosting domain (for example, and You should set the prefix for your hosted sites so that they are created as and

    If you are in a multi-tenancy environment, you must use the Set-SPAppDomain cmdlet in Windows PowerShell to configure the URL and prefix. For more information, see Configure the app URLs to use.
  • Keep prefixes short and simple

    Prefixes must be less than 48 characters and cannot contain special characters or dashes.

  • All URLs will be in the default zone

    If you are using alternate access mapping on a web application, you cannot use apps for SharePoint. Apps for SharePoint cannot use multiple zones in alternate access mapping. By default, all apps for SharePoint are available only in the default zone. Consider using host header site collections instead of alternate access mapping; apps for SharePoint are fully supported for host header site collections.

As a best practice, we recommend that you use a single web application that uses host-named site collections (host headers) instead of multiple web applications that use path-named site collections in your environment. When you use multiple web applications and path-named site collections you might have to complete additional configuration steps to guarantee that requests for apps for SharePoint are routed to the correct web application. For more information about host-named site collections and logical architecture, see SharePoint 2013 design samples: Corporate portal and extranet sites.

If you decide to provide approved apps for SharePoint for site owners to install, you can configure the App Catalog to contain those apps for SharePoint. The App Catalog is a special site that contains the apps for SharePoint that site owners can install.

The following illustration shows the difference between the App Catalog and the SharePoint Store, and how the on premises IT professional can control which apps a site owner can install.

Contrasts the SharePoint Store and the App Catalog.

Contrasts the SharePoint Store and the App Catalog

You can have more than one App Catalog in your farm, one for each web application in your farm. To configure the App Catalog for a web application, you just have to supply the names of the site collection administrators who you want to use for the App Catalog site. After you create the App Catalog, the site collection administrators can upload apps for SharePoint to it.

To plan App Catalog settings, determine the following:

  • Which web applications will need an App Catalog.

    This goes together with your decisions about your policy for supporting apps for SharePoint in the SharePoint environment. If you have different types of sites (intranet, extranet, Internet) on different web applications in your farm, you can determine whether you want an App Catalog for each of those web applications.

  • Who to add as the site collection administrators for the App Catalog.

    The App Catalog is a site inside a web application that can only be accessed from a link in Central Administration or directly by using the URL.

  • This section applies only to SharePoint Server 2013.

  • App monitoring is not available in SharePoint Foundation 2013.

  • App monitoring is not supported for SharePoint Server 2013 on-premise, multi-tenancy environments.

SharePoint 2013 Farm administrators can monitor apps for SharePoint to track the usage data and results, and any errors that occur. The Farm administrator must add apps to the Monitor Apps page in SharePoint on-premises in order for the apps to appear in the list. The maximum number of apps that can be monitored on the Monitor Apps page is limited to 100.

The Monitor Apps page requires the following search analytics and usage file import timer jobs to be active:

  • ECM analytics timer job name: Usage Analytics timer job for Search Service

  • Usage DB timer job name: Microsoft SharePoint Foundation Usage Data Import

SharePoint 2013 does not enforce app licenses. Developers who build apps must add code that retrieves license information and then addresses users. SharePoint 2013 provides the storage and together with SharePoint Store web services the app license renewal. SharePoint Store handles payments for the licenses, issues the correct licenses, and provides the process to verify license integrity. Note that licensing only works for apps that are distributed through the SharePoint Store. Apps that you purchase from another source and apps that you develop internally must implement their own licensing mechanisms. SharePoint 2013 supports the following app licenses formats:


License Type Duration User Limit





30, 60, 120 Days, or Unlimited

Number per user or Unlimited

Paid per user


Number per user

Paid unlimited users (site license)