1. On on-premises SharePoint side, only Integrated Windows Authentication (either NTLM or Kerberos) is supported. ADFS or other SAML based trusted identity providers would not work. Yes, you can still set up Cloud SSA on a web application, for example, using ADFS authentication. The Cloud SSA configuration will run through but users, both online and on-premises, will not be able to get desired search results on either online or on-premises content: all content secured using ADFS identities would be trimmed off.
2. On-premises user accounts must be sync'd to AAD to be able to use Cloud SSA. If an on-premises use's identity is not sync'd to Office 365 AAD, search engine will return "Sorry, something went wrong" message, and if you drill-down to the detail, it looks something like this:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute() at Microsoft.SharePoint.Client.ClientContext.GetFormDigestInfoPrivate() at Microsoft.SharePoint.Client.ClientContext.EnsureFormDigest() at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery() at Microsoft.Office.Server.Search.RemoteSharepoint.RemoteSharepointEvaluator.RemoteSharepointProducer.RetrieveDataFromRemoteServer(Object unused) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at Microsoft.Office.Server.Search.RemoteSharepoint.RemoteSharepointEvaluator.RemoteSharepointProducer.ProcessRecordCore(IRecord record)

Correlation ID: c662de9d-434f-00ec-d613-50b7ebedcef3

### Restoring SB Farm

Restore-SBFarm -FarmCertificateThumbprint <SB farm cert thumbprint> -GatewayDBConnectionString '<new SB gateway db connection string>' -SBFarmDBConnectionString '<new SB farm db connection string (must provide a new database name)>' -EncryptionCertificateThumbprint <SB encryption cert thumbprint> -RunAsAccount '<SB run as account>';

Restore-SBMessageContainer -Id 1 -ContainerDBConnectionString '<new SB container db connection string>';

### Restoring WF Farm

Restore-WFFarm -OutboundCertificateThumbprint <outbound cert thumbprint> -SslCertificateThumbprint <SSL cert thumbprint> -EncryptionCertificateThumbprint <encryption cert thumbprint> -RunAsAccount '<run as account>' -WFFarmDBConnectionString '<new farm db connection string (must provide a new database name)>' -InstanceDBConnectionString '<new instance db connection string>' -ResourceDBConnectionString '<new resource db connection string>' -InstanceStateSyncTime '<date time>' -ConsistencyVerifierLogPath '<file path>';

There is one problem: the sites are based on SAML (PingFederate is used as the IdP).

SAML based sites are a lot different from sites using Windows Integration Authentication methods such as NTLM and Kerberos when users log in. The user will be redirected from SharePoint to SAML IdP, be presented a web form to fill out their username and password, be authenticated, and then be redirected back with a SAML token to SharePoint to be validated and then start browsing SharePoint content.

These work fine under normal user scenarios, the question is how do we turn it into web tests and load test to simulate large amount of users and requests coming to the sites and see how SharePoint farm would perform.

After playing with VSTS and Fiddler and a little research, I found this very useful article online: https://blogs.southworks.net/sdurandeu/2013/01/03/load-testing-adfs-federated-sharepoint-applications/. It is written for ADFS but the idea stays the same. I modified the test cases and made them work for PING based SharePoint sites.

To test SAML sites, you need to create a web test to log in a user with SAML IdP first, then run subsequential web tests such as open a page, navigate the sites, search for something, and so on.

For the user log on web test, there are only two steps you have to take: 

1. Request the SAML IdP's log in page with the correct query strings and form data, to get the SAML token back
2. Come to SharePoint’s “/_trust/” to validate the token and get the FedAuth token

After getting the FedAuth token, you can start the real SharePoint performance and load tests.

All the above steps should be manually created in the VSTS and use a few variables to carry around some key factors, like the SAML token.

Below is the screenshot of the web test, you don’t have to write any code: 

In above web test the SAML token is carried around in a variable called "wresult", I also used a CSV file to store all test users’ credentials.

