Cindy Gross, Dedicated Support Engineer

Gathering the right data during a problem can get you a long ways towards resolving the problem. When you ask the right questions and clearly define the problem it changes the way you approach the remaining steps. Sometimes the answer to a seemingly simple question leads you right to the solution. In this series of data gathering blogs I am NOT going to tell you how to solve the problem, but I am going to tell you how to get a good set of troubleshooting data you can use to do your own troubleshooting.

Any time you have a SQL Server setup issue you will need to collect this information:

• Date/time of the failed setup
• Type of install and parameters used – GUI, unattended/command line, slipstream, sysprep
• Number of attempts, any actions you took to cleanup or remove prior installs
• Version/Edition/Exact build #/32bit or x64 or IA64 for
• Windows
• SQL Server
• Virtualization software (Hyper-V, VMWare for example)
• How many cluster nodes and SQL instances or state that it’s standalone
• Whether the problem is with RTM, SP, and/or CU
• Whether the problem is with a new install or an upgrade
• What components you are installing (Client tools, SSIS, SQL, RS, AS, BOL, samples) and whether any succeed
• Exact error message
• Repro steps and/or failure scenario
• All setup logs (i.e. %ProgramFiles%\Microsoft SQL Server\x0\Setup Bootstrap\LOG)
• Which step in the build doc you are at when you see the setup failure
• What permissions have been enabled/granted for MSDTC
• Any steps you take to attempt to resolve the problem and the result
• If on a cluster, have you re-run the cluster verification log and addressed all errors and warnings?
• Did you run setup using “run as administrator”?
• What account did you log into Windows with when you ran setup and what groups does it belong to?

Armed with this information you are now ready to solve the problem!