When trying to enable an IP to ‘Relay’ though my Exchange server, I found I was unable to select ‘Frontend TransportConnector’.
Solution
Apparently this is a a bug first seen in CU2, the only current fix is to either create the connector as a Hub Transport connector, then convert it using PowerShell, or create the connector in the Exchange Management Shell, which is what I did.
1. Connect to the Exchange admin center > Mail flow > receive connectors > Add.
2. Give the connector a name (take note of it, you will need it in a minute) > Select ‘Frontend Transport’ > Custom > Next.
3. Accept the default of TCP Port 25 (SMTP) > Next.
4. REMOVE the 0.0.0.0-255.255.255.255 range. (WARNING: If you do not do this you will become an open relay).
5. Add in the IP address of the host (from which you want to allow relaying) > Save.
6. Open the properties of the connector you just created > Security > Under Authentication select ‘Externally Secured (for example with IPSEC) > Under Permission groups, select ‘Exchange servers’ and ‘Anonymous users’ > Save.
7. At this point, you may find that when you test from the host you get the following error;
421 4.4.1 Connection timed out
I would suggest you change some parameters of the receive connector. Execute the following PowerShell command;
8. Restart the Microsoft Exchange Transport Service on the Exchange server.
[box]Restart-Service MSExchangeTransport[/box]
Exchange 2013 – Test Email Relaying from your ‘Allowed IP’
1. Go to the machine you have allowed relaying from, and attempt to ‘relay’ mail. In the example below I’m attempting to send an email to test@relay.com. In the first example we cannot relay, so something has been misconfigured.
2. However this time we CAN relay so our connector is configured properly.
Related Articles, References, Credits, or External Links
Microsoft have not only slipstreamed the service pack into the install media, they have (Finally!) got the install routine to put in all the usual pre-requisites, roles, and features, that you had to do yourself before. (With the exception of the Microsoft 2010 filter pack, but even then you can do that after the install).
The procedure below was done on a single server in a test environment, to demonstrate the simplified procedure, it IS NOT good practice to install Exchange (any version) on a domain controller.
Solution
Before Site Visit
1. Have your install media downloaded and ready to go (Make sure you also have the unlock codes for Exchange – or you will have 119 days to licence it, post install).
2. Does your current anti virus solution support Exchange 2010? Do you need an upgrade?
3. Does your current backup software support Exchange 2010? Do you need to purchase extra remote agents or updates?
Before Deploying Exchange 2010
1. Depending on what documentation you read, some say that the global catalog server(s) in the current site need to be at least Server 2003 SP2. Other documentation says the schema master needs to be at least Server 2003 SP2. Let’s hedge our bets, and make sure that ALL the domain controllers are at least Server 2003 SP2 🙂
2. Your domain and forest functional levels need to be at Windows Server 2003.
3. Don’t forget – your server needs to be x64 bit (the video below was shot on a Server 2008 R2 server).
4. Make sure both the server you are installing on, and the Windows domain, are happy (get into the event viewers of your servers and have a good spring clean before deploying Exchange 2010).
6. Install the roles required with the following PowerShell Commands;
[box]
Import-Module ServerManager
For Client Access, Hub Transport, and the Mailbox roles issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Web-WMI -Restart
For Client Access and Hub Transport server roles issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Web-WMI -Restart
For only the Mailbox role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart
For only the Unified Messaging role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart
For only the Edge Transport role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart
[/box]
7. Set the Net.Tcp Port Sharing Service for Automatic startup by running the following command;
With Exchange 2003 tarpitting was turned on post SP2 with a registry hack, with newer versions of Exchange it is enabled by default.
What is Tarpitting?
This is a method to stop a mail sender sending you multiple mail requests, it was designed to stop miscreant from carrying out either a :-
Directory Harvest Attack : Attempting to find out legitimate emails on your email server by randomly sending emails to loads of randomly generated names, that might exist on your Exchange Server. if they get an NDR back they know the address does not exist, if they do not get an NDR they will log that address and start sending spam to it.
NDR attack:
Essentially a denial of service on your mail server, this can be a result of a Directory Harvest Attack, insofar as your outbound mail queues fill up with thousands of NDR’s and the server slowly grinds to a halt.
To stop this from happening we have a system called Tarpitting, this stops a remote sender, from sending multiple emails one after the other. It imposes a time limit between emails from a sender (5 Seconds by default). The net result of this is, it’s far to expensive and time consuming to attack you, so the spammers and script kiddies will go elsewhere.
Solution
To find out what your tarpitting settings are
1. As said above the default setting for all receive connectors is 5 seconds, to verify your is still set the same way as it was when you installed issue the following command;
2. Above you can see all the receive connectors are set to 5 seconds.
To disable Tarpitting for all Receive Connectors
1. Tarpitting is a good thing and should be enabled so normally I’d only advocate doing this so you can test/troubleshoot a problem. Issue the following command;
2. Now the Default connector (Default DC2A) is set to 10 seconds and the rest remain at 5 seconds.
To disable Tarpitting for specific Receive Connectors
1. As said above tarpitting is a good thing and should be enabled, so normally I’d only advocate doing this so you can test/troubleshoot a problem. Issue the following command;
