Skip to main content


Configuring SharePoint 2013 Preview for On-Premise Apps

Since Apps are the “next big thing” for SharePoint, from an opportunity perspective, expect to see a lot of hullaballoo about how you should create apps because they’re going to be the greatest thing to happen to SharePoint since Shared Service Applications replaced the Shared Services Provider.  However, not all apps are created equal, and apps can be created in several varieties.  This blog is focused on setting up the flavor that the developer has the most control over: On-Premise Apps.

Update: After receiving a bunch of issues with Host Headers, I’ve posted a new blog covering host headers for both web applications and site collections here: SharePoint 2013 Apps and Host headers

Configuring SharePoint 2013 Preview for On-Premise Apps

On-Premise Apps are difficult to set up because you have to do all of the setting up to get your apps hosted on SharePoint manually.  There’s no pre-configured Office 365 environment for you to use.  Unfortunately, none of these steps can be done through the UI other than the creation of a Developer Site.  To successfully develop SharePoint On-Premise Apps, you need a Developer Site Collection, a pair of Shared Services Applications, running Shared Services Instances, the Office Developer Tools for Visual Studio 2012 Release Candidate, and an App Domain and prefix.  I’ll step through each item below.

Note: Microsoft has a guide just like this one on their SharePoint 2013 documentation site: How to: Set up an on-premises development environment for apps for SharePoint []

Developer Site

While you don’t explicitly need a Developer Site to use or develop SharePoint On-Premise apps, the site template provides testing and certification functionality that doesn’t exist in other site templates.  Therefore, I recommend that you create one to simplify your initial app development.  You can only deploy from Visual Studio to a Developer Site.  Fortunately, creating a Developer Site works exactly like creating any other site collection.  Note: a Developer Site must be a site collection.  You cannot create a developer site as a sub-site.

  1. Open Central Administration and select Create site collections under Application Management
  2. Give your site collection a name and URL.  Then select Developer Site from the Template Selection view.
  3. Click OK to create your Developer Site.  Remember the address because you’ll need it for development.

Create an Isolated App Domain

The way that SharePoint 2013 hosts Apps is somewhat odd in that there’s a single domain that Apps reside in regardless of where they actually reside on SharePoint.  SharePoint 2013 does this through site host headers, a little-known feature that actually exists in SharePoint 2010.  So while physically a SharePoint App becomes a sub-site of the site that it’s activated on, it’s logically located at a custom app domain.  The advantage here is that you can control Apps on a network level and it fully isolates the apps from SharePoint.

This isolation comes into play with cross-site scripting restrictions and prohibiting access directly into SharePoint except through the SharePoint Cross-Site Scripting library.  This reason right here is the major reason for an Isolated App Domain for SharePoint Apps.  Anyway, let’s talk about creating this isolated domain or sub-domain.

Create an App Domain

You’ll need to be running an elevated SharePoint Management PowerShell to complete this task:

  1. Ensure that the SharePoint Administration and SharePoint Timer services are running
     1: Start-Service SPAdminV4

     2: Start-Service SPTimerV4

  2. Create your isolated app domain by running this command with your App Domain in quotes:
     1: Set-SPAppDomain -AppDomain ""

Running Shared Services Instances

Before you create your App-specific Shared Services Applications you need to make sure the Shared Services Instances are running on at least one of your SharePoint farm servers.  You can do this either through an elevated SharePoint Management PowerShell or Central Administration:

