HTTP Proxy TargetBackEnd limits

powershellLast Update: February 4th, 2016

When deploying Exchange 2013 or Exchange 2016 in co-existence with a legacy version of Exchange, there comes a point where all traffic is routed through Exchange 2013/2016. Traffic for mailboxes hosted on legacy Exchange versions will be proxied by Exchange 2013/2016 to the back end.

This proxy process has some built-in limits for certain protocols, which you could encounter. Symptoms of these limits are Event 2022’s being logged in the Application log by the MSExchange Front End HTTP Proxy service:


Per Exchange 2013 CU7, this message should be considered a notice, despite the confusing event description. No connections are being blocked. However, the events create noise in your logs, which can be prevented by raising these limits. To accomplish this, you need to dive in to the web.config of the applicable HTTP Proxy protocols:

  • $ExInstall\FrontEnd\HttpProxy\sync\web.config (for ActiveSync, EAS)
  • $ExInstall\FrontEnd\HttpProxy\rpc\web.config (for OA, RPC/http)

In those files, create or adjust the entry in the <appsettings> configuration node, where <value> is the limit you want to configure (default is 150):

<add key=”HttpProxy.ConcurrencyGuards.TargetBackendLimit” value=”<value>” />

After adjusting these values, recycle the relevant application pools, e.g. MSExchangeSyncAppPool and MSExchangeRPCProxyAppPool.

The above steps need to be performed on all Exchange 2013/2016 Client Access Servers.

To automate this process of tedious editing in web.config files, I have created a small script which lets you alter these values for EAS and RPC against the local server or remotely. The script, Configure-HTTPProxyTargetBackEnd.ps1, has the following parameters:

  • Server to specify server to configure. When omitted, will configure local server.
  • AllServers to process all discoverable Exchange Client Access servers
  • TargetBackEnd specifies Target Backend limit (default 150).
  • NoRecycle to prevent recycling the MSExchangeSyncAppPool and MSExchangeRPCProxyAppPool

For example, to configure the local server with a limit of 2000 for Exchange Active-Sync and RPC access, use:

.\Configure-HTTPProxyTargetBackEnd.ps1 -TargetBackEnd 2000


Note that the script will create a backup copy of the web.config files before editing, using the current timestamp.

You can download the script from the TechNet Gallery here.

Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

See TechNet Gallery page.


Ex2013 LogoMicrosoft published three sessions from the Redmond Interoperability Protocols Plugfest 2013 on Channel 9 on the protocol MAPI over HTTP or MAPI/HTTP which looks scheduled to arrive with Exchange 2013 Service Pack 1.

This protocol is set to (over time!) replace the RPC/HTTP protocol we all know. RPC/HTTP, or Outlook Anywhere, is used by Outlook to communicate with Exchange Server and is most often seen with clients working remotely. With Exchange Server 2013, support for MAPI was dropped and RPC/HTTP became the only protocol. With Exchange 2013 SP1 it seems we will receive an alternative which is set to replace RPC/HTTTP, MAPI/HTTP.

Of course, the information is preliminary and subject to change as Exchange 2013 SP1 hasn’t been released yet, but it won’t harm to get familiar with the planned changes. It also remains to be seen how quick organizations will adopt this new protocol, which I’m pretty sure we will soon see getting supported by Office 365.

MapiHttp in Exchange 2013 SP1
Joe Warren, Principal SDE at Microsoft delivering a presentation covering the Exchange 2013 MapiHttp protocol implementation in Exchange 2013 SP1. Topics: What is MAPI-HTTP?, Why do MAPI-HTTP?, Goal of MAPI-HTTP, Why not rebuild with EWS?, Existing RPC-HTTP, New MAPI-HTTP, What does a MAPI-HTTP request look like?, What does a MAPI-HTTP response look like?, Session Context, Request Types, Sequencing & Protocol Failures. Click here.

Outlook 2013 Client Protocols
Shri Vidhya Alagesan, SDE at Microsoft presenting on Outlook 2013 Client Protocols from a client’s perspective. Topics: Client side view of Outlook-Exchange MAPI-HTTP protocol using WinHTTP, Error Handling & RPC Vs. MAPI-HTTP with sub-topics of Architecture Overview, Outlook & WinHttp, Cookies, Connection Status Dialog, Timeout, Pause/Resume & Protocol Switching. Click here.

