64 bit. I'm truly disappointed in mailenable right now. Current maintenance subscribers should get a free year for this nightmare. Security holes, lack of reply from the company, it seems like ME just doesn't care enough to do what is required to make this product really work.

He have been attending to raised support tickets as best we can. Truley every ticket that is raised via this channel gets attention over those issues that appear in the forum. Whenever a major release occurs, there is always an influx of support - and Version 7 had required alot of the modules to be rewitten (in particular the management console).

If people are getting frustrated with any issues, then the solution is to use the ticket system to we can better address their needs. I would specifically like to correct an issue here on security hole"s" - as raised here. I would think this inference is made in relation to the recent security update. I think in recent times, this is overly critical (ie: we annouce one security update and patch all versions up and until version 3 - a version thats decommissioned and all of the sudden plurals are getting thrown around). The good news is that we have broken the barrier of issues raised in relation to version 7 and can now direct staff to better reviewing the forum.

With respect to EAS issues, we have worked to address these as best we can - and there have been some devices that have deviated from the way the EAS protocol is specified (as well as some bugs that we have needed to patch in our implementation). For most of the part, pure android, apple and windows phones have worked thoughout - and its been niche implementations (like the S3 in particular) that have caused pain. The thing is that some of these devices/releases were not even on the market when EAS was released, so it becomes a matter of catch up. In many cases, there have been patches made to these devices that make the phones work with EAS (BB10 had significant problems as another example).

Regarding: If you guys are aware of the issues, why do we have to open tickets to get it fixed?
To most of the degree, we become aware of issues principally through what is raised in the ticket system.
Not that its relevant, but these feed an issue register, which then get allocated resources....; the tickets get updated... etc.. You know this of course because you have raised tickets before.

In terms of this particular installation issue of detecting the framework version and bitness to install - we currently do not have an issue open about it. Furthermore, on fresh installations and our beta sites, we had not seen the issue. A problem is, that if the incident is raised in the forum, and people require an quick resolution, then it may sit unattended until someone looks at the forum and discovers the item. In that event, it gets raised as an issue. The chances of reproducing it without any of the install logs or an understanding of what other app pools are installed, the bitness, upstream web.configs, etc.. are slim (I wish I was as slim).

With respect to running on a WAN, of course we do. I would need to know of a specific WAN issue and the module in order to comment further (this thread does not seem to relate to a WAN issue). With respect to finding issues like this, we had hoped environmental issues may have been identified in the 9 month V7 beta - but they unfortunately were not. I can assure you though, if you could direct me to a specific issue (PM me if you like), then I can verify whether its in the product issue register and establish where it is at.

Now with respect to this issue, the forthcoming releases have some improvements relating to installing in environments IIS compatability layer is installed and where the 4.0 framework was installed after MailEnable was installed - and then MailEnable is upgraded.

Current list of issues that I'm aware of. I'm not having this particular issue, clear if you read my replies. But,

Sent MAPI is broken, sent items appear as unread. Sent items have to be reloaded from the server upon clicking on the sent items folder.

EAS, sometimes all messages disappear on android 4.2.2 and 4.1.1 and have to be completely reloaded. Still high cpu usage.

Here's my complaint, things don't get truly fixed with your software. Issues get covered up with programming shortcuts that aren't real long term reliable solutions. I don't think that enough resources are being invested in your product to call yourselves "Enterprise".

EAS, sometimes all messages disappear on android 4.2.2 and 4.1.1 and have to be completely reloaded. Still high CPU usage.
This issue is more obscure and can happen if there is a communication error between the device and the server.

I cant comment specifically, for those devices, however if the device switches between Mobile Data and WIFI, whilst the device has a sync (hanging) in progress, then the returned result may get lost (this could also happen if there is a network outage while a sync- that has changes is in progress). The EAS protocol itself deals with this by requesting a fresh set of data for the folder, and this is why it is re-downloaded again. The only way to determine what is happening is by looking at the EAS log files and seeing what commands are being sent to and from the server (and whether there is a problem or protocol error at the time). The fact that it does not happen all the time would indicate that it is communication related (which is difficult to diagnose since it requires reviewing IIS logs if you are running EAS though IIS).

Now with respect to the workings of EAS and the Protocol "Specification". We do have an issue open with respect to this, but the device is different to the ones you mention (a re-sync issue is reported with another EAS client, but it appears to be a problem with the client itself whereby it is issuing Ping commands to the server while it a sync is in progress - which is not permitted in the EAS protocol - and the protocol does not outline what to do when a client misbehaves as such). Because the behaviour is undefined in the specification, making any change to the workings may impact other devices (even worse that future patches or releases to these devices may break depending on how these workarounds are made). BB10 was another example of an implementation that had quirks that required workarounds (although I believe they have since addressed these in updates). We do have some test devices with those Android versions and they passed our lab testing though - which again might suggest a communication error.

Here's my complaint, things don't get truly fixed with your software. Issues get covered up with programming shortcuts that aren't real long term reliable solutions.
I don't think that enough resources are being invested in your product to call yourselves "Enterprise".

You seem to know more about these issues are being fixed than I do (in that you are suggesting how they are being resolved)! All I can say is that we are doing what we can, and that we have processes for resolving issues. We have pilot sites with thousands of users - and unfortunately these issues unfortunately do not surface in those environments before kits are released. To some degree though, the recent security update (which was patched 2 minor release versions ago for V7) required that kits be deployed within a shorter window than we would prefer (I think the unread sent items folder issue was an introduced bug that was an effect of this).

"This issue is more obscure and can happen if there is a communication error between the device and the server. "

on 4g/3g when traveling, there will always be communication errors. That shouldn't matter if there are communication issues -if it does, that is a severe limitation of ME. Not both my tablet and cell phones.

It is not a limitation of MailEnable's EAS implementation, it is just how the ActiveSync "Push" (aka hanging syncs and pings work).

It does not matter what EAS server you are talking to, if the communication failure happens when changes occur mid hanging sync or hanging ping, then a resync is required. This is because the synchronisation keys enter an unknown state).
If you don't want this behaviour, then disable push (and use scheduled pull) - most devices allow this.

The protocol has that built into it for exactly that reason. The ONLY action that can be taken when a communication error occurs during a "Push" sync that results in the client not getting the sync key is a re-sync.
There is more info here: http://msdn.microsoft.com/en-us/library ... g.80).aspx