Powershell to Query Active directory

Powershell to Query Active directory and get the list of Domain controllers in the current AD Site which you server is located

%{[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Servers | % { $_.Name} }



Powershell to Query Active directory to get the current AD sites



Exchange 2007/2010 Dynamic Distribution List filter customizing

As the name says Dynamic Distribution List is the group which maintains the list of users in the group dynamically. Every time it’s hard to maintain Static list. Static list needs to be manually managed for adding and removing users. If it’s the smaller list then it can be managed easily and if the group is very big and it bigger the problem

Dynamic Distribution list is can be created using Exchange management Console or Exchange management shell. Dynamic Distribution list manages the users using filter condition. Default filter condition provides us limited filter options like State, Department, Company, and other custom attributes like 1 to 15. Same has been shown in Figure 1.


Figure 1. List of Condition Options for filtering members to group

With this option we can build the Dynamic DL and these options some times can match our requirement and some times it may not.

For example we need to build a Dynamic DL with the list of users belonging to the specific Mailbox Server. Requirement option can vary depending on the business. Here i am just trying to take one example and explaining the concept.

Dynamic DL saves all the filters in the Active directory. AD Attribute msExchQueryFilter, msExchDynamicDLFilter has all filters settings.

msExchQueryFilter hold the OPATH filters. OPATH is basis for the filtering syntax used by Powershell.

msExchDynamicDLFilter hold the LDAP filter which is available in msExchQueryFilter attribute

If we wanted to change the filter to match the requirement then we need to use ADSI Edit and edit the AD attributes and apply the new filter.

1. Access ADSI Edit from your computer and connect to Default naming context. Figure 2


Figure 2. connecting to Active Directory – Default naming context

2. Create the Dynamic DL in Advance and Browse the Adsiedit to the Dynamic DL which is create and right click and properties


3. Copy and paste the below OPATH filter on msExchangeQueryfilter and replace server name with the mailbox servrname, if clusterd then cluster CMS name

(((RecipientType -eq ‘UserMailbox’)) -and (-not(Name -like ‘SystemMailbox{*’)) -and (-not(Name -like ‘CAS_{*’) -and (ServerName -eq ‘Servername’)))

4. Now you have configured the filter. If you wanted to see if this filter is applied then you can use the below Powershell cmdlet. Replace DymamicDL with the name of the DL which we have worked on and it will get the result of all the users’ name that belongs to the specific server.

$DynamicDL = Get-DynamicDistributionGroup -Identity “DynamicDL”

Get-Recipient -RecipientPreviewFilter $DynamicDL.RecipientFilter |select name,servername

You can get this requirement if you wanted to send communication to specific users on the specific server when there is any maintenance etc. As I said earlier we can use similar filters based on the requirement to add users dynamically into the list. Technically you can get any Powershell filter into Dynamic DL

Tips on Quest and Exchange Shell to Manage Groups and Group Members

Tips on Quest and Exchange Shell to Manage Groups and Group Members

Groups are of two types Security groups and Distribution Groups. Securities groups are normally used in provide AD Object Permission and NTFS permission and Distribution groups are used to email members of the Distribution Groups or shortly we call it as DL (Distribution List). Security groups can also be enabled as mail enabled security groups that used for Setting Permission and also sending email to the Members of the groups


Figure 1. Details of the Security Groups in Quest Shell

If you wanted this security group to mail enabled so that users can send email to the members of the group once this it enabled this group will also be visible in the GAL. You can only enable universal Security groups. Enable-DistributionGroup Exchange cmdlet does this for us


Figure 2. Exchange Cmdlet to enable Security group to mail enabled security group

Nested Groups is always Challenging. If you are working Nested group and you wanted to find the list of Indirect Nested groups which this group belongs, below Quest cmdlet gets the details

Get-QadGroup <groupname> | Select NestedMemberof


Figure 3. Cmdlet to get the list of Nested member DL

To get the list of DL which this group is member of then

Get-QadGroup <groupname> | select Memberof


Figure 4. Cmdlet to get the list of DL which DL is member of

Groups will always have members and in it. Get-QadGroupsmembers <groupname> will get the list of all the members in it. Members can be a users, group, contact. In the below example usergroup5 has type group “usergroup4” as member. But usergroup4 also has members in it. Those members can be users or groups. Using -Indirect parameter provides the list of all the Direct and Indirect members of the group. This is so simple right. If you wanted to do that same in VBscript we need to write lots of codes may be a recursive finding to find al the members in the nested groups.


Figure 5. Cmdlet to get Direct and Indirect members of the Group

Lets now try to filter out only required object like users or groups or contacts from the Group members. Below powershell cmdlet will get the list of all the -Indirect members and it filters out and displays only members of type Group

get-qadgroupmember usergroup5 -indirect | ?{$_.type -eq “group”}


Same can be done using LDAP filters but this time lets try to get indirect members of type users

get-qadgroupmember usergroup5 -indirect -ldap “(objectCategory=user)”


If you wanted to find the count of all the users in the group then below command does it for us. This uses ldap filter to find the count

@(get-qadgroupmember usergroup5 -indirect -ldap “(objectCategory=user)”).count


Figure 5. Cmdlet gets the count of all the Indirect users in DL Usergroup5

Similarly if you wanted to find the count of group members then we can also use where command to get the count

@(get-qadgroupmember usergroup5 -indirect | ?{$_.type -eq “group”}).count


Figure 6. Cmdlet gets the count of all the Indirect groups in DL Usersgroup5

Another Interesting way to get the Members of the Group and the member count

Below powershell cmdlet gets the list of all the members CN name using get-Qadgroup

(get-Qadgroup usergroup5).members


In the same fashion we can also get count members just by suffixing with .count

(get-Qadgroup usergroup5).members.count



Exchange 2010 Connectors

Exchange 2010 Connectors


A connector, as its name implies, is used to communicate between Exchange 2010 and External Entities like Internet Email Servers, legacy Exchange servers, 3rd Party mail servers, applications, appliances etc. Understanding this will help to create and configure various connectors and configure for the communication. This also helps on how mail flow can happen between exchange and other external entities.

This article is for all administrators on how to create and configure connectors and the application of the connectors. I thought of putting all the connectors will help to get some clear understanding of mail flow between Exchange and other email communication word.

Below are the various connectors which can be created and configured in Exchange 2010 Servers. Let’s understand one by one

– Send connector

– Receive connector

– Foreign (Delivery Agent) connector

– Linked connector

– Routing Group connector

Send connectors

A Send connector is basically used to send email to Internet Servers (i.e. servers outside of your own organization), and it controls how email should be passed to the “outside world”. No send connectors are created by default during the installation and setup of your Exchange server roles, and at least one needs to be created manually, which is a process we’ll look at in just a moment.

While there are invisible Send connectors which are created by default, these are used for mail delivery within the Exchange 2010 organization, and we have no control over them. Send connectors which we manually create must be created on a Hub Transport server, and are stored in the Active Directory. This information is therefore accessible to any Hub Transport Servers in the organization, which can then use this connector to send the email to the Internet word.

Multiple Send connectors can be configured to send email outside your organization. Multiple send connectors can be created with different cost for sending emails through different ISP Connection. This helps when you have multiple ISP connection and when there is failure of one ISP then you can use different Send connectors to route the email to the Internet. Multiple send connectors also help when you want certain traffic routed using a different connector. For Example you wanted to send email to Microsoft.com using a specific ISP connection and email to Simple-talk.com using a different ISP connection then different send connectors come in handy.

In addition, the Hub Transport server can be configured to send email to directly to the recipient, or it can direct outgoing email to a smart host (which can be an Edge Server or any application like Borderware, Postini, ironport etc.). If it’s configured to send email directly, then we need to make sure that the DNS is properly configured so that it can resolve internal and external DNS MX records. On the other hand, if it’s configured to send email to a smart host, then naturally the smart host should be configured to deliver the email to the Internet. Let’s take a look at how to set these options up.

How to Create and Configure Send Connectors

There are two ways to create a Send connector; via the Exchange Management Console or the Exchange Management Shell. Both methods end up with exactly the same result, you just need to pick the process you feel more comfortable with.

Via the Exchange Management Console

Open the Exchange management console and navigate to the result pane under Organization Configuration > Hub Transport Server. Select the Send connectors tab, and click on New Send Connector within the Action pane.


Figure 1. Creating a new Send Connector within the Exchange Management Console.

Now you need to go through a few configuration steps to make sure the new Send connector is correctly set up.

1) Specify the intent of the Connector

Providing a unique name which describes the connector’s purpose, particularly if you have multiple connectors, will help you to identity and differentiate specific connectors. Once you’ve given the connector a name, you need to specify its intended use:

Custom: Custom options are used when you wanted to send mail to a specific domain which is not an Exchange Server. Custom connectors are used for forwarding messages to a smart host, which are configured to use DNS MX records to deliver the email to their destination.

Internal: Internal connector is used when you want your Exchange Server to communicate with other Exchange severs in different forests. Eg. If there are multiple Exchange forests in your organization and you want communication between the multiple forests to follow a specific path then an Internal connector is the way to define that path.

Internet: An Internet connector is used to send email directly to the Internet, and is configured to use DNS MX records to route email to its destination. This will be created on the organizations Internet-facing server(s) in order to deliver email. This option is generally used when you do not use a smart host to deliver email.

Partner: The Partner connector is, unsurprisingly, used to send email to a partner domain. For example, if a one company acquires another, then there may be business requirements that need these two companies to run independently, but they also want to make sure that emails shared between these domains are not sent over the public internet. This is when the partner Send connector comes into effect.

More in-depth information on the Intended options can be found on Technet.


Figure 2. Specifying the intended use of your Send connector

2) Specify the Address Space

Once you’ve specified the purpose of your Send connector, we have to state the domain address space to which the connector will be used to send mail:

– A “*” in the Address indicates that this connector will route all domains that do not match the internal organization’s list of accepted domains.

– “Domain.com” in the address indicates that this connector is dedicated to sending email to domain.com addresses.

– “*.Domain.com in the address space indicates that this connector is used for sending email to recipients in domain.com and any sub-domains.

Cost is used to set the priority of this connector, used when two or more connectors are configured for the same address space. The lower the cost higher the priority.

– A Scoped Send connector identifies which Hub Transport servers can use this connector. Send connectors are objects stored in Active Directory and, as they are also an organization configuration object, can normally be used by any Hub Transport servers in the organization. If you want to restrict the scope of the Send connector, so as to limit its use to just within the AD site of the Hub server it was created on, then this option needs to be checked.


Figure 3. Configuring the address space of the new Send Connector

3) Configuring the Network Settings

