I recently realized that you really get what you pay for with free email services (Gmail, Yahoo, etc…). No unified contacts synchronization or calendar management. And POP/IMAP? Way too 1980’s. We have better technologies and protocols for these things now. Google realized this and they incorporated ActiveSync (Microsoft’s mobile synchronization protocol) into their Gmail service, but then ditched it late last year due to licensing costs (apparently it’s still available for paid accounts). Now if you want to sync your phone to Gmail, it is back to 30 year old technologies.
Enter Microsoft Exchange Server. Likely the most feature rich and popular messaging platform in existence. ActiveSync is already baked in and ready to use with the mobile device of your choice. And with Exchange 2007 or newer you get Autodiscover, which is a feature that allows your email client to find and connect to your email server given nothing more than an email address and a password (no more typing in server names, RPC proxies, msstd:WTF).
Due to the high licensing price of Exchange, it is almost exclusively a business messaging solution. There are a few providers that offer ~$10/month personal Exchange accounts, which was what I ended up using, at first. I purchased a personal Exchange account from 1and1.com along with a domain name (everything comes in these confusing bundles that don’t really allow much flexibility) and I was on my way. Started setting up my first email client: put in my email address and password….no dice. Ran an Autodiscover test from my PC and it turns out that they do not offer the Autodiscover service. All fields must be filled in manually (they also offer a small app that you can download and use to configure your Outlook client).
The breaking point came when I was preparing a proposal to a small business customer of mine to sign them up for this 1and1 service. “Why sign them up to pay this provider $10/month/mailbox when I can create a superior service and offer it to my customer at the same price”. And so the project began…
The Specs:
Hosting domain: provider.com
Tenant domain: tenant.com
Platform: Windows Server 2008 R2 Standard
Exchange Version: Exchange Server 2010 Standard with SP1
Exchange Installed Roles: Client Access, Hub Transport, and Mailbox
Domain Controller FQDN: DC01.PROVIDER.COM
Domain Controller IP Address: 10.161.1.20
Exchange Server FQDN: EX01.PROVIDER.COM
Exchange Server Primary IP Address: 10.161.1.21
Exchange Server Secondary IP Address: 10.161.1.23
Hosting Organization Name: HostingCompany
Tenant Organization Name: TenantCompany
The first step is to stand up your hosting domain controller and Exchange server. For the purposes of this lab, we are using provider.com with NETBIOS name “PROVIDER”. If you need instructions on installing Windows Server, promoting it to a domain controller, and joining a member server, then you are probably not ready for this lab.
Once you have a DC built and a member server joined. We need to prep the member server and install Exchange.
First, we need to install the Exchange 2010 Prerequisites. Since we will be installing all roles onto the same server, we will need quite a few PreReqs.
Install the Prerequisites
1> Install Office 2010 Filter Packs (Link Here)
2> Install Roles for Exchange 2010
This is most easily done via Powershell. If you don’t like Powershell, too bad, Exchange 2010 in “Hosted” mode is PowerShell only
The server will now install the necessary roles and then restart itself
3> Install the TCP Port Sharing Service
Now restart your Exchange box and take a snapshot (if you were bright enough to run your server as a VM)
Install Exchange 2010
Here we install Exchange with the “/hosting” switch. You will need select a name for the parent organization. I use “HostingCompany” in the example. Open up an elevated command prompt (not PowerShell), navigate to the directory of your Exchange setup files, and run:
Once the install finishes, reboot the machine to complete the installation
Certificate Request and Installation
Next, you will need to generate a Certificate Signing Request (CSR) that you will submit to your SSL provider to sign. To properly use Exchange, you will need to be issued a Unified Communications (UC) certificate. A UC cert has Subject Alternative Names (SANs) included that allow you to secure and verify multiple domain names. In this case, you will need 3 SANs on your cert(EX01.PROVIDER.COM, AUTODISCOVER.PROVIDER.COM, and MAIL.PROVIDER.COM).
Digicert offers a great tool you can use to generate your script here. I’d also recommend purchasing your UC certificate through them. Here is an example CSR script that uses my best practice common name and SANs:
This will dump a CSR .txt file onto your current PowerShell working directory. Use the text in that .txt to submit your CSR.
Once your issuer has returned a signed certificate to you, you will need to install it and assign Exchange services to it. Download the certificate file onto the Exchange box and navigate your PowerShell session to the directory containing your certificate. Then run:
This should import the certificate into IIS and assign the necessary services to it. Now we’re ready to move on to Hub Transport tasks.
Hub Transport Connectors
The Exchange 2010 Hub Transport role comes with little to no pre-configured ability to communicate with the outside world. In order to allow SMTP messages to flow inbound and outbound from our server, we need to configure send and receive connectors.
This will configure a basic internet send connector with no authentication required
This will configure a basic internet receive connector with no authentication required. It will bind the connector to the primary 10.161.1.21 IP address on port 25 and will be used to receive SMTP messages from all IPv4 addresses.
Now you should be ready to send and recieve mail on your primary IP
Enable Client Access Features
Now it’s time to enable some of those client access features that make Exchange such a great messaging platform!
Outlook Anywhere (A.K.A RPC Proxy in Exchange 2003) allows Outlook to connect to Exchange through a HTTPS tunnel on port 443.
Once this command completes, Exchange will take approx 15 minutes to fully enable Outlook Anywhere. Once it is done, it will generate a message in the application log.
Now we need to set our internal and external ActiveSync URLs that will be handed out during an Autodiscover transaction with a mail client
Our Client Access features are now ready to roll. On to the fun part: HTTP redirectors.
HTTP Redirection Pools
The tricky part of multi-tenancy Exchange is getting mail clients with different mail domains to properly redirect to your mail server with as little interaction from the user as possible. The biggest obstacle in this process is SSL common names and SANs. When a mail client uses the autodiscover service to find its mail server, it uses the domain name of the email address.
For example, if a user types in “user@tenant.com” as his email address when setting up his email client, the client will first check https://autodiscover.tenant.com for an autodiscover service. The client will also validate the certificate it recieves from that site against the site name. This is a problem as we don’t want to add a SAN to our certificate for every tenant on this Exchange server.
Luckily, the second step taken by the Autodiscover process on the client (in the event the first step fails) is to check the unsecured site http://autodiscover.tenant.com for the autodiscover service. At this point, we will want to send a HTTP redirect to the client to redirect them to our provider Autodiscover site https://autodiscover.provider.com (for which we have a valid certificate).
We will also want to setup, in the same way, a webmail redirection site that will redirect “http://webmail.tenant.com” to “https://webmail.provider.com/owa”.
The easiest way to set up these redirection pools is to create two new websites in IIS and bind them to the secondary IP of the Exchange server. You will need to set host header values on those bindings for things like “autodiscover.tenant.com” and “webmail.tenant.com”. Also remember to setup the redirection on the websites.
You will then need to setup your own public DNS names for your mail server and redirect sites. Below is how I would recommend setting them up.
A RECORD: EX01.PROVIDER.COM points to your primary Exchange IP
A RECORD: MAIL.PROVIDER.COM points to your primary Exchange IP
A RECORD: AUTODISCOVER.PROVIDER.COM points to your primary Exchange IP
A RECORD: AUTODISCOVERREDIRECT.PROVIDER.COM points to your secondary Exchange IP
A RECORD: WEBMAILREDIRECT.PROVIDER.COM points to your secondary Exchange IP
And that’s it! Now we’re ready to enroll a tenant!
Tenant Creation and Configuration
1> The first step in the creation of a tenant is to create the Exchange organization and a mailbox. In this example, we will the organization “TenantCompany” with the new user “John Smith”.
This command will take a few minutes to complete, as the entire organization structure must be built in AD. Also, you will be prompted for credentials for the Admin user for the organization.
Now we create the new Mailbox in the new Organization:
Once this completes, you may want to log in as that user in OWA to make sure the mailbox is working properly
2> The second step in setting up the tenant is to bind their hostnames to your redirection websites. You will want to bind “autodiscover.tenant.com” to your autodiscover redirect site and “webmail.tenant.com” to your webmail redirection site.
3> The last step in setting up the tenant is to have them set the correct public DNS names for their domain to point to your mail server and redirect sites. I would recommend having them use CNAME DNS records rather than A records as it will allow you to change your public IPs without requiring them to change anything. You will want them to set up the below records:
CNAME RECORD: AUTODISCOVER.TENANT.COM points to AUTODISCOVERREDIRECT.PROVIDER.COM
CNAME RECORD: WEBMAIL.TENANT.COM points to WEBMAILREDIRECT.PROVIDER.COM
MX RECORD: “@” MX record for TENANT.COM points to MAIL.PROVIDER.COM
For testing the autodiscover functionality for your new tenant, I would recommend either Microsoft’s TestExchangeConnectivity site or this utility from a TechNet blog by Kip Ng on this same topic.
And that’s it! You’ve successfully set up your own Exchange email service provider!
Be the first to comment on "Exchange 2010 Multi-Tenancy"