Went through the wringer on this one and could not find any clear documentation/resolution on it on the web, so after discovering the cause/fix, I thought it’d be a good idea to post. I had just finished a Swing Migration for a client when the client reported problems with OMA. The core problem was a certificate error on his Windows Mobile device that wouldn’t allow him to sync, but since he knew about OMA, he tried to use that instead, but got errors. Specifically, he got the following error after logging in to the OMA interface:

A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.

Outlook Web Access worked fine on the server, as did the full Outlook client. It was just OMA that was having fits.

I got in and looked at the event logs on the server (after verifying that other accounts got the same error with OMA) and found an MSExchangeOMA 1503 error. The full text of the message is really verbose, so I won’t paste it all here. I dug around Google and eventid.net, but didn’t really find anything that pointed to a fix.

Finally contacted another resource who pointed me to the solution. Turns out that at some point during the migration, the homeMTA attribute for the user accounts got munged. The homeMTA attribute value looked similar to this:

CN=Microsoft MTA\0ADEL:111e6f10-7865-41da-8c30-8d249bf3a050,CN=Deleted Objects,CN=Configuration,DC=domain,DC=local

Well, the Deleted Objects container was a clue that it wasn’t pointing to the correct place. I created a new test user on the server and looked at the homeMTA attribute value for that user, which was:

CN=Microsoft MTA,CN=LEONSERVER,CN=Servers,CN=first administrative group,CN=Administrative Groups,CN=LS,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local

After changing the homeMTA attribute on the Administrator account, OMA worked fine. All user objects that were present prior to the migration had incorrect values for homeMTA, and I adjusted them all. Case closed, OMA working.

Where do you find the homeMTA attribute? In ADSIEDIT. ADSIEDIT is not for the faint of heart. It’s actually more invovled that registry diving. But if you encounter this error, the fix is relatively straightforward.

First, you need to install the Support Tools package on the server. In an SBS install, the Support Tools installer is on CD #2 in the \SUPPOR\TOOLS folder, and the installer is named SUPTOOLS.MSI. Once you install that, you can access ADSIEDIT by running adsiedit.msc from a command prompt. Expand the Domain node, and browse into DC=domain,DC=local -> OU=MyBusiness -> OU=Users -> OU=SBSUsers. Right-click on a user object and select Properties. Then scroll down the list of attributes until you find the hostMTA entry. Find the user that will have the correct value and copy the value, then paste it into the user that has problems. Apply the changes and OMA should immediately work.