Now I have Mercury running again on our new Windows Server 2016 Standard. It was a "try and error" game, but finally it's working again with all of our Pmail user accounts.
Firstly I've installed Mercury 4.8 as a complete new installation, but in the same folder structure as on the old server. Then I have copied all of the important Mercury configuration files from the old server to the new server. Then I have copied the Pmail user mailboxes. But because I don't want to have these mailboxes as a subfolder within Mercury (like on the old server for many years), I put them into a separate new folder. Finally Pmail program files has been simply copied from the old server to the new server. At the end I've got a Mercury folder, a Pmail folder and a Mailboxes folder which is also containing the Queue folder.
Within the mercury.ini I have updated all path values. On first manual Mercury start I have further updated the Mercury-Pmail Interface which creates a new pmgate.sys within the Pmail folder. Finally I have deleted the old pmail.cfg. That caused that Pmail, on first start, asked for the location of user mailboxes. Here I could simply assign the new Mailboxes path to.
So far so good, but now the Windows Service problem was still remaining. Firstly I tried to create a new Windows Service by using the Windows SC.exe command. The service was created successfully but didn't start neither the mercury.exe nor the loader.exe. It seems the program files are not able to communicate with the Windows service system properly. Service removed again. Then I have tried to add a task planner job, which should be carried out automatically on reboot and without user logon. But also this didn't work. Mercury didn't start. Finally I have repeated the Mercury setup process. At the end the setup is asking whether a Windows service should be created. Don't know how the setup is creating a service, but it works. Of course with the well known problems that the GUI is invisible when connected to the server remotely.
Our workaround is to connect to the server via RDP because RDP is our main administration way. Then we stop the Mercury service and restart it manually. Then the GUI appears and keeps visible within all future RDP sessions.
So far my last experiences with the installation / taking-over of Mercury on our new Windows Server 2016.
edit: It should be kept in mind, that Mercury will be terminated in case the RDP session is being finished by User Log-off. In case the manually started Mercury should be kept alive, the RDP session is to be finished by closing it without Log-off. Or Mercury is to be finished and the Mercury Service (without GUI) has to be manually restarted. In that case the remote user can log-off.
<p>Now I have Mercury running again on our new Windows Server 2016 Standard. It was a "try and error" game, but finally it's working again with all of our Pmail user accounts.</p><p>Firstly I've installed Mercury 4.8 as a complete new installation, but in the same folder structure as on the old server. Then I have copied all of the important Mercury configuration files from the old server to the new server. Then I have copied the Pmail user mailboxes. But because I don't want to have these mailboxes as a subfolder within Mercury (like on the old server for many years), I put them into a separate new folder. Finally Pmail program files has been simply copied from the old server to the new server. At the end I've got a Mercury folder, a Pmail folder and a Mailboxes folder which is also containing the Queue folder.</p><p>Within the mercury.ini I have updated all path values. On first manual Mercury start I have further updated the Mercury-Pmail Interface which creates a new pmgate.sys within the Pmail folder. Finally I have deleted the old pmail.cfg. That caused that Pmail, on first start, asked for the location of user mailboxes. Here I could simply assign the new Mailboxes path to.</p><p>So far so good, but now the Windows Service problem was still remaining. Firstly I tried to create a new Windows Service by using the Windows SC.exe command. The service was created successfully but didn't start neither the mercury.exe nor the loader.exe. It seems the program files are not able to communicate with the Windows service system properly. Service removed again. Then I have tried to add a task planner job, which should be carried out automatically on reboot and without user logon. But also this didn't work. Mercury didn't start. Finally I have repeated the Mercury setup process. At the end the setup is asking whether a Windows service should be created. Don't know how the setup is creating a service, but it works. Of course with the well known problems that the GUI is invisible when connected to the server remotely.
</p><p>Our workaround is to connect to the server via RDP because RDP is our main administration way. Then we stop the Mercury service and restart it manually. Then the GUI appears and keeps visible within all future RDP sessions.</p><p>So far my last experiences with the installation / taking-over of Mercury on our new Windows Server 2016.</p><p>edit: It should be kept in mind, that Mercury will be terminated in case the RDP session is being finished by User Log-off. In case the manually started Mercury should be kept alive, the RDP session is to be finished by closing it without Log-off. Or Mercury is to be finished and the Mercury Service (without GUI) has to be manually restarted. In that case the remote user can log-off.
</p>