Over the last couple of days, I took the time to upgrade my personal Exchange environment to Exchange 2010 SP1 Rollup 1 (I was on 2010 RTM). The update appeared to go without a hitch, but a day or so later, I discovered my iPod (in fact, this is true for any Apple iWhatever device) wouldn’t sync mail over the air via EAS, it wouldn’t send email and OWA replies/forwards failed with ugly error messages.
If you’re seeing any of the following errors just after upgrading to SP1, you might find the root cause and the associated fix is very simple – if so, read on.
- An error occurred while delivering this message
- This message has not been downloaded from the server
- Cannot Get Mail – the connection to the server failed
- In OWA: An unexpected error occurred and your request couldn’t be handled
- In event traces, imceaDomain must be a valid domain name.
Now, this issue was picked up and discussed in the release notes for 2010 SP1 as a known issue, but I didn’t clock this initially because I didn’t exactly read the notes thoroughly – a brief scan, perhaps, late in the evening, but nothing looked relevant on my tired eyes at the time. I’ve also already performed a number of SP1 upgrades elsewhere without experiencing issues, so I didn’t consider it important to refresh my memory by re-reading the notes.
The exact symptoms:
On the ActiveSync device:
Your email will sync, but there won’t be any content. The preview of the message text will display in the folder view, so you know something is there, but expanding the message to actually read it reveals the message: This message has not been downloaded from the server. Scrolling down, you can use the button to download remaining content – but it claims the message is 0 bytes in size and pressing this doesn’t do anything.
Message view - the messages just don't download
Sending email from the device resulted in a message: “Cannot Send Mail. An error occurred while delivering this message.” Unfortunately, all the errors issued by the Apple kit are fairly generic (probably because, in this instance, it didn’t actually know what the problem was – but I’m inclined to think it’ll always make you dig to find the root cause).
Non-Exchange accounts, such as Gmail, and potentially accounts on other Exchange environments configured differently to avoid this bug, worked absolutely fine.
Via OWA:
OWA, again, reports a generic error:
Expanding the details in the error or looking in your server’s event log, reveals an interesting exception message:
Exception message: imceaDomain must be a valid domain name.
If you’re not familiar with IMCEA (Internet Mail Connector Encapsulated Address), it was originally a method of inter-connecting mail environments by providing temporary addresses to users sending email via SMTP, but did not possess an SMTP email address. The mail system handled the encapsulation and subsequent reverse process in order to send and receive email for the user. The technology is still used today in the latest versions of Exchange, and you will often see cases where an SMTP address is unknown, so an IMCEA version of an X.500 address is displayed – often in NDR reports. According to Technet, Exchange actually uses IMCEA encapsulation for any address other than the default authoritative domain.
In this case, Exchange is having issues dealing with just that – the default authoritative domain. You see, if the friendly name you gave it has a space in it, or some other illegal character for a domain name, it triggers an error in the programming, which ultimately leads to this major loss of core messaging functionality.
As always, the fix is fairly simple. Remove any spaces from the friendly names of your accepted domains. You can do this at shell or the console – I prefer using the shell, in which case, use
Set-AcceptedDomain “Friendly Name of your default authoritative domain” -name “AnyNameWithoutSpacesOrIllegalCharacters”
Once the name change is complete, throw a restart on the MS Exchange AD Topology service during a period of planned system outage and functionality should come back. I pick that service because it restarts most of the others at the same time.
As a result of this issue, I will be forcing a new naming convention everywhere I manage Exchange, whereby accepted domains are ALWAYS named after the actual domain name for ALL accepted domains, thus containing no spaces and no other illegal characters. It transpired that the other sites were named in this fashion for the default domain anyway, which explains the reasoning as to why I never experienced this issue with those users.
