Sounds like your server has gone "deaf" a known problem with FileMaker server. Try restarting the server and/or restarting the server computer to see if that corrects the problem.
For More Information see: FMSA 10 stops external authentication; Admin Console can't stop database server or close databases
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
Sheesh. I read the link and that sounds terrible. I'm thinking maybe I don't want to run server. Terrible that there are such problems but worse, that they go on for months without solution.
While I evaluate a little further, what about FMServer running as a service? So it can be running even before anyone has logged onto the win server? And about it automatically opening certain dbs so they're available as soon as the win server boots up?
FMServer is a service already. With a Java application also running as the administration "console" for managing the hosted database files.
The issue is poorly understood at this time as some servers never have this problem and the frequency with which it occurs varies a lot. I use FMServer 10 which has more trouble with this issue. Supposedly, FMServer 11 has upgrades that reduce the impact of this particular issue.
Please note that a deaf server continues to function normally for the clients, but you cannot use the admin console to close files or run server schedules--such as scheduled backups. And we would have a great deal of trouble using FileMaker the way we need to use it with out Server, its regularly scheduled back ups and scripts and support for more simultaneous clients than we could manage without server.
We have one server running Windows Server 2007 in 64 bit mode that frequently has this issue and I routinely restart the server remotely in the early morning before anyone is using the database when I spot the issue. A second server running a very similar version of the database, but with Windows Server 2003 in 32 bit mode has never once had this issue. Thus, we've made tentative plans to set up a virtual install of 2003 on the problem server to see if that works any better than the current setup...