You can run the Maitre’D Back-Office Server as a service on Windows 2000 Server or Windows Server 2003 only.
The first step is to install the Maitre’D software the usual way, including the Service Pack. This is required to be sure that the system is correctly installed and running. In the case of a system that is already installed, only the latest service pack needs to be added.
The second step is to select this function to stop the Server application.
Once this is done, open an explorer window and navigate to the folder where the back-office applications are installed.
Locate the BoSrv.exe application.
Rename the BoSrv.exe to something else such as BoSrvOriginal.exe.
In the same folder, locate the BoSrvProxy.exe application.
Rename it as BoSrv.exe.
Execute this first command line: "C:\Posera\MaitreD\Prg\MdService -u".
Execute this first command line: "C:\Posera\MaitreD\Prg\MdService -i".
In Windows's Services, find the entry for MdService and double click on it.
Set to automatic if it is not already set to this value.
Select the "This Account" radio button and enter the user name and password of the computer’s administrator. This is required for the service to run without interruption when users Login and off.
Restart the Service
Click to start the service.
Verify that both boService and MDService.exe are running.
Select this function to start the BoSrv.exe application that we have replaced earlier.
This application is the communication point between all the back-office modules and the server running as a service and is also implementing the user interface for the service. At this point workstations can be brought up and running.
In order to run the server application as a service, some functionality had to be put aside. Here’s a list of the issues that are different than the regular server.
The progress dialog cannot be updated as often since the process is done by the service and the progress bar is driven by the proxy module. Trying to update the progress bar as often as it used to would slow down the process as too much communication between the service and the proxy would be required.
These modules are started, if needed, but run in the service context and, therefore, cannot be displayed on the user screen. This issue will be resolved sometime in the future, as the customers who will be using the service do not require them for now.
Critical errors generated by the service are logged in our error journal and on every back-office modules main page but cannot be displayed on screen since they would be displayed in the service context. We currently have no way to display those on the user screen.
In the case of a critical error, since nothing can be displayed on the user screen, we have no choice but to stop the service, who would not respond to the workstations anyway. Doing so will force someone to Login to find out why the service is stopped by verifying the error journal and the message that is displayed on every back-office module main page.
When the end of day is started from the workstation or automatically or a reconstruction occurs, there will not be any progress dialog displayed as we currently have no way to do this properly. A message in the back-office modules main page will tell the logged on user what is going on.
Since restoring a Main Server is an exceptional procedure and requires user interaction, it is not possible to do this using the service. The Main Server must be re-installed using the regular back-office server, following the normal procedure. Once this is completed and everything is back to normal, then the user will have to repeat the setup to run the server as a service.
If using the beod.bat and eod.bat batch files that are called at end of day, you must be sure that no application can be called that will require user intervention. These batches will be run in the service context and nothing will be displayed on the user screen. If anything called in those batches prompt the user for intervention, the service will lock since there is no way the user can intervene with the service context.
The MDService .ini file must be configured correctly before installing the service. A description of how to setup the file is present in the file provided with the Maitre’D suite but some fields required for the service to run properly could be easily forgotten. Here is a description of each entry required for the BoService module. An explanation will follow the required content.
Define the setting section in the ini file.
Name of the application as it will appear in the Service module of Windows.
This is the number of process started by the MdService module. This value can be higher if the MDService module is required to start other application as services.
If the service fails, it will be restarted after the number of minutes specified here, provided that you set the failure option to "restart service" in the recovery tab of the service.
Define the first process section in the ini file.
This is the actual command line to start the BoService module. You have to replace the path shown here by the actual path were the application and data folder are located on your hard drive.
This is the path of the Maitre’D data folder on your hard drive.
This entry should be set to No as no user interface should be displayed by the service. The actual setting of this entry will be overridden by the Login As option described in section 5.
This should be set to Yes in order to restart the service in case of failure but it is overridden by the setting described in section 5.
For example, for Corporate Communication, you could add these lines above the PauseEnd line:
This last line is the time in millisecond (here 15 seconds) to wait, once a stop service command is issued, for the service to actually stop. If the service has not stopped after this time, Windows will terminate the service, no matter its actual state. If the value here is too small, the service may be terminated too fast and may trigger unnecessary reconstructions. If it is too long, it will take longer to terminate a locked process. The proposed value of 15 seconds will be too short if the service is processing end of day or reconstruction but should be adequate for normal operations.
