In part 9 of this mini-series, I’ll look at how to configure the Fully Qualified Domain Name (FQDN) of the Default Frontend receive connector in Exchange 2013.
Firstly a warning: Don’t modify the FQDN value on the default Receive connector Default that’s automatically created on Mailbox servers. If you have multiple Mailbox servers in your Exchange organization and you change the FQDN value on the Default Receive connector, internal mail flow between Mailbox servers fails.
In a single Mailbox server environment to change the Default Frontend receive connector FQDN follow the steps below.
Firstly using Telnet to connect to the Exchange server’s external FQDN we can see the following:
Exchange Admin Center
1. In the Exchange admin center (https://localhost/ecp) click mail flow on the left hand side, click receive connectors, and then click the Default Frontend servername, finally click edit.
2. If you click scoping and scroll to the bottom, and change the FQDN to match the external FQDN and click save you’ll receive the following Error Message:
If the AuthMechanism attribute on a Receive connector contains the value ExchangeServer, you must set the FQDN parameter on the Receive connector to one of the following values: the FQDN of the transport server “OX-Exch1.ad.oxfordsbsguy.com”, the NetBIOS name of the transport server “OX-EXCH1”, or $null.
Exchange Management Shell
To perform the same tasks in the Exchange Management Shell we’ll use Get-ReceiveConnector and Set-ReceiveConnector.
- First letsuse Get-ReceiveConnector to view all the receive connectors.
You can see highlighted the two settings we are interested in.
Set-ReceiveConnector -identity “OX-EXCH1\Default Frontend OX-EXCH1” -AuthMechanism Tls, Integrated, BasicAuth, BasicAuthRequireTLS
Then we’ll modify the FQDN.
Set-ReceiveConnector -identity “OX-EXCH1\Default Frontend OX-EXCH1” -Fqdn mail.oxfordsbsguy.com
In this post I’ve shown you how to change the FQDN of the Default Frontend receive connector using the Exchange admin center and the Exchange Management Shell.
I’m uncertain whether I would recommend this or not. In a single Exchange server environment it might be useful to hide your internal server FQDN, but nowadays most email systems we setup go through a third party anit-spam gateway service, so remote mail servers never directly speak to our mailserver (as long as you have your external firewall configured to only receive smtp from the anti-spam gatway). They will send mail to the anti-spam gateway which will then forward it to our Exchange server, and likewise when Exchange sends an email it is sent to the anti-spam gateway, before going on to the receiving mail server.
The other potential issue I can see if that if you make the changes above and your organisation grows, when you add a second Exchange server you may run into internal mail flow issues.
For the other articles in this series please go to:
- Exchange 2013 Cumulative Update installation tips and best practices
- How to install Exchange 2013 (SP1) on Windows Server 2012 R2
- Exchange 2013 Initial Configuration Settings
- Exchange 2013 Initial Configuration Settings: Setting SMTP accepted domains (Part 1)
- Exchange 2013 Initial Configuration Settings: Setting email address policies (Part 2)
- Exchange 2013 Initial Configuration Settings: Rename and move the default mailbox database and logs (Part 3)
- Exchange 2013 Initial Configuration Settings: Change mailbox size limits (Part 4)
- Exchange 2013 Initial Configuration Settings: Create a send connector (Part 5)
- Exchange 2013 Initial Configuration Settings: Set the offline address book (Part 6)
- Exchange 2013 Initial Configuration Settings: Enter the Product Key (Part 7)
- Exchange 2013 Initial Configuration Settings: How to configure a Postmaster address (Part 8)
- Exchange 2013 Initial Configuration Settings: How to change the FQDN on the default frontend receive connector (Part 9)
- Exchange 2013 Initial Configuration Settings: How to configure the virtual directories (part 10)
- Create and apply an SSL certificate (work in progress)