Exchange 2013 Protocols
Andrew Davidoff, Senior Software Developer Engineer in Test at Microsoft presenting on the Exchange 2013 protocol families and important protocol updates for Exchange 2013. Click here.

Apart from these sessions on protocol change announced for Exchange Server 2013 SP1, Microsoft also published some other interesting Exchange-related sessions:

Exchange 2013 Web Services Overview
Harvey Rook, Principal Development Lead, and Naveen Chand, Senior Program Manager Lead, deliver a presentation on Exchange Web Services best practices. Click here.

Exchange RPC and EWS Protocol Test Suites
Jigar Mehta, Software Development Engineer in Test provides an in depth overview of the test suite packages for the Exchange RPC and Exchange Web Services protocols. Click here.

The Attribute, the Myth, the legacyExchangeDN

Exchange 2010 LogoAfter some recent Exchange troubleshooting I decided to do a small write-up on an attribute most people working with Exchange know about, the infamous exchangeLegacyDN.

In the early days of Exchange, the NT world was flat. Exchange utilized its own hierarchical X.500 addressing scheme, and to uniquely identify objects it used an attribute called obj-Dist-Name (similar to distinguishedName nowadays). It contained a constructed value using elements like organization, containers and the canonical name to construct the entry, e.g. /o=Contoso/ou=EMEA/cn=Recipients/cn=User.

Then came the introduction of Active Directory with the release of Windows Server 2000. In AD, while you could refer to object using obj-Dist-Name’s counterpart distinguishedName, objects are primarily identified using their static Global Unique Identifier (GUID). The distinguishedName is constructed using relative names like the OU and CN, e.g. CN=User,OU=EMEA,DC=contoso,DC=com. Because it’s dynamic, the distinguishedName will change when you move or rename the object.

For backward compatibility with older versions of Exchange, clients or 3rd party tooling the legacyExchangeDN attribute was introduced which was to provide a unique key for the Exchange object. A process called Recipient Update Service (RUS) was responsible for populating the legacyExchangeDN value using the current location in conjunction with the given name (CN). Since Exchange 2007, legacyExchangeDN is set at creation time or can be updated manually using the Update-Recipient cmdlet. When a conflicts are detected, a unique value was constructed by adding a GUID-like series of hex characters.

When public folders are used for publishing Free/Busy information, the legacyExchangeDN was used to determine in which public folder the information was published. More information on this in an earlier blog here.

Typical values for the legacyExchangeDN attribute are:

  • Pre-Exchange 2007:
    • /o=Contoso/ou=First Administrative Group/cn=Recipients/cn=UserA
  • Exchange 2007 and later:
    • /o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA

Until Exchange 2010 SP1 Rollup 6 the legacyExchangeDN value was predictable, but as of this Rollup (and Exchange 2013), 3 random hex characters are added for uniqueness.

Exchange Internal Addressing
While SMTP addressing is the de facto e-mail addressing standard, Exchange internally still uses an X.500 addressing scheme. Using X.500 implies that an X.500 is required, which is why mail objects in an Exchange organization such as mailboxes, require a properly populated legacyExchangeDN.

The most encountered symptom of not having properly populated or unpopulated legacyExchangeDN attributes is failure of e-mail delivery or transport, which I’ll elaborate on a bit below. I’ll mention it again: legacyExchangeDN is required, unlike some Exchange admins I overheard a while ago when they were looking for the cause of several NDRs discussing SMTP was used so it should be ‘no problem’.

When sending a message, the sender and recipient are checked against the Global Address List (GAL). When it can’t find a match in the GAL, IMCEA encapsulation is used which stands for Internet Mail Connector Encapsulated Addressing. An IMCEA encapsulated address looks like:

A trailing “EX” at the end of IMCEAEX indicates that a non-SMTP address was encapsulated. The used SMTP domain “contoso.local”  is taken from the GAL object unless the lookup failed; in that case the forest DN is used.

Migrations and Co-existence Issues
Clients like Outlook cache information like the legacyExchangeDN for name lookups (the infamous name cache or .nk2 files). It will also store the legacyExchangeDN (PR_EMAIL_ADDRESS) with e-mail item. This is used when replying to old e-mail and which is why you’ll see X.500 addresses when you open the e-mail outside of the organization.

While using the legacyExchangeDN makes your client insensitive to e-mail address changes, name changes etc. it will provide a (small) challenge when for example a mailbox is moved to a different forest (or to or from Office 365 for that matter) as it will get a new legacyExchangeDN value.

