You can configure SharePoint 2010 DR farm using SQL Log shipping or SQL database mirroring for SharePoint databases. Before i start SharePoint 2010 DR farm configuration, I want to give an overview of SQL database mirroring, SQL log shipping and what can be used. In this post i am going explain followings.

1. Overview to SQL Database mirroring
2. Overview to SQL Log shipping
3. What can be used for SharePoint 2010 DR Farm configuration
4. SharePoint 2010 DR Farm configuration using SQL Database mirroring
5. SharePoint 2010 DR Farm configuration Using SQL Log Shipping
6. Comparison
7. Changes required when you failover

Overview to SQL Database Mirroring:

Database mirroring feature is available in SQL 205 and SQL 2008. Its a solution to provide database high availability and its configured per-database basis. You can only configure the database mirroring for the databases that use the full recovery model. You cannot configure the database mirroring for the System Databases (master, msdb, tempdb & model).

In database mirroring there will be 2 copies of a single database residing on 2 different SQL instance. One SQL server instance act as Primary server and holds the active databases. All the clients or applications connect to this database server. Other SQL Server instance act as Secondary server or mirror server which holds the hot or warm databases. Once the database mirroring has been configured and databases are synchronized state, failover can be performed without a loss of data. While you configure the SQL database mirroring you can also configure the Witness server. This is going to another SQL instance which would be monitoring the primary SQL server instance. If primary SQL Service fails then witness server will automatically failover the databases from primary SQL server instance to Secondary SQL server instance.

There are 2 operating modes for configuring Database mirroring:

• Asynchronous: This doesn't need the Witness Instance, that means there is no automatic failover. Once the Database server is not available administrator to stop the database mirroring session manually.
• Synchronous: You can configure this with witness server (optional). If you configure with witness server then you get the advantage of automatic failover feature. However, automatic failover requires both the databases to synchronized.

Lets look at the advantages and disadvantages of database mirroring.

• Database Mirroring Advantages:
  • Easy setup and maintenance
  • Real-time synchronization of transaction log
  • Automated failover (in High Availability Mode, Witness Server Instance required)
  • Fast & easy Failover
  • Using connection strings you can make your application mirroring aware or using SQL alias.
• Database Mirroring limitations:
  • Database mirroring is configured per database not per SQL server Instance.
  • Mirror database always in recovery mode and this database can’t be used for any purpose or database queries.
  • Database mirroring can only configured for one database to another database. There can’t be more secondary server.
  • Database mirroring can’t be configured for once database once than once.

Overview to SQL log Shipping:

SQL log shipping allows to backup the transaction logs from primary SQL Server instance in regular interval to one or multiple secondary SQL Server instance. Transaction log backup are restored to all the Secondary SQL Server instances individually. SQL Log Shipping consist of 3 operations:

• Backup transaction log from the primary server
• Copy the transaction log backup to the secondary server or secondary servers
• Restore the transaction log backup to the secondary server instance

Above 3 operation will create 3 jobs on SQL Servers. Backup Job will be only available on Primary SQL Server instance. However, Secondary SQL Server instance contains the Copy job and Restore job. All these job executes in regular interval and you can define the time. SQL agent service has to be on running for log shipping.

• Log Shipping Advantages:
  • Flexibility to backup, copy and restore the transaction logs.
  • Due to scheduled jobs database corruption can be avoided.
  • Multiple secondary databases can be configured
  • Secondary databases are in read-only and standby mode and can queried if required.
  • Log shipping allows multiple standby databases
  • Log Shipping disadvantages:
• Log Shipping Disadvantages:
  • No option for automatic failover
  • Minimum time to synchronize is a min. which can be configured. 
  • For failover need to execute SQL Query. not simple as database mirroring.

What can be used for SharePoint 2010 DR Farm Configuration:

For SharePoint 2010 Disaster Recovery Farm configuration you can use both. However, if you use Database mirroring then databases on Secondary SQL Server or Databases on Secondary Datacenter will be on restoration mode which you cant attach to the web application. I would always recommend to use SQL log shipping for SharePoint 2010 DR Farm configuration. Again, SQL database mirroring is mostly used for HA and SQL log shipping is used for DR. On this post i will be explaining DR farm configuration with both and compare at the end so you can choose what's best for you.

SharePoint 2010 DR Farm Configuration using database mirroring:

To configure the DR Farm using Database mirroring, you need to start a fresh installation of SharePoint 2010 on Secondary Datacenter. You should have below:

