It's lacking a lot of features that are part of the EAS policies you would find in an Exchange 2K3 SP2 or higher or Exchange 2K7 setup. I think I can put in perspective why this stuff is really so important to have and that BOTH sides of it are configured correctly.

First off, anyone using a self signed certificate will have nothing but problems...period. Importing the cert into a PDA or PC and then "trusting" it defeats the purpose of having a cert. If you aren't an Exchange guru or a security guru like me, you either don't care or just think that its plain stupid since its stopping you from getting your mail. The whole purpose of using certs is to verify the identity of the server by comparing keys stored on a public server (like Verisign, GoDaddy, etc). Using a self signed cert and then telling users to simply "trust it" is like putting on a name tag that says "God" and now telling everyone you are really God...just trust me on this. That is why a self signed cert is pointless when you use it on the Internet. You have no way of telling if it is indeed the real deal since you elminiated any back checking.

The Pre does NOT support client side certificates either. Meaning, an Exchange administrator can make an EAS (Exchange Active Sync) policy that mandates that not only does a client connection need the proper username and password, it would also need to present a "known" valid client certificate. But as stated above, if you are using a self-signed cert, all of that is pointless. But for for a corporate exchange guru dealing with sensitive government information in emails, I need to keep it tight and verify that the end user is who they say they are and that for them, the server is who it says it is (with a PUBLIC cert) so they aren't giving their user/pass to just ANY server. Apple, for whatever reason, also did not include the ability to use client side certs in their iPhone rendition.

The Pre does not support the ability to have a mandatory locking mechanism. Meaning you can make an EAS policy force a device to use a PIN number or password to lock itself after a certain amount of time. But if the device does not support this, you will get errors on the first sync attempt. The whole purpose is that if some drunk engineer leaves his PDA at a bar or at the airport lounge, nobody can read his emails, powerpoint presentations, etc. You would be surprised how many things are leaked out from pure stupidity like that.

Which leads us to the next important step, remotely wiping a device through the Exchange Admin console. This way if it does become lost, it can simply be zapped remotely to prevent it from being tampered with, etc. This is Remote Device Security 101 here.

Exchange 2007 is HIGHLY complicated when compared to Exchange 2003. Too many IT guys have been slapping Exchange 2003 on servers with little understanding of how it works or what they are doing. Microsoft closed a ton of holes and made it so you actually have to configure 2007 to get it work correctly. This means IT guys will actually have to know what they are doing, GASP! Installing the proper public certs on an Exchange 2007 box can only be done through the Power Shell and the days of dropping a self-signed cert through IIS are loooooooong gone

So while I am glad Palm is going to address some of the EAS issues, I believe the majority of the griping is from uneducated end users who were previoulsy using unsecured and improprely configured Exchange servers to get their stuff. However, Palm certianly should have been more upfront with what works and what does not. That would have made it a whole lot simpler to figure out just why "it worked before, but now it does not".