When setting up a second SharePoint farm for disaster recovery purposes, there are all kinds of things to take into consideration. Most of those are perfectly covered in other blogs and on TechNet.
With the new app model though, there is one additional factor to take into account: apps! When in case of a disaster you need to switch operations over to your second farm, you want your apps to remain working. And there’s some stuff you need to take care of to make sure they do. Read on to find out what.
Note that the below items do not cover the basics of DR farm synchronization. So I assume you are using two farms and that your databases are somehow mirrored or synced between them.
1. The app set-up
Maybe a bit of a no-brainer, but first thing to do is to make sure that both environments are configured in the same way to use apps. More specific, make sure your app domain and app prefix are the same in both farms and that the same site is used as an app catalog.
2. Site synchronization & app catalog
If you’re planning to use the app catalog, you need to make sure this site collection is synchronized with your DR farm. That process is equal to normal site synchronization, so nothing new there. But remember: when creating new site collections you need to detach & attach your content databases in the DR farm to make sure SharePoint registers the newly created sites in its internal sitemap.
3. Token signing certificates
This is usually the point where things start going wrong. The development team created a new app which uses a certificate to sign its security tokens. In order to get the app to work, the certificate needs to be installed on the SharePoint farm servers and added to the trusted certificates list. Do not forget to do this on the DR farm too! If you don’t, the DR farm won’t be able to verify the signed tokens and your app will be denied access to SharePoint. Nasty!
4. App registration & authentication realm
This last one is the real gotcha. For (fulltrust) apps you’re adding manually, you need to register the app. This is usually done either in Powershell (my personal favorite) or via /_layouts/15/appregnew.aspx. Now you might think this information is stored in the content database with the site, but you would be wrong. Instead, this data is stored in one of the databases which is not synced automatically. So again, you need to do this on each individual farm.
The gotcha though, is the authentication realm which is used to (partly) identify the app. You might recognize a string like:
i:0i.t|ms.sp.ext|214f73f0–dd1e–4203–b786–fa0ac77bbb02@050f8591–559f–4bcf–b3ec–555f660e9708
This string registers the app in SharePoint and is used to assign permissions to the app. The last part of this string is made up out of two guids seperated by an ‘@’-sign. The first is the app client id, the second is the authentication realm (farm id). That “(farm id)” addition should trigger you to think: hey, that one might be farm dependent. And indeed: it is. So without any action, each farm will have it’s own authentication realm which will imply a different ID and thus a different identification string for apps.
Now in our DR set-up, we obviously want the DR farm to be as equal to the primary farm as possible. Luckily, Microsoft has provided us with the Set-SPAuthenticationRealm cmdlet which allows you to modify the realm. So: get the realm from your primary farm and make sure you update your DR farm to match it. That way, both farms will generate the same identification string for your apps and permissions will be properly sinced. Note that it’s best to do this before setting-up any apps. Changing the realm will result in existing tokens becoming invalid, so it’s best to do this before you set-up any apps. Also, if you’re planning on using site subscriptions, it’s possible that you’ll be using multiple realms (one per subscription). If that’s the case, you need to ensure that the entire collection of realms (and subscriptions) is equal across farms. I would advise to automate that.
Follow the above steps and switching to your DR farm should not break any installed apps any more. Of course, in case of provider hosted apps you might also want to consider a failover for your IIS servers (or whatever webserver you use for that matter).
Update 10-04-2015: a not to be forgotten addition has to be made to this article. For a proper set-up, you need to verify that your database sync scheme includes the App Management and Subscription Settings service application databases. These are very important for apps and not syncing them will lead to errors like:
app “i:0i.t|ms.sp.ext|930fc405-2029-4afc-bfe4-8cd7a9f22e15@56775c06-47b3-4957-9b5b-003e2b4b0d23” does not exist.
If you ever come across this error, it’s likely that you forgot to put those databases in sync. Also, syncing these databases eliminates the need to register your app on the secondary farm since the registration will be synchronized through the databases instead. So that saves you step 4 from this blog post!