SharePoint 2013 Apps: Setting Up an App Domain for SharePoint

One of my clients recently had a variation on the App Domain theme, that presented a set of challenges that I have not seen well documented elsewhere. TL;DR: We had multiple Web Applications hosted on Windows Server 2008 R2 that had to implement SharePoint App domains with SSL, and no Wildcard Certificate for the Web Applications.

Trawling through Google brought up a few posts(see here and here) but none that gave clear guidance (at least to me) on how to manage the scenario above. The closet I got was here, but this relied on using Windows Server 2012 or above, which in our case, was not an option at the time

First, a little background. The client had a well architected environment that took into account High Availability, as well as a very high level of security (The Web Front Ends were on a different VLAN to the App servers which were on a different VLAN to the SQL servers which were on a different VLAN to the normal users. As well as this, there were firewalls between each layer, which made it a challenge to figure out which ports to open – but that is another blog post)

Scenario

We had already architected the environment for High Availability, and had the structure shown below in place. The missing pieces were the apps and how they were set up. We had always planned to do SharePoint Apps, but there had been no need at the start. A project was coming along that required us to get it working however, so hence this post.

Requirements

  • Host Multiple SSL Web Applications to isolate the security and content
  • Use Windows Server 2008 R2
  • NO Wildcard certificates were allowed on the main domain (e.g. *.deviq.local)
  • An ACE Load Balancer that was unable to be configured to manage multiple DNS/IP

This left us scratching our heads for a bit. Eventually, after a lot of thought and discussions, we came up with the following architecture:

SP2013AppTopologyWithSSL_V2

Web Applications

intranet.local

This Web Application contained migrated content from SharePoint 2003. In this instance, the client required that the SharePoint 2003 environment was to be decommissioned (due to Windows Server 2003 not being supported and an Active Directory upgrade would have made the SharePoint 2003 environment potentially unusable due to changes in the LDAP environment).

portal.local

This Web Application would be hosting the new Document Management system, and was to be kept separate from the others

businessapp.local

This was a SharePoint application that had been developed in SharePoint 2010 and had subsequently been upgraded to work with SharePoint 2013.

Hopefully, the diagram above is a fairly good explanation as to what was going on from an Infrastructure and Architectural point of view.

Topology

The SharePoint environment was composed of the following servers:

2 x WFE
2 x App Servers
1 x  ACE Firewall
2 x SQL Server

Network/DNS Tasks

  • Create DNS entry for intranet.deviq.local and point to ACE VIP IP (30.1.1.10 in above diagram)
  • Create DNS entry for portal.deviq.local and point to ACE VIP IP (30.1.1.20 in above diagram)
  • Create the DNS Foreword Lookup zone as you would according to the MS Guidance (in the diagram above, we have set this to *.spapps.deviq.local)

Firewall/Load Balancer Tasks

I will have to confess, that this was a step that I had to get the Network guys to do. This is some arcane voodoo to me, as I am a developer by trade that has had to delve into the Infrastructurey side of things for this environment. (ASIDE: Having said that, I think that ALL SharePoint developers should have at least some understanding of what is going on underneath it all).

The tasks that we are summarised below. Your environment may differ – speak to the network guys

ACE Firewall Tasks

  • Create Entry for intranet.deviq.local on IP 30.1.1.10 for port 80 and 443
    • Ensure that redirect to HTTPS from HTTP occurs
    • Balances between 10.1.1.10 and 20.1.1.10
    • Ensure "sticky" sessions


  • Create Entry for portal.deviq.local on IP 30.1.1.20 for port 80 and 443

    • Ensure that redirect to HTTPS from HTTP occurs
    • Balances between 10.1.1.20 and 20.1.1.20
    • Ensure "sticky" sessions


  • Create Entry for IP 30.1.1.30 for port 80 and 443

    • Ensure that redirect to HTTPS from HTTP occurs
    • Balances between 10.1.1.30 and 20.1.1.30
    • Ensure "sticky" sessions


Network

