Gary,
Em Client crashes if you try and update an Internet Calendar. So, if you can’t up date it, which is totally useless, at least it shouldn’t crash the software if you try to.
Well meaning folks like myself can’t see the problem in version 7.1.32088. I setup an Outlook.com account in which it enabled this protocol. The calendar syncs without error.
Yes - FOR OUTLOOK.COM - if you actually read the comments, you’ll notice we’re NOT complaining about it when you WANT to connect to a M$ server; what is being complained about is the (now) broken ability to connect to a NON M$ server that supports ActiveSync connections. As such, ‘well meaning’ comments are NOT helpful! There IS an issue here! Try connecting to a non-M$ activesync server and THEN come back and say it works … (you won’t)
Thanks Richard, I guess you changed your view on Outlook.com. Previously you said it doesn’t use EAS, now you agree it does.
Thus I am wondering, as eM Client does work with EAS, is the issue maybe with the implementation of that protocol on your server rather than a problem with eM Client itself? You might know if there is a difference between the product that runs on Exchange or a non-Exchange server. Maybe the non-Exchange product itself changed around the time of eM Client’s update to 7.0.3x.
In the end though, whatever the reason, I personally don’t see eM Client using resources to develop something that is practically dead on the desktop platform. As Randy says it works on his mobile device, and that seems to be only platform on which it is now successfully used and developed. Of course you are welcome to use any other desktop client that does support the version of EAS that is running on your server.
If you don’t find my comments helpful, that is OK, I don’t mind. You don’t need to click the Like link. 
No, I haven’t changed my stance on OUTLOOK.COM - M$ changed the connection protocol and emClient appear to have changed to match. My server (along with a number of others) use the ActiveSync protocol - they haven’t changed (as evidenced by others). - and we haven’t asked for ‘development’ - just that if an existing protocol is in place and works with the generic protocol, it remains in place, with a NEW protocol (which is the case with outlook) being added - not used to replace. emClient appear to have just followed M$ and stuck two fingers up to non-M$ providers.
May I ask; do you have a software background?
Thanks Richard, that makes sense. Unfortunately most software developers change with current trends, and eventually they drop older and less developed formats. I suppose it becomes too expensive or complicated to maintain them in their development than just what they see as being more popular in the present and the future. At least eM Client still has the older versions available for download, so you have that option as well as other desktop clients.
I have worked in the software field since the mid 80s. So yes, I would consider that a background.
I was wondering about Outlook.com because previously you said Outlook.com doesn’t use AirSync, but today you said that it does. I guess I was mistaken that you had changed your view.
There’s actually trade description issue though. All the publicity states ‘AirSync’ - which is the ORIGINAL branding for EAS - and if that’s what emClient state is what is supported, then that’s what it should provide - which it used to. And AirSync was specifically designed for groupware/mobile device synchronisation - note I don’t use the term ‘outlook’, but ‘groupware’ - of which there are a number of providers who provide EAS servers.
I believe that Outlook.com changed to EAS 16.1 - the protocol was rewritten.
The problem with emClient’s current implementation is that the server connection detail appears to be hard coded as, even if you manually change the server detail to point to a non-M$ EAS server, the current build seems to ignore it and continues to ‘connect’ to the (hardcoded) M$ server … and that’s my major beef. By all means hard code a server address, but if you’re going to do that, a) provide it as a separate tab (called OUTLOOK if you want), but b) don’t kill the existing capability - especially if you’re still going to provide the field to change server details! - It’s distinctly possible that the current version WOULD connect to a third-party EAS server … if only the server address wasn’t (apparently) hard coded!
Oh - and I also was - I’m now retired, a software engineer with Raytheon UK - working on ATC, GPS and other similar applications … and was heavily involved with Configuration Management!! - which is what this particular issue is really all about!!
Oh - and any software application, if it purports to support a particular protocol - and there are modern providers still supporting said protocol, shouldn’t prompting refuse to connect to said servers … unless the manufacturer happens to be funded by/in the back pocket of M$ and are attempting to kill off all the other competitors … (some of whom provide software -as in the case of ClearOS, Zarafa, SOGo etc al, is free (or semi-free) …!). That’s just shafting us the users! - who they are relying on to use/buy their software!!
You probably already tried it, but I wonder if you added a profile for the server in providers.xml if that would make any difference setting up your account? Or would you end up with the same problem as adding the account with the Outlook.com method and not be able to change the AirSync url?
Haven’t tried that - may look into it.
I’ve now setup a (free) Fruux account and connected emClient and my phone together that way. I’m using CALDAV for calendar stuff - none of it ideal as the former means that it’s outside my control … and that is the whole point of using a local EAS server (rather than outlook.com) - I want control of my own security; I don’t like handing that over to someone else!
Richard,
You are correct about ActiveSync/Airsync. You are also correct that many popular email clients like all of those on hundreds of millions of cell phones, Zimbra (which millions of Shaw subscribers use), Horde and other email servers still use this protocol.
You area also correct that they have hardcoded something to directly try an connect with a Microsoft server if you try and use Airsync thus “breaking” the ability to do as you say and connect with other severs that are not Microsoft.
So, on all counts you are correct and your points are very valid.
And for Gary, I too have been developing software for decades including embedded real time systems. I am not a novice.
Who would break something that was working just fine and is used by hundreds of millions of people???
Richard, it is obvious that eM Client is not moving in the direction you want, and that is not likely to change either. My suggestion is that as you aren’t happy, please change to another desktop client that does support your required protocol.
The crazy thing is, this thread is now nearly a year old(!) and I’ve already reconfigured my setup - including my phone as it’s pointless having two items on the same system that can’t talk to a single point of contact (ie an EAS server)
Suggest we just leave this - but if the developers were to read the thread (and others like it) and reconsider … I’d be more than happy!
Ah sorry Richard, my last comment was directed at Randy. Don’t know why I wrote Richard. :-0
No problem - I did wonder!
BTW - for both of you …
Gary’s suggestion of tweaking the xml file works. I’ve created a VM and installed emClient therein. Tweaked the providers.xml file to have MY server details rather than the M$ ones and it connected to my EAS server. YEA!!
If you want to do the same, load the file into notepad and search for AirSync - there’s only one entry.
Really, really happy that it worked for you Richard. I had played around with it before, so should have suggested it sooner.
Just be aware that if you reinstall or upgrade eM Client, it will replace the providers.xml file. So make a backup of the lines you changed.
If you want the profile for a particular problem server added to the file for future updates, or you want to change something that is already there, you can write to eM Client and ask for it to be included. Olivia Rust is very helpful in this regard, and I am sure that there would not be any problem incorporating your suggestions.
As you suggested, maybe now it is time to put this to rest.
Generalised fix. Insert at of file (under GMail is a good place) to speed detection, and change the domain/port details to suit
example.me.uk
example.me.uk
example.me.uk
" rel=“nofollow” target="_blank" title=“Link http//schemasmicrosoftcom/exchange/autodiscover/outlook/responseschema/2006a”>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">;
IMAP
example.me.uk
993
SSL
" rel=“nofollow” target="_blank" title=“Link http//schemasmicrosoftcom/exchange/autodiscover/outlook/responseschema/2006a”>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">;
SMTP
example.me.uk
465
TLS
on
" rel=“nofollow” target="_blank" title=“Link http//schemasmicrosoftcom/exchange/autodiscover/outlook/responseschema/2006a”>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">;
AirSync
example.me.uk
Richard,
This blows me away. So, what you have found is that Em Client does in fact still support ActiveSync/AirSync. However, someone at Em Client has botched the xml file. Holy cow I have been on this for months and being continually being told that Em Client doesn’t support this protocol any longer when it in fact does.
Still shaking my head.
Thanks though for posting the solution. You too Gary for the XML suggestion.
For most servers, eM Client relies on the server’s autodiscover for how the account is setup. The providers.xml only provides setup templates for servers that have known problems, such as where the autodiscover is missing or incomplete or where eM Client is not able to use that information correctly. It does not provide templates for all servers.
I think this is the problem with your servers. eM Client is not able to correctly determine the AirSync protocol from the autodiscover, or if there is already an entry in the providers.xml for your server, then eM Client’s information is in error.
This is how I originally came to know of the xml, and managed to successfully add missing protocols for my own server.
Once you have a working solution, I encourage you to submit the changes to eM Client so that they can be included in future updates.
Ah, but it appears that unless there is an AirSync entry, the autodetect can’t help. The xml file is the way to go with this - if you put the customised entry in, the autodetect mechanism then picks up the AirSync details.
There’s no point in submitting the change to emClient for my purposes, as it’s my own server and only supports the family email accounts - it’s not for external users. It’s not a server that you can setup an account on for example. Now I know the fix, it’s easier enough to update manually on any application releases.
I had a bit of a reputation for figuring out this sort of thing when I was working. I remember many moons ago working on a (now old I guess) battlefield comms system (BATES) that no-one had been able to understand and code. Guess who figured it out