EWS Not Working after Upgrade from SM 11 to SM 12.3.5318

Problem reported by tim - 8/24/2014 at 7:13 PM

Submitted

Hello all,

Just upgraded to SM 12.3.5318 by uninstalling SM 11, rebooting and installing the new version. I've reactivated the license and can see EWS listed as being active. However, the Mac Mail clients that were all working before the upgrade now can't connect to the server anymore.

If I delete the EWS account and add it as IMAP, it's fine.

Any ideas?

Thanks a lot.

Take care,

Tim.

14 Replies

Reply to Thread

Bruce Barnes Replied

8/24/2014 at 8:32 PM

When you reactivated your license for SmarterMail 12.X, did the EWS license reactivate as well?

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

tim Replied

8/24/2014 at 9:02 PM

Hello Bruce,

I'm pretty sure it did, both that and EAS are showing as valid until June 2015. EAS is working fine by the way, as are all of the other protocols.

Robbie Wright Replied

8/27/2014 at 10:17 PM

We are just starting from scratch with 12.3.5318 and are beginning to move clients over to it and are having problems with EWS as well. Specifically, there seems to be a bad variable being passed through as it appears EWS is only returning "https" rather than the full hostname. Autodiscover is working good for all other protocols but this one. Here's the output we get when testing EWS:

Creating a temporary folder to perform synchronization tests.
Failed to create temporary folder for performing tests.

Additional Details

Exception details:
Message: The request failed. The remote name could not be resolved: 'https'
Type: Microsoft.Exchange.WebServices.Data.ServiceRequestException
Stack trace:
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.Tools.ExRca.Tests.GetOrCreateSyncFolderTest.PerformTestReally()
Exception details:
Message: The remote name could not be resolved: 'https'
Type: System.Net.WebException
Stack trace:
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.TraceAndEmitRequest(IEwsHttpWebRequest request, Boolean needSignature, Boolean needTrace)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
Elapsed Time: 2566 ms.

Steve Reid Replied

9/2/2014 at 11:43 AM

Have you populated the autodiscover host field in protocol settings?

tim Replied

9/7/2014 at 1:11 PM

Hello all,

Still got the same issue. Since writing this post I have uninstalled and reinstalled SM. I have noticed that there are no errors in the SM EWS log, but do get the following error in the IIS log:

2014-09-07 19:44:48 W3SVC2117438050 212.89.XXX.XXX POST /EWS/Exchange.asmx - 443 - 81.187.XXX.XXX Mac+OS+X/10.9.4+(13E28);+ExchangeWebServices/4.0+(193);+Mail/7.3+(1878.6) - 500 0 0

Any ideas?

Take care,

Tim.

Robbie Wright Replied

9/11/2014 at 12:24 PM

Tim, here's the response from SM support. Confirmed broken for EAS and EWS for Outlook 2013 and Outlook 2011 on Mac. Looks like we'll be waiting until a while.

I had discussed this issue with our developers, and right now Autodiscovery with EAS and EWS appear to configure Outlook 2013 and Outlook 2011 for Mac as an Exchange connection utilizing MAPI and not through EAS (Outlook 2013) or EWS (Outlook2011 for Mac).

This is based on the XML data returned to these clients when the Auto discovery process has been ran. We were able to replicate the same behavior within our test environment.

Changing this process will need to be a core change to SmarterMail. Each change to the EAS\EWS protocol must be tested against a wide range of clients to ensure the process does not get broken for more devices and clients. Please also note that the clients themselves control what protocols and methods they prefer based on the data returned, some clients will prefer IMAP\SMTP over EAS or EWS, this is something we do not have control over.

With that being said, the behavior has been reported and will be improved on in the next major release of SmarterMail.

In the mean time EAS and EWS accounts must be setup manually. I do apologize for the inconvenience in caused by this. I've refunded this ticket back to your account for future use as well since this will be improved on.

Cyril P. Replied

10/4/2014 at 10:13 AM

We're having the same issue. Autodiscovery is broken for Outlook, even after disabling the autodiscovery host for EWS. Any idea when a fix will be available?

Bruce Barnes Replied

10/4/2014 at 1:48 PM

First, upgrade to the latest version of SmarterMail, here's the link:

http://www.smartertools.com/smartermail/mail-server-download.aspx

Then, check out this article on setting up the DNS side of autodiscover:

https://portal.chicagonettech.com/kb/a117/configuring-your-mx-server-for-autodiscover.aspx

The autodiscover settings in SmarterMail are a goid start, but to really make the process work seamlessly, you'll need the DNS side, too.

Michael Cummins Replied

10/8/2014 at 8:42 AM

I was thinking of upgrading from 11 this weekend as well. Will it disrupt my EWS clients? Should I reconsider the upgrade for now?

Bruce Barnes Replied

10/8/2014 at 8:55 AM

So long as you follow the MAJOR VERSION UPGRADE procedure: uninstall, reboot, and install the major version upgrade, you should not have any issues.

See: https://portal.smartertools.com/kb/a2856/major-upgrade-of-smartermail.aspx?KBSearchID=613850

(posted as REPLY TO THREAD to allow active link - not capable in reply to comment)

Cyril P. Replied

10/8/2014 at 9:59 AM

This is not a case of upgrade or misconfiguration. Our autodiscover DNS entries are fine, they work, and the latest version of SmarterMail was freshly installed.

The fact is that, with EWS activated, the autodiscover feature sends the wrong data to Outlook 2013 which prompts it to think it's talking to an Exchange server. Activesync works but only when the account is added manually to Outlook.

Thank you for checking that out. We needed to buy EWS for some of our clients but now it's causing issues to others who need the autodiscovery feature.

Bruce Barnes Replied

10/8/2014 at 10:36 AM

Did you create all SEVEN of the required autodiscover DNS records? These are in addition to the SmarterMail autodiscover entries in the administrative web interface.

The XMPP record, at the end of the list, if optional, and only required if you have XMPP available.

_autodiscover._tcp.yourdomain.tld
_caldav._tcp.yourdomain.tld
_carddav._tcp.yourdomain.tld
_imap._tcp.yourdomain.tld
_pop._tcp.yourdomain.tld
_smtp._tcp.yourdomain.tld
_webdav._tcp.yourdomain.tld
_xmpp._tcp.yourdomain.tld (if you support CHAT)

See: http://portal.chicagonettech.com/kb/a117/configuring-your-mx-server-for-autodiscover.aspx for step-by-step instructions.

Robbie Wright Replied

10/9/2014 at 9:26 AM

Bruce, this is an issue that SM has acknowledges exists with their autodiscover method returning MAPI rather than ActiveSync.

And Bruce, correct me if I'm wrong, but generally speaking those records force autodiscover for clients or servers that cannot use the normal autodiscover record, correct? Basically _autodiscover is supposed to point clients to the XML of the SmarterMail server which is suppose to return the preferred connection method.

Bruce Barnes Replied

10/9/2014 at 9:38 AM

They work fine, if you have nothing unusual setup for your domains.

It is highly recommended that autodiscover DNS records be setup for EACH domain, pointing back to the domain which actually handles the MX traffic for the domain.

In our case, securemail.chicagonettech.com handles all traffic, for all hosted domains.

So, every hosted domain has every one of those autodiscover records setup in their DNS and every one of them autodiscovers completely automatically from any device.

The difference between the call to the DNS records, vs the SmarterMail record, is that the DNS, on a domain-by-domain basis, gives complete control to the DNS, and not SmarterMail.

Back to Community Threads

Please leave this box unchecked

14 Replies

Reply to Thread

Tags

Related Knowledge Base Articles