SharePoint 2013 brings with it a brand new application model, which we euphemistically refer to as the “app model” or “cloud app model”. While it brings a whole new set of opportunities from a development perspective, it also carries with it infrastructure requirements that you need to plan and build to support them. When I think about the app model in fact there are really three big pieces that I look at:
Now let’s start working through the list of these different infrastructure components. First and foremost, you need to make sure that you have an instance of the App Management and Subscription Settings service applications created and running in the farm. The App Management service is used for things like keeping track of applications and deployments, licensing, etc. The Subscription Settings service is the same service application that is used for multi-tenant deployments, and it is also used by the app model to create the unique Urls that are used by applications.
So how are these Urls created? Well it starts with the Apps configuration that you do in Central Admin. When you go into Central Admin you will find a new section called Apps. If you click on it you will see an option to Configure App Urls. In there you will find two values that are used to create an application Url – the App Domain and App Prefix. The App Domain is analogous to the host name that is going to be used for all applications in the farm. Here are three things to consider when you plan for this name:
So let’s look at a specific example. Suppose your web applications are something like team.contoso.com, my.contoso.com and portal.contoso.com. First of all, you probably don’t want to use just “contoso.com” for your App Domain, because doing so will require you to create a wildcard DNS entry for ALL of contoso.com that points to your apps endpoint (more on that in a minute). Also you don’t want to use something like “apps.contoso.com” because that is a child domain to what you are using for your web applications (which are all rooted in “contoso.com”). So a better choice based on these rules would be something like “contosoapps.com”.
The App Prefix value can be anything you want – it’s plugged into the first part of the application Url, which we’ll talk through next.
I mentioned using a wildcard DNS entry above, and that’s the next part to cover. When an application is installed and that application is hosted in SharePoint it will have a Url that is something like this: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. The elements of the Url break down like this:
As you look at the Url and how it’s formed, hopefully you understand why you will want to use a wildcard DNS entry. Because the first part of the Url is going to be different for every single application instance that is installed – even if the same application is installed in multiple site collections – it is not feasible to continually update your DNS for every single instance. So that being said, that means for DNS for the scenario I’ve described here, you are going to want a wildcard DNS entry for *.contosoapps.com. Now the IP address that it points to is something we’ll discuss in just a bit.
Related to the wildcard DNS entry is a wildcard SSL entry. Just so we’re perfectly clear on this point – if you’re using apps, you should be using SSL. The app model involves passing around OAuth access tokens, which describe who the current user and application are. Just like if you were passing around SAML tokens for a user, you want to encrypt the channel that these tokens flow over to prevent any kind replay style attack that would grant access to content by someone who might be out there sniffing your network traffic. Using SSL prevents those scenarios from happening, and since you’ve seen the Urls for these applications are going to be different for every installed instance, it also means that in order to be manageable you will need a wildcard SSL certificate. Again, in our scenario, we would get a wildcard SSL certificate for *.contosoapps.com.
Okay, so far we’ve talked about the service applications that are required, the configuration that is required for the App Domain and Prefix, how the Urls are formed, and the DNS and SSL entries that are needed. Now to tie everything off we need to talk about how application requests get routed. Generally speaking, you will need a separate SharePoint web application just to do the routing of application requests. Let’s take a look at why that is. Suppose again that you have three web applications that are defined as follows; they are all using SSL so we are using unique IP addresses for each one:
Now as described above you can only have one App Domain in the farm, and it should not be a child domain. This opens up two very real problems with the applications above:
The solution then is to create a fourth web application. SIDE NOTE: Technically you could create a second IP and SSL binding on an existing web application as long as that web application does not use a host header. You would of course then need to bind the SSL wildcard certificate for your apps namespace to that SSL binding. I do not cover that in the description below, but if you are doing a PLA-style deployment (i.e. one web app and only use host header site collections) that would be another option. This is already fairly complicated so I don't want to try and work that into the rest of this content, but wanted to point it out for completeness. You can create it without a host header name and assign it a shared IP of 192.168.1.13. In DNS then your wildcard entry for *.contosoapps.com will point to 192.168.1.13. What ends up happening is that your apps web application “listens” on that IP address and the SharePoint http module that is responsible for routing will pick up the request for the application. It will then use the App Management service application to determine what web application is actually hosting that application and request all of the information about the app, security, etc.. The request is then served from the web application that was listening, which is why it needs to be using the same app pool account as the other web applications are using - so it can access the content databases for those web apps.
Now our farm configuration looks like this:
No host header, or you could use something like contosoapps, etc. – it doesn’t really matter since we aren’t routing based on host header, we’re routing based on IP address.
Now, that we have all of the infrastructure configuration aspects of apps covered, there are a couple of other considerations you need to remember when planning for the rollout of new apps for SharePoint 2013:
One other important, final note: this seems like a lot of configuration, and it is. However, you should keep in mind that if you are using Office 365 then all of this is taken care of for you - no muss, no fuss, just easy to install and use applications. You should give that some consideration when weighing your options.
So there you have it – SharePoint Apps are a big part of SharePoint 2013, but they require some planning and design work up front to ensure the infrastructure is in place to support them.