SharePoint Disaster Recovery vs. Active Passive Farms

Just a quick clarification on terminology & methodologies for SharePoint “disaster recovery” (DR). In case you didn’t know already, multiple SharePoint farms can be run sharing the same content data, which is very handy if you need near 100% uptime for your SharePoint sites & apps. If for any reason your primary farm dies, you…


Patching SharePoint DR Farms with Replicated Service-Applications with SQL Server AlwaysOn

So now we’ve got an active/passive SharePoint farm solution setup, the next question that is how to patch both farms with as little drama as possible. We need to patch one farm while the other’s in use so that our beloved users don’t notice anything’s even happened to SharePoint – one of the key reasons…


Running SharePoint Service Applications in Read Only Mode for Disaster Recovery Farms

As mentioned before, there’s good reason to have a disaster recovery (DR) farm setup for SharePoint if you need near 100% uptime. As also mentioned, you may need to synchronise some service-applications between farms too for data consistency; taxonomies, user-profiles etc often go hand-in-hand so having unique service-applications on each farm just isn’t an option….


Combining Disaster Recovery Farms with SQL Redundancy for SharePoint with SQL Server AlwaysOn

Alternative title: “how do I get a redundant SQL backend combined with a disaster recovery site, using AlwaysOn”? This is a question that has come up a bit just recently so I though I’d clarify how this can work. Arranging the SQL Server AlwaysOn setup for SharePoint, especially when a contingency/disaster-recovery farm is involved alongside using…


Synchronising Service Applications Between SharePoint Disaster Recovery Farms

A key part of hot-standby/disaster-recovery SharePoint 2013 farms is the principal that only content is synchronised between the two farms. The reason being is that we want to reduce the chance that a failure will replicate over to the other farm too, so we just replicate content and keep services separate in each farm. This…


SharePoint Disaster Recovery Failover Techniques

So you’ve got or are interested in two SharePoint farms running in parallel and you want to know how to switch users between the two farms for when you need to. There’s a few options to do it; choosing the right one largely depends on how quickly you need to be able to failover everyone,…


Introduction to Running Disaster-Recovery/Hot-Standby SharePoint Farms

So you’ve heard about the possibility of running two SharePoint farms in parallel to help keep SharePoint users happily online longer, and you want some more information about how it works and why you’d want it. This one is a nice and quick post on just the basics to sell the idea a bit -…


Patching SharePoint with No Downtime using SQL Server AlwaysOn

As highlighted in a previous post, it is perfectly possible to patch SharePoint without suffering any downtime at all if you have x2 SharePoint farms to play with. This is great if you’re worried about the update process taking either too long for a maintenance window or not completing at all (initially). Edit: here’s some important…


Setting up SharePoint Disaster Recovery Sites with SQL AlwaysOn

Something I’ve been promoting as an essential high-availability strategy for SharePoint for a while now is having a Disaster Recovery (DR) site for SharePoint. A SharePoint DR site is simply an entirely separate SharePoint farm that uses a copy of the content data in case the first farm runs into problems for some reason, or…


Why Disaster Recovery Farms are Essential for High-Availability SharePoint

It’s not uncommon for customers plan a highly-available SharePoint (HA-SP) installation to satisfy uptime requirements for the business. It is uncommon that said designs give an architecture in the best way for staying online always though, and this is what this post is about. The Normal High-Availability SharePoint (HA-SP) Strategy The normal approach to SharePoint…