Share via

Enabling the SharePoint App Store on-premise

  • Article

There are some really great apps out there for Project Server and SharePoint 2013, especially the various Bulk Edit applications that mimic the built-in functionality of the Resource Bulk Edit feature in the Resource Center of Project Server 2013. There can be significant demand from the users to getting this functionality up and running. But, to enable them you have to do a little beyond-out-of-the-box configuration. If you are running Project Server inside a company, likely it's going to touch on networking and security configuration issues as well. There are already some great guides out there, but no all-in-one doc I can find that produces reliable results, so I'll take a stab based on what I've learned deploying this functionality. There's a lot of moving parts, so bear with;

 

Overview (Things you need)

  • A Wildcard SSL Cert.
  • Wildcard DNS routing.
  • Enable internet endpoint routing.
  • Turn on App Management Service and the Microsoft SharePoint Foundation Subscription Settings Service.
  • Create Subscription Settings Service and App Management Service app and proxy.
  • Configure App Store URL's in Central Admin.

You'll want to familiarize yourself with the official documentation as well.

https://technet.microsoft.com/en-us/library/fp161236.aspx

 

Wildcard Certificates

There are some items not clearly covered in the documentation above. Like, where to put the cert, how to configure it, etc. I'll go over the items I've discovered, and between that and the documentation, should put all the pieces together for you:

  1. DNS name needs a wildcard prefix: '*.Myserver.Mydoman.net'. The asterisk is the standard 'wildcard' element.
  2. Friendly Name gets the prefix too. '*.Myserver.MyDomain.Net'.
  3. CN of the Subject gets it as well: "CN = *.Myserver.MyDomain.Net'.
  4. You want the certificate in the path of the trusted Root signer.
  5. You place the cert in the Personal Certificates folder of the Computer's zone, not the user zone when you start up the certificate snap-in to import it.
  6. Bind the cert in IIS Manager to your web application.
  7. The trickiest part I ran into was, you have to put the server names in the Subject Alternative Name zone of the certificate. Short and long names. Presumably you're running in SSL anyway, so this works for the apps, and the server, Example Subject Alternative Name:

DNS Name=*.ProjectServer
DNS Name=*.ProjectServer.MyDomain.Net

DNS Name=ProjectServer

DNS Name=ProjectServer.MyDomain.Net

DNS Name=MyAppServer1

DNS Name=MyAppServer2
DNS Name=MyWFEServer1
DNS Name=MyWFEServer2
DNS Name=MyWFEServer3
DNS Name=MyWFEServer4

DNS Name=MyAppServer1.MyDomain.Net

DNS Name=MyAppServer2.MyDomain.Net
DNS Name=MyWFEServer1.MyDomain.Net
DNS Name=MyWFEServer2.MyDomain.Net
DNS Name=MyWFEServer3.MyDomain.Net
DNS Name=MyWFEServer4.MyDomain.Net

 

Wildcard DNS Routing

This piece is covered pretty well in the docs. So I'll skip it, but I'll try and answer any questions that come up. I just create a zone for it.

 

Enable Internet Endpoint Routing.

This is a proxy and firewall issue. Essentially you're just opening up access for the app store to reach out and hit the MSFT SharePoint store. It's possible to install apps from the store offline, if you can get the author to send you a copy of the installer package, but this is not guaranteed/out of your control, so probably not the best way to handle it. Plan ahead on this piece, because this will likely be a business decision around security, more than a config issue. The Config is generally easy, if your server can hit bing.com, you're there, and this piece is complete.

 

Enable Services

Very easy, just launch SharePoint Central Admin and click on 'Services on Server'. Turn on both services. But keep in mind, this does NOTHING to configure them, and the subscriptions settings literally cannot be configured through the Central Admin UI. You MUST use PowerShell.

 

Create Proxies

Enter PowerShell. There's several example scripts out there, they vary in nuance, but this worked great for me. I run them line by line, just in case.

 

$account = Get-SPManagedAccount DOMAIN\FARMADMIN
$appPool = New-SPServiceApplicationPool -Name SubscriptionServiceAppPool -Account $account
$serviceApp = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -name "Subscription Settings Service" -DatabaseName "FARMNAME_Subscription_Settings_DB"
$serviceAppProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $serviceApp
$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name "AppServiceAppPool" -DatabaseName "FARMNAME_App_Service_DB"
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

Pretty easy. Moving on.

 

Configure URL's

This piece is pretty straightforward. Pop back into Central Admin and click on the Apps section.

Click Configure App URL's, and enter the app domain in the top box: ProjectServer.MyDomain.Net

In the bottom box, enter the prefix for any app that will be running in the farm. I just use "App", nothing fancy.

 

 

Troubleshooting

At this point, you should be able to add apps, and things should work great. Note the use of the word 'should'. There are some gotcha's, and items that may not have gotten set correctly.

 

  • The first, and most important, is to keep in mind who you are and where you are. If you are logged in as the FarmAdmin account, you cannot interact with the app store. You'll get cryptic errors.
  • Second, you should be in the web app you want to add applications to. Most likely, your app install will be blocked if you entered the app store through Central Admin. Be in PWA or whatever you called your Project Server app when you enter the app store.
  • "Sorry, apps are turned off. If you know who runs the server, tell them to enable apps." This must be a catch-all error. Of course, it's caused by setting the option in Configure Store Settings in SharePoint Central Admin to 'no' for allowing users to get apps from the store. Assuming that is not the problem, the error can be very frustrating. Most likely cause is a config piece that sometimes gets set, sometimes not when creating the App Management Service.

In Central Admin go to Application Management and Manage web Applications.

Highlight the web app you need to access the store on (where it is currently failing) and click Manage Features.

Activate the "Apps that require accessible internet facing endpoints" feature at the top. Click ok.

Click Service Connections. Most likely, the App Management Service Application for the '[custom]' connections group, is not checked. Turn it on.

  • More specific to the bulk edit apps for Project Server, ensure the oData feed is functioning, or they will never work. You should be able to see Project data at <ProjectServer.MyDomain.Net/PWA>/_api/projectdata/Projects . If you can't, the bulk edit apps won't work. This can be broken by having a reserved name in a Custom Field, such as naming a field "Project ID". If you need that name, try an underscore instead of a space, to make it unique.
  • Memory/CPU Consumption. Keep an eye on the W3WP process on your WFE servers. This is also where apps run, and if the app is badly designed or misbehaving, it can potentially bring down your farm. Especially if, again in the case of Project Bulk Edit apps, it allows your user to attempt to load every project and every field on the server.

 

Hopefully this helps demystify the process a bit, and fills in some of the gaps on the documentation linked up towards the top. Have a great day!

Comments

  • Anonymous
    February 01, 2016
    The comment has been removed