The information you have to modify according to your own environment is highlighted. Your environment may have different values for those “w*” variables, the best way to find this out is to use Fiddler to monitor a full SAML log on session, you will see the values in Fiddler’s WebForms window.

After you get the user log on web test, you can add other recorded SharePoint web test scenarios to your load test, just make sure you configure the user log on web test as the initial test to execute before other tests for each virtual user in your load test’s Test Mix.

One more thing to keep in mind: when you run load tests against your SAML based SharePoint sites, you will put a lot of pressure on your IdP (PING in my case) as well. Just make sure that you check with the team manages the IdP before you run your load tests, you don’t want to interfere with other users and systems that your IdP is supporting.

Courtesy of https://www.learningsharepoint.com/2012/08/09/sharepoint-2013-hide-newsfeed-skydrive-sites-deltasuitelinks/, you can inject a snippet of JavaScript to simply hide the DIV containing the links. However, the DIV's name has changed since the blog was publishing. Below is the correct script to do the job:

<script type='text/javascript'>// <![CDATA[
_spBodyOnLoadFunctionNames.push("HideBrandingsuite");
function HideBrandingsuite()
{
 document.getElementById('DeltaSuiteLinks').style.visibility = 'hidden';
}
// ]]></script>

Notice the name of the DIV has been changed to "DeltaSuiteLinks".

Now, how do we inject above script to a SharePoint site? Of cause you can create a control that includes the script and utilize Delegate Control to put it on your master pages. This is a typical full trust development and requires coding and deploying WSPs on server side. There are two more options that don't require any code development and server side customization:

1. Simply put a Script Editor web part with the JS code above on the pages you want to hide the links. (This option only works for individual pages)
2. Modify the master page you use to include the JS code. To do this follow these steps:
1. Navigate to your site's /_catalogs/masterpage directory and download a copy of the master page of your site (HTML version preferred if that's the case).
2. If you are using OOTB master page, change the downloaded master's name (we don't want to touch anything that is OOTB).
3. Open the downloaded master with a HTML editor, insert the code above to the master page and save the changes.
4. Upload the modified master page back to the site. Switch your site's master page if its name has been changed.
5. Test the new master page and make sure it works.
6. Publish the new master page.

Of cause the two options mentioned above are manual work and wouldn't scale for large amount of site collections, in that case you need to create a sandbox or full trust solution to do the job.

Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint 2010
Microsoft Consulting Services

If you do not see C:\ProgramData folder, you need to change your explorer's viewing option to "Show hidden files, folders and drives".

Enjoy troubleshooting OWA!

Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint 2010
Microsoft Consulting Services

The easiest and dirtiest way is hard-coding them in code. It maybe fine for a small and quick proof-of-concept but of cause you should not do it.

