Posted by Alex Verboon on 19th May 2010
If you get tasked to do some system troubleshooting and you just want to get as many information possible from a client, then have a look at the Microsoft Product Support Report Tool and the Product Support Reports Viewer.
The Microsoft Product Support Reports Viewer 2.0 can be downloaded from here and the Microsoft Product Support Reports from here
First launch the Microsoft Product Support Tool, which is a self-extracting executable (no installation needed). Once launched you can select the diagnostics you want to execute, then select Next to get the Diagnostic (Data Collection) started. Note that depending on the diagnostics selected, this process can take a while (up to 25 minutes).
Once the Diagnostic process has completed you can browse, e-mail or save the results. When saving the results, all data is stored in a single CAB file.
The Microsoft Product Support Report Viewer provides an interface to view the collected diagnostic data, which consists of several individual XML files.
While the diagnostic tool was running on my client, I copied the content of the temporary folder that the tool creates within the users TEMP folder into another folder. (if you have many folders in your TEMP folder just sort by date, and open the one with the newest date).
Within that folder you will find a Tools folder which contains all the executables and scripts used by the Diagnosis Tool.
So next time you get one of these famous calls to help solving a system problem, consider using this tool to gather detailed system information data.
Tags: support, Troubleshooting
Posted in Active Directory, GPO, Knowledge, Microsoft, Network, Performance, Protocols, SQL, Tip, Tools, Windows 7, drivers | 1 Comment »
Posted by Alex Verboon on 14th March 2010
During the Installation of the App-V Management Server on a Windows Server 2008 with SQL Server 2008 Express installed I ran into an problem specifying the database server and got an error as shown in the picture below. 
The installation program could not connect to the configuration data store. Please see the installation log file for more information.
I solved the problem by opening the SQL Server Configuration Manager and enabled TCP/IP in the SQL Server Network Configuration options.
Within the Properties specify Port 1433 as shown in the picture below.
Finally restart the SQL Server Service. Once the SQL Service has restarted the App-V Management Server installation Wizard should find the SQL Server Instance.

Update: May, 2010, although I managed to get this running with SQL 2008, i recommend using SQL 2005 as that to my knowledge is the official supported SQL Database. Any inputs welcome.
Tags: 1433, App-V, Port, Setup, SQL Server 2008
Posted in App-V, Protocols, SQL, TCP/IP, Tip | 2 Comments »
Posted by Alex Verboon on 7th March 2010
I got a bit confused by all the different SQL Server 2008 Express downloads that exist, so spend a little time in getting some insight. If you want to download SQL Server 2008 Express you have the following options:
| Package |
Download |
| Microsoft® SQL Server® 2008 Express Edition Service Pack 1 |
Download |
| Microsoft® SQL Server® 2008 Express with Tools |
Download |
| Microsoft® SQL Server® 2008 Express with Advanced Services |
Download |
Then I recommend reading the following blog posts. What’s up with SQL Server 2008 Express editions provides an overview of the supported feature of each distribution. The SQL Express 2008 family is getting bigger gives a good insight what the different installation packages do contain.
Tags: Download, Edition, Express, SQL, SQL Server 2008 Express
Posted in SQL, Tip | No Comments »
Posted by Alex Verboon on 20th November 2008
When you install SQL Server 2000 / 2005 / 2008 you can configure under what user account the services are running. In the past i’ve often seen people selecting “local system”, I also selected that….not thinking too much about security then and it was the easiest to do with no need to create an additional user account and as long as you don’t need to access any other domain resources that worked fine.
Today from a security perspective though running the SQL services under the local sysem account is probably not a good idea, as the local system account is equivalent to a local administrator, so bad code that might get into your SQL server might hit the underlying system as well. From reading various sql forum postings and articles and Microsoft Technet articles it appears to be the best to simply create standard users accounts, during installation these accounts are being given the necessary permissions on the system they need.
If you don’t need access to other domain resources, the creation of local user accounts on the system that hosts the SQL server is enough, if not create them in AD.
The article “Picking Service Accounts” describes it all in more detail. (note that you must register yourself to read articles on SQLServerCentral.com
Tags: Security, SQL
Posted in SQL, Security, Tip | No Comments »