I just installed a clean CS2007 using the MSI installer. I use a backend SQL2005 server that is on a different host than the web server. The install completed successfully, but upon loading the CS web page, I received a data provider error.

The database has a user NETWORK SERVICE but the error message says that login to the SQL database has failed for DOMAIN\MACHINE$ - so it looks like CS is trying to access the SQL database using the machine account and not the Network Service account.

Maybe the installer needs to add a SQL login for the machine account?

I'm also having this issue after running the CS2007 Beta 2 MSI .  Does anyone know how to resolve?

Here is the full error message...

Critical Error: SiteUrls.Config The file containing the SiteUrl Data could not be loaded. Please contact your CommunityServer administrator. A technical explanation of why this error is caused is below.

Community Server expects to find a valid XML file containing all of the links for a community. By default, this file is located at the root of the with the name SiteUrls.config.  A common error is to included unescaped XML characters, such as "&" when defining a querystring. If available, the location of the error will be listed below: Unable to open connection to data provider. Login failed for user 'GWTECHSERVICES\DEV03$'.

 

 

I consulted with resident SQL guru David Penton, here is his answer:

"Basically if the db and webserver are not on the same machine, I just use sql auth.  There are ways to do it these days, but for the most part servers are not guaranteed to be set up in such a way that SSPI can be used."

It looks like you cannot always use the Windows Auth option - the SQL Auth option is much more likely to work in all circumstances.

SQL authentication is a poor alternative to Windows integrated security. Microsoft seems to agree and applications such as MS CRM 3.0 and SharePoint 2007 install perfectly well with Windows security on remote SQL2005 servers, so it is certainly a supported and recommended configuration. CS manages to set everything up but then fails to set the correct permissions on the database. Surely this is just a bug - not a policy?

NameOfTheDragon,
I totally agree that it is a supported configuration.  But, hHaving a database setup to run at NETWORK SERVICE is not really the best scenario anyways.  I believe the expectation is that if the administrator (i.e. the person installing CS) should be knowledgeable enough about the configuration to be able to set that appropriately.  I'll tell you this - if you website is trying to access a database with NETWORK SERVICE you can't expect to access a remote database with that.

I agree with you about Network Service - but none of the application I mentioned work that way. In the case of SharePoint 2007, for example, the administrator must nominate a domain account and provide the login credentials for that account during the setup process. All data access is then performed using those credentials.

In the grand scheme of things, I guess I don't really care if CS uses domain credentials or a SQL Server login. What I don't think is acceptable is that the installer exits leaving the installation non-functional. Either don't let me get into that state, or tell me what I need to do to fix it, but don't just abandon me.

Also, since SQL authentication is disabled by default in new SQL installations, that's another reason not to rely on it. I hate it when the tail wags the dog - that is, I'm forced to reconfigure my domain security policy to accommodate one application. I've said my piece and now I will be silent, but I urge the CS team to look again at this and resolve it one way or another.

NameOfTheDragon,

It really depends upon who you talk to at Microsoft as to whether Windows Authentication or SQL Authentication is better.  MOSS 2007 is a poor example to use as it is designed for Intranet usage, not Internet usage, no matter what anyone from Microsoft tells you.  There are some serious drawbacks to Windows Authentication (mostly with connection pooling) that have gotten better over the years, but there are still serious performance and security issues with it when used for Internet applications.

Usage of the "NETWORK SERVICE" account should only be used if both the client and server ar on the same machine.  AFAIK, you can't access the "NETWORK SERVICE" account of another machine.  Giving the "NETWORK SERVICE" account access to your SQL Server is a very serious security risk.  This account is supposed to be a limited access account and giving it additional access rights is a bad thing.

Anywho, take it easy,
Bill