The next cool feature of ORF 5 we are about to show falls into the category where the new version offers the most: overall experience improvements.

The Log Event View already exists in previous versions – this is the dialog you get when you double-click an event in the Log Viewer. In ORF 5, it underwent an major renovation:

I guess it is a fine example of how a picture is worth a thousand words. Now let’s see what’s new in there besides the aesthetic improvements.

1) Grouping and Highlighting: Every logged event has 16 fields. Each one carries useful information, but you rarely need all of them, so we grouped the fields and hid many lesser used fields to reduce the information load. The Email Subject and the Event Message columns are now highlighted.

2) Event Summary: Each event gets a one-sentence automatically generated summary. This will primarily benefit those new to ORF, but could provide everyone a quick overview of the event and its significance.

3) Remote Control Integration: Now you can send IP and email addresses to the ORF configuration from this dialog.

4) Integrated Log Knowledge Base: This is the coolest new stuff in here. No idea what a log message means? What are its implications? What action to take? Click the Explain button to look the event up online and get a knowledge base article specifically crafted for the logged event.

We expect this to become a major self-help option, because in a huge number of technical support cases the administrator finds the log message, but not sure what to do with it. Say, you run into a DNS timeout or SERVFAIL warning event. Many questions arise: how do I fix this? Does it has to be fixed at all? Does this mean the Vogon fleet is about to blow up Earth? Or is it the Klingons? Goa’ulds? Is the l33t Jeff Goldblum really our only hope? These are particularly complex questions that a short log message cannot volunteer to explain, but using this feature we will deliver the latest information right there where you need it.

Stay with us, next week we will look into another new feature.

Configuration Synchronization is an enterprise service in ORF 5 which helps organizations to reduce the administrative overhead of maintaining multiple ORF servers. This feature allows appointing a central settings repository server (“Publisher”) and takes care of distributing the setting changes to the rest of the servers (“Subscribers”).

The audience of this feature are organizations who maintain multiple ORF installations, e.g.

• Companies with two or more ORF servers on their network (e.g. one on the primary MX, another on the secondary MX)
• IT shops who manage the ORF installations of their clients centrally.

Back to the technical details, subscriber servers periodically check the publisher server for configuration changes. When a change is encountered, subscribers download the publisher configuration and reinitialize with the latest settings.

The entire process utilizes the same communication foundation as introduced in our previous Remote Access article. Thanks to this, administrators can grant Config Sync-only access to the subscriber clients.

In addition to the full configuration synchronization, ORF 5 also allows overriding certain settings from the publisher. This is called “localization” in ORF – when you “localize” something, the local settings of the subscriber will take effect, overriding the publisher settings.

ORF 5 has two localization scopes: Path Localization and Feature Localization.

Path Localizations are for overriding file system path settings, e.g. the path to the log files. This comes handy if the publisher and the subscriber servers are almost identical, having same role and location within the network, but the file system paths are different.

Feature Localizations allow overriding entire features, like the Intermediate Host List or the Sender Whitelist (a “feature” is something that has its own page in the ORF Administration Tool). This allows a versatile range of localizations, e.g. a different Intermediate Host List for a different location within the network.

As for fault tolerance questions, subscribers can operate with the last known configuration indefinitely if the publisher is not available for any reason (at least one successful initial sync is required, though).

Screenshots (some of the UI is subject to change):

Questions? Comments? Let us know.

The first new feature we are detailing in this article series is the Remote Administration in ORF 5.

This feature is pretty much what it sounds: in ORF 5, you can access and manage remote ORF installations with just one click – no more RDP, VNC or walking up to the server room. Sounds good?

There is also more to Remote Administration than just shaving off a couple of minutes here and there: the Remote Access communication foundation that enables this feature also opens up a way for remote ORF components to talk to each other. For instance, ORF 5’s Configuration Synchronization relies on this very same foundation and certain future developments are enabled by this.

A few basic facts:

• Remote Access can be enabled using the Administration Tool (disabled by default).
• All ORF management tools are supported (Administration Tool, Log Viewer and the Reporting Tool).
• Default connections can be configured (useful if you always work with the same server). Shortcuts can be created per management tool for multiple-server scenarios.
• ORF 5 Setup comes in two versions: a full setup and a freely distributable Management Tools-only setup.

Security and network facts (nobody likes opening ports in the firewall, right?):

• Accessing the service requires an administrator-configured password.
• The default communication port is TCP/6242 (can be changed per interface).
• Communication is HTTP-based – a slightly modified version of the SOAP protocol, typically used for Web Services.
• The password is never stored directly on the computer (only hash on the server, salted hash on the clients).
• Secured challenge-response authentication. No plain-text password is sent over the network. VPN can be employed for additional security.
• Service can be restricted to specific local interfaces/IPs.
• Access can be granted by client IP addresses.
• HTTP proxies are supported by the communication protocol.

And now a few screenshots.

What do you think? Will you use this feature? Got any questions? Feel free to comment.