Configuring SMTP Namespace Sharing between two Exchange Forests – Part 5

In our previous post we deployed the new Email Address Policy, generated a unified communication certificate and changed the Exchange URLs to reflect the new shared SMTP namespace. In Part 5, we will be dealing with the below points:

  • Handling Cross-Forest Autodiscover Queries
  • Publishing the new Exchange URLs on ISA\TMG

For the purpose of illustration, I will be using ISA to publish the new Exchange URLs. But conceptually, ISA is not much different from the way TMG works.

Handling Cross-Forest Autodiscover Queries

As we have already discussed in Part 4 of this series of posts, Exchange uses the Autodiscover Service to retrieve the Exchange URLs (like OWA, EWS, OAB, etc.). In a cross-forest environment where a single SMTP namespace is utilized for both the forests, the Mail Clients will query a single Autodiscover URL. In our example the Autodiscover  URL for the shared SMTP namespace DOMAINC.COM will be autodiscover.domainc.com.

It becomes a challenge to address this issue keeping in mind that the change should be transparent to the end users or mail clients. Luckily, Exchange comes to our rescue. By design, Autodiscover Service performs 4 iterative queries before it fails to retrieve the Exchange URLs. Success on any step, ends the process of Autodiscovery by returning the Exchange URLs retrieved by that step. This 4 step process provides us a possibility to configure the Autodiscovery Service of Exchange to work in cross-forest scenarios where a single SMTP namespace is used.

Thus regardless to the forest where the user belongs, the Autodiscover service will execute the following iterations to discover the Exchange URLs pertaining to an Exchange User.

STEP 1: It tries to query “https://domainc.com/Autodiscover/Autodiscover.xml/”. If it gets a response, it uses that information to get the Exchange URLs of the user. If no response is received or if an error occurs, it goes to STEP 2.

STEP 2: In Step 2, it tries to query the URL “https://autodiscover.domainc.com/Autodiscover/Autodiscover.xml/”. If a successful response is received, the Exchange URLs for the user will be retrieved. If no response is received or if an error occurs, it goes to STEP 3.

STEP 3: In Step 3, the Mail Client tries to query “http://autodiscover.domainc.com/Autodiscover/Autodiscover.xml/”. If it gets a response, it uses that information to get the Exchange URLs else it goes to STEP 4.

STEP 4: Step 4 is the final iteration which executes a query to DNS SRV record for _autodiscover._tcp.domainc.com. If it gets a response, it uses that information to get the Exchange URLs else it generates an Error.

External Mail Clients – Autodiscover Behaviour

As discussed in Part 2 of this Post series, we will be load-balancing the DNS name autodiscover.domainc.com using DNS Round-Robin on the external DNS (ISP DNS). Any Mail Client on the Internet that uses the Autodiscover service to retrieve the Exchange URLs, will contact the autodiscover.domainc.com as mentioned in STEP 2.

If the Host record autodiscover.domainc.com resolved by the Mail Client belongs to the forest where that user resides, autodiscover will successfully retrieve the Exchange URLs for that User and the Mail Client will be configured automatically. But if we consider the scenario where the user doesnot belong to the forest where the autodiscover.domainc.com has pointed the Mail Client, then an error will occur. This error will invoke the Autodiscover service to try STEP 3.

I recommend to configure STEP 3 for Mail Clients who access from the Internet. Basically this configuration needs to be done on the Publishing Server on which you are publishing the Exchange Web Services. So for STEP 3, we will be dealing with two possibilities.

Domain A User lands up in Domain B ISA: In this case, we will configure an HTTP Redirection on the Publishing Server that denies the traffic coming to “http://autodiscover.domainc.com/autodiscover/autodiscover.xml” and then redirects the traffic to the unique Exchange URL of the remote Domain A “https://webmail.domainc.com/autodiscover/autodiscover.xml”. When the traffic is received to Domain A, it will successfully resolve the recipient and the Exchange URLs will be provided for the Domain A User.

Domain B User lands up in Domain A ISA: In this case, we will configure an HTTP Redirection on the Publishing Server that denies the traffic coming to “http://autodiscover.domainc.com/autodiscover/autodiscover.xml” and then redirects the traffic to the unique Exchange URL of the remote Domain B “https://mail.domainc.com/autodiscover/autodiscover.xml”. When the traffic is received to Domain B, it will successfully resolve the recipient and the Exchange URLs will be provided for the Domain B User.

At this point, the Autodiscover service will be able to retrieve any valid user from either of the two forests. The Publishing rules needed to achieve the above scenarios will be discussed later in the Post.

Internal Mail Clients – Autodiscover Behaviour

As discussed in Part 2 of this Post series, we will be creating a forward lookup zone for DOMAINC.COM in the Internal DNS and an A Record will be created in that zone pointing to the local Exchange Web Service URL. Any Internal Mail Client that uses the Autodiscover service to retrieve the Exchange URLs, will try to retrieve the Exchange URL as mentioned in STEP 2.

If the internal user belongs to that forest then then the autodiscover will successfully retrieve the Exchange URLs for that User and the Mail Client will be configured automatically. But if we consider the scenario where the internal user belongs to the remote forest then an error will occur. This error will invoke the Autodiscover service to try STEP 3.

