Creating a Custom Receive Connector in Exchange 2013

Receive Connectors are used to control the flow of inbound messages into Exchange. With Exchange 2013 they are configured on servers with the Transport service (all mailbox servers) or with the Front End Transport service (all Client Access servers).

This means we can configure a Receive Connector in two different places... However, the big difference is that the Front End Transport service does not queue any messages locally while the Transport service does! Therefore, if you want Exchange to queue e-mails received by a custom Receive Connector (for example, in case of a problem with the recipient’s mailbox) you have to create it on your Mailbox servers.

Obviously, all the Receive Connectors required for internal mail flow are automatically created when a Client Access server or Mailbox server is installed. While Exchange 2007/2010 Hub Transport servers were not configured out of the box to accept e-mails from the internet, the new Client Access server comes with a Receive Connector named “Default Frontend server_name” already configured to allow “Anonymous Users” to connect to it to allow inbound flow from the Internet.

But sometimes custom Receive Connectors are required for various reasons: to control which servers receive messages from a particular IP address; to configure special connector properties for messages received from a particular IP address such as allowing larger messages or more recipients per messages; or to allow servers, applications or devices such as printers to establish unauthenticated SMTP connections to Exchange in order to send e-mails.

To create Receive Connectors in Exchange 2013 we can use the Exchange Administration Center [EAC] or the Exchange Management Shell [EMS]. In this tip, we will be using the Shell to create a Receive Connector that:
• Is associated with the Mailbox server called MBX1;
• Listens for incoming SMTP connections on the IP address 10.10.1.1 and port 25;
• Accepts incoming SMTP connections only from the IP range of 192.168.1.1 to 192.168.1.10;
• Accepts e-mails of a size up to 50MB;

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB

But what if a server is multi-role and has the Client Access and Mailbox server roles? How does Exchange know which role to associate the Receive Connector with? For these situations we have the TransportRole parameter exactly to designate the server role associated with this connector. The valid types are FrontendTransport and HubTransport.

So our example would become:

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB –TransportRole HubTransport

Office 365 Wave 15 Release Date

It’s official! According to several Microsoft sources at the Exchange Ignite, the new version of Office 365 commonly known as “wave 15” will be released in a couple of weeks in February 27th! :)

This coincides with the release of Exchange 2013 CU1 as well.

So stay tuned in the Office 365 Blog!

Exchange Server 2010 SP3 Released

Finally the much anticipated SP3 for Exchange 2010 has just been released! It brings the features and capabilities:

• Support for installing and deploying Exchange 2010 on Windows Server 2012;
• Support for Internet Explorer 10 to connect to Exchange 2010;
• Fixes;
• Coexistence with Exchange 2013.

 

Important: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is scheduled to be released in February 27th.

 

Please also note that this Service Pack requires schema updates.

 

DOWNLOAD it here.

Moving the Primary Active Manager

If, for some reason, the server currently hosting the Active Manager role of Primary Active Manager [PAM] fails, this role should automatically move to a surviving server of the Database Availability Group [DAG] which then takes ownership of the cluster quorum resource.

However, you might face a (rare) scenario where this doesn’t happen and you end up with a failed server and with Exchange still thinking that server is the PAM. Among other things, you will not be able to add/remove members to/from the DAG...

PAM decides which database copies will be active and passive, is responsible for getting topology change notifications and reacting to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group).

So how do we move the PAM to one of the surviving servers? To achieve this, we need to use the command line and use the following Windows Clustering command to move the cluster quorum resource:

cluster.exe “DAG Name” /MoveTo:NewDAG

where “DAG Name” is your DAG Cluster Name and NewDAG is the node where you want to move the PAM to.

Exchange 2013 Automatic Reseed

Microsoft has made great improvements in Exchange 2013, some of these around Database Availability Groups [DAGs]. For example, it is now possible to reseed a database from multiple sources, greatly reducing the overall time this operation usually takes. Another improvement, in this case a new feature, is called Automatic Reseed, or simply AutoReseed.

With Exchange 2010, if you lose the disk where your database is (either active or passive), Exchange will failover that database to another server (assuming it is part of a DAG with multiple copies). After that, an administrator will typically replace the faulted disk and reseed the database back to that server. This, of course, in scenarios where resilience through RAID or enterprise-level storage is not provided, which would cater for disk failures.

The purpose of AutoReseed is to overcome this situation and automatically restore database redundancy by using spare disks provisioned specifically for this. All it involves is pre-mapping volumes and databases using mount points that will be used for the databases and the reseed operation. In a simplistic way:

1. Mount all volumes (used for databases and as spares) under a single mount point, C:\ExchangeVolumes for example;
2. Mount the root directory of mailbox databases as another mount point under C:\ExchangeDatabases for example. Next, create two directories for each database: one for the database itself and another for the log files;
3. Finally create the database(s).

 

Here is AutoReseed process flow:

1. The Exchange Replication service periodically scans for database copies that have a status of FailedAndSuspended;
2. If one is found, it does pre-requisite checks like checking if spare drives are available and ensuring nothing might prevent Exchange from automatic reseeding the database;
3. If all the checks pass, the Replication service allocates and remaps a spare drive;
4. Seeding is performed;
5. Once seeding is complete, the Replication service checks if the seeded copy is healthy.

All an administrator needs to do now is simply replace the faulty disk and reconfigure it as a spare for the DAG!

To read all about this new feature and how to implement it, please check the article at MSExchange.org.