This week, I had a pretty strange request. An organization wanted to host multiple Email domains in their Exchange environment while keeping it hidden from external mail users and outside parties. Same organization was ok, same AD and Exchange servers were not.
The mail flow portion was pretty simple. Added a new accepted domain to Exchange 2007, to the spam filter appliance, configure LDAP for this new SMTP domain, and change the primary email address for certain users. I used an email policy that assigned the primary SMTP address based an AD attribute. This requires the attribute to be populated during user creation. I also changed the default email policy to not affect these users. Created separate GALs in exchange so there was no crossover between the 2 user bases.
Publishing the OWA URLs however and login process was not quite so easy.
My first step was to get my UC certificate reissued with the new subject alternative names for the new email domain. Since same organization was ok, it was ok for me to use the same certificate with the original SANs listed on it. You have to create a new certificate request on your Exchange 2007 server and resubmit to your CA. Once this is done, import and enable this new certificate on all exchange servers. Then export the certificate and bring it over to the ISA 2006 server.
I created a new OWA publishing rule for my new domain and a redirect rule below it. This however didn’t work straight off. It seems unless the traffic between ISA and your Exchange CAS uses the same FQDN as the common name of the certificate, the CAS will not respond. I got around this by using a different internal name on the second domain rule with the true public FQDN for the first domain name. ie..
First Domain Rule:
 |
Second Domain Rule:
 |
My ISA server has host file resolution that resolves both real FQDNs to the internal IP address of the CAS server. Since I have it configured that Request appear to come from the ISA server computer, the CAS server doesn’t know which rule its responding to and answers to the same URL in both instances. However the users sees the Public URL of either mail.firstdomain.com or mail.seconddomain.com depending on which they used to get there.
This solved ISA and OWA answering to different public URLs. Now I had to change the login process so that users no longer had to type Domain\Username. Email address was the obvious choice as the suffix is different for the 2 domains and wouldn’t appear to have any crossover.
To accomplish this first I had to create 2 new Alternate UPNs in the Active Directory. I added each email domain suffix. I then changed my LDAP authentication login expressions in ISA and remove the domain\* entry and put in both *@firstdomain.com
and *@seconddomain.com
No change was needed on the Exchange CAS as it was already set to Basic Authentication and not Forms Based. This change forced users to login using only their email address (newly created UPN) as their username.
Now the OWA Forms Based Authentication in ISA needed to be changed to ask for email address instead of domain\username. This is accomplished by editing the strings.txt file located at:
C:\Program Files\Microsoft ISA Server\CookieAuthTemplates\Exchange\HTML\nls\en
I replaced the domain\username with email address then restarted the Microsoft Firewall service. The result:
As you can see, no more evidence.
Recently while performing the initial steps for an Exchange 2003 to 2007 migration, I ran into one of the more frustrating issues with Exchange 2003 to 2007 transitions. Broken inter-organization mail flow. After banging my head against the wall for a few hours, and sending enough test emails to get added to who knows how many OBLs, I finally stumbled on the answer.
Exchange 2007 could talk to the 2003 environment as well as route mail outbound to the Internet, however all 03 to 07 mail was getting jammed in the queues. The customer was running Exchange 2003 in an Active-Passive cluster configuration and had problems previously with their Default SMTP Virtual Server. Their resolution was to disable it and create a new SMTP VS Instance as a cluster resource.
When you install Exchange 2007, by default it creates two routing group connectors and binds them to the SMTP VS instance with the index of 1 on the Exchange 2003 side. In this case the disabled Default VS Instance. Luckily this client had a front end 03 server with it’s own Default VS Instance. I was able to restore mail flow by removing the Routing Group Connectors that 07 put in by default using Power Shell, then create new ones that attached to the front end server rather than the mailbox cluster. This also allowed for me to list multiple Hub Transport servers in my connector rather than just the first one installed in the organization. By listing multiple HT servers, redundancy is achieved during the migration period.
To remove the connectors:
How to Remove Routing Group Connectors in Exchange 2007
To create the new ones:
How to Create Routing Group Connectors from Exchange 2007 to Exchange Server 2003