In Part 4 of this series we will be going through the below three tasks:
- Creating Email Address Policy for Shared Namespace
- Procuring & Installing Unified Communications Certificate
- Configuring new Exchange URLs in both Domains
At the end of this post, we will have users in both the Forests exchanging emails based on their new primary email address. Internally the mail clients will be configured to communicate over the shared SMTP namespace. The External Client access and Cross-forest Client access will be discussed in the forthcoming posts related to this series.
Creating Email Address Policy for Shared Namespace
As we have already established the Mail Routing between two domains, its time for us to enable the users to accept email communication on the shared SMTP namespace. For a recipient to send or receive e-mail on the shared SMTP domain, the recipient must have an e-mail address belonging to the shared SMTP namespace. The E-mail Address Policy is created to generate Email address belonging to the shared SMTP namespace (Email Domain) for the target recipient(s).
While in the Exchange Management console, navigate to the Hub Transport role under the Organization Configuration. From the Actions pane, click on New Email Address Policy to create a new Email Address Policy. This will invoke the New E-Mail Address Policy wizard.
On the Introduction screen of New E-Mail Address Policy wizard in the Name field enter any descriptive name for the new Email Address Policy that you will be creating. Under Include these recipient types, select The following recipient types and choose Users with Exchange mailboxes. Depending on your needs, you could also choose Mail-enabled groups to include the mail enabled groups in Exchange to get the new Email Address. Click on Next to continue with the configuration.
On the Conditions screen of New E-Mail Address Policy wizard do not select any conditions to filter the recipients. You can click on Preview to see the list of the recipients to which the new email address policy will be applied. Click on Next to continue with the configuration.
On the E-Mail Addresses screen of New E-Mail Address Policy wizard, click on Add to create an SMTP Email address format. This will prompt you for a new window for creating the SMTP Email address that will be included in the email address policy.
On the SMTP E-mail Address window that appears, We will be choosing Use alias to derive the email addresses based on Alias.You can alternatively choose the standard that you follow for creating SMTP Email Address. Next choose the option to Select accepted domain for Email address. Click on Browse and then select the shared SMTP namespace DOMAINC.COM which we had previously created as an Accepted Domain (Refer Post 3). Click on OK to complete the SMTP Email Address format creation. Note that it is vital to have the shared SMTP namespace added in our Accpeted Domain to proceed in this step.
Verify the new SMTP Email Address format that you just created. If you wish to modify the format, select the format and then click on Edit. Click on Next to continue with the configuration. Alternatively you can also add the SMTP email address format for the current domain and control the primary address by making sure that the shared SMTP namespace is selected as the Set as Reply in the Email Addresses section of the policy. To ensure that the recipients get the new Email Address policy, you must make sure that the Automatically update e-mail addresses based on recipient policy checkbox is selected in the Email Addresses tab of the Recipients.
On the Schedule screen of New E-Mail Address Policy wizard, specify the schedule when you wish to apply this email address policy to the Exchange recipients. We will leave it to the default option of applying the policy Immediately. Click on Next to continue with the configuration.
On the Configuration Summary screen of New E-Mail Address Policy wizard, verify the selections that you have made to configure the new email address policy. You can modify the email address policy. Once finalized, click on New to create and apply the policy based on the schedule selected.
On the Completion screen of New E-Mail Address Policy wizard, ensure the successful completion of all the tasks and then click on Finish to exit the wizard.
Once the new email address policy is created and applied to all the recipients in the domain, users can start sending and receiving email on the new SMTP namespace.
Procuring & Installing Unified Communications Certificate
Exchange primarily uses certificates for securing client connectivity and mail routing. As a result of unifying two Exchange organizations over a single primary SMTP address, we will also be required to decide on the new host names that will be accessible by the two organizations over the internet. The new host names will be registered under the shared smtp domain name.
Note that in shared SMTP namespace scenario, we should have a unique Exchange URL by which that the organization will be identified on the internet. If we are sharing two Exchange organizations then we will require two unique Exchange URLs. In our scenario, we will be registering the Exchange URL webmail.domainc.com for DOMAINA.LOCAL and the Exchange URL mail.domainc.com for DOMAINB.LOCAL. The Autodiscover URL autodiscover.domainc.com will be shared across both the organizations. Additionally we will also need to add the host names that will be used for receiving SMTP traffic (so as to enable TLS on SMTP traffic). If you do not require to secure SMTP traffic then you need to procure the certificate with only three SAN Names – two for the Exchange Web URLs and one for Autodiscover.
Before we request for a certificate from a Public Root CA, we need to finalize the host names that will be included in the certificate. Ideally we will need to include the Exchange URL, the Autodiscover URL and the SMTP URLs (Optional – only if needed).
Once decided on the host names, you need to the issue a unified communications (UC) certificate containing the the host names as Subject Alternative Names (SANs).
Creating a Certificate Request
Digicert has an excellent SSL certificate management tool which provides a very user-friendly GUI to create certificate requests. You can utilize this tool to generate certificate request file and later use the resultant request file to issue a public UC certificate from any CA vendor.
Open the Digicert Certificate Utility, and then click on Create CSR to create a certificate request file.
This will invoke the DigiCert Certificate Utility – Create CSR wizard. On the Certificate Details screen, supply all the details that are necessary to create a certificate request file. Once all the details are entered, click on Generate to create a certificate request file.
The contents of the certificate request are displayed in the resultant window. Click on Copy CSR to copy the certificate request contents to the Clipboard. Alternatively, you can click on Save to File to save the contents in a certificate request file so that it can be used later.
The Unified Communication (UC) public certificate can be issued from vendors like Digicert, Thawte, Symantec (formerly Verisign), etc. A complete list of all the public certificate authorities providing SAN certificates can be found here. Once the certificate has been issued, it has to be imported using the same Digicert utility.
Open the Digicert Certificate Utility, and then click on Import to import the public UC certificate. This import has to be executed on the same computer from which the request file was first generated as the private key of the certificate is stored on that computer. Importing public UC certificate will fail if the import is executed on the target computer where no relevant private key is found.
Once the certificate import is successful, the certificate will be listed in the Digicert Certificate Utility. Alternatively this certificate will also be found in Certificates snap-in of the Local Computer.
This public UC certificate has to be exported alongwith the private key. This UC certifcate can be imported to all the Exchange Servers and all the Publishing Servers (ISA/TMG) in both the domains. The public UC certificate has to be imported in the Certificates snap-in of the Local System.
After the public UC certificate is installed on all the Exchange Servers, we have to tell the Exchange infrastructure in both the domains to utilize this new Certificate. This configuration has to be done on the Client Access Servers/Hub Servers.
We first need to retrieve the Thumbprint value of the Exchange Public UC Certificate that has been installed on the Exchange servers. This can be done from the Exchange Management shell by executing the below command.
Get-ExchangeCertificate -DomainName <<commonnameofnewpublicuccertificate>>
Once the Thumbprint value has been retrieved, use the thubprint value to execute the below command. This will enable the public UC certificate for the Exchange services that we mention in the command.
Enable-ExchangeCertificate -Thumbprint <<Thumbprint_Value_of_Public_UC_Certificate>> -Services IIS, SMTP, IMAP, POP
The above steps have to be executed on all the Exchange Client/Hub Servers across the two domains. Once the new certificate is enabled on the Exchange of each domain, we can configure the new Exchange URLs that will be utilised under the unified SMTP namespace. Note that though the Exchange URL of every domain is unique, we will be issuing a single certificate across the two domains. This activity will avoid certificate issues in future.
Configuring new Exchange URLs in both Domains
Now as the public UC certificate has been enabled for Exchange, we have to reconfigure the Exchange Client Access virtual directories in each domain to reflect the new Exchange URL. We will be using two host names – first one for Autodiscover and second one for other services such as the Availability service, IMAP, POP3, OOF and OAB. We will be utilizing a single Autodiscover URL across the two domains (autodiscover.domainc.com). The other services will utilize a unique URL for each domain – we will be utilizing webmail.domainc.com for Domain A and mail.domainc.com will be utilized for Domain B. This is to facilitate smooth access of these services from internet.
Autodiscover Autodiscover Service is used by the Mail Clients to automatically retrieve other Exchange Web Services URLs. Incorrectly configuring this URL might result in Certificate warnings and frequent password prompts. The Autodiscover URL configuration has to be modified to allow the autodiscover requests on the shared SMTP namespace. To modify the Autodiscover URL in the Exchange infrastructure navigate to the Exchange Management shell of any Exchange Server and execute the following command. This command will update the URLs of every Client Access Server in the forest.
Get-ClientAccessSerever | Set-ClientAccessServer -AutodiscoverServiceInternalUri “https://autodiscover.domainc.com/autodiscover/autodiscover.xml”
It is very important that the same command be executed on the client access server of the remote forest as well.
Note that both the forests will have identical autodiscover configuration. For mail clients on the internet (external clients not connected to either forests), the Public DNS Servers situated on the internet will forward autodiscover requests to any of the forests based on the name resolution response. If a remote forest request is received then it will be redirected to the appropriate forest. This will be discussed further in next part (Part 5) of this series.
For Cross-Forest requests made from within any forest, extra configuration needs to be done to resolve the autodiscover. We will discuss this in detail in the Part 6 of this series.
Outlook Web Access (OWA)
Outlook Web Access provides a Web based way for Exchange users to read and manage the contents of their Mailboxes. To configure Autodiscover service to return the URLs for OWA, navigate to the Exchange Management Shell of any Exchange Server in Forest A and execute the following two commands
Set-OwaVirtualDirectory -Identity “DOMAINACAS1\Owa (Default Web Site)” -InternalUrl “https://webmail.domainc.com/OWA” -ExternalUrl “https://webmail.domainc.com/OWA”
Set-OwaVirtualDirectory -Identity “DOMAINACAS2\Owa (Default Web Site)” -InternalUrl “https://webmail.domainc.com/OWA” -ExternalUrl “https://webmail.domainc.com/OWA”
Similarly you have to configure the URLs for OWA in Forest B by executing the following two commands
Exchange Web Services (EWS)
The Exchange Web Service URL is needed for Availability and OOF services to function.
Navigate to the Exchange Management shell of any Exchange Server belonging to Domain A and execute the following commnand. This command will configure the EWS Exchange URL on all the Client Access Servers of Domain A.
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl “https://webmail.domainc.com/EWS/Exchange.asmx” -ExternalUrl “https://webmail.domainc.com/EWS/Exchange.asmx”
Similarly from the Exchange Management shell of any Exchange Server belonging to Domain B execute the following commnand. This command will configure the EWS Exchange URL on all the Client Access Servers of Domain B.
Offline Address Book (OAB)
The Offline Address Book URL is referenced by Clients to download the OAB.
Navigate to the Exchange Management shell of any Exchange Server belonging to Domain A and execute the following commnand. This command will configure the OAB Exchange URL on all the Client Access Servers of Domain A.
Similarly from the Exchange Management shell of any Exchange Server belonging to Domain B execute the following commnand. This command will configure the OAB Exchange URL on all the Client Access Servers of Domain B.
The Unified Messaging component of Exchange can also be configured to automatically retrieve the Exchange Server settings using the Autodiscover service. To configure Autodiscover service URLs for Unified Messaging, navigate to the Exchange Management Shell of any Exchange Server in Forest A and execute the following command
Get-UMVirtualDirectory | Set-UMVirtualDirectory -InternalUrl “https://webmail.domainc.com/UnifiedMessaging/Service.asmx” -ExternalUrl “https://webmail.domainc.com/UnifiedMessaging/Service.asmx”
Similarly to complete the Unified Messaging configuration in Forest B, execute the following command
Get-UMVirtualDirectory | Set-UMVirtualDirectory -InternalUrl “https://mail.domainc.com/UnifiedMessaging/Service.asmx” -ExternalUrl “https://mail.domainc.com/UnifiedMessaging/Service.asmx”
The above two commands will change the Microsoft Unified Messaging URLs of every Client Access Server in their respective forest.
Mobile Phones supporting Microsoft ActiveSync can be configured to automatically retrieve the Exchange Server settings using the Autodiscover service. To configure Autodiscover service URLs for Microsoft ActiveSync, navigate to the Exchange Management Shell of any Exchange Server in Forest A and execute the following command
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl “https://webmail.domainc.com/Microsoft-Server-ActiveSync” -ExternalUrl “https://webmail.domainc.com/Microsoft-Server-ActiveSync”
Similarly to configure Autodiscover service URLs for Microsoft ActiveSync, navigate to the Exchange Management Shell of any Exchange Server in Forest B and execute the following command
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl “https://mail.domainc.com/Microsoft-Server-ActiveSync” -ExternalUrl “https://mail.domainc.com/Microsoft-Server-ActiveSync”
The above two commands will change the Microsoft Activesync URLs of every Client Access Server in their respective forest.
At the end of this post we have successfully configured an email address policy which will enable the users to send and receive emails using the shared SMTP namespace. We have also procured a new Exchange certificate from a Public CA and installed the certificate on the Exchange Servers and the Publishing Servers. Finally, we changed the URLs of Exchange in each domain to reflect the new URLs.
In the Posts ahead we will be uncovering the special publishing requirements of the accessing a shared SMTP namespace over the internet. We will also address issues that come into picture after deploying cross-forest autodiscover service in the forthcoming post.
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 5
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 6 (Not Live)
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 7 (Not Live)