The Network Settings determine how the message is to be routed to the destination SMTP server, and they can be configured to work in one of two ways:

1. Use DNS MX records to route mails automatically.

2. Route mails though to one or more smart hosts and let them handle the rest of the delivery.

The option to use Domain Name System MX records to route email automatically should be taken when you want your Send connector to talk directly with the destination SMTP server’s gateway and deliver the emails to that destination gateway itself. You need to make sure that DNS is properly configured for the server to resolve the Destination MX Records. This option is only available when you have selected Custom, Partner or Internet as your connector intent in step 1, above.

Alternatively, if you select the route mail through the following smart hosts option, you will need to supply one or more IP addresses or the FQDN of the smart host which is going to accept the email from this connector. Obviously, you need to make sure that the smart host is capable of delivering emails to the destination SMTP server.

If this send connector needs to resolve remote domains using External DNS server then check "Use the external DNS lookup settings on the Transport Server" as shown in Figure 4. When you use this check box you also need to make sure the each Hub Transport servers which communicates with the Internet hasits ExteernalDNSServers configured. To Configure External DNS servers on Hub Transport Servers, the command is:

Set-TransportServer <ExchangeServer> -ExternalDnsServer <ExternalDNSIPaddress1>,<ExternalDNSIPaddress2>


Figure 4. Specifying IP addresses for smart hosts.

