Default Install of SQLExpress Does NOT Work Well

I have modified one of the ASP.NET 2.0 Starter Kits using and when deploying it to a new server it works great when installed to a server that I have manually installed SQLExpress 2005 first, but if I deploy to a clean server and configure my standard Setup and Deployment project to require .NET 2.0 Runtime and SQLExpress 2005 problems start. The setup program will detect no .NET Framework or SQLExpress 2005 installed and will download and install them from Microsoft as it should. The ASP.NET web app installs correctly. I then grant the ASPNET machine account WRITE access permissions to the web app's App_Data directory where the database files are located for the application. For Windows 2003 Server this account has been renamed to: IIS_WPG.
To allow remote connection to this SQLExpress server, I then run the Surface Area Configuration Tool to allow remote connections via TCP/IP and Named Pipes and I set the SQLBrowser service to a running state with auto-start. The server is then re-started. The now infamous error occurs:

Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed.

The very same app can be XCopyed to another server where SQLExpress has been manually installed and where other ASP.NET web apps using attached DBF files are running merrily along, and it will work perfectly after granting ASPNET or IIS_WPG users write access to the app's data directory. Using local or remote access.

QUESTION? What is it with the default installation of SQLExpress 2005 when triggered via a Setup and Deployment project installer (MyApp.msi) and auto-downloaded from a Microsoft web site during installation of MyApp (ASP.NET 2.0 web application) that causes this.

This is a very bad thing if it is so hard for a web developer to distribute SQLEXpress with their applications and to get it running easily. The fact that the software is free pales against the backdrop of a support nightmare when a client just tries to get a simple web app up and running on a Microsoft IIS server. As a developer you have the intergrated SQL Server Developer Edition that just works, but when the rubber hits the road during deployment and the end user trys to install your "simple" web app and hits these roadblocks he/she justs gives up and moves onto another vendor's product.

Note to MS SQL Team: Distribute a product such as SQLExpress with the default settings set to allow the most reasonable security footprint for an intended audience. Default it to allow TCP/IP access for remote connections, and enable the SQLBrowser by default. Microsoft's focus on "security" goes way too far when the default installation of your products won't work out of the box without 3-4 days of searching the web for some arcane command settings. Do not ship a product such as this locked down for the FBI/CIA/Interpol/The Royal Canadian Mounted Police etc. They won't be shipping simple web applications that use it to small and medium sized businesses. They will however, use SQL Server 2005 Enterprise Edition and you can reasonably expect that they would have on their IT staff someone who knows how to "open up" the database from a security viewpoint. Your "free" product must work in a reliable, no-touch mode right from the box for the small developer to interested in shipping it with their software products. SQLExpress 2005 is an excellent product and a great step up from MSDE 2000, but when it doesn't work, it can bring a small development shop to its knees. I had a well-tested and running ASP.NET web application that used SQLExpress rejected by upload.com because when they went to verify that the application ran it was installed onto a clean machine and the .MSI installer triggered a download of .NET 2.0 Framework and SQLExpress. Developers such as myself look stupid trying to explain to an upload.com QA team that "the program really runs; honestly...", you just have to stand on one foot, touch your nose with your left hand, while learning to use the included Surface Area Configuration tool.
Assume little to no knowledge on the part of the end user installing an application, and configure your default settings of a low-end product from that perspective. The end user in a small business tring a demo web application should not have to worry about port numbers, surface area configuration tools, or any of that, they just want a product to work well.

By the way, don't get the impression that I am mad or otherwise frustrated from using this product...

That pretty much says it all... seems issues have not been addressed since Nov 2005... Do you have any tips regarding remote connections since you have dealth with many of the issues earlier...