Exchange 2013 migration options are opening soon and ORF 5.1 with support for the next-generation Exchange platform will arrive just in time to fill in your need for spam protection.

In our three-part series, we talk about the changes the new Exchange version brings to ORF.

The next ORF version will support deployment on any of the Exchange 2013 roles, but not all deployment scenarios are made equal. In this article, we outline five different deployment scenarios and check their benefits and drawbacks.

Scenario #1: Exchange 2010 SP3 Edge Transport + Exchange 2013

Exchange 2010 SP3 Edge Transport in the DMZ + ORF => your Exchange 2013 Mailbox Server.

This a great setup for both Exchange and ORF, with a few minor trade-offs. If your existing Exchange 2010 setup features Edge Transport, this is the way to go.

• Pros: ORF performs best and requires the least maintenance when deployed on the network perimeter (that is, on Edge Transport).
• Pros: All previous functionality of ORF is available.
• Pros: You do not even need ORF 5.1 for this – ORF 5.0 and even 4.4 will install and work fine.
• Pros: Exchange 2010 Edge Transport is designed for DMZ use and a compromised Edge Transport server does not automatically allow an attacker access to your company network. Without Edge Transport, you would have to expose your Exchange 2013 Client Access Server (CAS) to the internet. CAS must be part of your network, so just by having Edge Transport you mitigated a security risk.
• Cons: 2010 Edge Transport must be linked with your 2013 Mailbox Server, which bypasses your Client Access Server.
• Cons: The Recipient Validation feature of ORF is not available under Edge Transport. This affects the DHA Protection feature as well, because it cannot receive data from the Recipient Validation feature.

Scenario #2: Exchange 2013 CAS + Mailbox Server (mixed)

Both roles of Exchange 2013 installed on the same server + ORF.

• Pros: No additional maintenance and configuration (if CAS is exposed directly to the Internet — otherwise, you should set up and maintain the Intermediate Host List).
• Pros: All previous functionality of ORF is available.
• Cons: Exchange 2013 CAS (a domain member server) must be exposed to the Internet, which may be a security concern ranging from “Oh, it’s OK” to “No. No. Over my dead body. No.”, depending on which school of IT security you subscribe to.

Scenario #3: Exchange 2013 Client Access Server

Separate Exchange 2013 Client Access Server + ORF => separate Mailbox Server.

• Pros: None that we know of, but it works.
• Cons: Only Before Arrival filtering is available and outbound email monitoring (for collecting data for Auto Sender Whitelist) is not supported.
• Cons: For the complete range of ORF features to be available, ORF must be deployed on the Mailbox Server as well. Configuration Synchronization must be set up between the Mailbox Server, the CAS or other CAS instances in the CAS array.
• Cons: CAS security concerns (see previous scenarios).
• Cons: The Replay Directory is not available. SMTP fallback must be configured (see previous article).

Scenario #4: Exchange 2013 Mailbox Server

Separate Exchange 2013 Client Access Server => separate Mailbox Server + ORF.

• Pros: None that we know of, but it works.
• Cons: Only On Arrival filtering and outbound email monitoring (for collecting data for the Auto Sender Whitelist) are available.
• Cons: CAS security concerns (see previous scenarios).
• Cons: Your CAS server IPs must be added to the Intermediate Host List of ORF and need to be maintained.
• Cons: If you need Before Arrival filtering, ORF must be deployed on the CAS server as well. Configuration Synchronization must be set up between the Mailbox Server and the CAS.

Scenario #5: IIS SMTP front-end with Exchange 2013

Any Windows Server edition with the IIS 5 or 6 SMTP Service feature installed, Exchange 2013 CAS configured as smart host + ORF => Exchange 2013 Client Access Server.

• Pros: You do not even need ORF 5.1 for this – any previous ORF version will do, as long as it supports the operating system.
• Pros: ORF performs best and requires the least maintenance when deployed on the network perimeter (that is, on the IIS front-end).
• Pros: All previous functionality of ORF is available.
• Pros: Can be safe for DMZ use.
• Cons: The IIS SMTP 5/6 Service is a legacy technology.
• Cons: CAS should be configured to relay outbound emails via the front-end server for the Auto Sender Whitelist to work.

To sum things up, ORF 5.1 will work the best on the network perimeter. Your network perimeter is ideally an Exchange 2010 SP3 Edge Transport server or an IIS SMTP front-end, but if you accept considerably more work, you can get ORF to work on any of the Exchange 2013 roles.

A friendly reminder for distributed setups: ORF Fusion licensing enables deployment on an unlimited number of servers without any extra fees and charges, as long as all servers belong to your organization or its subsidiaries. If you decide you need a CAS array and a range of mailbox servers, Fusion has your back.