A brief overview of all important SharePoint 2016 directories and their functionality. All of these directories must be backed up so that SharePoint can be completely restored at file level in the event of a disaster. Don’t forget to backup the directories containing data from 3rd party applications.

To keep SharePoint running with optimal performance, it’s recommended to run the following maintenance tasks for your SharePoint databases:

Check database integrity

Defragment indexes by reorganizing or rebuilding them

Set the fill factor for a server

Those tasks may performed by Transact-SQL commands or using the Database Maintenance Wizard.

Check database integrityDBCC CHECKDB checks the integrity of all objects in a database. It’s recommend to run DBCC CHECKDB instead of DBCC CHECKALLOC, DBCC CHECKTABLE and DBCC CHECKCATALOG commands. DBCC CHECKDB identifies the widest range of possible errors and is therefore safer to run in a production environment. Because of heavy load it’s not recommended to run this check during production hours.

Defragment indexes by reorganizing them or rebuilding them
Since SharePoint 2010 uses SharePoint Health Analyzer rules to automate index defragmentation and statistics maintenance it is no longer required to perform those tasks manual. A daily health evaluation is done automatically for the following databases:

Config database

Content databases

User Profile Service Application Profile databases

User Profile Service Application Social databases

Web Analytics Service Application Reporting databases

Web Analytics Service Application Staging databases

Word Automation Services database

The following databases do not have an automated maintenance mechanism because they do not typically have much fragmentation. Monitor these databases for fragmentation and rebuild the indexes when fragmentation exceeds 30%.

Search Administration Database

Secure Store Database

State Service Database

Profile Sync Database

Usage Database

Managed Metadata Database

Business Connectivity Services Database

PerformancePoint Services Database

Use sys.dm_db_index_physical_stats to determine fragmentation for the indexes. The column avg_fragmentation_in_percent shows you the fragmentation in percent.

Set the fill factor for a server
A server-wide fill factor level of 80 is optimal to support growth and minimize fragmentation for SharePoint.

Shrinking Database
Shrinking causes index fragmentation and should not be done unless absolutely necessary. Only perform shrinking after you removed a lot of data from a database and you do not expect to use that free space again.

Some guidelines when you think about shrinking a database:

Do not auto-shrink or schedule shrinking tasks

Shrink database only when more than 50% of its content is removed

Shrink only content databases

Do not shrink during operation hours, it’s a highly resource-intensive operation

Creating a SQL Server maintenance plan
You can also automate and schedule the discussed maintenance tasks above. To do this open the SQL Server Management Studio, navigate to Management > Maintenance Plans and click on Maintenance Plan Wizard.

Click Next until you reach the Select Plan Properties page.

Specify a Name for your maintenance plan. Click on the Change… button to schedule the job.
If your environment has 10 or more content databases or more than 200 GB content it’s recommend to configure separate maintenance plans.

Specify the frequency, the day and the time to run the task. A weekly execution should be enough. Make sure you run the maintenance plan outside working hours.

Click Next.

Select Check Database Integrity, Rebuild Index and Maintenance Cleanup Task. Please note: You should either run a index reorganization or index rebuilding, not both. Do not shrink a database.

You can change the order of the tasks. Click Next.

Select the databases you want to check for integrity. You can select all SharePoint databases. Click Next.

Check the box to delete Maintenance Plan text reports. Check Search folder and delete files based on an extension and specify a folder for your maintenance plan logs. In the File extension field type txt (without . in front of txt).

By default, all IIS logs are stored on the C: drive. This is not recommended, however, because on the one hand this causes performance loss (depending on the configuration) and on the other hand there is a risk that the system drive will run full and the OS will crash.

Moving IIS Logs
Copy the following code into a text file (e. g. Notepad) and change the path in the second line. Save the file as PS1 by changing the file extension from filename.txt to filename.ps1. Run the file filename.ps1 as administrator on the server where you want to move the log files of all IIS sites.

By default, all SharePoint logs are stored on the C: drive. This is not recommended, however, because on the one hand this causes performance loss (depending on the configuration) and on the other hand there is a risk that the system drive will be full and the OS will crash.

Logs can be easily moved using PowerShell. The following commands must be executed on each SharePoint server in the SharePoint 2016 Management Shell.

Moving Trace Logs
The trace logs can be moved using Central Administration > Monitoring > Reporting > Configure diagnostic logging, in which the path is changed in the Trace Logs section. In my example, the new path is D: \Logs\SharePoint\TraceLogs

By default, all IIS logs are stored on the C: drive. This is not recommended, however, because on the one hand this causes performance loss (depending on the configuration) and on the other hand there is a risk that the system drive will run full and the OS will crash.

There are some limitations for changing license types and keys in SharePoint Server 2016. The most important ones are listed below.

Enabling SharePoint Enterprise Features
You can upgrade from SharePoint Server 2016 Standard to Enterprise at any time.

In Central Administration click Upgrade and Migration > Upgrade and Patch Management > Convert farm license type, enter the product key and click OK. The upgrade process may take a few minutes. Alternatively, this process is also possible using Enable Enterprise Features.

After successful activation click Enable Features on Existing Site to enable enterprise features on all existing sites.

Alternatively, you can do this manually by first activating the SharePoint Server Enterprise Site Collection features on the desired site collections via Site Settings > Site Collection Administration > Site Collection Features. You must then also activate the SharePoint Server Enterprise features on the same sites under Site Settings > Site Actions > Manage Site Features.

While setting up different SharePoint 2016 farms I’ve been running several times in the same problem. The creation of a users MySite was stucking on “We’re almost ready”. The reason for this is a feature that hasn’t been provisioned. This following solution works for me and is quite easy.

For testing purposes I deleted a Site Collection and tried to restore it in the same Content Database using the Restore-SPSite cmdlet. But then I got the following error message:

Sorry, something went wrong
The operation that you are attempting to perform cannot be completed successfully. No content databases in the web application were available to store your site collection. The existing content databases may have reached the maximum number of site collections, or be set to read-only, or be offline, or may already contain a copy of this site collection. Create another content database for the Web application and then try the operation again.

In some cases, for example when analyzing or optimizing the distribution of Site Collections in a SharePoint farm, it may be helpful to see which Site Collections are stored in which Content Databases. This can easily achieved by using this SharePoint Management Shell cmdlet:

Just a short reminder: As of today (October 13, 2015) Microsoft ends its mainstream support for SharePoint 2010. But don’t panic.. Your SharePoint farm will still be working, even after today. It actually keeps receiving security updates. However, Microsoft no longer distributes non-security updates or accepts requests for new features. In addition to it all warranty claims end, therefore you won’t get complimentary support by phone or online. But all knowledge base articles and product-specific resources will remain online, although the content is not maintained anymore.
If your farm is still running on SharePoint Server 2010 or SharePoint Foundation 2010 – no matter which Service Pack is installed – you should consider an upgrade to SharePoint 2013 or move to Office 365.