The Microsoft recommendation for SharePoint database fill factor has changed over the years.  In SharePoint 2007, the recommendation was 70.  However, a new stored procedure was introduced in the content and configuration database as of SharePoint 2007 Service Pack 2.  This stored procedure, named proc_DefragmentIndicies, set the fill factor to 80 when running SQL Server 2005.

SharePoint 2010 continued to leverage the same stored procedure by way of the Health Analyzer rule “Databases used by SharePoint have fragmented indices“.  This rule would run proc_DefragmentIndicies, and based on certain conditions, would reindex or rebuild the indices as well as set the fill factor to 80.

Now we introduce SharePoint 2013.  The same Health Analyzer rule exists, however proc_DefragmentIndicies has changed, and thanks to Vlad Catrinescu over at SharePoint-Community.Net for pointing that out.  It no longer sets the fill factor!  In addition, store.sql (the SQL script used to create content databases) sets the fill factor to 95 for most indexes, and 100 for the remainder of the indexes; in SharePoint 2010, the fill factor was not set by default from this script.  A fill factor of 80, for content databases, is nowhere to be found.

Microsoft also introduced two new classes in the Microsoft.SharePoint.dll and Microsoft.Office.Server.dll.  These classes contain references to add indices, including one interesting property:

It appears, and I have no confirmation on this, that a fill factor of 80 is, by default, no longer appropriate for SharePoint 2013.

When using the built-in mechanism to send email from SharePoint (or SPUtility.SendEmail), SharePoint stamps a X-Mailer header of:

Microsoft SharePoint Foundation 2010

If SharePoint is configured to send to the same SMTP service it is set to pick mail up from, SharePoint will drop any message with the above X-Mailer header indicating a possible message loop.

One thing to watch out for in a two-way trust scenario with the People Picker.  Typically with the People Picker in a two-way forest trust, you do not have to make any changes to SharePoint to resolve users in the target trusted forest.

However, if the Administrators of the target forest have chosen to implement Selective Authentication, you’ll run into an issue where by users cannot be resolved in the remote domain.

The ULS log will display the following (this was a search for ‘user’):

Additionally, a Network Monitor trace from the SharePoint server will show the following entry at the time of the attempted search:

In this case, 10.10.20.18 is the SharePoint server, a member of Nauplius.local, and 10.10.20.25 is the Domain Controller for Contoso.local.  With Selective authentication in place and with the Application Pool service account not having any explicit rights in Contoso.local to resolve users, we receive KDC_ERR_POLICY.  In order to resolve this issue while maintaining Selective Authentication, add the Application Pool account (or any account needing to resolve users in the remote domain using the People Picker) the Allowed to Authenticate right in the Domain Controller computer objects in the remote domain.  Make sure to do this for each Domain Controller computer object in the remote domain that SharePoint Server is able to authenticate to.

Given no Kerberos tickets were previously granted by Contoso.local to, in the above example, to NAUPLIUS\s-sp2010apppool, there is no need to log the account out of the SharePoint server(s) (in other words, iisreset).