Next place is application config file. In the case of SharePoint solutions, it is the web.config. Configuration data stored in web.config is not hard-coded, easy to change (who doesn't like NotePad?), and very easy to access from code.

There are other places to store configuration data, SharePoint lists are also popular. The problem is that you have to store the lists’ sites and names somewhere else, otherwise you code would not know where to get the data. An external data store, such as SQL server, is also being used at some customers. Similarly, you have to deal with the data connection information separately as SharePoint lists.

However, in this blog I am going to recommend *NOT* to use any of the approaches mentioned above. To make my point, please check the comparison sheet below:

For storing configuration data for SharePoint solutions, I would like to recommend use either property bags or hierarchical object store, maybe together with SharePoint lists depends on the amount of data you are dealing with. Some people may argue that they do not have built-in UI, actually it could be a good thing in this case, because that means they are not likely to be altered by accident, and it is easier to control access.

Below are some useful links on property bags, hierarchical object store, and application pages:

• Property bag:
• https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.utilities.sppropertybag.aspx
• https://pbs2010.codeplex.com/
• Hierarchical object store:
• https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.sppersistedobject.aspx
• https://www.chaholl.com/archive/2011/01/30/the-skinny-on-sppersistedobject-and-the-hierarchical-object-store-in.aspx
• Application page:
• https://msdn.microsoft.com/en-us/library/ee231581.aspx

What about farm level SharePoint solutions? For example one of my customers developed a solution to support their enterprise search, some other customers developed timer jobs. Those solutions are not deployed for a specific site, site collection or a web application. Where should they store the configuration data?

The answer is to store the data in property bag in Central Admin or hierarchical object store, and deploy your application pages to CA. Here is an article about how to do it: 

• Get CA's URL: https://www.sytone.com/2010/07/getting-the-central-admin-url-for-a-farm-in-sharepoint/
• Deploy an app page to CA: https://msdn.microsoft.com/en-us/library/ff798467.aspx

Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint 2010
Microsoft Consulting Services

I officially became a Microsoft Certified Master for SharePoint Server 2010 on March 22, 2012.

The journey began more than a year early. If you read my earlier blog (https://blogs.msdn.com/zwsong/archive/2011/02/24/passed-all-4-sharepoint-2010-mcp-exams-at-techready.aspx), you would know that I passed all 4 MCP exams for SharePoint 2010 in February 2011, and that was the hard pre-requisition for being accepted by MCM program.

Around April and May 2011, I started to consider if I wanted to pursue a MCM certificate. An MCM or Master title not only is the second highest Microsoft certificate (there is a higher MCA title for enterprise architects), but also highly respected by the whole industry.

However, MCM is not easy, actually it is very hard, time consuming and expensive to achieve. Not only do you have to spend large amount of time to prepare and take very intense trainings and exams, but also would cost more than $25,000, and significant billable hours (I am a consultant).

Fortunately, my manager was very supportive and was willing to spend the big amount of money for MCM on me. (Microsoft employees get less than 50% discount on MCM training and exam fees). So, like a fool, I decided to go down the route.

Here is a list of major events of my entire MCM experience:

1. Pass all SharePoint 2010 MCP exams (Feb. 2011)
2. Apply for MCM: online application with $250 fee (May 2011)
3. Submit resume and a write-up about my SharePoint projects (May 2011)
4. Telephone interviewed by MCM program manager and a SharePoint Master (July 2011)
5. Being accepted by MCM program and pick up a training rotation (July 2011)
6. Pay the MCM program fee ($25,000 minus discount) (July 2011)
7. Prepare for the rotation (July – early September 2011)
8. Attend the on-site 3-week MCM training rotation in Redmond, WA (September 2011)
9. Pass knowledge exam (September 2011)
10. Fail Hands-on Qualification Lab (September 2011)
11. Prepare for QualLab retake (October 2011 – March 2012)
12. Pick a slot for QualLab retake (February 2012)
13. Pay QualLab retake fee ($2,500 minus Microsoft discount) (February 2012)
14. Take the QualLab retake (March 20, 2012)
15. Pass the retake and officially become a MCM (March 22, 2012)

As you can see, it has been a very intense year for me and my team has spent a lot of money and lost quite some billable hours on it. And frankly speaking, I still couldn't believe I am a Master now. I still couldn't believe that my name will be listed with the world's best SharePoint gurus whom I look up to.

My many thanks go to my manager, MCM program managers, MCM instructorsm, my classmates at the rotation, and especially my wife and kids, they suffered when I was away preparing and going on training, they comforted me when I did not pass all the exams at first try, they supported my efforts and rejoiced when it had finally come.

Here are some links for the MCM program if you want to learn more about it:

• MCM Overview: https://www.microsoft.com/learning/en/us/certification/master.aspx
• MCMs and MCAs List: https://www.microsoft.com/learning/en/us/certification/master.aspx#meet
• Master Blog: https://blogs.technet.com/themasterblog/

Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint Server 2010
Microsoft Consulting Services

Turns out the fix is very simple: Run "Enable-PSRemoting -Force"cmdlet before your Set-MsolAdfscontext cmdlet.

This is what you do to set up an Office 365 SSO domain:

$cred=Get-Credential
Connect-MsolService -Credential $cred
Enable-PSRemoting -Force
Set-MsolAdfscontext -Computer <ADFS server FQDN>
New-MsolFederatedDomain -DomainName <Domain FQDN>

Enjoy Office 365!

Zewei Song, Ph.D.
MCPD, MCITP, MCTS: SharePoint 2010, .NET 3.5
Enterprise Services, Microsoft Corporation

This is what you would see in log file for this error:

6/6/2011 2:46:42 PM Command Set-MsolADFSContext invoked.
6/6/2011 2:46:42 PM Creating ADFS Server PS session.
6/6/2011 2:46:42 PM ContextCredentialsCommand:CreatePowerShellSessionToGenevaServer: Invoked.
6/6/2011 2:46:42 PM Creating PS session to 'adfsServer.contoso.com' ADFS server
6/6/2011 2:46:42 PM Connect using current logged-on user creds.
6/6/2011 2:46:42 PM Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfsServer.contoso.com AppName:wsman, Shell:https://schemas.microsoft.com/powershell/Microsoft.PowerShell
6/6/2011 2:46:42 PM Connection Uri: https://adfsServer.contoso.com:5985/wsman/
6/6/2011 2:46:42 PM Opening runspace to 'https://adfsServer.contoso.com:5985/wsman/'
6/6/2011 2:46:45 PM System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
at System.Management.Automation.Runspaces.RunspacePool.Open()
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
6/6/2011 2:46:45 PM fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
6/6/2011 2:46:45 PM Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
6/6/2011 2:46:45 PM Retry errorId: ConnectionToGenevaServerFailed
6/6/2011 2:46:45 PM Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
6/6/2011 2:46:45 PM Going to sleep mode for 1000 milliseconds before reattempt - 2
6/6/2011 2:46:46 PM Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfsServer.contoso.com AppName:wsman, Shell:https://schemas.microsoft.com/powershell/Microsoft.PowerShell
6/6/2011 2:46:46 PM Connection Uri: https://adfsServer.contoso.com:5985/wsman/
6/6/2011 2:46:46 PM Opening runspace to 'https://adfsServer.contoso.com:5985/wsman/'
6/6/2011 2:46:49 PM System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
at System.Management.Automation.Runspaces.RunspacePool.Open()
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
6/6/2011 2:46:49 PM fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
6/6/2011 2:46:49 PM Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
6/6/2011 2:46:49 PM Retry errorId: ConnectionToGenevaServerFailed
6/6/2011 2:46:49 PM Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
6/6/2011 2:46:49 PM Going to sleep mode for 2000 milliseconds before reattempt - 3
6/6/2011 2:46:51 PM Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfsServer.contoso.com AppName:wsman, Shell:https://schemas.microsoft.com/powershell/Microsoft.PowerShell
6/6/2011 2:46:51 PM Connection Uri: https://adfsServer.contoso.com:5985/wsman/
6/6/2011 2:46:51 PM Opening runspace to 'https://adfsServer.contoso.com:5985/wsman/'
6/6/2011 2:46:54 PM System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
at System.Management.Automation.Runspaces.RunspacePool.Open()
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
6/6/2011 2:46:54 PM fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
6/6/2011 2:46:54 PM Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
6/6/2011 2:46:54 PM Retry errorId: ConnectionToGenevaServerFailed
6/6/2011 2:46:54 PM Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
6/6/2011 2:46:54 PM Failure after too many retries attempts..
6/6/2011 2:46:54 PM Wrong credentials to ADFS Server connection, attempt #'1'
6/6/2011 2:46:54 PM Prompting the user for 'adfsServer.contoso.com' ADFS Server creds.
6/6/2011 2:46:54 PM ContextCredentialsCommand:GetServerCredentials: Invoked.

You can follow this articles to set up a stretch farm using SQL mirroring: https://technet.microsoft.com/en-us/library/dd207314.aspx

Following Q&As are based on my real-world experiences with SQL mirror and SharePoint stretch farm. 

Questions and Answers (DC stands for Data Center): 

• What are the requirements for setting up a SharePoint stretch farm?
  For a stretched farm to work, there must be less than 1 millisecond latency between all the SQL Servers and the front-end Web servers in one direction, and at least 1 gigabit per second bandwidth.
• Where to put the witness server?
  Put the witness server in the most reliable DC. If the secondary DC is more reliable and the connection between the DCs is at least as reliable as the DCs, you can put the witness in the secondary DC, otherwise, it should be in the primary DC. 
• What is the minimum firewall requirements for the witness server?
  Open up the TCP port of the SQL mirroring endpoint for inbound traffic. 
• Can I use SQL Express as the witness?
  Yes, you can.
• How to test a stretch farm?
  You can simulate a failed SQL server by stopping its service using SQL Management Studio. Open the studio, connect to the SQL instance and right click on the instance name on the left pane and select Stop command. If the SQL instance is the principal, the mirror SQL instace will take over the principal role and the SharePoint farm will come back to service within a few seconds.
• How to manually failover from one DC to another DC?
  Run following T-SQL command on the principal SQL server instance. You need to run the command for each database.
  

  ALTER DATABASE <your database name> SET PARTNER FAILOVER

• What to do when I lose the primary DC?
  When you have the witness server in primary DC and the whole DC is gone (disaster happens), the mirror SQL instance will become "Principal - In Recovery" but won't serve data. To bring it back online so your SharePoint services resume, you need to run following T-SQL commands. You have to do it for all of your databases.
  

  ALTER DATABASE <your database name> SET PARTNER OFF

  RESTORE DATABASE <your database name> WITH RECOVERY

  Above commands break the mirroring partnership. You have to backup/restore the databases and resume the partnership after the primary DC is recovered.
  If the witness server is in the secondary DC, the mirror SQL instance will automatically become the principal server, your SharePoint farm will resume services in a few seconds.

• What to do when the primary DC is recovered after a disaster? 
  Assume you already ran the commands to break the mirror partnership. You have to follow the steps to resume it. Note the principal SQL instance is in the secondary DC at this point:
    1. On the principal server, back up all SharePoint databases.
    2. Copy the backup files to the mirror database server. The server should be running on stand-alone mode.
    3. Delete all the SharePoint databases from the mirror database server if they are still present
    4. Restore the databases to the mirror server.
    5. On the mirror server, set up the mirroring partnership.
    6. On the principal server, set up the mirroring partnership.
    7. On the principal server, set up the witness partnership.
    8. Test SharePoint and make sure it is still functioning.
    9. Failover to the original principal server if necessary.
  If the SQL instance in the secondary DC automatically took over the principal role, you don't have to do anything but just give them some time to sync up.

• What happens if I lose connection between the primary and the secondary data centers?
  Assume both the DCs are still working but the connection between them is broken. Both the SQL instances will become principal. The one with access to the witness server will be serving data, the one without access to the witness will stop serving data and the SharePoint servers in that DC will stop working.
• Can SQL mirroring work with cluster?
  Mirroring can work between SQL clusters, and a SQL cluster and a single server SQL instance. Mirroring, however, does not work within a SQL cluster.
• What happens when my principal cluster fails over?
  SQL cluster failover always takes longer time than SQL mirroring witness interval. Therefore, SQL mirroring roles will be switched when the principal cluster fails over. You can failover back to the original cluster after SQL cluster failover is complete.
• Does stretch farm affect SharePoint performance?
  According to my limited performance tests, no.
• How do I set up failover for SharePoint features that do not have UI to set up failover instances?
  You can run following PowerShell commands in SharePoint PowerShell console on a SharePoint server:
  

  $db = get-spdatabase | where {$_.Name -eq "<database name>"}

  $db.AddFailoverServiceInstance("<failover SQL instance name>")

  $db.Update()

• Does stretch farm protects all SharePoint functionalities?
  No. It does not protect functionalities with dependencies beyond 14-hive and databases. Some examples of the not supported dependencies are file shares, and external data sources. Some 3rd party SharePoint solution without failover capabilities will also not be protected. Contact your vendors for more information.

Zewei Song, Ph.D.
MCPD, MCITP, MCTS: SharePoint 2010, .NET 3.5
Enterprise Services, Microsoft Corporation