Let’s take a look at making use of the one of the new features of
SP2013, Apps. Whether you’re planning to use downloadable apps across your
organisation or a developer creating your own, both require a correctly
configured app infrastructure.
MS recommend that you have a separate domain name for Apps that is not a
child of the domain in which your servers are sitting. They also say you need
to ‘purchase’ a domain name, what they fail to say is this is only applicable
if your publishing apps externally. If, like me you’re configuring this within
the walls of your corporate network, then simply creating a new domain is
possible without making a purchase in the real world.
Important! – This isn’t creating a new domain as you may imagine,
because that does sound overkill right? Actually it’s about creating a domain
(zone) in DNS. This then needs to have a wildcard alias. This is so your App
namespace can eventually be ‘AppName.DomainName’.
Head over to your DNS console and create a new Forward Lookup Zone, this
should be of type ‘Primary’ and replicate to all DNS servers in the domain.
Now this is present, we now need a new Wildcard Alias for this zone.
Right click on the new domain you just created and choose CNAME, add an * to
denote wildcard in the Alias Name section. In FQDN, add in the full URL of your
SharePoint site.
OK, were done now for DNS, let move onto to configure SharePoint. We
need two service applications created to deal with the App infrastructure, App
Management Service Application and Subscription Settings Service Application,
and their associated proxies.
As for App management, not really anything out of the ordinary here.
Central Admin – Service Applications – New – App Management Service
Give the Service Application a decent name, its own database and app
pool and let it create an App Management Service Application Proxy.
When done this will appear in the list of Service Applications
Open up the SP Management Shell on of your 2013 servers, run the
following to set a variable with the desired managed account, obviously his
account must be present in managed accounts in central admin – security:
$account = Get-SPManagedAccount "ServiceAccountName"
OK, now let’s create a new application pool using the account we set earlier and store to a variable.
$appPoolSubSvc = New-SPServiceApplicationPool -Name “Subscription Settings Service Application Pool” -Account $account
And now to bring it all together, creating the service application using the variable we created before, we’re adding the name of the Service Application here and giving it a database name:
$appSubSvc = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPoolSubSvc -Name “Subscription Settings Service Application” -DatabaseName SharePointSubscriptionSettingsService
And finally, the proxy for the Settings Service Application, we don’t get the option of giving it a name here.
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubSvc
Head to Central
Admin - Apps and click on Configure App URL’s
On this
screen we set supply SharePoint with the app domain we created earlier in DNS.
Also you need to go for a prefix for the apps. I’ve gone for SP, but you can go
for anything you want.
Change the
web application to the one in which you wish to create the site collection, and
select ‘Create a new app catalog site’
Hit next
and at the next screen you create a site collection just like any other. The
only difference being adding the ‘End Users’ i.e. group of people that can see
the apps in the store.
You can add AD groups in here or individuals. If this is for all your users, then add ‘Everyone’, that should cover it.
You can add AD groups in here or individuals. If this is for all your users, then add ‘Everyone’, that should cover it.
Okay, so now we run into a bit of a gotcha. Although everything is configured correctly, and you can head to the app catalog and add apps. If you attempt to use an app you've added you will get a HTTP 404. This is due to our wildcard domain we created in DNS. The app URL will be correctly produced, with the prefix-appid.domain which in-turn resolves to your SharePoint box but obviously IIS is not recognising this host header and knowing which web application to route it to.
The solution to this is to create an 'empty' web application on port 80 without a host header. This will then receive any unrecognised requests and know what to do with them. Give this a name of something descriptive, I've called mine 'SharePoint App Host', on port 80 and leave the host header blank.
Important! - Make sure the app pool you choose has access to the web application databases you're using for your apps. Otherwise you will get random access issues. So you want to choose the same app pool as your other web applications, or, if creating a new one (as I am in the screenshot below) choose the same security account you used for the other pool..
You'll notice in the screenshot above that I've called the database 'temp' this doesn't matter as when the web application has been created, you can go to Databases - Manage Content Databases and remove this.
Now you should be able to add, use and develop apps!