Get the network guys to do allocate some IP addresses and add them to the associated servers. This is important, since we are using Windows Server 2008 R2, and each Web Application requires its own IP address to be able to bind a different SSL certificate to. Using Host Headers is not going to cut-it in this situation

  • Allocate 9 IP addresses as follows:
    • For intranet.deviq.local
      • 30.1.10 - ACE Firewall
      • 10.1.1.10 - Web Server 01
      • 20.1.1.10 - Web Server 02


    • For portal.deviq.local

      • 30.1.1.20 - ACE Firewall
      • 10.1.1.20 - web Server 01
      • 20.1.1.20 - Web Server 02


    • For a SP WebSite with no host header

      • 30.1.1.30 - ACE Firewall
      • 10.1.1.30 - Web Server 01
      • 20.1.1.30 - Web Server 02




Certificate Tasks

The next step was to get the network guys to create some SSL Certificates for us. Since this was a large organisation, they had their own PKI, so the certificates were generated internally. You may need to use a different approach if getting SSL certificates from another certificate authority

  • Create New SSL Web certificates for the following:
    • intranet.deviq.local
    • portal.deviq.local
    • Wildcard for *.spapps.deviq.local
      • NOTE: Ensure that the *.spapps.deviq.local is entered into the Subject Alternate Name otherwise the wildcard cert will not work as a wildcard cert




Server Tasks

The next task was to allocate the new IP addresses to the appropriate Web Applications on the Front End Web Servers. Note that these IP addresses are in addition to the others that may be present (e.g. HeartBeat IP, other web applications, etc)

  • Web Server 01:
    • 10.1.1.10
    • 10.1.1.20
    • 10.1.1.30


  • Web Server 02:

    • 20.1.1.10
    • 20.1.1.20
    • 20.1.1.30


SharePoint Tasks

Finally, we are now able to do the SharePoint stuff to (hopefully) make all this work

  • Create the new Web Applications using PowerShell to ensure that Database names etc. can be controlled in a repeatable manner (NOTE: You may need to use a Hosts file at this point to ensure that the sites can be created). I will leave it as an exercise to the reader to do the creation. Suffice to say, we need to create 3 web applications:
    • intranet.deviq.local
    • portal.deviq.local
    • Blank web application with no host header


IIS Tasks

Next, we need to tell IIS which AP’s and SSL certs belong to which SharePoint web site

  • Web Server 01
    • intranet.deviq.local
      • 10.1.1.10
      • Host Header of intranet.deviq.local
      • Bind SSL certificate that was generated for intranet.deviq.local  to port 443


    • portal.deviq.local

      • 10.1.1.20
      • Host header of portal.devqi.local
      • Bind SSL certificate that was generated for portal.devqi.local to port 443


    • empty web site (i.e. No Host Header)

      • You are going to need to stop the Default web application
      • 10.1.1.30
      • Bind the SSL certificate that was generated for *.spapps.deviq.local to port 443




  • Web Server 02

    • intranet.deviq.local
      • 20.1.1.10
      • Host Header of intranet.deviq.local
      • Bind SSL certificate that was generated for intranet.deviq.local  to port 443


    • portal.deviq.local

      • 20.1.1.20
      • Host header of portal.devqi.local
      • Bind SSL certificate that was generated for portal.devqi.local to port 443


    • empty web site (i.e. No Host Header)

      • You are going to need to stop the Default web application
      • 20.1.1.30
      • Bind the SSL certificate that was generated for *.spapps.deviq.local to port 443




Verify AAM in Central Administration

Now that IIS has been configured, you will need to ensure that the Alternate Access Method entries have been set appropriately for the new DNS entries

Set up App Services

The next step is to set up the  app services to use the spapps.deviq.local address with whatever prefix you want (e.g. apps). The TechNet article covers this part quite well.

*phew*

Hopefully at this stage, you now have your add-ins running across HTTPS on your infrastructure. This is most likely not something that you will get to do too often, as I think it is an edge case for on-premises. However, this burnt a lot of time for us, and I have not found a lot of clear guidance or walk-through on how to do this, so wanted to share with the community at large.

Any feedback is very welcome

Richard

Richard is a Director and the principal Consultant at Dev iQ Pty Ltd. He specialises in SharePoint, Team Foundation Server/Visual Studio and .NET Development.

Subscribe to richard angus

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!