Disable Windows Update Service

In my SharePoint 2013 farm, I was seeing the svchost.exe taking up a lot of memory directly affecting the performance of my site.

There's a great article on How to Troubleshoot svchost.exe Issues to determine what service is the culprit of your memory leak. In my case, it was the Windows Update Service. Since my Windows Updates are controlled by a group policy, I decided to disable this service which solved my performance issues.

Go to Start > Administrative Tools > Services. Right click the Windows Update service. Under Startup type, selected Disabled.

Set Up an IIS Response Header

If you have a test or staging environment, it is helpful to set up a response header if you have multiple Web front ends (WFEs). Then you can easily determine which server the error is on through your browser's developer tools, Fiddler, or an equivalent.

Open IIS 7, click on your site. In the Features View, double-click on HTTP Response Headers icon.

Now click on the Add link in the right navigation pane. For Name, enter something that is meaningful to you. In my example, I chose ServerName. For Value, type in the details. I entered WFE1 in the example below. You don't need the whole server name, just some hint that will quickly identify the server.

Using Fiddler, you can easily see the result under the Headers tab.

Be Concerned About Security

Something to keep in mind is that it's never a good idea to give away too many details about your server so never identify your server names in a production environment. This is just very easy way to help troubleshoot.

SharePoint in Practice

Where SharePoint is considered, when you get an error you always are given a correlation ID. If you know which server you are on, you quickly know which server to check the logs on. In a multi-server farm, this can save a lot of time.

 

Configure Logging for SharePoint 2013

All log files can become large. If you get a major error that fills up log files quickly, a consequence is your disk space can fill up and cause your SharePoint site to crash. So avoid this issue (and keep your system administrators happy) by moving all your log files to an external drive. This process applies to both SharePoint 2013 and SharePoint 2010.

Configure your logs to an external drive (anything other than C:). I'll use a D: drive in my example. I like to create a LOGS folder and underneath create separate folders for all my key logs.

IMPORTANT! Make sure you configure the same folder structure on the same drive on all your servers in your farm.

Here’s the folder structure I use:

• LOGS
• Trace
• Usage
• IIS

SharePoint Logs

Trace Logs

In Central Administration, go to Monitoring > Configure diagnostic logging. Near the bottom on the screen, update the Path to your external drive location such as D:\LOGS\Trace\.

Usage Logs

In Central Administration, go to Monitoring > Configure usage and health data collection. Under Log file location, update the path to your external drive location such as D:\LOGS\Usage\.

IIS Logs

In IIS under the server name, click Logging. Update the directory location. Staying consistent with my example, I would update the location to D:\LOGS\IIS\. You’ll have to do this step directly on all servers in your farm.

That’s it! Now all your log files are easily found in one location and they won’t cause your SharePoint to crash if the logs fill up.

Virus Protection and SharePoint Exclusions

Servers with virus protection software such as Symantec or McAfee can sometimes cause problems for SharePoint. It is important to exclude certain key folders for SharePoint. If the content in these folders became quarantined, whammo! All of SharePoint is down. This holds true for all versions of SharePoint.

Now you don't really want to exclude folders entirely in a production environment. That would be silly. You still need protection. So in production, just be sure to disable on-access scanning. In a test environment, you can exclude these folders from all scans. Terminology may vary by virus protection software.

The key folders are:

• C:\Program Files\Microsoft Office Servers
• C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions

Additionally, on your search server exclude your index folder. You can find your search index location through this sp shell script:

$ssa = Get-SPEnterpriseSearchServiceApplication
$ssa.AdminComponent.IndexLocation