For the first time in three and a half years, ORF Fusion licenses received a minor adjustment today (April 8, 2016) to reflect changes since Fusion pricing was introduced in 2012. The pricing change only affects ORF Fusion licenses, ORF Fusion for SBS prices will remain the same as before.
If you have questions about this change or our pricing and licensing in general, please contact our sales team, we are happy to answer your questions.
There is a good reason why the Recipient Validation feature of ORF is disabled on Edge Transport Servers: Exchange does a better job there. Unlike ORF, it does not require direct access to your Active Directory, so if your Edge server gets compromised, your AD data is still safe.
However, once you install CU1 on your Exchange 2016 Edge Transport Server, things will turn sour quickly. A client of us, Microsoft MVP Norbert Fehlauer from Systema Gesellschaft für angewandte Datentechnik mbH have discovered a major issue with Exchange recipient validation that results in bouncing all inbound emails. The issue is now documented in the Exchange 2016 Release Notes.
No hotfix is available for the issue at the moment. We recommend temporarily disabling Recipient Validation (see Release Notes above on how) and keeping an eye on this — as a major argument for having an Edge Transport Server is doing recipient validation on the network perimeter, we can probably expect a quick update to be released in the coming days.
Update March 29, 2016: No word on the hotfix from Microsoft (rumor has it they plan to address the issue in a subsequent Cumulative Update only), but Exchange MVP Maksim Barakin investigated the issue and came up with another workaround that temporarily fixes the issue by disabling the recipient validation cache of Exchange using the following Exchange shell command:
Get-TransportService | Set-TransportService -RecipientValidationCacheEnabled $false
Caching is normally enabled on Edge servers and disabling it may have performance implications, so we recommend keeping an eye your server for a while after the change.
Update June 24, 2016: Although the issue is not discussed in the release notes of Exchange 2016 CU2, the newest CU seems finally to fix this problem.
This is just in from our test labs: ORF 5.4 passed all Microsoft Exchange 2016 compatibility tests with flying colors and it is now officially compatible with the latest from Microsoft.
Transport Agent status on Exchange 2016
Architecture-wise, Exchange 2016 has reduced the number of roles further from Exchange 2013’s three roles (Edge Transport Server, Client Access Server, Mailbox Server) to just two roles, Edge Transport Server and Mailbox Server. Both roles are supported by ORF 5.4. In fact, from a technical perspective, the new Mailbox Server role is just a unified Client Access Server and Mailbox Server role, which makes Mailbox Server a prime installation site for ORF. However, when Edge Transport Server is available, we still recommend deploying ORF on that.
As ORF 5.4 pre-dates Exchange 2016 RTM, it still detects the new platform as Exchange 2013, but don’t be confused by that — every process and documentation we have for Exchange 2013 still applies to Exchange 2016. If you look behind the scenes, you will find that Exchange 2016 is arguably more like Exchange 2013 SP2, which is underlined by the fact that the Exchange internal version progressed from 15.0 to 15.1 with a minor version change only.
In the coming days we will update our documentation and materials to reflect the above. Meanwhile, feel free to head out and experiment with Exchange 2016 — we have your back! Just remember the following:
- Exchange 2016 is fully supported by ORF 5.4 (not by previous versions, though).
- Exchange 2016 Mailbox = Exchange 2013 Client Access Server + Mailbox Server
- ORF detects Exchange 2016 as Exchange 2013, but there’s no need to worry about that.
If you have any questions, leave a comment or contact our Customer Service.
We are excited to announce the latest 5.4 version of ORF. Some of the highlighted changes in this release:
- Built-in recursive DNS resolver
The new DNS resolver can obtain DNS data without the help of a dedicated DNS resolver server. This greatly simplifies the DNS setup in ORF and eliminates common DNS configuration problems that lead to a diminished spam filtering performance.
- Updated DNSBL definition set and recommendations
The new set is compiled based on comprehensive true positive, false positive and overlap analysis to maximize the spam catch rate without risking the loss of legitimate emails.
Download ORF 5.4 from the Client Portal after logging in and learn more about the new release in the Change Log.
The first preview of ORF 5.4 we talked about in our article series has finally arrived – try it today.