This tip pertains to all versions of SharePoint and no versions of SharePoint. It is really more of an IIS troubleshooting tip. But we’ll let it slide for today. :)

The extended logging options in IIS can help in troubleshooting issues in SharePoint. HTTP status code logging can help with unauthorized issues and time-taken logging can help in performance related issues.

To enable the extended logging options for all web sites in IIS 6.0, open Internet Information Services Manager and right-click the “Web Sites” node and select Properties. Under Enable Logging click the Properties button. In the Logging Properties window, click the Advanced tab. By default not all of the extended properties are selected, select all of the properties and click OK. For IIS 7 the wording a slightly different. See the images below for more details.

This tip is for Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 and may apply to SharePoint Foundation 2010 and SharePoint Server 2010.

Although it is a good practice to manage the RFC 2822 header fields, or X-Headers in your email system, SharePoint does use some X-Headers for alert and workflow emails that need to be allowed in messages for all functionality to work. For instance, the edit or open task button in Outlook client (see below in red) may not work if the X-Header to connect to the task list is not present.

When clicking on the open or edit buttons, you may receive an error like the following:

An error occurred while retrieving the workflow task details. This could be caused by not having connectivity to the server or because the task no longer exists.

Here is a list of some of the X-Headers used by SharePoint in various versions:

X-Sharing-WSSBaseUrl, X-AlertWebSoap, X-Sharing-ItemID, X-Sharing-Remote-Uid, X-Sharing-Config-Url, X-AlertServerType, X-AlertWebUrl, X-AlertId, X-AlertTitle, X-Sharing-Title

So if your email servers are using any kind of message filtering, like the Exchange Server 2010 Header Firewall and wanting to have full functionality in Outlook for SharePoint emails; make sure that the above X-Headers are not blocked.

This tip is for Windows SharePoint Services 2.0, SharePoint Portal Server 2003, Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007, SharePoint Foundation 2010 and SharePoint Server 2010.

To reduce update surface and reduce conflicts, it is always a good idea to only load the specific versions of the .Net Framework needed for SharePoint to function. This follows with best practice to only load what is needed for the application(s) to function. Windows 2008 and IIS 7 are good examples of this type of methodology.

For WSS 2.0 and Portal Server 2003, this would be .Net Framework 1.1.

For WSS 3.0 and MOSS 2007, this would be .Net Framework 2.0 (x86, x64) and 3.0 (x86, x64).

For SharePoint Foundation 2010 and SharePoint Server 2010, this would be .Net Framework 3.5 SP1.

Note that some custom web parts and solutions may require a different .Net Framework version loaded on the SharePoint servers.

This tip is for Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 and may apply to SharePoint Foundation 2010 and SharePoint Server 2010.

There is a hidden list in SharePoint called Workflow History. This list is hidden from the “View All Site Content” and the “Manage Content and Structure” pages but you can browse to it and view information on running and completed workflows. The list is located at http://site/Lists/workflow%20history. Whenever a new workflow is created using the default history list, the workflow writes information to this list. Since workflows can write many items to the list whenever a workflow is ran, you can imagine that it can grow fairly quickly. Since the workflow history is a list, it is also bound by capacity guidelines on list size. This means that after about 2000 items per level/view in the workflow history list, the list performance will suffer. The best way to mitigate this is to create a new workflow history list when a new workflow is created. This way the workflow information is spread out between more than one list. The way to create a new workflow history list for a workflow will very between the various workflow types, the Web GUI can be used to change the workflow history list when creating a new workflow instance based on one of the feature workflows like Approval, Three-State, Collect Signatures, Collect Feedback and Disposition Approval. To create a new workflow history list in the Web GUI go to the list/library settings->Workflow Settings->Add a workflow. Select “New history list” from the History List.

After running a workflow with a new history list, a new list will be created with the following format; <Workflow name> History. So if I created a workflow called Approval1, and selected new history list; then a list called Approval1 History will be created.

In workflows created with Visual Studio with VseWSS installed, if the “Auto Associate” property is set to False for the project, then you will use the same steps as above to create a new history list. You can also run through the “New Office SharePoint Workflow” wizard by selecting the History List property and click the … button.

New Office SharePoint Workflow wizard

Workflows created in SharePoint Designer will write to only the Workflow History list. There is not any way to change this. So in this case, the only thing that can be done to keep the item count of the Workflow History list down is to trim the list in datasheet view manually. Deleting history items that are older than 60 days would be a good start, or create a program that will delete the items that can be scheduled with Task Scheduler.

So the take away from all of this is that you want to keep each workflow history list under the 2000 item limit so that the performance of workflow and the Workflow Auto Cleanup timer job stay within acceptable levels.

This tip is for Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 and may apply to SharePoint Foundation 2010 and SharePoint Server 2010.

Take the following example. You have a SharePoint web application with both NTLM and anonymous authentication enabled. You leave the default permissions on the root site collection for the web application. You create a new subweb under the root site collection and enable anonymous access. The site hierarchy would be similar to the one below:

· Web Application

·Site collection with NTLM and Anonymous

·Site with Anonymous

While it may be possible to shoehorn this configuration and get it working; I don’t advise doing so, a host of issues may occur depending on what type of site template and configuration the sites contain. One being, if the root site collection site is a publishing portal, the Anon subweb will not be able to search with the root site’s search center. Another being issues with the master page and style library files for the root site collection are not usually set to allow anonymous if the root site is NTLM. This can cause HTTP 401 Unauthorized issues on the anonymous site.