KB - Deploying ORF in a Microsoft® Exchange 2013 Environment

Deploying ORF in a Microsoft® Exchange 2013 Environment

Article was last updated on July 14, 2023. View products that this article applies to.

Introduction

Microsoft introduced several changes in Exchange 2013 which affect ORF deployment. This article aims to provide information and help in different deployment scenarios. The article focuses on Exchange 2013, general deployment instructions are described in the Deployment Guide.

This article provides instructions for ORF 5.3 and later versions: if you have an earlier Exchange 2013-compatible version (ORF 5.2 or 5.1), please consult this KB article instead.

Exchange 2013 Roles

One of the most notable changes in Exchange 2013 is that the five roles of previous Exchange server versions (Edge Transport, Hub Transport, Mailbox, Client Access, Unified Messaging) have been reduced to two (Mailbox and Client Access server roles) in the initial release. The third, Edge Transport server role was introduced in Service Pack 1.

Exchange 2013 SP1 Notes

Please be aware that compatibility with Exchange 2013 Service Pack 1 requires fixing a known issue with Service Pack 1 before ORF could be deployed.

Deployment Scenarios

Information regarding the various possible Exchange 2013 setups is available below:

Scenario A:
ORF + Exchange 2013 Edge Transport > Exchange 2013 Mailbox server

Notes

The recommended setup: ORF is installed to the perimeter Edge Transport server in the DMZ, filtering emails before they are relayed to the Mailbox server. As the 2013 Edge Transport server must be linked directly with your 2013 Mailbox server, the Client Access server will be bypassed.

Limitations

Please note that Active Directory-based Recipient Validation is not available on Edge servers, since ORF cannot query the AD from the DMZ. This is usually a non-issue since Exchange has its own recipient validation feature, but the DHA Protection Test of ORF (relying on Recipient Validation) will not work either, unfortunately. Save for these, ORF can filter emails at both filtering points and all other features are available.

Extra Steps

No extra steps required during deployment, simply follow the steps described in our guide.

Scenario B:
ORF + Exchange 2013 Server with both Mailbox and Client Access roles

Notes

ORF receives emails directly with both roles available. Please note that the Client Access server is a domain member, so exposing it directly to the Internet could be a security concern.

Limitations

There are no limitations to speak of: ORF can filter emails at both filtering points and all other features are available.

Extra Steps

If there are any additional perimeter servers, those must be added as Intermediate Hosts. Otherwise, no extra steps required during deployment, simply follow the steps described in our guide.

Scenario C:
ORF + Exchange 2013 Client Access server > Mailbox server

Notes

Please note that the Client Access server is a domain member, so exposing it directly to the Internet could be a security concern.

Limitations

On Client Access servers, only Before Arrival filtering will work. On Arrival filtering and outbound email monitoring (for collecting data for Auto Sender Whitelist) are not supported. Also, as Client Access servers do not queue any emails, the Replay Directory is no longer available under this role (see Extra Steps below).

Extra Steps

ORF relies on the Replay Directory feature in a number of situations, so as a workaround, an SMTP fallback must be configured manually. See the related Help topic for details.

In order to utilize all features of ORF, it is recommended to install ORF on the Mailbox role as well and to use the Configuration Subscription feature to keep the configurations in sync. A shared, external SQL database should be also set up, so both instances could work with the same data. For detailed instructions, please consult our Multi-Server Usage Guide.

If the CAS server subscribes to another publisher server, make sure to localize the settings of the SMTP fallback server (see above), otherwise the default (localhost) server will be used. See the related Help topic for details.

Scenario D:
Exchange 2013 Client Access server > ORF + Mailbox server

Notes

Please note that the Client Access server is a domain member, so exposing it directly to the Internet could be a security concern.

Limitations

On Mailbox servers, only On Arrival filtering and outbound email monitoring (for collecting data for Auto Sender Whitelist) will work, Before Arrival filtering is not supported.

Extra Steps

The IP address of the Client Access server must be added to the Intermediate Host List of the ORF instance running on the Mailbox server.

In order to utilize all features of ORF, it is recommended to install ORF on the CAS role as well and to use the Configuration Subscription feature to keep the configurations in sync. A shared, external SQL database should be also set up, so both instances could work with the same data. For detailed instructions, please consult our Multi-Server Usage Guide.

Scenario E:
ORF + IIS SMTP front-end > Exchange 2013 Client Access server (smart host)

Notes

The IIS SMTP 5/6 Service is a legacy technology, poorly supported by Microsoft® nowadays.

Limitations

There are no limitations to speak of: ORF can filter emails at both filtering points and all other features are available.

Extra Steps

The Client Access server should be configured to relay outbound emails via the front-end server for the Auto Sender Whitelist to work. Apart from that, no extra steps required during deployment, simply follow the steps described in our guide.

Applies To

The article above applies to the following products and versions:

  • ORF 6.8.3
  • ORF 6.8.2
  • ORF 6.8.1
  • ORF 6.8
  • ORF 6.7
  • ORF 6.6.1
  • ORF 6.6
  • ORF 6.5
  • ORF 6.4
  • ORF 6.3
  • ORF 6.2.1
  • ORF 6.2
  • ORF 6.1.1
  • ORF 6.1
  • ORF 6.0.1
  • ORF 6.0
  • ORF 5.5.1
  • ORF 5.5
  • ORF 5.4.1
  • ORF 5.4
  • ORF 5.3
hnp1 | hnp2