XWall supports queue based load balancing that is compatible with any SMTP server and unlike DNS round robin it gives you much more control how the messages should be balanced between the different XWall.

Install XWall on your primary and secondary MX. On the primary XWall enable

View->Advanced Configuration->Threads->Refuse inbound connections when max thread count is reached

Once the inbound queue of the primary XWall goes up, XWall gives the sender a 4xx error and closes the connection. The sender immediately connects to the secondary XWall and the message goes over the secondary XWall. This results in an active load balancing and the primary XWall will never gets overstressed.

XWall has the option to synchronize the White List database across a server farm.

One XWall will be defined as the master server and holds the main White List.

All other XWall are slave server and query the master server for the White List.

Note: Each XWall keeps a local White List and caches the result from the master.

You can configure the master and the slave at View->Advanced Configuration->White List

There is no need to synchronize the Greylisting data, assuming that load balancing is active and that Greylisting is enabled on all servers.

Here is an example how it works: Assume two XWall, with load balancing and Greylisting enabled.

Both XWall are idle and the first message arrives

sender connects to XWall1 and XWall1 sends back a 4xx because of Greylisting

sender connects to XWall2 and XWall2 sends back a 4xx because of Greylisting

At this point both XWall have the same information in the Greylisting database.

Assume 15 minutes later and XWall1 is busy

sender connects to XWall1 and XWall1 sends back a 4xx because XWall1 is busy

sender connects to XWall2 and XWall2 accepts the message

Assume the same server sends a new message and XWall1 is no longer busy

sender connects to XWall1 and XWall1 sends back a 4xx because of Greylisting

sender connects to XWall2 and XWall2 accepts the message because it knows the IP is ok

The message is never delayed more then necessary without that the Greylisting data is synchronized between the servers.

To run more than once instance of XWall as a service on a single machine you need to manually install XWall as follows:

Create a directory for each instance ( e.g. c:\xwall1 and c:\xwall2 )

Extract MBServer.exe and MBAdmin.exe from the zip file and copy the files into the directories

Create a file named mbserver.svc with one line in it, the name of the XWall service.

The name must not have a space in it and you may use something like XWall-Instance1

Install the service as usual, by typing

MBServer install

If you run more than one instance of XWall on a machine, then make sure that each instance uses it's own TEMP directory. Failing to do so will result that both XWall attempt to create the same temp files and only one XWall will win. The other XWall will run into a timeout decelerate.

Either change the TEMP environment variable for each XWall or tell XWall which directory it should use in View->Advanced Configuration->Advanced->Temp Directory

This sample assumes that you have two XWall, installed in c:\xwall1 and c:\xwall2

Create a directory of your choice ( e.g. c:\central ) and copy MBAdmin.exe and XWall. ini to c:\central

Open c:\central\XWall. ini with Notepad and remove registration number from the shared XWall. ini

Note: This is necessary or else both XWall run with the same registration number and this will cause a license violation and your XWall will stop working.

The line that looks like

and is usually near the end

Open c:\xwall1\XWall. ini and locate the registration number and remove all other lines except the registration number

Then add the line

Include=c:\central\XWall. ini

Repeat this with the second XWall

As a result XWall reads then the registration number from the local XWall. ini and all other setting from the shared XWall. ini and you can change all shared settings with MBAdmin in c:\central

Sharing the configuration between two XWall on different machines:

When you use the simple sharing method on different machines, you need to make sure you start the XWall service with an account that has the right to access the central XWall.ini. Also keep in mind that XWall will not be able to start in the case it can't access the central XWall.ini.

In the case of different machines the following additional steps are recommended:

Create a directory below the XWall directory ( e.g. c:\xwall1\shared )

Open c:\xwall1\XWall. ini and add the line

Include=c:\xwall1\shared\XWall. ini

Create a batch file that copies c:\central\XWall. ini to c:\xwall1\shared and c:\xwall2\shared

Call the batch file every time you changed something on the central configuration

The batch file will copy the shared XWall.ini to the machine and the running XWall will detect the change and restart itself. Even in the case your central XWall.ini get lost, the shared XWall will still work.

Note: MBAdmin will not write back any value to an XWall.ini with an include= line.

The reason is that MBAdmin does not know to which file the value should be written.