1
EWS Not Working after Upgrade from SM 11 to SM 12.3.5318
Problem reported by tim - August 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.
 

10 Replies

Reply to Thread
0
Bruce Barnes Replied
August 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

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
0
tim Replied
August 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.
0
Robbie Wright Replied
August 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.
0
tim Replied
September 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.
0
Robbie Wright Replied
September 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.
0
Cyril P. Replied
October 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?
0
Bruce Barnes Replied
October 4, 2014 at 1:48 PM
First, upgrade to the latest version of SmarterMail, here's the link:
 
 
Then, check out this article on setting up the DNS side of autodiscover:
 
 
The autodiscover settings in SmarterMail are a goid start, but to really make the process work seamlessly, you'll need the DNS side, too.
Bruce Barnes
ChicagoNetTech Inc

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
0
Bruce Barnes Replied
October 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.
 
 

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

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
0
Bruce Barnes Replied
October 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)
 
Bruce Barnes
ChicagoNetTech Inc

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
0
Bruce Barnes Replied
October 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.
Bruce Barnes
ChicagoNetTech Inc

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

Reply to Thread