SharePoint DR strategies

Hi Folks,
Andrzej here. My role in Predica is Managing Partner and Infrastructure Architect. Today I’d like to share with you some insights on SharePoint Server 2010/2013 Disaster Recovery (DR) design.

Truth is, designing SharePoint DR is not a trivial task. SharePoint is a distributed application with a 3-tier architecture (web, application, database), and on each of those tiers we have multiple web applications, service applications and databases that communicate with each other. Additionally there is a number of underlying technologies that can be used in a DR design: Hyper-V Replicas, SQL log shipping, database mirroring, SQL 2012 AlwaysOn and SharePoint-level backup (PowerShell, stsadm). On top of that we can have SQL Remote Blob storage so part of our content is on a file store, custom applications and code that integrates with SharePoint and needs to be included in DR design.

There are a number of 3rd party products that allow to simplify (or at least add new options) to the DR design, but of course none of them is free of charge. Products, like Neverfail for SharePoint, AvePoint DocAve High Availability, Idera SharePoint Backup, Metalogix Replicator, or Microsoft’s Data Protection Manager, might be a good choice for some companies, but I do not recommend choosing any of them before careful technology validation/proof-of-concept and price/performance comparison. Let’s call it “experience”. In this article I want to focus only on what is available out-of-box as Microsoft native DR strategy.

In this article I will present two architectural patterns for SharePoint DR design:

  1. Single farm for high bandwidth, low latency DR sites
  2. Separate farm for low bandwidth, high latency DR sites

Before starting with your DR design you should collect following information:

  • Business requirements:
    • Recovery Time Objective (RTO)
    • Recovery Point Objective (RPO)
    • Note that they may be different for different content or different applications
  • Financial budget: DRC will require
    • Hardware
    • Licenses (different Microsoft editions, potential 3rd party products)
  • IT operations manual labor cost and availability
  • DRC site network parameters:
    • Bandwidth (Mbps)
    • Bandwidth available (%)
    • Latency (ms)
    • QoS capabilities
    • Load-balancing switch/router capabilities

How those scenarios are different in terms of DR approach from Sharepoint.

Scenario 1 – Single Farm

Key points:

  • 1 farm spanning 2 sites: a more hands-off approach
  • Requires synchronous database replication (e.g. with SQL AlwaysOn Availability Group), as

SharePoint does not support asynchronous replication of administration/configuration databases: link

  • You will need a sound network connection to DRC, recommended is min. 1Gbps and <10ms latency
  • Most of SharePoint SQL IO will be read (probably 60-80% for content management scenarios), so mirroring with AlwaysOn is a good solution, as writes, which need to travel across sites, are less frequent then reads, which do not
  • Failure of DRC SQL replica does not impact MAIN SQL instance
  • If you want to minimize the amount of traffic on the wire between sites, consider removing some databases from the availability group, and use a backup/restore or re-create method for them. Good candidates are: web analytics, search, user profile
  • If required this approach can facilitate automatic site switchover (with a witness in a 3rd location): I would not recommend this for various reasons outside the scope of this discussion – automatic DR switchover is only applicable in specific cases
  • Use network load balancing to divert traffic to DRC site, or keep an active/active setup, where DRC front-end/application servers connect to the currently active SQL Replica

Here’s simple diagram to illustrate this scenario (click to enlarge):

Scenario 2 – Separate Farm

Key points:

  • Separate farm in DRC
  • Only content databases are replicated asynchronously across site-link
  • Does not have stringent requirements on the site-link
  • Requires manual work overhead to manage, update the DRC farm
  • Switchover procedure requires more time and steps to be taken: DNS or load balancer changes, bring up the content databases online and attach them to DRC farm..
  • When restoring service applications, ensure you restore through SharePoint API (Powershell/stsadm/central admin) as Microsoft does not support restore of some service applications or configuration/administration databases from SQL backups
  • If you use SQL Remote Blob Storage (RBS) on some of your content DBs, good news is that with SQL 2012 AlwaysOn you can replicate content databases – just remember to configure RBS on the replica as well

As previously, simple diagram below illustrates this scenario (click to enlarge):

What to choose … where to go …???

These three aspects will have the most impact on the DR design decisions:

  • your Main-DRC network capabilities
  • RPO/RTO requirements
  • manual labor cost of managing a second, separate farm.

This was a very general overview, and there are a number of hybrid approaches.

My goal here was only to make you aware of some caveats. If you are still hesitant about how to approach SharePoint DR or any other SharePoint subject for that matter, do not hesitate to contact us!

