What information should I gather for ServiceDesk troubleshooting?
Last Updated February 29, 2012
1. Details about the issue: a. What exactly do you do to get the issue - steps to reproduce. Use screenshots, steps, screen recordings as needed. b. Make sure you include the exact time (or times, timeframes) the issue occurred, it is needed to find the relevant info from logs. c. Are ServiceDesk workflows customized in any way? If they are, how? d. Version of ServiceDesk installed (and Workflow version, if different).
2. ServiceDesk server: a. CPU cores, RAM b. If virtual environment, also a general description on how these resources are allocated. Note: Allocated resources in virtual environments are required to be dedicated, not shared. c. Are there any other applications installed that run on IIS? d. Zipped copy of the ServiceDesk Logs folder located under ServiceDesk install folder. (default location for ServiceDesk 7.0 - C:\Program Files (x86)\Altiris\Workflow Designer\Logs)
(default location for ServiceDesk 7.1 - C:\Program Files\Symantec\Workflow\Logs)
3. SQL Server hosting ServiceDesk database: a. CPU cores, RAM, Storage subsystem. b. If virtual, also a general description on how the resources are allocated. Note: Allocated resources in virtual environments are required to be dedicated, not shared. c. How is SQL Server configured to use RAM? d. Which drives (logically, physically) are ServiceDesk database, its Transaction logs and TempDB located on? e. Are there any other SQL Server instances besides the one hosting ServiceDesk database? f. Are there any other databases on the SQL Server instance that hosts ServiceDesk database? g. If there are other instances or databases on the same server, what are these? h. Is there a maintenance plan in place for ServiceDesk database to update statistics and rebuild indexes? How often does it run, has it been running properly? i. Recovery Model for ServiceDesk database should be Simple.
4. If there are SQL timeouts, deadlocks or connectivity issues in the logs, these tools will be useful: a. Collect and analyze PerfMon counters: TECH124987:Analyzing SQL Performance Using Performance Monitor Counters Note: With SQL Server hosting ServiceDesk database, always make sure these are gathered for all drives mentioned in point 3.d. above: - Physical Disk: Avg. Disk Queue Length - Physical Disk: Avg. Disk Read Queue Length - Physical Disk: Avg. Disk Write Queue Length b. When there are SQL timeouts or connectivity issues, you can use the SQL Ping tool to verify the stability of SQL connectivity: HOWTO5610:SQL Ping tool v1.4