Configuration of the connection(s) to the smart host(s) requires some additional steps to control authentication with the smart host server(s). The options available are:

None : The smart host does not require any authentication, and it accepts anonymous connections.

Basic Authentication: You will need to provide the smart host with an appropriate username and password to authenticate the connection. If you have multiple smart hosts, then you will need to make sure that they all allow access to the same username and password. Basic Authentication sends the credentials as plain text, and checking Basic authentication Over TLS will enable encryption on the communication.

Exchange Server Authentication: This option authenticates the connection to a smart host using an Exchange authentication mechanism, such as TLS direct trust or TLS\Kerberos.

Externally Secured:   Select this option if the connection to the smart host is secured by external means, such as being physically secured over a private network or secured using Internet Protocol security (IPsec).


Figure 5. Authenticating the connection to the smart host.

4) Source Server Settings.

This is the final configuration step in which you need to identify which severs will be making use of the new connector to route emails. Adding only required servers helps to ensure that only specific servers are able to participate in email delivery to the Internet or other partner networks. Adding the required servers is simply a matter of clicking the Add icon at the top of the configuration pane, and supplying the necessary server names and details.


Figure 6. Specifying which servers will be using the new Connector

5) Create the Send Connector

Once you’re done with the configuration, then you can just click Next and then New to create the new Send connector. At this point, we are pretty much done with the creation of send connectors through the Exchange management console.


