Do not enable auto-create statistics on a server that hosts SQL Server and SharePoint Server. Enabling auto-create statistics is not supported for SharePoint Server. SharePoint Server configures the required settings during provisioning and upgrade. Manually enabling auto-create statistics on a SharePoint database can significantly change the execution plan of a query. The SharePoint databases either use a stored procedure that maintains the statistics (proc_UpdateStatistics) or rely on SQL Server to do this.

There seems to be no mention for auto_update_statistics. So I worked with my colleague, Derek Wilson, an SME in SQL Server to find the official stand on the update statistics.

For SharePoint 2010, we do not recommend to enable the configurations (Create and Update). However, if you see performance issues, you can enable these settings. For SharePoint 2010 only, this is supported by content databases as it does not affect the SharePoint functionality.

For SharePoint 2013, enabling this setting is NOT supported.

Background

As far as auto-update, it can be a very helpful feature at times, and other occasions can cause performance issues after it kicks in within a SharePoint environment. If you turn it off then you would have to make sure that either the DBA's or someone on the SharePoint team has a process that manually updates statistics that need to be updated on a fairly regular basis.

While the built-in SharePoint timer job (one of those Health Analyzer rules) will run the stored procedure - proc_UpdateStatistics.  This procedure does not exist in every SharePoint database.  If the stored procedure is not found in a particular database, then that database will end up with stale statistics - which can lead to inappropriate and inefficient query plans based on the amount of data that is being queried (https://msdn.microsoft.com/en-us/library/ms190397(v=sql.105).aspx) .

Recommendation:

For SharePoint 2010

· If you are manually updating statistics, then you would not need to enable the “auto update statistics asynchronously” option along with the auto update statistics option. If you are not manually updating the statistics, then you can enable the “auto update statistics asynchronously” option on non-content databases. This would be an option that could be enabled on the databases that do not have the proc_UpdateStatistics stored procedure. These databases would include the following (this is not an all-inclusive list):

Application Service databases:
Service_BusinessConnectivity
Managed Metadata Service
SessionState
StateService_
Application_Registry_Service_DB
PerformancePoint Service Application
Profile Service Application_SyncDB
Bdc_Service_DB
Secure_Store_Service_DB
ReportServer
ReportServerTempDB
If using FAST Search:
FAST_Content_SSA_DB
FAST_Content_SSA_PropertyStoreDB
FAST_Query_SSA_DB
FAST_Query_SSA_PropertyStoreDB
FASTSearchAdminDatabase
If using SharePoint Search:
Search_Service_Application_DB
Search_Service_Application_PropertyStoreDB
If using Project Server 2010:
ProjectServer
ProjectServer_Draft
ProjectServer_DW
ProjectServer_Published
ProjectServer_Reporting
PPCentralConfig

· Databases that do not have the proc_UpdateStatistics, have a process in place to manually update the statistics on the databases that are not covered by the Health Analyzer rule. This process can include the setup and configuration of a SQL Server Maintenance plan (https://technet.microsoft.com/en-us/library/cc262731%28v=office.14%29.aspx#DBMaintenanceForSPS2010_CreateSQLS2008MaintPlan).

FOR 2013,

· Respect SharePoint configuration settings and do not turn it on or off.

· Databases that do not have the proc_UpdateStatistics, have a process in place to manually update the statistics on the databases that are not covered by the Health Analyzer rule

Here is a great video that talks about optimizing SQL Server for SharePoint:  https://channel9.msdn.com/Events/TechEd/NewZealand/2013/SES312

Recently, I was working with a customer where they complained of images rendered corrupt in SharePoint document libraries. If you take the busted document and save it as a .zip file and see the media folder, the image will be corrupted. If you try to open it, you will get a message that the image is corrupt. Now, after researching, I found the issue to be with the third party RBS provider. The third party RBS provider was corrupting the images during save to the disc. Nonetheless, the third party provider quickly provided a hot fix, and the issue was resolved.

Having said so, I relaized that there are many misconceptions about RBS. It is not my goal to explain what RBS is as there is a lot of information about it. There are some misconceptions that I want to address.

Is RBS is a silver bullet for content database size?

RBS would not be a mechanism to reduce content database size. As per the boundaries and limits. If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed the boundaries specified in the link. https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#ContentDB

By using RBS can I reduce the time for database backup and restore?

The answer is no. RBS adds complexity for the backup and restore, AND, RBS must be backed up in synchronization to maintain references consistency. The backup time = time taken to back up content db. + Time to back up RBS. If you look at the section “Implications of using RBS over the IT life cycle” at https://technet.microsoft.com/en-us/library/ff628583(v=office.15).aspx , RBS adds complexity for the backup and restore, AND, RBS must be backed up in synchronization to maintain references consistency. Here is an excerpt, For example, using a remote RBS provider will require increased IT operations complexity and some cost increases. This is because the content database and the BLOB store must be backed up in synchronization to maintain references consistency

Does RBS remove the 2 GB file size limit?

No, it does not.

Third Party RBS providers, shredded storage and RBS threshold!

With OOB FILESTREAM either everything is in RBS or nothing. With third party providers, you can specify thresholds. For example, if the content size > 1MB move it to RBS.

Now consider RBS with Shredded storage. By default, shredded storage will slice files that are SharePoint aware (e.g. Office documents) to 64 kb chunks; others (zip and media) to 1MB chunks. So, if you use a third party RBS provider you can set the threshold to 1MB and all media and zip files will move to RBS and all office documents will move to content DB. Note: Office documents will never go to RBS because the split size of 64KB is less than the threshold. I am not suggesting that you use such a threshold to simply keep all office content in SharePoint and everything else in RBS.

Final thoughts

RBS is not a mechanism to reduce content database size and does not reduce the backup and restore time. In fact, it adds complexity. I would consider RBS solely for storing real blobs like media files, other very large files and for Records management. It is preferred to have most of the content in the content database along with a proactive approach for data retention and archival which is a topic for some another day.

Say you are migrating several terabytes of content from SharePoint 2010 to SharePoint 2013. Chances are that you are creating a temporary migration URL for your 2013 environment where users can test the migration. Further, you migrate content in several stages, probably one business unit at a time, or one web application at a time, so on so forth.

Now once, you move all the content of a business unit or department or project to 2013 and want to keep the same URL as your 2010 environment, what do you do?

Let’s put a concrete example.

• Say your 2010 URL: https://companyA.contoso.com = intended SharePoint 2013 URL.
• You create a 2013 temporary Migration URL: https://companyABeta.contoso.com. This is the URL that you share with the users of the content owners so they can test.
• If you have any web parts that were dependent on search, then the temporary migration URL is the content source for crawl.

Now, once testing is complete and the testers go ahead, then you switch all the users to the 2013 site. To do so you probably,

• · Take an outage for migration.
• · Change the temporary URL to the desired URL, which is the same as your 2010 URL. For example, rename the https://companyABeta.contoso.com to https://company.contoso.com
• · Point DNS to the 2013 production, and users can now access the new site content.

Now the problem is that after you have changed the URL, SharePoint sees a new URL and thought there will be an incremental crawl, it would be like a full crawl. Based on the volume of the content, it could take a while. Search based functionality would not be available till crawl is complete. Also, you will have to do these steps again and again, till you migrated all the business units or departments. Wouldn’t it be nice, if you did not have to re-crawl every time you migrated the content from 2010 to 2013?

Ok Let’s put a concrete example.

Say in SharePoint 2010 you had the following two web applications. You are using attach/detach method, or a tool like AvePoint or Metalogic to move this content.

SharePoint 2010 web applications

• CompanyA.contoso.com
• CompanyB.contoso.com

SharePoint 2013 logical architecture

• One web application with 2 HNSC having the same URL’s; that is,
• CompanyA.contoso.com
• CompanyB.contoso.com

Proposed migration steps.

1. Create your web application in SharePoint 2013. https://mylab
2. On the default zone create the HNSC collection using the script.

New-SPSite 'https://CompanyA.sp.contoso.com' -HostHeaderWebApplication 'https:// mylab' -Name 'CompanyA portal' -Description 'Portal for CompanyA' -OwnerAlias 'contoso\administrator -language 1033 -Template 'BLANKINTERNET#0'

New-SPSite 'https://CompanyB.sp.contoso.com' -HostHeaderWebApplication 'https:// mylab' -Name 'CompanyB portal' -Description 'Portal for CompanyB' -OwnerAlias 'contoso\administrator -language 1033 -Template 'BLANKINTERNET#0'

NOTE: Do not create a DNS entry for the 2013 environment. If the user types https://CompanyA.sp.contoso.com from their device, they should be navigated to 2010 site, not 2013. Since the HNSC is created in the default zones, search will use this to crawl.

Now, when I migrate the content to 2013, how will users test this content to approve migration?

3) Now, create a separate URL for users to test this site. Use the Internet zone.

Set-SPSiteUrl (Get-SPSite 'https://CompanyB.sp.contoso.com') -Url 'https://CompanyBPublic.sp.contoso.com' -Zone Internet

Set-SPSiteUrl (Get-SPSite 'https://CompanyA.sp.contoso.com') -Url 'https://CompanyAPublic.sp.contoso.com' -Zone Internet

4) Now set up DNS entry or host file to point to the public URL’s so users can test.