This was your DR-host for today, Andrzej … stay tuned for upcoming posts.

Cover picture: (ccInnisfree Hotels

ADFS SharePoint attribute store

Hi guys, it’s Paweł again – your SharePoint architect trying to make own little name in the identity world. In one of my previous posting from SharePoint meets identity series, I was writing about ADFS and its features. One of them was the ability to perform various operation on claims using attribute stores. During the course of the project which inspired this series, I had an challenging opportunity to create a custom attribute store which would provide data from SharePoint lists. So I thought it would be great if I shared my great invention with the outside world and the outside world should appreciate it as well, so this post will be all about that.

Continue reading

SharePoint meets identity – part 2 – technical basics (ADFS)

Hi, here’s Paweł again with SharePoint and identity goodies.

After my first post on the topic you should be pretty convinced (or at least you should think you are) that claims present some interesting possibilities in the area of SharePoint security. Let’s jump directly to the details of that and let’s validate if this assumption is true on something real. If you are already experienced with SharePoint, you should probably know it by now, that you can never assume something in SharePoint works the way you expect it to. That’s why whenever I design something, I always first validate it, because sometimes in the end it turns out… you know what.

To have something “real” to work on, you need to have a proper setup first.  Again, if you are somewhat experienced SharePoint guy, or girl (on the side: then please mail me, cause I’ve never met any ;)), then you should have some base SharePoint VM in place with SQL, Active Directory and SharePoint itself. If not I suggest you stop reading here, because it might not make much sense if you do. Having that, there is one additional thing you need – Active Directory Federation Service (ADFS).

Note from our infrastructure team: Whenever you are reading ADFS right now and you are running something lower than Windows Server 2012, we are not speaking about the service which is available as part of a system. It referees to ADFS 2.0 which you can download from the Internet (and remember about the fixes).

The “proper” setup which I meant before is simply having Active Directory as an identity provider, ADFS as a relying party and SharePoint as a target application (which not entirely true since SharePoint is also sort of a relying party, but let’s simplify for now), so the “identity flow” would be AD->ADFS->SharePoint. There are some nice guides how to prepare this setup on the web (like Steve Peschka blog which you have to subscribe to if you seriously thinking about doing some claims in SharePoint), so I won’t waste our precious time here for this – I want to focus more about what results we get from it and how we can utilize them in real-world solutions.

OK, but why do you need ADFS in the first place? ADFS is acting as a proxy by which identity information (claims / user attributes) flow from identity providers (like AD) to the target applications (like SharePoint) – click on a picture to enlarge it:

But as I mentioned in my previous posting, AD is not the best place to find identity information if you are considering Internet-facing scenario, so in this case ADFS will still be a proxy but this time between an external identity provider (ACS in our case) and target application (again – click to see bigger version):

Of course it is not just 1-to-1 proxy passing through all information, but allows to transform it and make some authorization decisions based on it. So once you went through ADFS-with-SharePoint-and-AD setup, you should already have some basic understanding about claims, what kind of information they hold and how to control it. AD identity provider can be used as a good starting point to play around with claims, but later it can be changed to something else.

If you look into ADSF management console, you’ll find something like this under SharePoint relying party configuration (you know what to do do see it bigger 😉 ):

This is where you define which attributes from Active Directory transform into what claims available later for defining access in SharePoint. The interesting thing about these settings is that you don’t have to rely entirely on AD’s (or other provider’s) data, but for example based on user’s account or e-mail get some extra information from some external data source:

The external data sources are called attribute stores in ADFS terms and by default they can be:

  • Active Directory
  • SQL Server
  • LDAP

But also you can create own attribute store or find some ready-to-use from the web:

The concept of attribute stores and their usage in claim flow from identity providers to target applications is important, because it allows to normalize claims coming from different sources and add some additional ones which target applications might utilize in their authorization logic.

Once the claims are processed in ADFS with or without transformations by attribute stores assistance, they are passed to target applications – SharePoint in our case and this is where their primary role begins. The setup you might have done already according to Steve’s blog entry includes also SharePoint configuration, but what exactly are the implications of such setup to working with SharePoint data and security, I will continue writing about in the next posting.

If you are looking for good source of step-by-step configuration for ADFS and SharePoint you can also visit Jorge’s blog where he provides good description of ADFS side of infrastructure (start with Part 1 and there is 8 more).

SharePoint meets identity – part 1 – claims business concept

