App Management and Subscription Settings
High-level steps:
- Create a forward lookup zone
- Create a web application (so that IIS will have an endpoint for that zone)
- Create a wildcard cert for secure communication
- Create a subscription settings service application (decide about least privilege)
- Create an app management service application (decide about least privilege)
- Give the account that is the identity for the application pool that houses the service application the proper server roles in SQL (db_creator and securityadmin)
- Configure your SharePoint site in IIS to use SNI on it’s binding (whether HNSC or not)
- Configure your SharePoint-Apps site in IIS to listen on port 443, all unassigned, with the *.sharepointApps.com cert, *.SharePoint-Apps.com, *.companyApps.com, or *.whateverYourDomain-Apps.com cert is named.
- Create an app catalog site or team site in the app catalog web application at the root
- Create an app catalog site in the web application for your SharePoint sites
- Add some apps
- Monitor Apps
- Manage App licenses (if any)
- Remove Apps
Note: There are additional steps for Access 2013 Service application
More info on this whole fiasco
There are a lot of schools of thought out there around configuring the App Management Service and Subscription settings service and a quite a few of them instruct to use the farm account. That approach would cause the App management service and Subscription Settings service to run in an over-privileged fashion. It is possible to spin up the app management and subscription settings service using the existing application pool that you’re running the other SharePoint service applications. The only issue with that approach is that the identity running those service applications would then have higher privileges in SQL after the App management and subscription settings service are created. This may or may not be an issue. The Microsoft Technet does not recommend any particular approach, as it says in step 8 of this post https://technet.microsoft.com/en-us/library/fp161236.aspx under the “Create the App Management service application in Central Administration” section that you can choose an existing application pool or create new.
The same is true for the Application Pool identity that runs the application pool that houses the endpoint for the Subscription Settings Service Application service application. Both, the App Management Service Application and Subscription Settings Service application need to run under identities that have db_creator and securityadmin fixed server roles in SQL. Normally, the service account that houses the other SharePoint service applications does not have these fixed server roles in SQL.
Access Service 2013
When it comes to Access Services 2013, the same is true for the account that runs the application pool that houses the endpoint for the service application. That identity needs db_creator and securityadmin in SQL. So, you could create one application pool for all three of these: Access 2013 Service application, App Management, and Subscription Settings.
This powershell will spin up the Subscription settings in an existing application pool; so, that means that the identity that runs that pool would need to be elevated
$databaseServerName = "SharePointSQL"
$saAppPoolName = "SharePoint Hosted Services"
Write-Host "Creating Subscriptions Settings Service…"
$SvcApp = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $saAppPoolName -Name "Subscription Settings Service Application" -DatabaseName "SubscriptionSettingsdb" -DatabaseServer $databaseServerName
$SvcAppProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $SvcApp
Get-SPServiceInstance | where{$_.TypeName -eq "Microsoft SharePoint Foundation Subscription Settings Service"} | Start-SPServiceInstance
This powershell will create a new application pool, and then you’d need to use a new account if you’re truly going to keep the Shared Hosted Services identity least privileged. Otherwise, if you were to use the same identity here, you would over privilege all the other service apps. The key here to remember is that this is the only way to keep your other service applications least privileged. And, the account being used below must already be a managed account in SharePoint. (e.g. you’ve ran New-SPManagedAccount or have added it via the Central Admin GUI)
$appPoolUserName = Get-SPManagedAccount "DOMAIN\Prd2016-SP_APPS"
$saappPoolName = "App and Subscription Settings AppPool"
$saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName -EA 0
if($saAppPool -eq $null)
{
Write-Host "Creating Service Application Pool…"
$appPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName -EA 0
if($appPoolAccount -eq $null)
{
Write-Host "Please supply the password for the Service Account…"
$appPoolCred = Get-Credential $appPoolUserName
$appPoolAccount = New-SPManagedAccount -Credential $appPoolCred -EA 0
}
$appPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName -EA 0
if($appPoolAccount -eq $null)
{
Write-Host "Cannot create or find the managed account $appPoolUserName, please ensure the account exists."
Exit -1
}
New-SPServiceApplicationPool -Name $saAppPoolName -Account $appPoolAccount -EA 0 > $null
}
$appSubSvc = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $saAppPoolName –name "Subscription Settings Service Application" -DatabaseName SubscriptionSettings
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubSvc
After running this powershell, you can go to manage service applications in your farm and see that the Subscription Settings Service application is created. You should also see the proxy. Don’t worry if you don’t see the proxy immediately, sometimes it takes a minute or two for it to appear. Reset IIS and look again.
Once you run that code you’ll have an application pool named AppSettingsServiceAppPool, that runs under a new active directory account and not the account that runs the Shared Hosted Services. This brings up the discussion about the Secure Store Service, and the fact that Microsoft says that this service application should have its own application pool in order to be truly least privileged. Although, the farm will work fine if you run the secure store in the Shared Hosted Services Application pool, the same can be said for the configuration of the Subscription Settings and App Management. Remember, Step 8 of https://technet.microsoft.com/en-us/library/fp161236.aspx explains that the application endpoint can run under the application pool of your choosing. This means either create a new application pool, use the same app pool that you use for subscription settings, or use the Shared Hosted Services application pool. In either case, you need to give the identity that runs the app pool the fixed server roles in SQL of db_creator and securityadmin.
If you opt to use the same app pool as the subscription settings service, this is the powershell:
$appPoolName = "App and Subscription Settings AppPool" $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolName –Name "App Management Service" -DatabaseName "AppManagement" $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
If you opt to use the same app pool as the SharePoint Hosted Services, this is the powershell:
$databaseServerName = "SharePointSQL" $saAppPoolName = "SharePoint Hosted Services" $saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $saappPoolName –Name "App Management Service" -DatabaseName "AppManagement" $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
Whichever application pool approach you choose, you do not need to use the farm account as the account to run the app pool as this would over-privilege the apps and subscription settings. The account will need the fixed server role of db_creator and securityadmin in SQL.
Unlike the Subscription Settings service application, the app management service application can be created via the Central administration GUI. The choices are clear and similar to creating any service application: give the name for the service application, its database, and the application pool and account. Remember, to truly least privilege the SharePoint Hosted Services apps, a separate application pool and identity would be needed for this app, and this requires more server resources.
DNS Changes for Apps
You need to create a forward lookup zone that uses a different name than what your SharePoint sites use. This is for security reasons. A lot of companies go with appending apps to whatever their name is. For example, this blog might choose to go with anothersharepointblogapps.com if it were to use SharePonit and have an apps domain. The Tampa Bay SharePoint User group site at https://www.tbspug.com might opt to use tbspug-apps.com for the apps domain. You get the point. This is performed by creating a forward lookup zone and then adding two records to that forward lookup zone as follows:
Host A Record
Same as parent that points to the IP address of the WFE
CNAME record
Wildcard (*) that points to the name of the forward lookup zone
Technet would have you point the wildcard at the WFE, which would also work.
Web application and IIS Site changes
You need to create a web application either on port 80 or port 443. If creating on port 443, you specify port 443 and use ssl when creating the web app. If you want the web app to use a vanity URL, you DO NOT use a host header. You create the web application without a host header and then go back and alter the public URL to your vanity URL. For example, if you wanted the web application for the apps site that the www.tbspug.com sharepoint site will use to be located in the tbspug-apps.com, you would create the web application on port 443 and then it would spin up https://servername showing 443 as the port in the web application management page in central admin. Then you would navigate to the Alternate Access Mappings and make the changes there to change servername to apps.tbspug-apps.com and because you have a wildcard in the forward lookup zone at tbspug-apps.com traffic to apps.tbspug-apps.com will route to the WFE. Then in IIS you make some things happen so that all unassigned requests route to the site where you have the apps.tbspug-apps.com web application.
In IIS, the new web application will be listed under the sites node and you can assign the binding to the wildcard cert here for all unassigned. At first it will automatically have whatever cert you have specified for the www.tbspug.com site that runs your sharepoint and you don’t want this. You also do not want the www.tbspug.com site to change to use the wildcard cert that you’ve acquired for your apps either. For example, let’s assume you’re running host named site collections and that the www.tbspug.com site is a hnsc under a web application named SharePoint – HNSC:443, the binding for that www.tbspug.com site would show a cert named something like *.tbspug.com. This allows you to have accounting.tbspug.com, books.tbspug.com, beer.tbspug.com, and so on and so forth.
The new web application needs to use the tbspug-apps.com without affecting the www.tbspug.com, so what you do is on the www.tbspug.com is select the server name identification box. Then you go and set the site where the apps are located to all unassigned and you do not set server name identification on this site. You also make sure that the default site is turned off and that the default site is not turned on. Some blogs advise removing the default site; but, you do not have to do this, as this is the site that SharePoint uses as it’s template to create new sites. Just make sure the default site is turned off.
Steps up to this point
- Obtain a wildcard cert for apps, e.g. *.tbspug-apps.com or *.domain-apps.com
- Decide which application pool will house the endpoints for the app management service, subscription settings service, and access 2013 service application.
- Create the Subscription Setting Service using powershell
- Create the application management service using powershell or the GUI
- Create the DNS forward lookup zone, host A record, and CNAME record
- Create a web application to house the apps management site on port 443
- Optional step: change the AAM of the web app to a vanity name
- Turn off the default site if it is on, it should be off by default
- Set the SharePoint sites to use SNI in their binding
- Set the Apps site in IIS to use all unassigned and be bound on port 443
Next steps
Now that we’ve got the App Management Service Application stood up either in it’s own application pool, along with the subscription settings service, running under an identity that is not the farm account, and that identity has the db_creator and securityadmin fixed server role in SQL, it is time to create the app domain setting inside the SharePoint Central Administration. You can do this one of two ways. As technet says in the section entitled “Configure the app URLs to use” on this post https://technet.microsoft.com/en-us/library/fp161236.aspx this can be accomplished from clicking on Apps > Configure App URLs > and then enter the app domain (tbspug-apps.com) and then a prefix for the apps. Usually, people just enter app or apps for the prefix, but you could use whatever you want.
You can also accomplish this setting using powershell, as follows:
Set-SPAppDomain <appDomain>
e.g.
Set-SPAppDomain tbspug-apps.com Then after you run that, you would run this to set the prefix
Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false
Where app is the prefix you chose, if you wanted your prefix to be set as Acme-Apps you would run:
Set-SPAppSiteSubscriptionName -Name "Acme-Apps" -Confirm:$false
Some of the Apps in the SharePoint store require internet facing endPoints and if you plan to use any of those apps, you’ll also need to run this line:
Set-SPAppStoreConfiguration -Url http://office.microsoft.com -Enable $true
From this point on the process of adding apps is straight forward, you click add an app and then either add an app from the SharePoint store or one that you’ve developed. If you’re working with Access 2013 Service application, you’re not done though, as there is more that needs to happen to the server. This blog by Kirk Evans, is by far the best resource for getting the 2013 On-Premises farm setup for Access Services: https://blogs.msdn.microsoft.com/kaevans/2013/07/14/access-services-2013-setup-for-an-on-premises-installation/ there are more changes to the SQL server that we didn’t cover in this post, as of yet, and these include:
Make sure the following features are installed in the instance:
- Database Engine Services
- Full-Text and Semantic Extractions for Search
- SQL Management Tools feature (for troubleshooting)
- Client Tools Connectivity
Make sure these settings are in place on the instance:
- Security Mode = Mixed Mode
- Service Account (db_creator, securityadmin)
- Enable Contained Databases = True
- Allow Triggers to Fire Others = True
- Default Language = English
- TCP/IP Protocol = Enabled
- Named Pipes Protocol= Enabled
- Windows Firewall Inbound Ports TCP 1433, TCP 1434, and UDP 1434
Microsoft has written an excellent white paper on this called Office 2013-Access Services Setup for an On-Premises Installation http://www.microsoft.com/en-us/download/details.aspx?id=30445
The last step is to configure the service application pool to load the user profile. Kirk’s blog lists out a couple of the common issues that are sometimes faced with Access Services.
