SharePoint 2013 Disaster Recovery- Creating, Testing and Maintaining the DR Plan- Part 1

This article is 1 of 4 articles that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.

One of the first steps of a DR plan and introduces the reader to the activities around creating, testing, and maintaining an effective DR plan for their SharePoint environment. Before creating a test plan, one must have a clear understanding what each component of their SharePoint farm is, the role it plays, and the threats each of these components faces that could cause the disaster recovery plan to be exercised.

A SharePoint farm is a collection of SharePoint servers or SQL servers that work in together to provide a set of basic SharePoint services that support a single site.

The ability of multiple servers to work in conjunction and provides system is its failover capabilities and load balancing. The servers can also provide readily available backups that can scale to immense sizes. Useful for DR!

Within a farm, there are several services that run on one or more servers. These services provide basic functionality for SharePoint and regulate which services should run on which servers, in an effort to manage the impact on overall farm architecture and performance.

There are occasions when multiple SharePoint farms make sense. An enterprise might have a quality assurance (QA) and PROD farm. Geographically dispersed enterprises might have a farm in Europe, one in the Asia-Pacific region and another in North America.

 

In this article, we will cover:

  • Identifying all components of your SharePoint Environment
  • Identifying Threats to your SharePoint Environment
  • Creating an Effective Disaster Recovery Plan
  • Testing your Disaster Recovery Plan
  • Maintaining your Disaster Recovery Plan

Getting Started

Imagine you are the administrator of a SharePoint implementation for a large company that uses SharePoint for their corporate intranet, collaboration sites, enterprise search, and other mission critical business processes. One day you are sitting at your desk and you get a call from a user saying they are receiving an error when trying to access the intranet.

As you begin taking a look at this, you receive several more phone calls as well as e-mails from other users experiencing the same problems. You attempt to log in remotely into the SharePoint Central Admin server to check on the server logs and Unified Logging System (ULS) logs; however, there is no response from the server. What do you do now?

You begin with basic troubleshooting to see if you can determine what the issue is and see if you can get it corrected in a timely manner; however, in this particular case you discover your server that runs Central Admin and several key SharePoint services has died.

This would be the time to refer to your DR plan (ideally not saved in SharePoint) to see what to do next assuming you had a plan. Even if you had a plan, are you sure it will work? Has it been tested? These are the kind of questions that need to be answered before a disaster occurs, not after you are in the midst of one.

So how do you start with a SharePoint DR plan? There are some preliminary steps you should take as part developing your SharePoint DR plan. These steps include identifying each component of your SharePoint environment and the threats to each that could cause a disaster

Identifying all components of your SharePoint environment

As a first step before creating a DR plan, you should take a complete inventory of each component of your SharePoint environment. This inventory should include:

  • The physical architecture such as the servers, the database, and the network
  • The logical architecture such as web applications, service accounts, service applications, and apps
  • Custom software installed in the farm

Physical architecture

You should begin the process of taking an inventory of each component of your SharePoint environment by starting with the physical architecture. The physical architecture should include all farms and related components in your SharePoint environment including any development, testing, staging, quality assurance (QA) and production farms.

While the other SharePoint farms aside from your production farm may not be part of your SharePoint DR plan it is good practice to make sure you have an inventory of each farm as you may need to utilize individual components of the physical architecture of any of these environments as part of your overall SharePoint DR plan should you experience a failure in any of the physical components of your production SharePoint farm.

As part of the process of identifying the Physical Architecture of your SharePoint farms you should create easy to read diagrams using a tool like Microsoft Visio.

Servers

