Known issues with SPDiag
Updated: August 27, 2009
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2009-08-20
Read this section for information about known issues in SPDiag.
When you import a project containing IIS or ULS log files that were generated on a computer with a different language setting than the computer running SPDiag, SPDiag experiences an unhandled exception due to an ASCII page code mismatch.
Workaround: Before you import the project, on the computer running SPDiag, change the locale in Windows Server Regional and Language Options to match the language of the computer on which the log files were generated. After the project has been imported, you can change the locale back to the original setting. However, if you import additional log files in the future, you will need to change the locale again before you import them into the project.
This issue only applies to SPDiag v2, as you cannot import projects in SPDiag v1.
When you create a new project in SPDiag, and you try to create the project database on a SQL Server computer that has been configured to use named pipes instead of TCP/IP, SPDiag experiences an unhandled exception. We recommend that you configure the computer running SQL Server and hosting the project database to use TCP/IP connections.
If you must use named pipes, you can work around this issue by adding the prefix np: to the pipe name in the format np:hostname.
This issue has been resolved in SPDiag v2.
If SPDiag is run in offline mode, the database column in custom reports will read NOT AVAILABLE. This is by design. When SPDiag is not connected to a SharePoint farm, this information is unavailable. If this condition is unexpected, check to be sure the farm is operational.
When you examine the “Installed physical memory” field in the Snapshot pane for a SharePoint server running in a virtual machine, the value is incorrect. There is no workaround at this time.
When Unicode characters are used in SharePoint URLs, IIS logging will convert the characters to questions marks unless UTF-8 logging is enabled in IIS, and the relevant language packs are installed on the computer running SharePoint Products and Technologies.
For more information on UTF-8 logging in IIS, see Enabling UTF-8 Format for Non-English Languages and Security (http://go.microsoft.com/fwlink/?LinkId=141340).
For more information about installing Office SharePoint Server language packs, see Deploy language packs (Office SharePoint Server) (http://go.microsoft.com/fwlink/?LinkId=141342).
For more information about installing Windows SharePoint Services 3.0 language packs, see Deploy language packs (Windows SharePoint Services) (http://go.microsoft.com/fwlink/?LinkId=141341).
In order for SPDiag to calculate and display farm performance counters (such as number of requests across the farm, or request response time), you must first upload the IIS logs for the desired time range by selecting them in the Consolidated Logs pane. If data from the IIS logs have not been uploaded to the project database, SPDiag cannot calculate the data, and no results will be displayed for these counters.
If an SPDiag project is missing data even though SPDiag has been configured correctly, the user account you are using to run SPDiag might not have sufficient permissions to access WMI data, or to copy log files from the target servers. Make sure the user account has administrative rights on all farm servers, and has been granted administrator rights using SharePoint Products and Technologies account administration.