Figure 7. The newly-created Send connector, configured and active.

Exchange Management Shell

Creating the Send connector in Powershell is pretty easy, because it’s just a single command, although naturally you need to make sure the parameters are correctly provided. Below is the simple command to create the Send connector for sending mail to the Internet, and it will create exactly the same connecter as the one we created using the console.

New-SendConnector -Name ‘To Internet’ -Usage ‘Custom’ -AddressSpaces ‘SMTP:*;1’ -IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts ‘[]’,'[]’ -SmartHostAuthMechanism ‘None’ -UseExternalDNSServersEnabled $false -SourceTransportServers ‘KEXCH’

Post-Creation Configuration

There are some important configurations which you should consider after creating your Send connectors; specifically, things like MaxMessageSize, SMTPMaxMEssagePerconnection, Protocollogging etc. Adjusting these configurations on a Send connector can be easily done using the set-Sendconnector cmdlet:

Set-Sendconnector -Name ‘To Internet’ -MaxMessageSize 20 MB -smtpmaxmessageperconnection 25

If you’re not sure how your Send connector is configured, using the Get-Sendconnector cmdlet will give you more information on the connectors, which you may want to take a look at in order to better understand them:

Get-senderconnector -name "Connector name" |format-List

Receive Connectors

As the names suggests, this connector is used to receive incoming email from other Exchange servers, the Internet, partners, etc. Receive connectors are dependent on the Hub Transport Servers, and each Hub Transport server is created with two receive connectors; a default Receive connector (for SMTP) and a client Receive connector (for POP3 and IMAP)


Figure 8. The two default Receive connectors on the Hub Transport Server role.

Each of these connectors has a specific configuration which we will take a look at shortly, and you can also create custom Receive connectors on the Hub Transport servers to act as secure relays within your organization. Each connector is associated with a local IP address and port number, and it’s also useful to define the IP address or range of IP addresses that a receive connector can accept connections and emails from, as well as the maximum message size, necessary authentication, permissions etc.

Initial Receive connectors on the Hub Transport Servers

