Introduction
This guide helps with setting up and operating ORF on multiple servers within your network. The intended audience of this document are system administrators.
Table of Contents
Introduction
Organizations with multiple email servers face the challenge of unified management and operation of servers. ORF supports for this usage scenario by enabling easy sharing of ORF settings and data between servers.
Example scenarios when this guide can help:
- Multiple perimeter email servers (e.g. primary MX and secondary MXs)
- Multi-site installations (e.g. subsidiary email servers with central management)
- Load-balanced servers
- Separate Microsoft® Exchange role installations (e.g. separate Exchange 2013 Client Access Server and Mailbox server)
About Configuration Synchronization
Configuration sharing in ORF is provided by the Configuration Synchronization feature. This works in a Subscriber-Publisher model. A Publisher is an ORF server that you appoint as a central configuration repository. Subscriber servers retrieve their settings from the Publisher. A single Publisher can serve one or more Subscribers.
Subscribers check the Publisher periodically (every minute) for configuration changes and automatically download and apply any changes.
Publishers and Subscribers rarely have exactly identical setup and role in the network, so Subscribers can override settings from the Publisher to manage the differences. ORF calls such overriding "localization" and it is available with two scopes:
- Feature Localization: Allows overriding settings for an entire feature at once, e.g. the Intermediate Host List or the Sender Blacklist. The resolution of the localization equals a settings page in the Administration Tool.
- Path Localization: Allows overriding the file system paths configured in ORF. This is less intrusive than Feature Localization, but also rarely covers all differences.
About External Databases
A handful of features in ORF rely on data that has to be available in the entire organization. These features are:
- Auto Sender Whitelist Test
- Greylisting Test
- Directory Harvest Attack (DHA) Protection Test
- Honeypot Tests
All of the above features can share their data using an external data repository, called an "External Database" in ORF. This is a SQL database, most commonly some version of Microsoft® SQL Server® (including the free Express editions).
Planning
Determining the synchronization scope
Configuration publishers and subscribers often differ in various details, like file system paths and server network location. During this stage of planning, you need to determine what are these differences exactly and how they affect ORF settings. When setting up synchronization, you can configure the subscriber to "localize" the affected settings.
Planning for file system differences
You can easily override any path settings from the publisher using the Path Localizations of ORF. For instance, if you log to C:\Logs\ORF
on the publisher, but you prefer to keep logs at D:\Email\Logs\ORF
on the subscriber, Path Localizations will enable you to do this without
overriding the rest of the log feature settings.
Find the list of paths that can be localized below.
Path Setting | Location in the Administration Tool |
---|---|
Path to the ORF Text Logs | System / Log > Configure: ORF Text Log > Settings tab |
Path to the ORF PowerLogs | System / Log > Configure: ORF PowerLogs |
Path to the Statistics Storage | System / Statistics Settings |
Path to the DNS Cache | System / DNS > DNS Settings > Caching |
Exchange 2019/2016/2013/2010/2007 Replay Directory | System / Microsoft® Exchange |
Auto Sender Whitelist Private Local Database path | Whitelists / Auto Sender Whitelist > Database > Configure |
Greylisting Private Local Database path | Blacklists / Greylisting > Database > Configure |
DHA Protection Test Private Local Database path | Blacklists / DHA Protection Test > Database > Configure |
Honeypot Test Private Local Database path | Blacklists / Honeypot test > Database > Configure |
Attachment Quarantine folder path | Blacklists / Attachment Filtering > Settings |
In this step, compile a list of file system path that are different on the publisher and subscriber. If you are converting an existing ORF server into a subscriber, ORF can import your current path settings, so you can skip this step.
Planning for more complex differences
Unless the publisher and the subscriber have identical role in your network, you will probably need to override certain parts of the publisher settings. Subscribers can achieve this by Feature Localizations.
A "feature" is defined roughly as one page in the ORF Administration Tool.
In this step, compile a list of features that are different on the publisher and subscriber. Please consult the list below for the available features.
List of localizable features
- System / DNS
- System / Log
- System / Microsoft® Exchange
- System / Statistics Settings
- Filtering / Actions
- Filtering / Intermediate Hosts
- Filtering / Tests
- Whitelists / Authentication Whitelist
- Whitelists / Auto Sender Whitelist
- Whitelists / DNS Whitelist
- Whitelists / IP Whitelist
- Whitelists / Keyword Whitelist
- Whitelists / Recipient Whitelist
- Whitelists / Sender Whitelist
- Blacklists / Attachment Filtering
- Blacklists / Charset Blacklist
- Blacklists / DHA Protection Test
- Blacklists / DKIM Test
- Blacklists / DMARC Test
- Blacklists / DNS Blacklists
- Blacklists / External Agents
- Blacklists / Greylisting
- Blacklists / HELO Blacklist
- Blacklists / Honeypot Test
- Blacklists / IP Blacklist
- Blacklists / Keyword Blacklist
- Blacklists / Recipient Blacklist
- Blacklists / Recipient Validation
- Blacklists / Reverse DNS Test
- Blacklists / Sender Blacklist
- Blacklists / SPF Test
- Blacklists / SURBL Test
Localization tips
- Pay attention to the network location differences. For instance, if the publisher is a network perimeter server and the subscriber is not on the perimeter, you will probably need a different choice of test assignments (Filtering / Tests), a different Intermediate Host List (Filtering / Intermediate Host List) and maybe different actions (Filtering / Actions). These settings are usually dependent on the location ORF takes within your network.
- External Agent settings are synchronized, but the agents themselves are not. Make sure to have the same agents installed at the same location on both the publisher and the subscriber (or localize this feature).
- On Exchange 2019, Exchange 2016, Exchange 2013 Edge and Mailbox role servers, Exchange 2010 and 2007 servers, ORF needs to know the path to the Exchange Replay Directory. This is specific to your Exchange installation, so you usually need to localize either the path or the feature (System / Microsoft® Exchange). We recommend localizing the feature, because this will allow you to update the path anytime from your current Exchange settings by clicking the Detect button. Note that Exchange 2013 Client Access servers do not have Replay directories, so a fallback SMTP server has to be configured. For more information, see the related Help topic.
- For IIS SMTP Service, Server Bindings (System / Server Bindings) are not included in the synchronization. Make sure to set up the subscriber with the proper server bindings.
- Path Localizations take precedence over Feature Localizations. For instance, if you localize the System / Log feature and localize the ORF Text Log path as well, ORF will apply your feature localization first, then localize the ORF Text Log path.
- The settings under System / Configuration Subscription and System / Remote Access are not included in the synchronization.
Once the list of feature differences is compiled, move to the next point.
Setting up External Databases
Sharing data between the configuration publisher and subscriber is essential if you are using any of the features below:
- Auto Sender Whitelist
- Greylisting
- DHA Protection Test
- Honeypot Test
This sharing can be achieved by using External Databases in ORF. In case you are using any of the above ORF features, set up these databases as part of the planning. A broad range of database solutions are supported by ORF, please check the Database Guides page for the complete list and database setup instructions.
Selecting the DNS resolver
ORF relies on DNS extensively and offers two methods for resolving DNS data: using the default built-in DNS resolver and using external DNS servers.
When ORF is ran on multiple servers concurrently on your network, you can benefit from using a shared DNS cache, as provided by an appointed external DNS server. Such shared DNS cache may result in faster name resolution and less DNS traffic directed to DNSBLs, SURBLs and other DNS resources.
In such setups, we recommend using a single external DNS server as a resolver, instead of the default built-in resolver. Be sure to consult the Deployment Guide on the requirements for external DNS servers.
Network security setup
Communication between the subscriber and the publisher takes place entirely on the designated ORF remote access port. Only the subscriber makes connection attempts, the publisher never turns to the subscriber. Make sure to have the necessary port open on your network security equipment.
ORF installations may require access to additional network services. Find an overview below.
Port | Description |
---|---|
TCP/6242 | Default port for configuration synchronization and remote ORF management. |
UDP/53 and TCP/53 | DNS traffic. When using the default built-in resolver, these ports have to be opened to any internet hosts. When using external DNS servers, DNS ports can be restricted to the specific servers. |
TCP/80 and TCP/443 | HTTP communication between ORF management tools and our servers (HTTP proxies are supported). |
TCP/389 or TCP/3268 | Default ports for Active Directory LDAP or GC communication if the Recipient Validation Test is enabled in ORF with the Active Directory source. Optional (if the above test is disabled). |
(Varies) | Communication with External Databases (e.g. Microsoft® SQL Server) if ORF is configured to use these. Please consult the database manual for port information. |
Setup
Follow the steps below to set up Configuration Synchronization between a publisher and a subscriber. The steps below assume you have already finished setting up External Databases.
Setting up the Publisher
1 | On the publisher, open the System / Remote Access page in the ORF Administration Tool. |
2 | Set the "Enable Remote Access" checkbox. |
3 | Click "Local Bindings" and select the network interfaces and ports that will accept connections from the subscriber server. |
4 |
Click "Allowed IPs" and add the subscriber IP address(es) to allow them connecting to your publisher server. Make sure that Configuration Synchronization is among the allowed services for the subscriber. You may want to grant Remote Administration right as well (here is why). |
5 | Click "Set Password" and set the password required to access the publisher remotely. |
6 | Save the configuration using File | Save Configuration or by pressing |
Setting up the Subscriber
1 | On the subscriber, open the System / Configuration Subscription page in the ORF Administration Tool. |
2 | Click the Subscribe button. |
3 |
Click the Publisher Access button and set the publisher server name/port. Click the Test Connection button to make sure the subscriber can access the publisher. If necessary, adjust the proxy settings from this dialog or using the Proxy Settings button on the previous page. |
4 |
If you have identified any paths subject to localization during the planning, click the Local Paths button and set the paths. When converting an existing ORF installation into a subscriber, you can also click the Import button in this dialog to retrieve the paths from your current ORF settings. |
5 |
Click Feature Localizations and select the features to be overridden on the subscriber (note that a few features are overridden by default). |
6 | Save the configuration using File | Save Configuration or by pressing |
7 | Launch the ORF Log Viewer and check if the synchronization has completed successfully. |
Congratulations, you have now set up ORF successfully for multi-server use.
Notes
Merging Logs
While logging to network drives is not supported (the ORF Service user account does not have network access rights), you can get a unified view of your ORF logs by copying the log files manually to a network location and configuring the ORF Log Viewer to load logs from that location.
To avoid file name conflicts, we recommend changing the log file name format from the default orf-{yyyy}-{mm}-{dd}.log format to orf-server1-{yyyy}-{mm}-{dd}.log format (System / Log > Configure: ORF Text Log > Settings tab). Enable the Server column in the Log Viewer to show the server name with events (View | Choose Columns menu).
Remote Control item forwarding
Remote Control is an ORF feature that enables sending IP and email addresses directly from the ORF Log Viewer to ORF address lists, such as the IP Blacklist or the Sender Whitelist. When working with subscriber servers, the target list might be controlled by the publisher settings, so your submission would be ignored. To prevent this, the Log Viewer can ask the subscriber to forward the submission to the publisher. This forwarding comes with the following restrictions:
- As Remote Control is an administrative feature, the subscriber must have Remote Administration right on the publisher.
- The submission might take up to one minute to get distributed back to the subscriber.
Fault tolerance and Configuration Synchronization
- In case the publisher becomes unavailable, subscribers will keep working with the last known configuration and will attempt to contact the publisher with the regular 1-minute schedule.
- If settings of critical important cannot be applied to the subscriber after localization, the ORF Service may shut down to prevent email loss. This will not interrupt the email flow, but ORF email filtering will not be available until the problem is fixed.