5) Now when migration is complete, the internet public URL may be removed, and DNS reset to the final URL to direct users to that URL. As the original URL is maintained, search will not re-crawl the data.

What if you are not using HNSC?

You could do the same as above. The only difference would be how you make the site available for testing while the 2010 site is still live. Instead of using Set-SPSiteUrl to create a test URL, you should temporarily extend the web application and make it available for testing by creating a DNS entry. Once you are done testing, remove the extended application and the DNS.

1) I am developing SharePoint hosted apps; do I need to create multiple DNS zones? One for each environment, e.g. dev.contosoapps.com, qa.contosoapps.com

For provider hosted apps, NO, you do not need to have multiple DNS zones. This can be managed with virtual sub directories below the root domain. In other words, you could have a single host and sub directories for each environment, and subdirectories under each environment for each app

E.g.:

· https://app.contoso.com/prod

· https://app.contoso.com/prod/fooApp

· https://app.contoso.com/dev

· https://app.contoso.com/dev/fooApp

· https://app.contoso.com/stage

· https://app.contoso.com/stage/fooApp

2) What about SharePoint hosted apps?

For SharePoint hosted apps you will need a different zone for each SharePoint farm.

3) OK, let me kick this a notch up. So for my production, with multiple web applications, I decide to use provider hosted apps along with the app webs (hybrid). Now, the app web will require four domains as there are four web applications. Can I share a single domain across multiple web applications?