Each server in each SharePoint farm in your environment needs to be identified. The information collected for each server should include the following:

  • Server Name
  • Server Description/Purpose
  • Server Location
  • Physical or Virtual
  • Host Name (if Virtual)
  • Internet Protocol (IP) Addresses
    • Internal
    • External (if applicable)
  • Operating System (including Service Packs, patch level and hotfixes))
  • Processor(s)
  • RAM
  • Network Interface Cards (NIC)
  • Hard Drives
    • Drive Letter
    • Drive Type (Internal, Storage Area Network (SAN))
    • Space
    • Purpose
  • Backup Schedule
  • Services and Roles
    • Application Server Role
    • Internet Information Services (IIS)
    • Simple Mail Transport Protocol (SMTP)
    • Others
  • Installed Software (version, Service Packs, patch level and hotfixes)
    • SharePoint
    • Anti-Virus
    • Utilities
    • Tools
    • Others

Database

A complete inventory of all SharePoint related database servers should be collected. It may be necessary to work with a DBA to gather this information. Information gathered should include:

  • SQL Server Version (including Service Packs, patch level and hotfixes)
  • SQL Server Configuration (Standalone, Mirrored, Clustered, Always On)
  • Database Instances
    • Names
  • Databases
    • Names
    • Data File Name
    • Data File Location
    • Log File Name
    • Log File Location
    • Settings (Autogrowth, Log File Size, and so on)
  • Additional Services (Reporting Services, Analysis Services, Integration Services, and so on)
  • Backup Tools
  • Backup Schedule
    • Full
    • Incremental

Network

In order to get as much detail about your SharePoint environment and to help you develop your SharePoint DR plan you should include details about the network(s) used by the SharePoint environment. Information collected about your network should include:

  • Network Topology
    • Internal
    • External (if applicable)
  • Domain Name Service (DNS) Mappings
  • Load Balancers (if applicable)
    • Virtual IP Mappings
  • Firewall Rules

Logical Architecture

The next step in the process of taking an inventory of each component of your SharePoint environment deals with the logical architecture. The logical architecture should include the high level logical components in your SharePoint environment including any development, testing, staging, quality assurance (QA) and production farms.

Web Applications

The highest level in a SharePoint logical architecture for a SharePoint farm is the Web Application. The information collected for each Web Application in every one of your SharePoint farms should include the following:

  • Web Application Name
  • Uniform Resource Locator (URL)
  • Port(s)
  • Alternate Access Mappings
  • Content Database Name(s)
  • Application Pool(s)
  • Authentication Provider(s)
  • Additional Settings
  • web.config files
  • IIS Settings (i.e. Host Headers)

Service Accounts

It is important to identify each Service Account used by each SharePoint farm in the environment. Service Account information that should be captured is as follows:

  • Service Account Name
  • Purpose
  • Local Rights
  • Domain Rights

Service Applications

Each SharePoint Farm will have several associated Service Applications. Service Application information that should be captured is as follows:

  • Service Application Name
  • Service Application Description
  • Server(s) Running Service Application
  • Service Application Pool(s)
  • Service Application Database Name(s)
  • Service Application Service Account(s)
  • Additional Settings (i.e. the Secure Store Service Application” needs to record and keeps the passphrase, used to encrypt the credential, in a secure location)

Apps

SharePoint 2013 introduces the concept of the Apps model to the product. Apps are essentially web applications that fit seamlessly into the SharePoint website where they are installed and therefore bring data and functionality to the users’ familiar work environment and provide them with a familiar user experience.

For example, let’s say you have a SharePoint site to collaborate with a team, and you want to create a survey to gather more data. In SharePoint 2013, you can get a “survey app” from the Office Store or from your SharePoint App Catalog and install it on your site.

Apps can be hosted in a variety of different ways including in a private cloud, a public cloud such as Windows Azure or directly within SharePoint. The following diagram summarizes the critical aspects of the various hosting approaches for the SharePoint 2013 App Model.


You should capture information about all of the apps that are installed and used in your SharePoint farm so if you need to recover you environment in the event of a disaster you can reconfigure all of the apps in the farm. Information about SharePoint Apps that should be collected is as follows:

  • App Name
  • App ID
  • App Description/Purpose
  • App Domain
  • App Service Settings
  • App Authentication Configuration