[quote user="Greenman"]You can use Group Policy to force a screensaver to kick in after xx minutes. It locks the server/client.[/quote] We have such a GPO additionally in force. Locks all client machines after 15 minutes inactivity. [:D] We had to implement additional security measures after the great EU General Data Protection Regulation came in force this summer.

Cheers

Joerg

Hi I bought a proper licence for Mercury so I could set it up to run as a service.  The service is now running and email is flowing whether or not the mercury software is running or not so it is working as a service properly and was working with noone logged into the server which is good.

The problem is now when I have the mercury software open I cannot see the emails coming in and out in the status windows.   Is there a way to get the status messages to show in there so I can actually watch the emails coming in and out like I could when mercury was running as a stand alone application I am on V4.73 installed on 2008 server R2?  Is there a different interface I should now be runing to control mercury now it is a service and not the application itself or a setting that needs changing?

Thanks Graham

Hi I had to make a change on the system and it didnt take affect until I restarted the service, but when I restarted the service the status windows in the mercury I had open started showing the mail again.  So I think if the mail doesnt show in the windows I just need to restart the service.

Since Windows Vista Windows users aren't allowed to interact directly with programs running as a service. This can be solved by having a second program that communicates with the service in an alternative way, but the current version of Mercury does unfortunately not support that. Mercury v5 will though, and we hope to start beta testing it soon. Until v5 arrives the options are to run Mercury as a service under Windows XP, or to shut down the service and run Mercury in application mode to access console windows and configuration. The application will then need to be shut down again before restarting the service.

Hi the odd thing was when I restarted the service while the mercury loader was active the mercury loader took over and the windows started filling with email info.

I will take your advise and shut off the service and use the mercury program while making changes, or just leave the service set to automatic but turn it off manually and use the mercury application that way if the server reboots due to updates the service will take over.

Thanks Graham

Hi Graham,

Is your Mercury running at a Windows Server OS? When we've got our new Windows Server 2016 Standard Edition some months ago, I've tried also different things. Finally the best result have been achieved with the following procedure: Install Mercury "as a service". This guarantees that Mercury will be started automatically on each server reboot, also without an administrator login. It's important that our mail server is running at any time because it is operating emails for about 20 users. Insofar Mercury has to run also when I'm on vacation or ill or not present on other reasons.

But how I can get the GUI? First time I've tried to manually quit the Mercury service followed by a manual restart of the Mercury service by using Windows Service Administration. This caused that the GUI appears and I thought all is fine now. I'm also a visual type and would like to see what happens with Mercury during day-by-day work. I minimized Mercury so that the icon remains within the sys tray where I could reactivate the GUI everytime. Works fine for some days. But after a few days the icon disappeared from the sys tray and I was not able to reopen the GUI alltough the service was still running properly, means I have to quit and restart the service again to get the GUI back - no smart solution.

Finally I'm using another solution. After a server reboot and when I find time, I connect to the server by RDP (since the server is mainly maintained remotely), manually quit the service followed by a manual start of Mercury from the start menu. Then the GUI appears and keeps running all the time. The advantage is, that this started GUI is available from each RDP session, irrespective whether I connect directly from my office desktop or remotely from home.

Ok, it's a little bit circuitous but automatically starting of the service guarantees that Mercury is starting automatically after an unintended server reboot. And when I would like to see how Mercury is working (GUI), I quit the service and start Mercury manually. This Mercury session with GUI is then running until the next planned or unplanned reboot where the game starts again with the service.

At the moment I have to restart our server once a month after installing the latest MS updates. Insofar this is not such a big effort to quit the service and restart Mercury manually. But you could also keep it running as a service until you really need the GUI. You've got all opportunities.

But I don't wanna keep something secret. Once a time I forgot to quit the service before starting the Mercury application from start menu. This causes that two Mercury session are running in "rivalry mode" which causes to many oddities. I needed different days with permanent user claims until I found out what happend. But now I'm trained [:D]

Cheers

Joerg

Hi Joerg

Thanks for the reply, mine is on a 2008 r2 server and needs to be running at all times.  I have it set up so that I have a local user on the server that is automatically logged in using a registry edit and mercury loader is in that users start up folder.  I have always managed that machine using VNC so I can have the user logged in at all times.  If the machine reboots for updates then the user is logged back in and mercury starts up again.

 The problem is recently they made me set a domain wide group policy to put a legal warning on when people log in and that messes up the automatic login.  I have found that if I stop the service and then use mercury loader I can manage he GUI and see the mail come in.  The service is stopped but still set to automatic so if the server reboots due to an update then the service will start up automatically and the mail will continue to flow.

If you are running Mercury as a service on Win7 (and I expect Win10) you can use the Interactive Services Detection service (UIODetect.exe) to get to the Mercury GUI, alter parameters and see the console windows.  There are some small limitations but it works well enough for me.

I suspect that the recent Server versions of Windows don't have that option.

As Rolf says, having the v5 separation of the GUI and the processing will be a very useful upgrade.

[quote user="GrahamW"]I have it set up so that I have a local user on the server that is automatically logged in using a registry edit and mercury loader is in that users start up folder.  I have always managed that machine using VNC so I can have the user logged in at all times. If the machine reboots for updates then the user is logged back in and mercury starts up again.[/quote] Due to security reasons I don't like automatic logons, especially at a server. The server is our Domain Controller, File server and E-mail server. Anybody could switch-on the monitor and would be already logged-in on the server.

When starting Mercury as a service, no user has to be logged-in. And when quitting the service and restarting Mercury application with GUI via RDP manually, a user log-in keeps necessary for each subsequent log-in into a running RDP session. Insofar the server keeps protected against unauthorised access.

Cheers

Joerg

Re: automatically logging in: You can use Group Policy to force a screensaver to kick in after xx minutes. It locks the server/client.