[SP2013] SharePoint add-ins in DR farms
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 add-in model though, there is one additional factor to take into account: appsadd-ins! When in case of a disaster you need to switch operations over to your second farm, you want your add-ins 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 add-in 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 add-ins. More specific, make sure your add-in domain and add-in prefix are the same in both farms and that the same site is used as an add-in catalog.
2. Site synchronization & add-in catalog
If you’re planning to use the add-in 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 add-in which uses a certificate to sign its security tokens. In order to get the add-in 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 add-in will be denied access to SharePoint. Nasty!
4. Add-in registration & authentication realm
This last one is the real gotcha. For (fulltrust) add-ins you’re adding manually, you need to register the add-in. 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 add-in. 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 add-in 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 add-in 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 add-ins.
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 add-ins and permissions will be properly sinced. Note that it’s best to do this before setting-up any add-ins. Changing the realm will result in existing tokens becoming invalid, so it’s best to do this before you set-up any add-ins. 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 add-ins any more. Of course, in case of provider hosted add-ins 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 add-ins 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!
Update 23-11-2015: a colleague pointed me to another issue when using add-ins in a DR scenario, especially SharePoint hosted add-ins. These create an appweb to store artifacts in. Such an appweb is essentially just a specific sort of site collection created on a generated URL (the appweb url). Now when you’re syncing content databases, you might know that SharePoint won’t pick up on newly created site collections until you refresh the sitemap. This is due to the sitemap being stored in the config database which is not synced in DR scenarios. So although your database might feature a new site collection, the index won’t know about it until you refresh it. This refresh you can perform with some PowerShell magic, schedule the following script to run daily:
$contentDB = Get-SPDatabase | where {$_.Name -eq "WSS_Content_Contoso"}
$contentDB.RefreshSitesInConfigurationDatabase()
This will refresh for a specific content database, you might want to create a foreach loop to do all content databases depending on your specific set-up. Of course this is not only useful for appwebs, it allows discovery of normal site collections as well. I grabbed the script from this blog, check it for some more detailed information.
Leave a Comment