As you can see in figure 8, each Hub Transport Server has two initial Receive connectors already in place: The default connector (for handling incoming SMTP email) and the client connector (for handling SMTP relay email). Both of these are configured to be secure by default, and it’s generally a good idea to keep them this way. Anonymous users permission is not enabled by default. Let’s take a closer look at these two connectors now:

Client [ServerName]

This connector is created when installing a Hub Transport server, accepts email from non-MAPI clients for SMTP relay, and is configured to use port 587. It can accept messages from any IP address and has permission to accept mail from Exchange Users, as they are basically authenticated users. The available authentication methods for use with this connector are: Transport Layer Security (TLS), Basic authentication, Exchange Server authentication, and Integrated Windows authentication. Only Exchange users have permission to use this connector.

Default [ServerName]

Also created upon server installation, this connector is configured to accept email from other hub servers and other servers on port 25 (the universal SMTP port). This connector is also configured to accept messages from any IP address, and it is configured with permissions for use by Exchange users, Exchange servers and legacy Exchange servers. The available authentication methods are: TLS, Basic authentication, and Integrated Windows authentication. Exchange users, Exchange users , Exchange Servers and Exchange Legacy Servers have permission to use this connector.

Custom Receive Connector

If you wanted a specific application server to be able to send email to an Exchange server then you can create a custom receive connector to accept email only from the specific application server. Configuration of Receive connectors to accept email from specific server and port is very important from a security point of view. This is so that we don’t allow any other application (such as a malware application) to use Exchange servers to relay email. To better understand Various configuration options available, let’s create a custom receive connector to suit our requirement and secure it.

First, access the Exchange Management console and navigate to Server Configuration > Hub Transport. Select the required Exchange Hub Transport Server from the upper result pane, and click on New Receive connector in the action pane Figure 9.


Figure 9: Starting the Receive connector creation process.

1) Specify the Intent of the Connector

As when creating a Send connector, provide a unique and appropriate name for the connector, and you now have various options for the connector’s intended use: Custom, Internal, Internet, Client and Partner. Each configuration has options for how clients can authenticate, interact with the local network, port configuration, the remote IP address range which can uses the Receive connector, etc. Let’s look at what each of the options provides us with:

Custom: This selection provides the most flexible options to create and configure receive connectors. Eg. Custom is selected when you have specific application requirements for communicating with Exchange on a different port.

Internet: This connector is open to messages from the Internet, and this setting provides the options to manage the connector’s local network IP addresses, ports and specific FQDNs, as well as providing anonymous and TLS authentication options.

Internal: This option only allows you to actively restrict which local network IP addresses can use this connector. This setting also provides options for TLS and Exchange server authentication, as well as permissions for Exchange servers and legacy Exchange servers.

Client: This setting only provides you with the option to change remote IP address settings. All Exchange users have permission to use this connector, and this setting also provides options for TLS, and also basic authentication with a TLS connection.

Partner: Similar to the “Custom” setting, “Partner” provides the option to manage the connector’s local IP addresses, FQDNs and ports, as well as the accepted remote IP address range. However, it only provides permission to partners, and provides TLS and enables domain security authentication.


Figure 10. Specifying the intent of the new Receive connector.

2) Modifying the Local Network Settings

The next step in creating the custom receive connector is modify the local Network settings with the connector’s IP address (es) and specified FQDN details. As you can see from the text in figure 11, these settings control which IP addresses and ports the connector will use to receive mail.


Figure 11. Defining the connector’s local network settings.

3) Managing the Remote Network Settings.

The next step is to control the range of remote IP addresses which can use this connector;:


Figure 12. Controlling the range of remote IP addresses which the connector will receive mail from.

4) Create the Receive Connector

Once you are done with configuring your custom Receive connector, follow the final instructions of the connector creation wizard, and you should be able to see the new connector alongside the others in the Exchange Management Console:


Figure 13. The newly-create Receive Connector

Exchange Management Shell

Creating the Receive Connectors in Powershell is pretty easy, because it’s just a single command, although naturally you need to make sure the parameters are correctly provided. Below is the simple command to create the Receive Custom connector for Receiving email on port 25, and it will create exactly the same connecter as the one we created using the console.

