This is something I’ve been meaning to write down for a while. I wrote an answer for this question to LinkedIn about a week ago and I’ve just emailed a MCM Exchange consultant with this – so here we go…
If you configure a Send Connector (Exchange 2007 and 2010) or Exchange 2003 SMTP Connector with multiple smarthosts for delivery to, then Exchange will round-robin across them all equally. This gives high availability, as if a smarthost is unavailable then Exchange will pick the next one and mail will get delivered, but it does not give redundancy across sites. If you add a smarthost in a remote site to the send connector Exchange will use it in turn equally.
So how can get get geographical redundancy with outbound smarthosts? Quite easily it appears, and it all uses a feature of Exchange that’s been around for a while. But first these important points:
- This works for smarthost delivery and not MX (i.e. DNS) delivery.
- This is only useful for companies with multiple sites, internet connections in these sites and smarthosts in those sites.
- This is typically done on your internet send connectors, the ones using the * address space.
You do this by creating a fake domain in DNS. Lets say smarthost.local and then creating A records in this zone for each SMTP smarthost (i.e. mail.oxford.smarthost.local). Then create an MX record for your first site (oxford.smarthost.local MX 10 mail.oxford.smarthost.local). Repeat for each site, where oxford is the site name of the first site in this example.
Then you create second MX records, lower priority, in any site but use the A record of a smarthost in a different site (oxford.smarthost.local MX 20 mail.cambridge.smarthost.local).
Then add oxford.smarthost.local as the target smarthost in the send connector. Exchange will look up the address in DNS as MX first, A record second, IP address last), so it will find the MX record and resolve the A records for the highest priority for the domain and then round-robin across these A records.
If you have more than one smarthost in a site, add more than one MX 10 record, one per smarthost. Exchange will round-robin across the 10’s. When all the 10’s are offline then Exchange will automatically route to mail.cambridge.smarthost.local (MX priority 20 for the oxford site) without needing to disable the connector and retry the queues.
If you used servernames and not MX’s then it would round-robin amongst all entries, and so equally sent email to Cambridge for delivery. The MX option keeps mail in site for delivery until it cannot and then sends it automatically to the failover site.
Updated Dec 8th 2011 to remove reference to LegacyExchangeDN
In Office 365 with Hybrid Deployment, if you create Dynamic Distribution Groups on the on-premises Exchange organization, these objects are not replicated to Office 365 via DirSync. Therefore for mailboxes in the Office 365 cloud they will not see the Dynamic Distribution Group in their Global Address List, and so therefore can only email the members of the list by sending an email directly to their email address.
To show the Dynamic Distribution Group in the GAL in the cloud, you need to add a MailContact to the cloud that represents the Dynamic Distribution Group. This MailContact object should have the following mappings:
Note that this MailContact object is made in Office 365 or Exchange Online and not in the on-premises AD. It is not replicated to the cloud via DirSync. If it exists on premises then the name for the DDL will appear twice in the on-premise GAL, once as a DDL and once as a contact object.
To determine the information need for the cloud contact object, run the following in Exchange Management Shell on premises:
Get-DynamicDistributionGroup | fl Name,EmailAddresses,LegacyExchangeDN
An alternative is to create the DDL in both the cloud and on-premises, but this can only happen if the attributes you are filtering on on-premises are replicated to the cloud via DirSync.
When you add additional servers to an ADFS 2.0 farm and you have used a subject alternative name from your certificate to create the first server in the farm the additional servers will not be able to join the farm. If you have used the subject name on the certificate all works fine.
You get the following error message:
The Subject name of the SSL certificate for the Default Web Site on this computer should match the name of the Federation Service to which you are trying to join this computer.
You also get the following error:
No certificates matching the Federation Service name were found in the Local Computer certificate store. Install the certificate that represents your Federation Service name in the Local Computer certificate store, and then try again.
The help file for ADFS 2.0 says “the actual name text is determined by either the Subject field or, if necessary, the Subject Alternative Name field of the certificate”, but the addition of additional servers does not work if you have used a Subject Alternative Name.
So how do you get around this. With thanks to Tim Heeney and Roberto Martinez Lima from Microsoft and the rest of the class on the inagural Office 365 Microsoft Certified Master class (a subset of the Exchange 2010 MCM program) we worked out the answer. You need to install the additional servers from the command line – the problem is a user interface bug in the ADFS 2.0 setup program.
FsConfig.exe JoinFarm /PrimaryComputerName ADFS-SRV-1 /ServiceAccount fabrikam\adfsservice /ServiceAccountPassword password /CertThumbprint “ef 72 a6 78 c0 ab 4a bf 07 10 7e e4 86 f5 5e ba 2a 3c 99 6b”
The thumbprint needs to be the thumbprint of the certificate used on the first ADFS server and imported into the computer certificate store on the additional ADFS servers.
On running the FsConfig command above you should get a series of green Passed statements. Existing databases can be removed with /CleanConfig switch. A yellow warning about an existing website can be ignored unless you have broken the website previously!