Monday, September 22, 2014

The challenge of configuring SharePoint 2013 for Apps

I am in the process of configuring new SharePoint 2013 farms in preparation to move from SharePoint 2010 to SharePoint 2013. I also have K2 BlackPearl and K2 Smartforms (which is brilliant and I shall post separately about).

I need to get the App stuff configured in order to use the new K2 for SharePoint.

I did quite a bit of research on this subject and it is quite complex and there is a lot of material available on the web. I have to admit it has taken several days to get this configured to a point where it seems to be working.

These are some of the posts I referred to;

However, these did not really give me all of the answers I needed. I think I have finally worked it out so I will share some points that helped me.

My scenario is that I have multiple SharePoint web applications which use host headers. I followed the guidance and created new ‘app’ domains for dev, staging and production rather than using sub-domains. These are just entries in our internal DNS for now. Unless we start publishing apps outside the firewall, there doesn’t seem to be any point in registering those domains externally. We generated wild card certificates for each of those domains from our Active Directory infrastructure.

Because I have two wild card certificates, one for SSL for my SharePoint web applications and one for the new App domain, I had to create a second IP address for each of my web front end servers. The DNS was configured so the new domains pointed at the second IP address. (I have seen some posts that Windows Server 2012 has some new capability to use a single IP address, but 2 addresses seemed simpler.)

Then I had to create a SharePoint web app on port 80 with no host header as per Jeremy Thakes post;

Some people have written posts about needing a root site collection to get it to work. However, it wasn’t clear where this needed to be created. In my case, the default SharePoint web app on port 80 does NOT seem to require a root site collection. The web apps that you are deploying to DO require a root site collection. (Because I have not yet restored my 2010 databases, I only had a dummy site collection which was not at the root.)

Then I started getting certificate errors. So now in IIS manager I changed the bindings on the SharePoint Default port 80 web site. I changed this so that ports 80 and 443 both bound to the second IP address and configured the SSL certificate to be the one generated for the apps.

Now I can publish a simple App from Visual Studio 2013 and it loads without errors.

In summary;

  • Create two IP addresses on the WFE, one for SharePoint and one for Apps
  • Configure DNS for the new domain you created for Apps to point to the second IP address on the WFE.
  • Create separate wildcard SSL certificates for SharePoint and for Apps.
  • Create a ‘Default’ SharePoint web application using port 80 and no host headers. (No need to configure it with Alternate Access Mappings to support SSL. No need for a site collection.)
  • In IIS Manager change the bindings for the ‘Default’ SharePoint web site to bind to the IP address designated for the apps. Assign the app wild card certificate to the https entry.
  • Bind the https entry for all of the other SharePoint web sites to the other wild card certificate.
  • Follow the guidance from various other sources to do the App configuration (starting the services, creating the service application etc)
  • Try publishing an app from the template in Visual Studio 2013 and see if it renders correctly and all SSL connections work without errors.



It wouldn’t surprise me if this is not the end of the story. However, I hope this might help someone else get to some of the answers more quickly than I did.

1 comment:

Jeremy Thake said...

Thanks for writing this up.

FYI there is a video in our training section about setting up your on-premises environment that references a lot of the MSDN pages that are available.