New-Receiveconnector -Name ‘From App’ -usage ‘Custom’ -Bindings ‘’ -fqdn ‘mail.k.com’ -remoteIPrantes ‘’ -Server ‘KEXCH’

Post Creation Configuration

Once this connector has been created, you can still manage and configure it either by right-clicking on it and examining its properties, or by using the set-receiveconnector Powershell cmdlet to do the same. The settings which are most worth your time are the various authentication options available and required for incoming connections, such as:

Basic authentication

In Basic authentication username and password is send in clear text which is not recommended. It is always advice to select the check box Office basic authentication only after starting TLS. Once this check box is enabled then first TLS connection is established between Exchange and other entity and then basic authentication is performed.

Integrated Authentication

When Integrated Authentication is checked then NTLM and/or Kerberos are used for authentication

Exchange Server Authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI).

This is used when you wanted Smart host to authenticate using TLS direct trust or Kerberos through TLS

Externally Secured,

Using this security mechanism that’s external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN)


Figure14. Defining the authentication options for a Receive connector.

Once you are done with the authentication settings, now its time to configure permission groups. First of all we need to make sure that we don’t enable anonymous users which will allow this connector as open relay. So that any one cannot use this connector with out appropriate rights. Other options available are Exchange users, exchange servers, legacy exchange servers and partners.

Exchange users – Offers Basic Authentication over TLS for connection

Exchange users and Exchange servers – Offers TLS and Exchange Server authentication

Partner Permission – offers TLS  and Enable Domain Security (Mutual Auth TLS) authentication. When you want a receive connector to receive email from a partner company over a TLS connection. More information on configuring Mutual Auth TLS can be found in TechNet.


Figure 15. Defining the Permission Groups allowed to use this connector

As already mentioned, Get-Receiveconnector also provides access to these settings, in case you prefer to use the Exchange Management Shell. Some of the options which are worth paying attention to are things like banner, maxinboundconnections, connection timeout, and protocol logging.


This setting is to determine the maximum number of connections a receive connector can process at a single time.


Connection Time out specifies how long connection can be established with the exchange server before it can Timeout.


Determine whether auditing is enabled on the connector. If is enabled then all the connection details and other related details will be logged. This can be very useful for troubleshooting issues.


Banner is the message which is displayed when a connection is initiated with the Exchange server. The default banner can give server details. If you don’t want this information to be displayed then this can be changed using Set-Receiveconnector.


Figure 16. a screenshot of just some of the information available through get-receiveconnector.

If you want to modify a Receive connector, the Set-Receiverconnector cmdlet provides you with a quick method for doing this. You can find extensive documentation of this cmdlets parameters and switches in this TechNet article, but here’s a simple example:

Set-ReceiveConnector -Identity "Internet Receive Connector" -Banner "220 Banner Text here" -ConnectionTimeout 00:15:00

Foreign Connectors

Foreign connectors are used to communicate with 3rd party systems, but rather than use SMTP to communicate with these systems, it uses drop directories to communicate. For example, if Exchange 2010 wants to communicate with such a 3rd party system (which could be a server or an application), then it leaves the message in a drop directory on the Hub Transport server or Network Share. The 3rd party application then retrieves the message from the drop directory, and processes the emails.

Alternatively, if a 3rd party application wants to send a message into Exchange 2010, then it performs a similar action using the replay directory, which exists on the Hub Transport server; correctly formatted email message files that are copied to the Replay directory are submitted for delivery.

Foreign connectors are stored in Active directory and are available to all the Hub Transport servers in the organization, which then use foreign connectors to route emails to destination folders for a given address space. For redundancy, multiple Hub Transport servers can be added to the connector, so that if one server fails or is otherwise unavailable, then the email will be routed using an alternate Hub Transport server.