• Install and Configure SharePoint 2010 Farm in Secondary datacenter in same AD Forest using Primary SharePoint farm Service accounts
• Install the customizations which are present on primary farm
• Create all the web applications which are present on primary farm
• Create all the Service applications
• Detach the content databases from the web applications and delete the content databases
• Configure the mirroring only for content databases from Primary SQL server to Secondary SQL server. By Default all the content databases uses Full Recovery Model. If you have changed the Recovery Model for to simple for any content databases, it will not allow you to configure database mirroring unless you change the recovery model back to full recovery model.
• Create database mirroring without the Witness server for all the SharePoint Content Databases only. No witness server required as database mirroring would be used for High Availability and auto-failover is not required

To configure Database mirroring using SQL management Studio you can follow the MSDN Article.

ALTER DATABASE ContentDatabaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

 SharePoint 2010 DR Farm Configuration using database log shipping:

To configure the DR Farm using database log shipping, you need to start a fresh installation of SharePoint 2010 on Secondary Datacenter. You should have below:

• Install and Configure SharePoint 2010 Farm in Secondary datacenter in same AD Forest using Primary SharePoint farm Service accounts
• Install the customizations which are present on primary farm
• Create all the web applications which are present on primary farm
• Create all the Service applications
• Detach the content databases from the web applications and delete the content databases
• Create the log shipping for the content databases only. By Default all the content databases uses Full Recovery Model.If you have changed the Recovery Model for to simple for any content databases, it will not allow you to configure database mirroring unless you change the recovery model back to full recovery model.

To configure Database log shipping using SQL management Studio you can follow the MSDN Article.

Comparison of using SQL database mirroring or Log Shipping for SharePoint DR farm.

Database Mirroring:

• In database mirroring Real time transaction log shipping to secondary SQL Server. Incase of primary SQL server failure latest information will be available on Secondary SQL Server.
• As Database on Secondary SQL Server would be “Mirror, Synchronized / Restoring” We will not be able to attach the databases to web application on DR farm. Incase of Failover we will need to make the databases active and attach the databases to web applications.
• After failover when we attach the content database to the web application, it will automatically refresh the site map on Configuration database.
• As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.
• When failover happens we need to run SQL script to make the all content databases writeable.

Database Log Shipping

• In Log shipping transaction log backup, copy and restore happens on scheduled time (Minimum time 1Min). Incase of fail-over from primary SQL Server to Secondary SQL Server we might loose some data if that's not restored on SQL Secondary SQL Server or manually restore the transaction log backup to Secondary SQL Server database.
• As Database on Secondary SQL Server would be “Stand by/ Read-only” It will allow you to attach the databases to web application on DR farm and we can crawl the content using Search Service Application.
• As the databases are attached to the web application we can run a script to refresh the Site Map on Configuration database.
• As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.
• When failover happens we need to run SQL script to make the all content databases writeable.

Changes required when you failover from Primary SharePoint 2010 to SharePoint 2010 DR Farm.

If you are using SQL database mirroring:

• On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.
• Run the SQL Query to make the database active. (ALTER DATABASE ContentDatabaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS)
• Attach content databases to the web applications.
• Start a full Crawl process on Search Server.

If you are using SQL database log shipping:

• On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.
• Restore all the pending transaction logs backup to database.
• Run the SQL Query to make the database active. (RESTORE DATABASE contentdbname WITH RECOVERY)
• Start an Incremental Crawl process on Search Server.

  After knowing both the options, now you can choose between database mirroring and Database log shipping for DR farm configuration.

   

   

   

   

   

   

   

   

   

SharePoint 2010 supports FBA, Like WSS 3.0 or MOSS 2007. It's a feature of ASP .Net which we use with SharePoint. SharePoint 2010 you can create web applications using Classic Based Authentication or Claims based Authentication. However, FBA can only be configured with web applications created using Claims Based Authentication.

What are the differences between Classic Mode Authentication and Claims based Authentication?

Classic Mode Authentication: It refers to the integrated windows authentication. You cannot configure the Forms based authentication if your web application is using Classic Mode Authentication. You can convert a web application from Classic Mode Authentication to Claims Based Authentication. However, that can only be done using PowerShell commands and its an irreversible process. I have detailed steps to convert the web application from Classic Mode authentication to Claims Based Authentication.

Claims Based Authentication: SharePoint 2010 is built on Windows Identity Foundation. It enables authentication from windows as well as non-windows based systems. This also provides the capability to have multiple authentication in a single URL.

Configuration of FBA with SharePoint 2010 involves 4 major steps. The steps to configure the FBA with SQL membership Provider are below:

I> Create or Convert existing web applications to use Claims Based Authentication

II> Create User IDs in SQL Database

III> Modify web.config file

IV> Give Permissions to users present in SQL database