From PowerShell:

  1. Start the Shared Services Instances if they aren’t started already:
     1: Get-SPServiceInstance | Where-Object {$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance

  2. Ensure that the Shared Services Instances are Online:
     1: Get-SPServiceInstance | Where-Object {$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}

From Central Administration:

  1. In Central Administration select Manage services on server from the System Settings group to open the Services on Server
  2. Make sure that the App Management Service and Microsoft SharePoint Subscription Settings Service are started on at least one server

App-Specific Shared Services Applications

Once your Shared Service Instances are started, you can create your Shared Services Applications to host apps: App Management Service Application and Microsoft SharePoint Foundation Subscription Settings Service Application.  You should only have one of each shared services application because the Subscription Settings Service is finicky about multiple App Management Services at the moment.  You also can’t create the Subscription Settings Service from Central Administration, but you can create an App Management Service Application from Central Administration.  This walkthrough will omit the Central Administration way because of this creation limitation.

Another important point is that both of these shared services applications must run on Application Pools running with farm administrator credentials.  The simplest option is to reuse the SharePoint Shared Services System application pool.  If you insist on creating your own application pool, your managed account must be a member of the farm administrators group.

You’ll need an elevated SharePoint Management PowerShell to complete this task:

  1. Get a handle on the SharePoint Shared Services System application pool:
     1: $applicationPool = Get-SPServiceApplicationPool -Identity "SharePoint Web Services System"

  2. Create the Subscription Settings Service Application:
     1: $appSubscriptionService = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service" -DatabaseName "SubscriptionSettingsServiceDB" -ApplicationPool $applicationPool

  3. Create the Subscription Settings Service Application Proxy:
     1: New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubscriptionService

  4. Create the App Management Service:
     1: $appManagementService = New-SPAppManagementServiceApplication -Name "App Management Service" -DatabaseName "AppManagementServiceDB" -ApplicationPool $applicationPool

  5. Create the App Management Service Proxy:
     1: New-SPAppManagementServiceApplicationProxy -Name "App Management Service Proxy" -ServiceApplication $appManagementService

App Prefix

Now that you have your Shared Services Applications you can set the App prefix on the SharePoint farm.  This does a lot of stuff behind the scenes, especially with the Secure Token Service (STS) to open up the OAuth channels necessary for your Apps to communicate with SharePoint.  You must have your Shared Services Applications created and running before this step.

You’ll need an elevated SharePoint Management PowerShell to complete this task and a little bit of patience:

 1: Set-SPAppSiteSubscriptionName -Name "App" -Confirm:$false


Add Your App Domain to the List of Intranet Sites in Internet Options

Now that you’re able to host apps, you’ll want to visit their pages.  Since you’re going to be crossing domains to get to the app from SharePoint, you’ll get prompted for credentials.  You can silence that prompt by adding your App Domain to the list of intranet sites in Internet Options from Internet Explorer.

  1. Open Internet Explorer, click the Gear icon, and select Internet Options
  2. Select the Security tab and then click Local Intranet
  3. Select Sites to open the Local Intranet sites detector.  From here select Advanced to set the list of sites
  4. On the list of sites, provide your App Domain preceded by a star (as shown in the example) and click Add to add it to the list
  5. Now that your app domain is added, click Close and then OK twice to save the settings.

Office Developer Tools for Visual Studio 2012 Release Candidate

Now that your SharePoint farm is configured for On-Premise Apps, you’ll need to grab the Office Developer Tools for Visual Studio 2012.  Unfortunately, SharePoint 2013 Preview and Office 2013 Preview shipped after Visual Studio 2012 Release Candidate, so Visual Studio doesn’t have any SharePoint 2013 tools built-in.  However, there’s a download for the tools available through the Microsoft Web Platform Installer.

Note: you’ll need a copy of Visual Studio 2012 Release Candidate installed to use the tools.

  1. Open Microsoft Web Platform Installer and select the Products group
  2. In the search box type Visual Studio 2012 Office and select to install both the Microsoft Office Developer Tools for Visual Studio 2012 RC – Preview and the Microsoft Visual Studio Tools for Office 2012 Design Time – Preview.  If you’re international, you can download the Microsoft Visual Studio Tools for Office 2012 Design Time Language Pack – Preview as well.
  3. After you’ve selected Install and accepted the license, the Microsoft Web Platform Installer will download and install the necessary prerequisites and items to set up the tools.

Using Your New App

From here, you are ready to create and deploy your first SharePoint app.  Be sure to use the URL for the Developer Site you created in the first step or Visual Studio will not deploy your App.

Disclaimer: My initials are ADS, and neither I nor Perficient have any affiliation with  I use it in this example because it’s short and easy to remember.

Thoughts on “Configuring SharePoint 2013 Preview for On-Premise Apps”

  1. First of all setting up on-Premise Apps is ,as you have to do all of the setting up to get your apps hosted on SharePoint manually and lot of setting can go wrong.

  2. Great post. Well documented and made it much easier for me to follow through and complete the setup. I was able to create a SharePoint 2013 developer site, package, deploy and install my SharePoint App. However launching the installed App from my site resulted “HTTP 500 Internal server error”. I have completed all configuration steps including isolated domain for Apps. I can also ping the App url. I am using VS.NET 2012 to build, deploy and install the App without any error.
    Any idea? Thanks in advance.

  3. Investigating SharePoint log with search string of the App url revealed the following message:
    App Deployment – The current user has System.Threading.Thread.CurrentPrincipal.Identity.Name = 0#.w|kandev15\sean …
    App Auth – App token requested from appinfo.ashx for site: db9a8a53-133f-4a5e-bde0-d122d89ac0c8 but the token was not generated.
    But I was not sure where I missed. If this has to do with the App Prefix then I surely have followed and executed properly.

  4. Sean,
    Are you able to deploy the starter Visual Studio SharePoint 2013 On-Premise App (i.e. the one you get by creating a new App and selecting On-Premise as the deployment type)? If you can, then the deployment and on-premise environment is configured correctly.
    If you’re trying to use OAuth or something more advanced then simple pages, JavaScript, and SharePoint assets, you might run into implementation issues that haven’t been completely cleaned up within SharePoint 2013 Preview yet. For example, OAuth does not currently work correctly with On-Premise apps. From your short post, I would start your search by looking into appinfo.ashx and determining what is happening in that handler.

  5. Andrew,
    I just tried using Napa tool to create a simple App consists of one page plus JavaScript file showing a Welcome page. The App worked on SharePoint 365 Preview. I exported the project into VS.NET 2012 and change the Site Url propery of the project to my on-premises site. Hit F5, everything looks good except the last step to launch the App from Site Contents page. I continue to get the “HTTP 500 server internal error” with “Web page cannot be displayed” message on page. The exact same project can be deployed to SharePoint 365 Preview site though. So I think there is something missing in my on-premises setup.

  6. Sean,
    Unfortunately, in SharePoint 2013 Preview, there’s still a significant difference between On-Premise and Office 365 apps and, as far as I am aware, you can’t deploy a Napa-based app as an On-Premise app and vice-versa.

  7. With having so much content and articles do you ever run into
    any issues of plagorism or copyright infringement?
    My site has a lot of unique content I’ve either created myself or outsourced but it looks like a lot of it is popping it up all over the web without my agreement. Do you know any techniques to help prevent content from being stolen? I’d genuinely appreciate it.

  8. Andrew Schwenker

    This has happened to me several times. Sadly, there’s no real way to prevent it. You can only treat the symptoms, which for us usually starts with the legal department notifying the poster or their ISP with a DMCA takedown notice. From there, I don’t know what else happens because it’s out of my hands.

  9. Pingback: はまる、App for SharePoint 2013 (オンプレミス; on-premises) とVisual Stuidoでのsharepoint hoted apps アプリデバックの環境(enviroment) : Exceedone Technical Knowledge

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Andrew Schwenker

Andrew Schwenker is a Sr. Technical Consultant within Perficient’s Microsoft National Business Unit East's SharePoint practice. Andrew has nearly 2 years of experience in consulting and has participated in projects that have touched nearly every aspect of SharePoint 2010. Andrew earned his Bachelor’s degree in Computer Science as well as Master’s degrees in Computer Science and Information Systems from Indiana University. He’s interested in creating winning solutions to generate business innovation using SharePoint. Prior to starting at Perficient, Andrew completed internships with General Electric, ExactTarget, and Great American Financial Resources. During his studies, he actively participated in Alpha Phi Omega National Service Fraternity and competed in the first annual Cluster Challenge at SC07 in Reno, NV. Andrew was a part of the dynamic PointBridge team that was acquired by Perficient.

More from this Author

Follow Us