In Exchange 2010, foreign connectors use Delivery Agent connectors to route email to the foreign systems. Delivery Agent connectors ensure that the messages intended for foreign systems are inserted into the appropriate queues on the Hub Transport servers that are used for delivering such messages. After the messages are queued, the delivery agent is invoked by Connection Manager, and the agent handles the actual delivery of the message to the foreign system.

Creating and Configuring a New Foreign Connector

For the sake of speed, we’ll handle this task using the Exchange Management Shell; once you’ve got the shell open, we run the New-Foreignconnector command, which is extensively documented on TechNet:

New-Foreignconnector -identity "ForeignConnector" -AddressSpaces "fax:*" -SourceTransportServers "Hub01.domain.com","Hub02.domain.com"

In Figure 17, we are trying to create a foreign connector for the Fax application, with the address space “Fax:*”, and making use of just a single Hub Transport server called “Kexch”. Naturally, any fax messages would use this connector:

New-Foreignconnector -name "foreignconnector" -addressspace fax:* -sourcetransportserver Kexch


Figure 17. Running the New-Foreignconnector cmdlet, and seeing the results.

Once you have created the connector, you can easily modify it based on your requirements using the Set-foreignconnector cmdlet. Below I have specified the drop directory for my new connector, and set the maxmessage size to 10 MB.

Set-Foreignconnector -Identity "Foreignconnector" -Maxmessagesize 10MB -dropdirectory C:\DropDirectory

Linked connector

As the name suggests, this is a situation where a Receive Connector which is linked to a Send connector (and so it is a relationship, rather than an actual connector in itself), and it exists for a very good reason. This connector is used when you have 3rd -party anti-spam and anti-virus systems (such as postini) processing your messages at a vendor’s location or on a different server. In that situation, you need to ensure that all the incoming email passes through the 3rd party appliance, and then receive those emails back once the email scanning and filtering is completed, and this is what the Linked connector enables.

Linked connectors are created on Hub Transport or Edge Transport Servers and, thankfully, can be used without changing your existing configurations, such as your MX records, Sender Policy Framework etc. Let’s look at how we can create Linked connectors on the existing network:


Figure 18. Simple network routing topology, including a pair of Linked connectors routing messages to an anti-spam service.

Let’s take a quick look at the setup in Figure 18: Image Source

Sendconnector:25 and Receiveconnector:25 are the two connecters configured to send and receive all email between the internal network and the Internet. When we want our email to be scanned by anti-spam servers, we need to create and configure the connectors between our internal network and those external servers, and then create an appropriate link to our existing connectors to allow for that.

First, we need to create the new Sendconnector:26, and link it with the receiveconnector:25, and configure the Send connector to deliver incoming email (from step 1 in the image) to the anti-spam solution (step 2 in the image). Next, we need to create the new Receiveconnector:27 to receiving email back from the anti-spam solution (step 3), and deliver that email to the internal Exchange server, which will then distribute the email to the appropriate users (step 4).

That sounds simple enough, so let’s create the new sendconnector:26 and Receiveconnector:27 connectors, and configure the link between receiveconnector:25 and Sendconnector:26

Creating and Configuring Linked Connectors

In the command below, we are creating a new Send connector and using the linkedreceiveconnect command to link the new connector with the existing Receiver. The -SmartHosts parameter allows you to enter the details if the anti-spam server. DNS routing needs to be disabled. Normal send connectors are configured with DNS for delivering emails to the remote domains. This Send connector is linked with receive connector to forward email to specific server and there is no need for DNS routing, hence DNS routing is set to $false. Smart host authentication is set to Externalauthoratative. Extenalauthorative authentication is used when the connection is fully secured between exchange server and Smart Host (Anti Spam Server). Once Enternalauthorative is set then any client can connect to Exchange sever as Authorized Server. Below is the Powershell command to create new Send connector:26 and link with receive connector:25 to deliver all the incoming emails from the internet to smart host.

