SMTP Relay in Exchange 2010

When an Exchange 2010 Hub Transport Server is installed two Receive Connectors are automatically created:

  • Client Receive Connector – used by end users with an SMTP client that want to send out messages. This is authenticated SMTP and the connector is using port 587 for this;
  • Default Receive Connector – used to receive SMTP messages on port 25 from other Exchange Hub Transport Servers or the Edge Transport Server.

I always recommend not to change the default receive connectors with the exception of setting Anonymous Users on the Permission Groups to allow other SMTP hosts to submit messages as well.

image

Relaying SMTP messaging

For relaying SMTP messaging I normally recommend to use an additional Receive Connector with an additional IP address on the server. This IP address can have an easy to remember FQDN like relay.contoso.com

To create the new Receive Connector use the following command in the Exchange Management Shell:

New-ReceiveConnector –Name “Relay Connector (EXCH01)” –usage Custom –Bindings 10.19.67.33:25 –FQDN relay.contoso.com –RemoteIPRanges 10.19.67.201 –Server ServerName –PermissionGroups AnonymousUsers

This command will create a new Receive Connector, bind it to the IP address 10.19.67.33 (this should be on the network card of the server of course) and allow the IP address 10.19.67.201 to submit SMTP messages anonymously. However, only messages for recipients whose SMTP domain is an an Accepted Domain in the Exchange organization are accepted at this point. This is a default setting so the permissions on the Receive Connector have to be changed.

The ms-Ech-SMTP-Accept-Any-Recipient permission is to make sure that all submitted recipients are accepted by the Hub Transport Server. This permissions can be added with the Add-ADPermission cmdlet:

Get-ReceiveConnector –Identity “Relay Connector (EXCH01)” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

If you have multiple Receive Connectors and want to check whether or not anonymous relay is enabled on any connector you can use the following command:

Get-ReceiveConnector | Get-ADPermission | where {$_.extendedrights –like “*Any-Recipient”}

Upgrade Windows Standard to Enterprise

Note. When Exchange is installed on this particular server you can use this procedure only in a lab environment. To change an Exchange server is not a supported scenario!

When installing an Exchange 2010 environment in my lab I discovered that the Fail Over Clustering bits were not available on my planned DAG members. It turned out that I installed Windows 2008 R2 Standard Edition instead of Enterprise Edition. Even worse, Exchange Server 2010 SP2 was already installed as well.

On TechNet there’s an article that explains how to Upgrade Windows 2008 R2 without using the installation media (i.e. reinstall Windows 2008 R2 from scratch) using DISM, the Deployment Image Servicing and Management Tool.

Continue reading Upgrade Windows Standard to Enterprise

Building Hosted Exchange – Part IV

In my earlier blog posts Building Hosted Exchange Part I (overview), Building Hosted Exchange Part II (Active Directory) and Building Hosted Exchange Part III (Exchange and ABP’s) we’ve created a simple Exchange 2010 organization that’s capable of hosting multiple organizations, separated from each other and each having their own Address Books. But as outlined in the Microsoft guidance document there’s more involved, especially when it comes to global settings that are identical for all users (in all organizations) or global settings that can reveal unwanted information.

Global Exchange configuration

When building a hosted Exchange 2010 SP2 environment a number of Exchange configuration settings have to be taken into account.

There are certain global settings that are valid for the entire organization and are therefore set on an organization level and not on a tenant level. Example of these configurations (this is not a complete list!) are Exchange ActiveSync settings, Exchange Web Services, OWA policies, Throttling policies, anti-virus and anti-spam checking, postmaster settings and the autodiscover settings.

Continue reading Building Hosted Exchange – Part IV

Autodiscover in Exchange part III

Autodiscover is a standard feature in Exchange Server 2007 and higher that’s being used by Outlook 2007 and higher. Looking at the number of questions I get regarding autodiscover I’ve written a number of blogposts that will look into Autodiscover in depth:

In Part I I’ve explained how domain joined clients work with autodiscover information that’s stored in Active Directory. In Part II I’ve explained how the same (domain joined) client behaves on an external network like the Internet.

Both posts work with the self-signed certificate, but it’s much better (and recommended!) to use a 3rd party certificate or a certificate of an internal PKI environment. Continue reading Autodiscover in Exchange part III

Exchange 2010 and Autodiscover Part II

Autodiscover is a standard feature in Exchange Server 2007 and higher that’s being used by Outlook 2007 and higher. Looking at the number of questions I get regarding autodiscover I’ve written a number of blogposts that will look into Autodiscover in depth:

In Part I I’ve explained how domain joined clients work with autodiscover information that’s stored in Active Directory. This is easy for domain joined clients that have access to the internal network, but it’s a bit different for domain clients that have no access (i.e. working from home or a hotel) and for non-domain joined clients. The latter don’t have access to Active Directory and there cannot query AD for the Service Connection Point of course.

In this post I’ll discuss the same client as in Part I, but this time when there’s no access to the internal network (and thus no access to Active Directory). Continue reading Exchange 2010 and Autodiscover Part II

Microsoft UC Specialist