Pages

Monday 28 June 2010

Internet Routing

Routing mail throughout your internal infrastructure requires little extra configuration if you rely on your AD topology to do the job. Of course, you must have a well designed AD infrastructure for this to work! As the previous post explained, you may need to adjust your setup to correctly establish just how email is routed if the AD topology favours AD replication and not email routing (hub sites for example).
Routing mail out of your exchange organisation to recipients that don't have internal mailboxes, will NOT WORK by default. Sending and receiving an email to and from a hotmail account for example. This post will show you what configurations are required to get this going.

Part One

Configure Accepted Domains
Exchange will accept email if the domain is configured as an accepted domain. For example, If a hotmail user sends an email to andrew@compulinx.com, my exchange server will accept the email and send the message to the Andrew recipient mailbox. The message will only be accepted if compulinx.com is configured as an accepted domain. This would have been configured by default if the AD domain has the same name (this would be a split DNS). Many AD infrastructures use .local as a top level domain name and so in this case, compulinx.com (the Internet registered name) would be added as a accepted domain.
There are three main types of accepted domain:
  • Authoritative
  • Internal relay
  • External relay
In the example just given, compulinx.com is an authoritative domain. The exchange organisation is 'responsible' for this domain and has recipients with this email address.

Relay domains are not part of your exchange organisation. Internal relay domains would result in inbound emails being sent by your exchange server to another by using a send connector based on that domain name. This might be used where exchange is sharing the namespace with another email system. Messages are first sent to your exchange server, if no mailboxes exist then they are sent to a different server linked by a send connector.
An external relay will result in exchange not checking if a mailbox by that domain name exists in the organization. It will send the email to a different server probably in a completely different organization using a send connector. For example, email could arrive at your edge server, get cleaned up then sent by external relay to another organization.
The following cmdlets are used to configure these different accepted domains:

[PS] New-AcceptedDomain -Name "compulinx.com accepted domain" -DomainName compulinx.com -DomainType Authoritative

Different domain types can be used in the above cmdlets. These include the following:
Authoritative
InternalRelay
ExternalRelay

Part Two

External DNS configuration
Another important consideration is to make sure the accepted domain name is registered properly on the Internet. Using perhaps your ISP web site you should create an MX record that references your public IP address. E.g. mail.compulinx.com ..... your public ip address. This might take a while to update.

Part Three