The short answer is yes.

One of the feature updates of the March 2013 Public Update for SharePoint 2013 enables you to use multiple app domains in SharePoint 2013 environments with alternate access mapping or host-header web application configurations.

As per the article at Enable apps in AAM or host-header environments for SharePoint 2013,

Apps domains can be shared across web applications if the zone, application pool identity, and authentication schemes match. For example suppose that webappA is configured to use the Default zone and webappB is also configured to use the Default zone. In addition, both web applications use the same application pool identity, and both web applications use NTLM. In this scenario, the web applications can share a single app domain.

However, you will need a way to update the app to four catalogs. You could probably automate this process. At the end of the day, the app catalog is a document library, so write an app that deploys apps to multiple web applications.

We know that there is a single app catalog per web application. With the one web application matra, you can have separate department or business units site collections under one web application. Further, these departments will develop their own apps that are valid only for their site collections and will have some security needs. So how to prevent users of one department/business unit from installing/seeing apps developed for another department. Here is the solution

Permissions and app scoping can be achieved by the following configuration

1. 1) Only site owners can install the apps
2. 2) The site owners must have read-only permission on the root of the app catalog to be able to see the app and thereby install it.
3. 3) Security isolation for the apps should be achieved by creating folders in the app catalog and assigning permissions to those folders.
4. 4) Once the folder is created, break inheritance on the folder and only provide read-only access to site owners who should be able to install the apps on their sites.

For example

• Site 1 – Site Owner is Bob
• Site 2- Site Owner is Joe

In the app catalog;

• Provide Bob and Joe read-only access at the site level
• Create a folder Site 1 Apps in the app catalog
• Break inheritance and remove Joe’s access to this folder so that only Bob has access to this folder
• Similarly, create a folder Site 2 Apps in the app catalog
• Break inheritance and remove Bob’s access to this folder so that only Joe has access to this folder

With this setup;

• Only Bob can add apps to his site, Site 1,  from the Site 1 apps folder from the catalog. He will not see the apps in the Site 2 Apps folder
• Similarly, Only Bob can add apps to his site, Site 2,  from the Site 2 apps folder from the catalog. He will not see the apps in the Site 1 Apps folder