To attach those old legacyExchangeDN addresses to an object in the new environment, add an X.500 entry to the proxy addresses (X.500 refers to the protocols built on the X.400 standard), e.g. X500:/o=Contoso/ou=First Administrative Group/cn=Recipients/cn=UserA.

When the target environment already contains a mail-enabled contact, ideally you want to preserve the current legacyExchangeDN as x500 address on the mailbox object (depending on if the solution transforms the contact of creates a new object). This way, users in the target environment won’t be getting NDRs because their legacyExchangeDN became invalid by the move, e.g.

Delivery has failed to these recipients or groups:
Philip Mortimer
The e-mail address you entered couldn’t be found. Please check the recipient’s e-mail address and try to resend the message. If the problem continues, please contact your helpdesk
Diagnostic Information for administrators:
Generating Server: L13L14EX1.fabrikam.local

In this case, the user tried to reply using the X.500 address /O=Contoso/OU=First Administrative Group/cn=Recipients/cn=philip. contoso.local (later more on address conversion).

If preserving the contact’s legacyExchangeDN isn’t possible, you could collect existing legacyExchangeDN values and stamp them as X500 address on the mailbox before or after moving it.

Unpopulated legacyExchangeDN
As explained earlier, the legacyExchangeDN is required for mail-enabled Exchange objects, including mail-enabled contacts. I’ve seen contacts with unpopulated legacyExchangeDN attributes in situations where the GAL Sync tool was misconfigured.

Sending an e-mail to such a contact will also result in an NDR:

Delivery has failed to these recipients or groups:
Francis Blake
The e-mail address you entered couldn’t be found. Please check the recipient’s e-mail address and try to resend the message. If the problem continues, please contact your helpdesk
Diagnostic Information for administrators:
Generating Server: L13L14EX1.fabrikam.local
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

Solving this situation depends on the solution used. Basically, GAL Sync or Identity Management products directly manipulate AD objects, bypassing the regular process like provisioning Exchange attributes. Therefor, they should call “Update-Recipient” to provision Exchange attributes like the legacyExchangeDN or any e-mail addresses to be set via E-Mail Address Policies.

Microsoft’s Identity Management product, ForeFront Identity Manager’s, contains a GAL agent which has a setting which will trigger the provisioning of Exchange attributes. Make sure this setting is enabled and you provided a valid URI:


Instead of waiting for users to report on (internal) NDR messages, you can consult the transport logs for failed delivery messages. For example, to report on all NDR messages of the last 7 days on all transport servers, you can run the following cmdlet from the Exchange Management Shell:

Get-TransportServer | Get-MessageTrackinglog -EventID FAIL -Start (Get-Date).AddDays(-7) -ResultSize Unlimited | Where {$_.Recipients -match "^IMCEAEX*"}

NDRReportReconstructing legacyExchangeDN
If for some reason you need to reconstruct the X.500 address using the information from the NDR message, support article KB2807779 contains a short instruction or utilize the small interactive script below to convert the reported IMCEAEX address to an X500 entry:

$Addr= Read-Host "Enter full IMCEAEX address:"
$Repl= @(@("_","/"), @("\+20"," "), @("\+28","("), @("\+29",")"), @("\+2C",","), @("\+3F","?"), @("\+5F", "_" ), @("\+40", "@" ), @("\+2E", "." )) 
$Repl | ForEach { $Addr= $Addr -replace $_[0], $_[1] } 
$Addr= "X500:$Addr" -replace "IMCEAEX-","" -replace "@.*$", "" 
Write-Host $Addr

Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

Microsoft Exchange Conference 2012, a Summary

After being absent for over 10 years, this year the most anticipated conference for Exchange minded people took place in Orlando, Florida (US), the Microsoft Exchange Conference 2012 (MEC).

Despite not being able to attend MEC 2012, I’d like to summarize the news on Exchange 2013 from the event. Some of this information went public as part of the release of Exchange 2013 Preview, which was released in July (yes, almost 2 months ago – time flies). Some statements were new, like for example the expected release date of Exchange 2010 SP3, which is required for co-existence with Exchange 2013.

