Hi Bill,

As SpamFilter progresses, we'll try to store all of the settings in a database, which will make remote administration simpler. I do not have any time estimates on this though.

Roberto F.
LogSat Software

Roberto wrote:

This has been discussed extensively in the forum. Unfortunately Windows 2000 Terminal Services do not allow to see the server's console, and thus the admin GUI is not visible with Terminal Services under that OS. Windows 2003 Terminal Services do not have that limitation, and for NT4, any remote utility which allows access to the server's desktop will show the admin GUI.

Hi Roberto,

Yes, I am aware of all this, but what I'm suggesting is that you all create a GUI tool to configure a SpamFilter server that's not on the current machine. Not everyone wants to run IIS and, on top of that, write their own administration interface. Also, remote GUI access, while my only option right now, is not the best enterprise-wide solution.

Regards,

Bill

Bill,

This has been discussed extensively in the forum. Unfortunately Windows 2000 Terminal Services do not allow to see the server's console, and thus the admin GUI is not visible with Terminal Services under that OS. Windows 2003 Terminal Services do not have that limitation, and for NT4, any remote utility which allows access to the server's desktop will show the admin GUI.

SpamFilter is very flexible in allowing administrator use various tools of their preference to make remote changes to the settings. We have purposely left this open as some users will want to access the config files using the web, other will see this as a security risk and will access them thru the network. Other yet write batch jobs to update their config files from nightly exports of their 3rd party applications. Out of the box we offer a GUI on the server itself to make all necessary configurations. If users want more we designed the system to (we hope) be as customizeable as possible.

Roberto F.
LogSat Software

Hi Sean,

No offense taken. :-) Right now I am actually using a Windows-only variant of VNC called UltraVNC. But that's not the sort of solution I am looking for. Using remote control is pretty clumsy at best. I'd much prefer an actual remote administration console of some sort.

Regards,

Bill

Bill,

I wasn't declaring your lack of knowledge of Microsoft IIS, I was just tryinig to help. Anyways here's another possible solution, best part is it is free. Let me know if it helps.

Anyone else looking for a way to remote Admin SpamFilterISP should also take a look at this. It might help.

Please check out: RealVNC

http://www.realvnc.org

Basically it's an open souorce PCAnyWhere solution.

-Sean

Sean wrote:

Well the Web Access is available from Logsat, it was on their main download page. Out of the box its nice for users, but as you said, custom work takes time.

Sure -- time I don't have. And I don't think I should have to write it anyway.

Also, since you are most likely running this on NT 4.0 or Win2000 or Win2003 you most likely already have the web server running and may not know it. Take a look at Microsoft IIS. That's the web server.

I know what IIS is and what a web server is. I am not running it on purpose because I have no need to do so. I do not want to open my network to vulnerabilities just so I can have an administration interface for SpamFilter. I believe that is unnecessary and that this functionality should be provided as part of the product. Hence the feature request.

Regards,

Bill

The problem is that I don't have a web server (nor do I need one or want one), and I don't really have time to write my own remote administration interface. I think this functionality should be a part of the package.

Regards,

Bill

Bill,

As Sean states, there is not much that can not be done VIA web interface.  Even the the settings that are set only in the GUI, can ve changed in the ini file and then a service restart issued.  We manage all our instances of SpamFilter totaly through custom ASP pages and a couple of Perl Modules.  The only time I use the actual GUI is during testing of build changes and debug sessions.  Most of the settings that must use the gui to change, are set once and not changed often there after.

Regards,

Dan S.  (SpamFilter User)