New-SendConnector -Name "Sendconnector:26" -LinkedReceiveConnector "Edge01\Receiveconnector:25" -SmartHosts antispam  -SmartHostAuthMechanism Externalauthoratative -DNSRoutingEnabled $False -MaxMessageSize unlimited

Now let’s create the new Receive connector for receiving email back from the anti-spam server. The new-receiveconnector cmdlet below creates a new connector with externalauthoratative authentication and the remoteIPrange set to the anti-spam server.

New-Receiveconnector -name "Receiveconnector:27" -AuthMechanism externalAuthoritative -RemoteIPRanges antispam

Routing Group Connectors

Routing Group connectors are connecters between Exchange 2010/2007 servers and Legacy Exchange 2003 servers for internal mail-flow between them. A RGC does not need to be created between Exchange 2010 and 2007, communication happens automatically. Bidirectional instances of these connectors are installed by default when you introduce a new Exchange 2010 Hub Server into the Exchange Organization. Or rather, are created during the installation; one each for mail flow between Exchange 2003 and Exchange 2010, and between Exchange 2010 and Exchange 2003.

Exchange 2003 uses a link state routing table to maintain routing information on how email is routed in organization, and this table is updated when the routing group master effects a change in the mail routes.

However, Link State routing isn’t used at all in Exchange 2010, which instead communicates with the Hub server directly and uses AD site cost to determine the shortest routing path. We can create multiple Routing Group connectors between Exchange 2003 and Exchange 2010, but if we do, we will need to make sure that Link state updates are suppressed so that message looping does not occur when route is recalculated.

Let’s take a look at how to create new Routing Group connectors, and also how to modify them to add additional source and target servers for redundancy in the event of a server failure.

The New-Routinggroupconnector cmdlet below creates a new Routing Group connector. In terms of settings, the Sourcetransportserver and TargetTransportservers need to be specified, and the Bidirectional setting controls whether this connector to allow for two-way or one-way mail flow. If bidirectional is set to $true, then two connecters will be created, as a reciprocal connector is created in the target routing group.

New-RoutingGroupConnector -Name "RGCBidirection" -SourceTransportServers "Hub2010a.domain.com" -TargetTransportServers "Bridgehead2003.domain.com" -Cost 100 -Bidirectional $true

For redundancy, we can add multiple source and target transport servers into the existing “RGCBedirection” connector using the Set-RoutingGroupConnector cmdlet:

set-RoutingGroupConnector -Identity "RGCBidirection" -SourceTransportServers “Hub2010a.domain.com”, “Hub2010b.domain.com” -TargetTransportServers " Bridgehead2003a.domain.com”,” Bridgehead2003b.domain.com"

And lastly, if you want to get the complete status on the newly created and configured routing group connectors, the you just need to use the Get-RoutingGroupConnector cmdlet like so:

Get-Routinggroupconnector -identity "RGCBidirection" | format-list

If you want a deeper understanding of the New-RoutingGroupConnector cmdlet, extensive details are once again available from Microsoft TechNet. Likewise, there is a huge amount of information available on the Set-RoutingGroupConnector and Get-RoutingGroupConnector cmdlets.


With this I would like to conclude my article. I hope this article is informative for the administrators to understand all the Exchange 2010 connectors, configuration and their applications.

In this article I have tried to create and configure connector using both Exchange management console and Exchange management shell. Creating and configuring using Powershell is always easy but we need to make sure that all the required parameters are used correctly. Some connecters like linked connectors cannot be created using Management Console, it always needs to created and managed only using Powershell. Creating and managing using management console provides with limited option. Powershell Set-* and Get-* cmdlets allows exploring various advanced option which cannot be done using management console. Set-* Powershell cmdlets allows connectors to be configured at a granular level.

2010 Microsoft MVP Award

On 1st July I got this email from Microsoft . This is a Very special Award for me.  I really would like to thank Microsoft for this Award.

Dear Krishna R,

Congratulations! We are pleased to present you with the 2010 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in PowerShell technical communities during the past year.