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.
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.
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.
This tip is for Microsoft Office SharePoint Server 2007.
Just like a teenager, the Office Server Web Services need checking on from time to time as they both tend to get into trouble when left to their own devices.
So what are the Office Server Web Services? When would you want to check them and what can you do to make sure they are working correctly?
The Office Server Web Services at the most basic level is an IIS web application that contains the .asmx web service files used by SharePoint for some of the functions in the SSP like search and Excel Services. You will want to check the web services when your SharePoint servers have entries like the following in the ULS diagnostic logs or in an application Event Log ID #6482; “The underlying connection was closed: An unexpected error occurred on a send.”. Other effects that can occur when the web services are not working are profile information is not being updated in SharePoint web applications/sites and search gatherer not indexing.
So the quick way to check the health of the web services is to browse the following URLs in Internet Explorer from each SharePoint server in the farm. If you can see a list of web service methods like the images below the URLs, then the web services are working. Note that on the SSL URLs you will have to click continue on the IE window to ignore the untrusted certificate.
http://<APPSERVER>:56737/SearchAdmin.asmx
https://<APPSERVER>:56738/SearchAdmin.asmx
http://<APPSERVER>:56737/<SSPTITLE>/Search/SearchAdmin.asmx
https://<APPSERVER>:56738/<SSPTITLE>/Search/SearchAdmin.asmx
This tip is for Windows SharePoint Services 2.0/3.0, SharePoint Portal Server 2003 and Microsoft Office SharePoint Server 2007 and SharePoint Foundation 2010 and SharePoint Server 2010.
As a SharePoint administrator there will be many times that you will find youself running the SharePoint command line administration tool Stsadm.exe and other programs in the %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\<version>\BIN folder. Please, save your hands from RSI and update your PATH environment varible to include the location above. This will allow you to type just the command of Stsadm.exe from any location in a command prompt instead of typing out the change directory each time.
To update the PATH variable, go to Start->Run. Type sysdm.cpl. In the System Properties dialog click the Environment Variables... button. Under System variables, click PATH and then the Edit... button. If there is not a semi-colon at the end of the path enter one and then enter the path to the SharePoint BIN folder for the version of SharePoint installed on the server. For MOSS 2007 the path would look like the following:
%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\BIN
Now rejoice in your new found pain free SharePoint administration.