Note: If you want to configure FBA with LDAP membership Provider then you can refer TechNet article.

Please find the detailed steps below:

I> Create or Convert existing web applications to use Claims Based Authentication

Note: - Web Application has to be created from the Central Administration console or PowerShell, however it should be using Claims Based Authentication.

A. Creating web application using Central administration

• Open Central Administration Console.
• Click on Manage Web application Under Application Management.
• Click on new on the Ribbon.
• Chose Claims based Authentication From the top of the page.
• Choose the port no for the web application.
• Click on Enable Forms Based Authentication (FBA) Under Claims Authentication Types. Windows Authentication is enabled by default and if you dont need windows authentication then you need to remove the check the box.
• Add the Membership Provider & Role Manager Name
• As soon as web application has been created please verify the Authentication Provider settings for the web application. I have the screenshot below:

Note:- If you want to use Windows Authentication and Forms Based Authentication in Single URL then you have to select Enable Windows Authentication and Enable Forms Based Authentication.

Note:- Just for understanding, i am using Membership Provider as “SQL-MembershipProvider” and Role Manager as “SQL-RoleManager”. You can use different names, however you need to remember the name so that you can refer them in web.config files. These names are case sensitive.

B. What if you already have a Web application created using Classic Mode Authentication or How to convert Web application from Classic Mode authentication to Claims based Authentication?

You don’t have to delete that web application. You can convert that web application from classic mode authentication to claims based authentication. However this can only be done using PowerShell and it’s an irreversible process. Follow PowerShell commands to convert the web application from Classic Mode Authentication to Claims based Authentication:

$App = get-spwebapplication “URL”

$app.useclaimsauthentication = “True”

$app.Update()

Example:-

$App = get-spwebapplication “https://sp1:8000”

$app.useclaimsauthentication = “True”

$app.Update()

Once you have the web application using Claims Based Authentication, you can create a site collection. Now if you access the web application, you can access the site choosing Windows Authentication or Forms Based Authentication as shown in below image.

Choose windows authentication and login to site. When you login your currently logged in credentials will be used. Make sure the account you are logged in with has access to SharePoint site; Otherwise, you will get access denied error.

II> Configure the Membership Provider and Role Manager.

• On SharePoint 2010 server open the command prompt.
• Navigate to C:\Windows\Micrsooft .Net\Framework64\v2.0.50727
• Run “aspnet_regsql.exe”. This will open ASP .Net SQL Server Setup wizard. On this click on NEXT.

• Click on “Configure SQL Server for Application Services”.
• Specify the Database name. If you don’t specify the database name then it will create a database call aspnetdb.

• Use membershipseeder tool to create the users in SQL database. You can find the tool and information on that from codeplex.

Note:- I have specified the database name as “SQL-Auth”.

III> Modify the web.config file for Membership Provider and Role Manager.

We need to modify 3 different web.config files for FBA to work. Web.config of FBA Web application, web.config of Central Administration Site & Web.config of STS.

A. Modify web.config of FBA web application.

• Add connection String:

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

Connection String has to be added after </SharePoint> and Before <system.web>

• Add membership Provider and Role Manager:

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

</system.web>

B. Modify web.config of the Central Administration web application.

• Add connection String:

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

Connection String has to be added after </SharePoint> and before <system.web>

• Add membership Provider and Role Manager:

<roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">

<providers>

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="SQL-MembershipProvider">

<providers>

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

C. Modify web.config of STS. You can locate the STS web.config from %programfiles%\common files\Microsoft Shared\web server extensions\14\WebServices\SecurityToken

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

<system.web>

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

</system.web>

Above has to be added before </configuration>

IV> Give permissions to users in SQL database.

• Access Central Administration console and click on manage web applications under Application Management.
• Select the web application and click on user Policy on ribbon.
• Click on Add user and select Default Zone.
• Now type the user name, add the user to the web application by defining appropriate permission.

Common Issues:

If you are using multiple service accounts as per TechNet article Administrative and service accounts required for initial deployment (SharePoint Server 2010) then you might not able to resolve the usernames or add the users to the web application. If you are using 3 different accounts (Farm Administrator account, Application pool account for web application and service application account) then you need to make sure that you have access to the SQL membership database (SQL-Auth).

Important:

What happens to FBA when we upgrade WSS 3.0 / MOSS 2007 to SharePoint 2010?

Before upgrading to SharePoint 2010 you need to remove the changes you have done to the web.config file. As soon as the process of upgrading finishes all the web applications will be upgraded; however, those will use Classic Mode Authentication. You can convert those web applications from Classic Mode Authentication to Claims Based Authentication.