With all the social media nowadays, you can track most of the statements made at the event. Thanks to people like Jeff Guillet and Devin Ganger and people from our The UC Architects group, like  Dave Stork, Michael van Horenbeeck, Pat Richard, Serkan Varoglu and John A. Cook, who reported live from the sessions they were attending (hastag #iammec), the community was kept up to date with information as it unfolded. At each the end of the day, Tony Redmond gave a nice summary including comments on the event as a whole.

Picture shows some of people behind The UC Architects together
with Perry Clarke (GM Exchange), who you might recognize from
the Ask Perry videos. The picture is taken by Tony Redmond.

The information presented here is a summary of all the information provided through social media and is additional to the information presented at the release of Exchange 2013 Preview; you can read all about that in my Changes in Exchange 2013 Preview article. It is in no way meant to be conclusive or complete.

Ok, now on to the goodness.

Exchange 2010 Service Pack 3 is expected to be released in the first half of 2013. Not only is it required for co-existence with Exchange 2013, it also supports Windows Server 2012 as Operating System platform. Note that SP3 will require a schema update.

No word on the expected release date of the update required for Exchange 2007 to support co-existence between Exchange 2013 and Exchange 2007. Since Exchange 2007 SP3 Rollup 8 was released in August, thus after the Exchange 2013 Preview became available, I assume we have to wait for Rollup 9 (or 10?).

Ross Smith from the Exchange Team confirmed the 99% IOPS reduction claim when comparing Exchange 2013 with Exchange 2003; when compared with Exchange 2010 it’s a 50% reduction. That’s down from 1 IOPS per mailbox in Exchange 2003 to .125 IOPS in Exchange 2010 to a 0,0625 IOPS per mailbox in Exchange 2013.


Also, passive copies have around 50% reduction in IOPS, mainly due to the increased checkpoint depth (100MB) and less aggressive pre-reading of data to keep in line with the checkpoint depth (I’ll devote a separate article on this at a later date). This means when mixing active and passive copies on a Mailbox server, the passive copies play more nicely from a storage perspective. Also, because of these changes database fail-over times are down from 20 seconds in Exchange 2010 to about 10 seconds in Exchange 2013.

To validate storage for Exchange 2013, JetStress for Exchange 2013 will become available 3 months after Exchange 2013 goes RTM. When required to validate storage in the mean time, it is recommended to utilize Exchange 2010’s version of JetStress since Exchange 2010 and Exchange 2013 will have the same IO pattern.

In Exchange 2013, multiple databases per storage volume allowed, which allows for active and passive copies on the same volume. Looking at the lower IOPS requirements of Exchange 2013 ESE’s engine and the 50% lower IOPS factor of passive copies, this allows for some serious consolidation on large volumes. The number of volume copies must match the number of databases per copy.

Note that putting databases on SMB3 shares (Windows Server 2012) is not supported; putting a virtualized Exchange server on SMB3 shares is.

Besides the recommendation to embrace 7,200 RPM disks for Exchange storage, large mailbox implementations are expected to take off (100GB+, including mailbox, archive and recoverable items) in an ongoing battle to get rid of PSTs and 3rd party solutions.

Due to database accounting changes in Exchange 2013, mailboxes may see a 30% increase in size when moved from Exchange 2010 to Exchange 2013. Make sure you adjust mailbox quota settings accordingly.

Client Access
CAS 2013 will proxy client traffic to Exchange 2010 using the CAS 2010 server’s FQDN, i.e. it won’t determine or use internalURL or InternalNLBBypassUrl. You can’t configure CAS-to-CAS proxying per site; it’s an all or nothing setting. At RTM, Exchange 2013 Client Access servers won’t contain support for SSL offloading.

Health Checking
Exchange 2013 will not only check the server’s health looking at the Exchange services, but it will also check the protocols.

CAS 2013 will determine the health of legacy Exchange servers using a simple HTTP HEAD call.

Automatic Reseeding
Besides the ability to seed databases using multiple sources, which prevents the situation where multiple remote copies are seeded over WAN links from the active copy, Exchange 2013 contains a feature called Automatic Database Reseeding or just AutoReseed.

AutoReseed can be utilized to automatically reseed databases when required, e.g. after a storage failure. AutoReseed can even allocate and initialize spare disks to restore database redundancy. AutoReseed requires configuring three new properties, which are part of the DAG:

  • AutoDagVolumesRootFolderPath refers to the mount point containing all available volumes, including spare volumes;
  • AutoDagDatabasesRootFolderPath refers to the mount point containing the databases;
  • AutoDagDatabaseCopiesPerVolume sets the number of databases copies per volume.

So for example, when you’ve configured a mount point C:\Volumes (AutoDagVolumesRootFolderPath) containing mount points for databases, e.g. C:\Volumes\DB1, and mount point C:\Databases (AutoDagDatabasesRootFolderPath) with mount points to Exchange databases, e.g. C:\Databases\DB1 (where C:\Databases\DB1 maps to C:\Volumes\DB1), and DB1 contains folders for database and logfiles, AutoReseed can utilize mount points from C:\Volumes to automatically recreate and reseed databases when DB1 fails.

Site Resilience
Exchange 2013 will feature an automatic site (datacenter) fail-over using a witness server located in a 3rd well-connected site. This enables customers to automate the process of site switchovers, from primary to secondary site. This feature is optional.

This may confuse existing Exchange customers, who perhaps learned with Exchange 2007 a 3rd site for the cluster voter was not recommended, after which it shortly became an option with Exchange 2010. Then, after a while an adjusted recommendation was published not to use a 3rd site and now it’s option again,

Despite this, I think this certainly is a valuable feature. Normally, site outages and datacenter switchovers are stressful situations; if it’s preconfigured and automated, the less prone to error the switchover process is.

Exchange fellow and colleague Jaap Wesselius, who did
2 sessions on Load Balancing Exchange, was interviewed
by F5. Click the image to watch the interview.

Exchange Online
You can use Exchange 2003 with Exchange 2013 Online (when it becomes available) by utilizing an Exchange 2010 CAS server, just like today.

Safety Net
Safety Net is the new transport dumpster in Exchange 2013 and will provide similar functionality. It will also take over the functionality of Shadow Redundancy, which purpose in Exchange 2010 is to guarantee delivery of messages and accommodate for transport failure. Lagged Copy functionality is also enhanced by Safety Net, since you can activate lagged copies by activating the (lagging) copy after which Exchange 2013 will use Safety Net to make the database current. How long Safety Net will hold messages is a configurable setting.

Exchange 2013 will support Litigation Hold, Time-based Hold (rolling data, e.g. items aged X days) and In-place Hold (formerly known as Legal Hold).

Unified Messaging
The Exchange 2013 UM role has a 100 concurrent calls limit. As you probably know, in Exchange 2013 Mailbox servers are used for UM as well. Because of that, this limit will have serious consequences when you’re designing an environment using several big servers; you might be forced to distribute the workload over more, lighter servers.

Exchange 2013 and ForeFront Treat Management Gateway
Exchange 2013 will work fine in conjunction with ForeFront TMG, except for maps feature when using TMG’s Forms-Based Authentication (FBA); the only thing you need to adjust is the logoff URL. Note that despite the ForeFront TMG 2010 End-of-Life statement from Microsoft last week, people like Greg Taylor (Program Manager Exchange) emphasized customers shouldn’t avoid using or opting for TMG while it is still available.

Public Folders
Migration of Public Folders from Exchange 2007 or Exchange 2010 is a cut-over scenario, so there will be no co-existence.

When using Exchange 2013 Public Folders next to Public Folders on Exchange 2007 or Exchange 2010, you need to manually map those to related folders in Exchange 2013 using CSV file.

Emphasis was put on being able to control Public Folders and put that data in the same store is worth losing the multi-master functionality.

Exhibitor ENow Consulting held a contest
for collecting the most autographs.

Message Hygiene
Exchange 2013 will include tools to block messages in a certain character set. This is useful in scenarios where you don’t expect messages in one of the Chinese languages and you want to block (potential) spam written in one of those languages.

In-Place Archiving
The new term for Personal Archive or Online Archive is In-place Archiving.

Message Routing
Exchange 2013 won’t use least-cost routing when routing messages, but it will use it to determine if Hub sites are defined. Exchange 2013 will honor Hub site definitions, but there are to be considered legacy.

A Delivery Group is a set of transport servers responsible for delivering messages to a certain routing destination. There are several types of Delivery Groups, depending on the destination, e.g. DAG or Site. Each transport server is used in a Round-Robin fashion when delivering messages.

An MBX server and CAS server listen for incoming messages on port 25 unless co-located; then the MBX server will listen on port 2525.

More background information on message routing in Exchange 2013 also in conjunction with Exchange 2010 is to be found here.

It is no longer required to have an Enterprise license for eDiscovery; it is still required to have an Enterprise license when using Legal Hold.

Many statements were made to de-emphasize virtualizing Exchange and only use if for testing purposes. When virtualizing, the same rules apply as for Exchange 2010.

Like with earlier versions of Exchange, the ESE engine will claim memory at startup using the amount of physical ram. Configuring Dynamic Memory is therefor not only pointless but also not recommended, like I stated in an earlier post on Exchange and Dynamic Memory.

It is also emphasized that putting VMDK files on VMWare NFS disks is not a supported scenario, so I assume this is often seen in the field despite not being supported from Microsoft.

ActiveSync in Exchange 2013 will cause 65% less RPC communications over Exchange 2010.

Outlook Web Access
When using OWA 2013 in offline mode, the locally generated cache file isn’t secure; use of BitLocker is recommended. Single Sign-On in combination with OWA on Exchange 2013 redirection will be fixed post-RTM. Also, be advised that at RTM, OWA in Exchange 2013 won’t have support for Public Folders.

A portal for the Exchange community was announced, Here, people involved with Exchange can get information from within Microsoft or other sources. How this will differ from the Exchange related topics on TechNet forum is to be seen.

It is unknown if there will be a MEC in 2013; Microsoft’s director of PM for Exchange, Michael Atalla, said there will a MEC when “theres’s something  to talk about”. It is rumored that recordings of the 1st day of the conference will be made available at a later date, except for the interactive sessions.

PS: The icon accompanying this article is the Exchange 2013 logo.

TargetAddress, ExternalEmailAddress and Set As External

In co-existence scenarios, the targetAddress attribute is leveraged to accomplish routing to different Exchange organizations by specifying the “final destination” e-mail address. The e-mail domain part of this address can be a non-accepted domain (i.e. other organization). This will enable organizations, when used in conjunction with mail-enabled users or contacts, to provision the (global) address list of their Exchange organization with mail-enabled objects of other organizations, also in a migration co-existence phase. Simply said:

  1. It can allow users in the local organization to select the object from the (global) address list and that object exists in other organizations;
  2. Exchange can route the message to its final destination using the specified targetAddress.

Reason for this blog is that I still see people putting e-mail address in the targetAddress property or the object by scripting against Active Directory (e.g. ADSI), even while they’re scripting using the Exchange Management Shell.

In the Exchange Management Shell, you can set the targetAddress by using the Set-MailContact or Set-MailUser in conjunction with the ExternalEmailAddress parameter, e.g.:

Set-MailContact  michel -ExternalEmailAddress

Setting this address is also possible using the Exchange Management Console, which may be more appropriate for testing purposes or a small number of changes (though I’d prefer the less-prone-to-error script any day):


When utilized in scripts, you can use PowerShell Piping Power (is that abbreviation already taken?) to process (CSV) files or use filtering to select the objects of which you want to configure the targetAddress, e.g.:

Get-MailContact -OrganizationalUnit “contoso.local/Division” -Filter {EmailAddresses -like *@contoso.local} -ResultSize unlimited | ForEach { Set-MailContact –ExternalEmailAddress “$($_.Alias)@newcompany.local” }

Get-Content “users.txt” | Get-MailContact | ForEach{ Set-MailContact $_.Identity -ExternalEmailAddress “$($_.Alias)@newcompany.local”  }

This will configure all mail-enabled contacts in the Division OU with an @contoso.local e-mail address with a target address which consists of the current alias followed by @newcompany.local. The other example uses a text file with names to process contacts and set the targetAddress to the current value of “alias” followed by the external e-mail domain.

Needless to say, the connectors between contoso and newcompany  as well as the accepted domains should be properly configured to route those contoso.local and newcompany.local domains between those organizations. Of course, this also depends on whether you’re using internal or external domain names and if you want those messages to go through the public network or not.

Note that this is also how you can set configure the targetAddress of a local (DirSync’ed) mail-enabled contact with an Office 365 mailbox in a Hybrid setup, for example after moving the mailbox to Office 365. In such case you set the targetAddress to the service domain in a Hybrid Office 365 setup, e.g.

Exchange Hybrid deployment and SMTP inspection

When setting up secure SMTP connections, also known as SMTPS or SMTP over TLS (Transport Layer Security), you encounter issues with SMTP obfuscating appliances, like Cisco ASA or PIX.

These appliances contain a feature called fixup protocol smtp, SMTP fixup, (E)SMTP inspect(ion) or Mailguard (Cisco), which – when enabled – limit the number of allowed SMTP verbs or obfuscate parts of SMTP dialogs. This tampering will cause problems when you try to configure SMTPS connections between e-mail servers and will prevent you from configuring a working Exchange Hybrid deployment, where TLS secured communications between the on-premise environment and Office 365 is enforced.

Note: By enforced, I mean it requires TLS which is more strict than opportunistic TLS,  which will attempt to set up TLS before continuing with regular SMTP communications.

You’ll end up with Office 365 specific Receive and Send connectors after setting up your Hybrid configuration using the Hybrid Configuration Wizard (or manually). Then, when sending e-mail between on-premise and Office 365, you notice e-mail doesn’t arrive and will remain queued.

After verifying your ISA or TMG isn’t blocking things (ports are open, SMTP filter not blocking STARTTLS etc), you start troubleshooting the issue by enabling Verbose logging for the Office 365 send connector (of course, this can also be achieved using the Exchange Management Console):

Set-SendConnector “Outbound to Office 365” –ProtocolLoggingLevel Verbose

The logs will by default be generated in the $exinstall \V14\TransportRoles\Logs\ProtocolLog\SmtpSend ($exinstall will contain the Exchange installation path).

If you look at the current log file, you’ll see the following pattern for each possible destination – in the example below the – as the local Exchange 2010 hybrid server will try to get the message(s) delivered:

Outbound to Office 365,08CEBBEB07152FBC,0,,,*,,attempting to connect 
Outbound to Office 365,08CEBBEB07152FBC,1,,,+,, 
Outbound to Office 365,08CEBBEB07152FBC,2,,,<,220 **********************************************************************************************, 
Outbound to Office 365,08CEBBEB07152FBC,3,,,>,EHLO, 
Outbound to Office 365,08CEBBEB07152FBC,4,,,<, Hello [], 
Outbound to Office 365,08CEBBEB07152FBC,5,,,<,250-SIZE 157286400, 
Outbound to Office 365,08CEBBEB07152FBC,6,,,<,250-PIPELINING, 
Outbound to Office 365,08CEBBEB07152FBC,7,,,<,250-ENHANCEDSTATUSCODES, 
Outbound to Office 365,08CEBBEB07152FBC,8,,,<,250-XXXXXXXA, 
Outbound to Office 365,08CEBBEB07152FBC,9,,,<,250-AUTH, 
Outbound to Office 365,08CEBBEB07152FBC,10,,,<,250-8BITMIME, 
Outbound to Office 365,08CEBBEB07152FBC,11,,,<,250-BINARYMIME, 
Outbound to Office 365,08CEBBEB07152FBC,12,,,<,250 XXXXXXXB, 
Outbound to Office 365,08CEBBEB07152FBC,13,,,*,,Connector is configured to send mail only over TLS connections and remote doesn't support TLS 
Outbound to Office 365,08CEBBEB07152FBC,14,,,>,QUIT,

As you can notice in this example, the SMTP banner has been turned into stars and AUTH and STARTTLS have been changed by the appliance into XXXXXXXA and XXXXXXXB. This behavior is typical of Cisco’s Mailguard feature; other smtp obfuscating appliances might result in different output. Key indicator is, expected elements are missing or garbled.

In such cases, you need to make sure SMTP traffic between on-premise and Office 365 goes through unfiltered. Depending on the capabilities of the device, you could allow the FOPE addresses to go through unfiltered. If that’s not an option, or you don’t like managing that address set, you need to disable the feature completely.

Note that Cisco is not the only vendor offering SMTP obfuscating products; companies like Checkpoint, Barracuda, Sonicwall or Symantec offer products with the feature mentioned above.

Quest product updates for Exchange 2010

Only four days after BinaryTree announced their Notes migration product update, Quest announced and released an update of their Quest Notes Migrator for Exchange (NME) product today. NME version 4.2, now with Exchange 2010 support, supports Notes to Exchange/Exchange Online migrations. NME is part of Quest’s suite of Lotus/Notes migration products, which also contains products to support Notes to Sharepoint and SameTime to OCS migrations.

You can find the press release here, more information on Notes Migrator for Exchange can be found here.

BinaryTree product updates for Exchange 2010

Binary Tree’s Common Migration Tool for Exchange, a cross-platform messaging migration and coexistence tool, has been updated to support direct migration and coexistence between Lotus Domino and Exchange Server 2010.

You can register here for an online event and presentation on their upgraded products and direct migration from Domino to Exchange 2010.

(Thanks to Brettjo)