Hi, my name is Paweł and here at Predica’s team I hold an honored position of SharePoint architect. Like it or not / love it or hate it, but SharePoint earned its place among many companies as a primary intranet solution, often integrating other systems within the company, sometimes also exposed to the Internet. Therefore I would like to share some from-the-field experience in designing SharePoint solutions based on the real-life projects we either did or are doing in Predica.

Note: This is first of the series of posts where I want to present the approach we have taken and implementation details for authentication and access management for Internet facing SharePoint solution.

Recently, we were approached by an customer with interesting requirement for a new solution preferably based on SharePoint. The story in general concerned an Internet-facing portal which should serve companies and individuals being the customers of our customer’s company. The primary goal for the portal was to allow the users to access various documents and participate in the processes which our customer provided for them, which meant that each of them should have own personal secured space (site) where the data could be stored.

Although, it does not seem like a big challenge, doing it properly, according to what you may understand as “standard Internet way of doing things” was not a that easy as it might look like.
First assessment of the fundamental assumptions for the new system, raised a question: how will we handle authentication and authorization? What were these requirements:

  • Our “users” were no necessary internal users. In most cases these were external users, which might be individuals or employee of partner companies
  • Our “solution” can be hosted outside of internal network in data center of our customer choice so it should be not very dependent on the infrastructure and easy to re-deploy

When you think SharePoint obviously authentication and authorization choice is Active Directory. At least it was so far. In this context though, the first thought is “nah, this doesn’t seem right”. OK, but why?

First reason (putting aside all kind of licensing considerations) is that if users in our solution mostly will be coming from the outside world and they will not be related to company which is hosting the application, why “service provider” should be bothered with maintaining these user identities and accounts at all (which will be a case if we would choose Active Directory as our identity store of choice)? Registration, information changes, password resets … think only about these aspects of this decision.

Another fundamental problem with Active Directory based approach for authentication and authorization in SharePoint context is that managing security based on AD groups simply means managing user accounts and groups.

The concept of groups is great (or else WAS great some time ago), if only it wouldn’t mean you have to manage them…

Simple example: you have an employee in your company who belongs to HR department and you have a group “HR Department” to secure some file shares, SharePoint sites and God knows what more. So what happens when this person moves to another department? Well, the person must be removed from the group and possibly added to another one. Lucky you, if you have some automated solution which does that for you (like Forefront Identity Manager, which we also deliver by the way :)). And unlucky you if you don’t and you have more than 10.000 employees… Of course same problem applies to SharePoint groups, which additionally cannot be embedded within each other.

So, taking all that and inspired by Tomek (our identity architect) and his passion to claims-based authentication approach, I decided to dig into the subject in the context of SharePoint security to see if indeed it can bring some resolutions to these problems. The whole idea of claims is in the air for some time now, but surprisingly I never saw any implementation of it in the real system, which made me a little suspicious. If you are not familiar with the concepts of claims, Boogle or Ging (whatever you prefer) more about it or use you favorite source – MSDN (this is a good start BTW), there’s plenty of information out there, so I will only  focus on the essence of what it is.

The best analogy that comes to my mind thinking about claims in SharePoint context is that they give you possibility of attribute-based security management. Now, what that means? Looking back at the previous example, what IS/SHOULD really happen when for example a person changes department within the organization?

(IS) You update his/her Active Directory account or any HR management system to relate to the new department and (SHOULD) all security related the previously held position should be revoked and access required for the new position should be granted. For some organizations it might seem like a wishful thinking, but in fact it’s not – it is possible and achievable. This is where claims can successfully come into play. If you related your security against person attributes (department in this example) rather than on his/her group membership, all security-related management should happen by itself.

Of course, relating claims to Active Directory attributes is a narrow-minded thinking, because AD is only one of the possible identity providers. You can think about Facebook, Google, Live and others which can serve the same function, also totally custom or based on already existing HR or customer databases. In our customer’s story, AD was out of question, but external Internet providers should serve the purpose very well (and also wouldn’t give you this tedious Windows credentials login window in the browser, like Windows authentication does). So it seems we have a winner in the design concept competition. But of course this is just the beginning of a long way to making this really work.

This article should only give you a glimpse of what claims-based authentication is. My intention is to follow on this subject in posts following this one, to share more information about the real design and the technical concepts implemented, which caused the project successfully meeting its assumptions both providing proper security and low management need. But because the concept for this particular project might seem quite specific, I will also keep mentioning how these concept could apply in the enterprises to increase information security and ease manageability.

So stay tuned!

Image courtesy of tungphoto / FreeDigitalPhotos.net