Unfortunately, it won't work. I tried several times using srvany, but the GUI portions of the server need to have a "desktop" login to interface with. I would end up with a hung process or a failed service start. It's unfortunate that an MS game doesn't support this and has features that keep it from being done "home brew" style.

I was actually wondering about this as well, the way I can see it working is to place it in startup folder and use a script that would hit the okay button. Haven't played with it as of yet...

(SR) Syndicate is running FLSERVER as a service using Fire Daemon. I got it work, however, I had to run it in an interactive desktop mode the first time to setup the console and server settings. Install the service and then stop it and go back into properties. add the /c switch and then make the service non-interactive with the desktop (It's just a check box on the settings tab). It will run as a service from that point forward. I tried to load FLAdmin but it doesn't want to play with FD well. Probably due to the fact that it cannot get exclusive access to the app (which is now a service).

Fire Daemon is at www.firedaemon.com. If there is a lot of interest in how to do this, I will draft a how to guide and get it to the LR folks to publish.

CEJ
SysAdmin for (SR) Syndicate FL Server

I've since tried with the NT resource kit tool (SRVANY?) but couldn't get it to work because of the interaction with the desktop. I think FireDaemon is a bit more sophisticated in this respect so I'll download a recent version (not used FD for years!) and give it a go.

Bit concerned about running without FLADmin, at least until FLServer is patched and a bit more stable. I'm assuming the reason it doesn't work as a service is that it hooks into the FLServer GUI. I'm no Win32 programming expert but I presume it'd be fairly easy to adapt the code to have it monitor a service instead of an application.

Maybe if that guide were written and more server ops were running it as a service we could persuade FLiK to make the necessary changes!


--

>bRydeR<

The /c parameter to FLServer.exe makes the server silent, so you have no interaction with the desktop!

"Bit concerned about running without FLADmin, at least until FLServer is patched and a bit more stable. I'm assuming the reason it doesn't work as a service is that it hooks into the FLServer GUI. I'm no Win32 programming expert but I presume it'd be fairly easy to adapt the code to have it monitor a service instead of an application."

Well, the Fire Daemon restarts the server automatically, just like a service. It does bomb out once and a while, and all you have to do is restart the service.

I use FLPing to check the server. It's a pretty cool little CLi utility that you run from a CMD dialog.

CEJ
SysAdmin for (SR) Syndicate FL Server

Edited by - CEJ on 22-04-2003 18:57:00

"Well, the Fire Daemon restarts the server automatically, just like a service. It does bomb out once and a while, and all you have to do is restart the service."

Presume you mean automatically on server boot-up (as per any Windows service set to auto in NT/2K/XP) rather than on a server crash?

The server is remote and normally unattended so it'd be difficult to connect regularly to restart the service - really needs to be done automatically, considering the stability issues with current version of flserver.exe


--

>bRydeR<

"Presume you mean automatically on server boot-up (as per any Windows service set to auto in NT/2K/XP) rather than on a server crash?

The server is remote and normally unattended so it'd be difficult to connect regularly to restart the service - really needs to be done automatically, considering the stability issues with current version of flserver.exe"

Actually no. My server is remote as well. I use a remote console utility similar to VNC or PCAW to control it.

FD will restart the service when it fails, however, sometimes the service does not load correctly and thus, it bombs out. I have only had it bomb out once.

When the server bombs out (it really does appear to be a mem leak), the server stays up, the service appears to be running, and the server does not have any additional issues (my NWN and TS service is unaffected). I just have to attach to the server, open up the FD tool and restart the service via the tool bar. Takes about 3 mouse clicks once I attach to the server.

Again, I use FLPing to make sure the server is up.

CEJ
SysAdmin for (SR) Syndicate FL Server

Edited by - CEJ on 22-04-2003 21:10:10

"When the server bombs out (it really does appear to be a mem leak), the server stays up, the service appears to be running, and the server does not have any additional issues (my NWN and TS service is unaffected). I just have to attach to the server, open up the FD tool and restart the service via the tool bar. Takes about 3 mouse clicks once I attach to the server."

Thanks for the input... I'll have a dablle with FD over the weekend when I have more time. At the moment I'm running it in a Terminal Server session so aid remote management but it's far from ideal.


--

>bRydeR<

Chck out VNC. It's worth a look as well as being an open source product.

I am using the pro version of FD, but you should try the lite version first. Let me know if you have issues and I will walk you through what I did.

CEJ
SysAdmin for (SR) Syndicate FL Server

"Chck out VNC. It's worth a look as well as being an open source product."

Had VNC running on an earlier server build but wasn't entirely happy with it (don't recall why) and reverted to pcAnywhere.

Don't have either on my current build as I found Terminal Services a bit quicker than either product and XP has the client installed "out of the box". A couple of the networks I need to connect to my server from don't pass traffic on the ports used by other remote control products but do allow RDP so I'm stuck with it anyway.

Only PITA thing is that you can't remote control the console session using Terminal Services, which pcAw and VNC both allow. Not ideal at the moment as it means running FLServer.exe in a TS session to allow remote admin, but hopefully that will no longer be necessary if I get it running under FireDaemon.



--

>bRydeR<