Configure Remote Domains Message Settings
Remote domains are domains outside of your exchange organization, in other words domains that your exchange server is not authoritative for. When your exchange recipients send mail to an external address e.g. a hotmail address a default remote domain configuration is used (unless a more specific remote domain configuration has been made). These remote domains are organization wide (you can see them in the EMC under 'Organization Configration' and 'Hub Transport). There are two settings that can be applied to your remote domains:

1. Out-of-office messages (OOFs)
2. Message format

 Out-of-office messages (OOFs)

















As you can see in the above screenprint, OOFs can be set to provide automatic messages on receipt of email informing senders that you are not available. These senders could be internal or external recipients of your organisation. Note however that 'Allow external out-of-office messages only' (the one shown above) applies to messages created by Outlook 2007 (or newer), OWA in Exchange Server 2007/2010 and maked as external. The next option allows all clients (Outlook 2003/2007/2010 and OWA connected to Exchange 2003/2007/2010) to send OOF messages when replying to messages marked as external. The last option allows all clients (Outlook 2003/2007/2010 and OWA connected to Exchange 2003/2007/2010) to send OOF messages when replying to messages marked as internal.

Message Format

Message Format settings can be used where perhaps you dont want automatic replies (or NDRs) to be sent to particular remote domains (maybe domains you dont trust). Spammers can determine whether the email address they send spam to is invalid or not.



















Part Four
Configuring Connectors to Send and Recieve Email To/From the Internet

1. Send Connectors

The following describes how to construct a necessary 'Send Connector' that will send Internet bound email from your Hub Transport server (i.e. not using an Edge server). This is not usually recommended. We will discuss the use of Edge servers in part 5.
  1. Open the EMC and browse to the Organisation Confiuguration, Hub Transport node
  2. Select New Send Connector in the Actions pane
  3. Type a name for the connector
  4. Select 'Internet' in the Intended Use For This Send Connector section
  5. In the address space screen, click add and provide a * in the address field
  6. Under network settings, use DNS MX records to route mail automatically
  7. On the source server screen, make sure your Hub Transport server is listed and finish the wizard.
The following script should provide the same configuration:

[PS] new-SendConnector -Name 'Internet' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'EX1'

    2. Receive Connectors

    The following describes how to modify an existing receive connector to allow a Hub Transport server to receive email from the Internet. It is best practice to allow external NAT routers to forward TCP 25 (SMTP) traffic to a Edge server in your DMZ. Without Edge servers, first configure your NAT routers to port forward to a Hub Transport server. Receive connector configuration essentialy involves changing the connectors ACL to allow sending email servers to authenicate anonymously.
    1. Open the EMC and browse to the Server Configuration, Hub Transport node
    2. From the list of Hub Transport servers, select the server that you want to receive Internet mail on.
    3. Select the defualt connector and properties
    4. Select the permissions Groups tab
    5. Select anonymous users and click OK

    Part 5

    Using Edge Transport Servers

    Edge transport servers sit in a perimeter network (in a workgroup outside of your internal AD structure). Its focus is to relay inbound and outbound messages to and from an Exchange Organization while providing message hygiene and security. Because its in a workgroup, it does not have direct contact with AD. To perform its functions, it uses AD Lightweight Directory Services (was called ADAM) which is like a read only copy of AD (at least just part of it). Replication is one way only (from Hub Transport to Edge Server). Only recipient,configuration and topology information required by the Edge server to perform its functions of message relay, message hygiene, anti-spam and use of transport rules are replicated. The MSExchangeEdgeSync service which runs on the Hub Transport server will push AD changes to AD LDS on a scheduled basis.
    The following section will explain how to install and configure an Edge Server:

    1. On a server install the AD LDS role
    2. Make sure the server has a FQDN (of AD domain name)
    3. Add the .NET 3.5.1 feature
    4. Assign the DNS IP address as the internal DNS server (on your DC)
    5. Make sure you create a host record for the edge server on the internal DNS
    6. Install the Edge Server role
    I have found that self-signed certificates are used here. If deleted (perhaps by mistake), Test-Sychronization and Test-Edgesubscription will fail. To overcome this do the following:
    1. On the Hub Transport Get-ExchangeCertificate to identify your certificates
    2. Type New-ExchangeCertificate
    3. Restart the Hub Transport service
    4. If any edge subscriptions and/or send connectors exist on the Hub Transport remove them (no subcriptions will exist if this is a first time configuration!). 
    5. Restart the Hub Transport service again
    6. Remove any existing subscriptions on the Edge server (none should exist)
    7. Create a new subscription file on the Edge server by typing New-EdgeSubscription -FileName "c:\edsub1.xml" 
    8. Copy the file to the Hub Transport server 
    9. On the Hub Transport server browse to Organization Configuration, Hub Transport and on the action menu select New Edge Subscription 
    10. In the wizard define the site and xml file to be used as shown below
     











    Once the edge subscription has been performed you can try a test. Try the following:

    [PS] Test-EdgeSynchronization

    And then try the following to start the synchronization process

    [PS] Start-EdgeSynchronization

    Another point to consider is to make sure that the "EdgeSync - Inbound to Default-First-Site-Name" send connector is configured correctly. The connector is shown below:








      On the connectors properties, select the network tab as shown


















      You should define the IP address of the Hub Transport server as the smart host. Without it mail will go out successfully to the Internet but you will not receive it.







        Monday 7 June 2010

        Internal Mail Routing

        Mail is 'moved' by transport servers. Hub transport servers move email throughout the intranet and to other sites that belong to the organization. Edge transport servers send mail to the Internet.

        Exchange uses the organizations Active Directory infrastructure to route mail between sites. For every site that a mailbox server role resides, you must have a hub transport server. The mailbox server role sends and receives all mail to and from a hub transport server in the same site. All mail that enters and leaves your organization must pass through the hub transport server.

        Transport servers use connectors to shift mail. During installation default recieve and send connectors are created which allow messages to flow throughout the organization.They are good to go! No extra configuration is needed. Messages will be sent from one hub transport (in your site) to other hub transport servers in other sites where a mailbox server holds the recipients mailbox.

        As explained, internal mail flow works with no extra configuration. The AD site infrastructure is held in the forests configuration partition (which is replicated to all DCs forest wide). It is this site infrastructure which is used to route mail. Active directory sites represent areas of well connected, high speed LANs. Sites are connected by intersite link objects. This class of object allows AD replication to occur every 3 hours by default. These can be assigned cost values which dictate preference of use. In the diagram NewYork can connect to Tokyo by first connecting to London or by connecting to Paris.
        Active directory sites represent areas of well connected, high speed LANs. Sites are connected by intersite link objects. This class of object allows AD replication to occur every 3 hours by default. These can be assigned cost values which dictate preference of use.

        In the diagram NewYork can connect to Tokyo by first connecting to London or by connecting to Paris. The total cost of the route is the sum of all the site link costs along the way. The route via London has a total cost of 20. Via Paris the total cost is 25. Messages from NewYork would be sent via London to recipients in Tokyo. AD administrators therefore define the message path since Exchange routing 'rides on the back ' of AD replication topology. This may be fine for your organization. However, Exchange administrators can take control of the situation and assign special 'Exchange costs' that override the normal AD site link costs. Note that Exchange administrators do not need any AD permissions for this. If Exchange costs of 5 are assigned to the site links that connect NewYork to Paris and Paris to Tokyo then messages from NewYork to Tokyo would now pass through London instead of Paris. AD replication would still travel via Paris. Exchange site link costs can be set by using the following cmdlet:

        [PS] Set-ADSiteLink NewYork -ExchangeCost 5

        To remove the site link cost set the -ExchangeCost value to $null
        Consider the following scenario:
        Messages are sent along the path that has the lowest accumulative cost (in this case NewYork - Paris - Dubai - Tokyo for messages sent from NewYork to Tokyo). You should remember that NewYork would try to contact Tokyo directly. What I mean is Exchange to Exchange communication. The NewYork exchange server would first attempt to send messages to the Tokyo exchange server first and would use the NewYork - Paris - Dubai - Tokyo routing path to get there. If it cant make this direct communication NewYork would attempt to contact the closest exchange server according to the routing topology. This would be Dubai. As you can see, messages do not relay to hub transports on route to the final destination server but backoff to a server in a site which is along the routing path. Messages are queued here in a retry state. This is called queue point of failure.
        Another consideration is bifurcation. A message sent from someone in NewYork to multiple recipients in different sites would be sent by the NewYork server to a server where a fork in the routing path exists. The bifurcated message is therefore relayed to an Exchange server in a site that represents a fork in the individual recipients routing paths. This is called delayed fan-out.
        Direct server to server relay between NewYork and Tokyo will not occur if a hub site exits along the routing path. A hub site is a AD site that messages would be sent to along the least cost routing path. What I mean here is all messages. Perhaps you require messages to be relayed to hub transport in a particular site first rather than the usual direct relay. However, the hub site designated must exist along the least cost routing path between source and destination.
        You can designate an AD site as a hub site by using the following cmdlet

        [PS] Set-ADSite Paris -HubSiteEnabled $true