This error can show up with or without the URL displayed. In either case the errors in the log show the URL attempted.
Error 1 VSeWSS Service Error: No SharePoint Site exists at the specified URL: http:///. The Web application at http:// / could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.
Log file written to: C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log 0 0
Spoiler: On a single server installation, the Default Public URL must be the Server Name. If you server is named Dashboard, then your Default Public URL must be http://dashboard/
Changing the Default Public URL will break VSeWSS deployment
There are a lot of posts around the internet to try to address this issue, and in most cases, not all situations are resolved. There are a lot of configurations that can cause this error, and so it was a configuration issue in my case.
My installation consists of 64 bit versions of Windows 2008 R2 with SQL Server 2008 and Visual Studio 2008 with VSeWSS 1.3 for 64bit installed on a single VM server. SharePoint is the only site on the machine and is using the default port and URL. i did modify the setup to use the SQL Server for the config database instead of the windows internal database. App Pools are setup properly using a domain account that has full permissions both in IIS and SQL Server. The account has also been added to every group and administrator list available in SharePoint Administration, and has been added to all WPG groups in windows, but the problem persists.
I then began experimenting with Alternate Access mappings, per suggestions returned by google searches on this subject. What I found was most interesting - When I added host header bindings in IIS Manager it broke the site, but when I added alternate access mappings through Central Administration those mappings worked. Several reboots and frustrating days later I returned to my site bindings, and there were the alternate access mappings I had made previously!
At this point I began to get suspicious - those bindings did not appear when I first added the mappings, so something under the hood must have found and generated them based on the mappings I added. So I did some research on Alternate Access Mappings and found this little note:
Host-named site collections cannot use alternate access mappings. Host-named site collections are automatically considered to be in the Default zone, and the URL of the request must not be modified between the end user and the server.I then revisited my Alternate Access Mappings and found that the Default Public URL of my server was not the server name - my servername is dashboard, in the domain mysite.org, but my Default Public URL is dashboard.mysite.org
http://technet.microsoft.com/en-us/library/cc288609%28office.12%29.aspx
Once I removed all Alternate Access Mappings and changed the Default Public URL to http://dashboard, VSeWSS deploy was successful!
I then added http://dashboard.mysite.org as the Internet Public URL - leaving the Default Public URL http://Dashboard and my site was once again available via multiple URLs, without breaking VSeWSS deployment. When you add a Public URL, Central Admin automatically adds the appropriate Internal URL for the modified Zone Public URL.
The lack of IIS7 documentation in regards to SharePoint is disappointing - IIS 7 is significantly different under the hood (eg no metabase file) than IIS 6 so the references are not relevant - new documentation is needed!