In STEP 3, the Mail Clients will try to receive a response for  the HTTP request of “http:\\autodiscover.domainc.com\autodiscover\autodiscover.xml” made by the autodiscover service. If no website or redirection exists which responds to this request, an error will occur causing the Autodiscover service to initiate the last iteration.

For Internal Mail Clients trying to retrieve the Exchange URLs of the users in the remote Forest, I recommend to configure an SRV Record in the internal DNS as mentioned in STEP 4. This SRV Record will automatically forward all cross-forest autodiscover requests to the respective Exchange URL in the remote forest.

We need to create an SRV record in the DOMAINC.COM Forward Lookup Zone of the Internal DNS of each forest. The values of the SRV Record are as shown below:

To create an SRV Record, Right-Click on the Shared SMTP namespace zone and then select Other New Records. Once in the Resource Record Type screen, navigate to Service Location (SRV) and then click on Create Record.

In the Internal DNS Server of Domain A, the New Resource Record will have the below parameters.

Similarly in the Internal DNS Server of Domain B, the New Resource Record will have the below parameters.

Creation of the above SRV records will handle the internal cross-forest autodiscover queries.

Publishing the new Exchange URLs on ISA\TMG

We now have to publish the new Exchange URLs on ISA\TMG so that they can be accessed externally. I will not dive into the details of the Exchange URL Publishing on ISA as there are numerous articles or blogs on the internet that can help you in successfully publishing these URLs.

I will be explaining you the basics that you have to follow so that you can reference the same against your configuration to sort out any publishing issues that might arise.

To to able to publish the Exchange URLs in ISA/TMG, we have to first create two Web Listeners that receive traffic on the same IP Address. This ISA IP Address is mapped to the Public Hostname of the Exchange CAS. The two Listeners have to be created on each forest.

In our scenario, two Web Listeners will be created on the DOMAINA ISA Server with the below characteristics.

Similarly, another two Web Listeners will be created on the DOMAINB ISA Server with the below characteristics.

The respective Listeners on both forests are alike in configuration except for the fact that each will be having an External Listener IP Address that is unique to their forest and which is finally mapped to the unique Public Hostname of their respective Exchange CAS.

Once the Web Listeners are created in the ISA Server, they can be used to created Mail Publishing Rules for the new Exchange URLs.

We have to create 4 Rules for Exchange URL Publishing and 1 Rule has to be created for handling the Cross-Forest Autodiscover requests as discussed in the beginning of the Post.

In total, the ISA Servers in each domain will have the following 5 new publishing rules to handle the shared SMTP namespace

  1. HTTP Redirect Rule
  2. Autodiscover Publishing Rule
  3. EWS & OAB Publishing Rule
  4. Outlook Anywhere and ActiveSync Publishing Rule
  5. Outlook Web Access Publishing Rule

These rules will be placed in the ISA in the same priority as mentioned above. Except for the HTTP redirect rule, all the other publishing rules will use the HTTPS Web Listener. The HTTP Redirect Rule for Autodiscover will be configured to use HTTP Web Listener.

The Autodiscover  HTTP Redirect Rule should be at the highest priority among all other rules of Exchange on ISA. This rule will handle the autodiscover traffic that is destined for the remote domain and cannot be resolved locally. The HTTP Redirect Rule will Deny traffic coming to the HTTP Autodiscover URL and redirect the traffic to the correct remote domain Autodiscover URL. The HTTP Autodiscover Redirect Rule in the ISA Server of DOMAINA will be configured to redirect the traffic to the Autodiscover URL of Domain B.

The Autodiscover Publishing Rule is used to publish the Autodiscover URL and handle the redirected Autodiscover traffic from the remote domain.

The EWS and OAB Publishing Rule handle the EWS and OAB URLs of Exchange.

The Outlook Anywhere and ActiveSync Publishing rule is configured to handle the Outlook Anywhere traffic and the ActiveSync URLs.

The OWA publishing rule is used to publish and handle the OWA traffic.

Similar rules have to be created in the remote domain ISA Server. The only difference being in the change of the Exchange hostname.  Also note that the HTTP Redirect rule of Domain B will redirect the Autodiscover traffic to the Domain A autodiscover URL “https:\\webmail.domainc.com\autodiscover\autodiscover.xml”.

Use the above tables as a means to verify your existing configuration. Note that in this scenario we have no downtime as users can still access their old Exchange URLs published using ISA.

Summary

In this post we have covered the publishing of the new Exchange URLs so that they can be accessible over the internet. We also discussed about autodiscover issues that arise after implementing shared SMTP Namespace and how to address these issues. Going forward in this series, we will be implementing a unified Address Book and Availability sharing across the organizations that share the SMTP namespace.

Click on the below link to access the different series parts:
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 1
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 2 Configuring SMTP Namespace Sharing between two Exchange Forests – Part 3 Configuring SMTP Namespace Sharing between two Exchange Forests – Part 4 Configuring SMTP Namespace Sharing between two Exchange Forests – Part 6 (Not Live)
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 7 (Not Live)

Advertisements

4 responses to “Configuring SMTP Namespace Sharing between two Exchange Forests – Part 5

  1. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 1 | Ibrahim Nore's Blog

  2. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 2 | Ibrahim Nore's Blog

  3. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 4 | Ibrahim Nore's Blog

  4. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 3 | Ibrahim Nore's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s