views:

85

answers:

2

I've recently setup a couple servers with the intention of moving our websites on to them. One is Windows Web Server 2008 and the other is Windows Server 2008 Standard running Sql Server 2008.

The first thing I installed was FogBugz, and everything seemed to install and run smoothly until we stopped using it for a while. Then when trying to access it again, I get an error saying it can't communicate with the database. This persists until I log into the web server via RDP. Then if I refresh the fogbugz page, it loads the page just fine.

I've done this a number of times now, and it seems that if the website isn't used for about 30 minutes, it will no longer be able to communicate with the database. But shortly after connecting via RDP (I don't make any changes) it starts working again.

Any ideas what might be causing this problem?

Edit: Some more details

The answer posted seems like it would be the cause, however the FogBugz account that was created is a local account, not a domain account. And the web server is using SQL Authentication, not windows authentication, so I'm not sure what would be running under a domain account. Is there some way to see what's running as a domain user?

Edit:

The problem is definitely related to the communication with the database somehow. I switched the app pool from the FogBugz user to NetworkServices and I've also installed a shopping cart app which has the exact same behavior. When I'm logged into the server, the websites work. When I'm not, they don't. It's just the db connection that is lost. FogBugz for instance shows a help page saying how to set the connection string. What would be running that manages database connections as a domain account?

A: 

I have a distant vague memory of something similiar, that was caused by the identity that the web site was running under, i.e. it was running under a domain\user (such as yourself) instead of a service account. The symptom was the same; after that user logged back on to the host, things would start working again.

Mitch Wheat
That definitely sounds like the problem. I'm logging in using a domain account. I didn't explicitly tell anything to run as the domain user though. The connection string is using a SQL Server account, not a windows account for authentication.
Timothy Strimple
A: 

There was something stranging going on with the domain controller. I brought up a new domain controller, and moved the existing servers over to it and the problems went away.

Timothy Strimple