Holly cow, it has been a while since I posted something. I have been doing much more management than tech stuff as of late, so I haven't had a lot to comment on. HOWEVER, now that my migration to SharePoint 2013 is done and I am starting to create Apps for SharePoint 2013, I have some gotchas to talk about.
I have an On Prem farm, complete with two WFEs, two Application Servers, two Office Web App Servers, two Database Servers, and now two IIS servers for provider-hosted SharePoint Apps.
Configuring you farms for Apps is actually pretty straightforward, but there are a lot of moving parts. Microsoft has really come through with some excellent documentation on how to get everything working. With an On Prem solution, you do have to make sure that you configure your certificates correctly, otherwise S2S auth will not work.
The gotcha that really tripped me up was the configuration of an app domain. What SharePoint does when you deploy a SharePoint hosted app or a provider hosted app with a SharePoint hosted component, is create a sub web off of the web where you are installing your app. This sub web is called the "App Web" and requires you to do some configuration. That configuration is well documented here. What that documentation DOESN'T tell you is that there are some things that you need to consider before pointing your app domain to your existing SharePoint DNS entry. There are some IIS considerations that you need to make.
IIS happily sits on your windows server listening for HTTP traffic. When you configure a new web site, you need to be specific with your IIS binding to make sure that two sites do not conflict. The easiest way to do this, without adding IP addresses to your IIS servers and because we want to have multiple sites listening on ports 443 or port 80, is with the use of Host Headers. The Host Header will tell IIS that any HTTP traffic coming in on a particular port, that has the DNS name of SharePoint.MyCompany.com goes to the correct web site. Most SharePoint deployments make use of Host Headers as they want to host both the Primary SharePoint Web Application and the MySites web application on the same servers in the farm.
Now, when you configure your app domain in DNS, you point the app domain to your primary SharePoint deployment with a wildcard CNAME alias. Here comes the fun part... Your app will have the URL of prefix-APPID.myappdomain.com.
If a wildcard alias points your traffic from prefix-APPID.myappdomain.com to SharePoint.MyCompany.com, AND you have IIS with a host header configured for SharePoint.MyCompany.com, the traffic from prefix-APPID.myappdomain.com will be ignored. Not only will it be ignored, it might get picked up by another web site... Such as the Default Web site that is configured without a host header, and set to respond to any IP address on the server by default. In that case, you will receive a 404 error when attempting to connect to your app, because the default web site is not where you deployed your app web.
Therefore you MUST remove the host header from your primary SharePoint IIS site. This, likely, will cause a conflict with your Default web site, so you must either stop that site, or remove it. What a pain!!
Now, if you have a provider hosted app, that uses a SharePoint hosted app web for authentication and other reasons, you will get strange errors that will have you chasing down the Cross-Domain library rabbit hole. Check your config first to be sure you are going the right direction!
