Bury the Berries? Not yet.

Research in Motion (RIM) changed the game when they introduced their Blackberry devices to provide mobile email solutions for Exchange and other email platforms.  Over the last few years, many other companies have stepped up to produce handheld messaging devices, mostly centered around mobile phones and carriers.  There are so many good competitors these days, that some companies are considering if they want to ditch the Blackberry Enterprise Server (BES) platform in exchange for… well… Exchange.

Exchange 2003 and up allowed for Exchange Active Sync, a series of mobile technologies that allow Exchange servers to communicate directly with mobile devices using push synchronization to deliver email, contacts, calendar items and other information.  Windows Mobile phones are natively equipped with the Active Sync technology; and the iPhone, PalmOS and WebOS, and various versions of software for Android phones have also licensed the Active Sync technology for those platforms. This means that these devices can communicate directly with an Exchange server and send/receive mail, sync contacts and tasks, and answer calendar requests without the need for an intervening server platform like BES.

However, there are two key reasons that I am (at least for now) sticking with my Blackberry device.  First, there is battery life. Talk time is a pretty standard 4-6 hours no matter what OS runs on the phone you’re holding.  But standby/messaging time is another story all together.  With push email active, I have yet to see a Windows Mobile phone go more than 6-8 hours without needing a charge.  If I turn off Bluetooth, push email and just about everything else that uses a transmitter, I can stretch that number to 12-14 hours, but then what’s the point of carrying the device?  Blackberry devices routinely go 24-36 hours of messaging, even with Bluetooth active (but not transmitting).  Android devices can go a bit longer than Windows Mobile, as do iPhones and WebOS systems. They typically run the middle-of-the-road between those two extremes.

Secondly, there is security.  BES allows for a remote device to be wiped natively.  Windows Mobile devices can also be remote-wiped if you’re on Exchange 2007 and up, but iPhone and other OS devices must use 3rd-party software to accomplish this goal.  Remote-wiping is used to provide security if a device is lost or stolen. Once activated, all personal/corporate data on the phone is deleted, rendering it both useless and safe.  Good Technologies has reinvented itself over the last few years as a great provider of remote-wipe and encryption systems for Android and iPhone platforms, but it is one more thing you have to manage in an environment that (based on who would use it) already has a BES server running.

Based on these two factors, I cannot envision organizations ditching BES in favor of an Active Sync solution set exclusively.  Battery life makes these devices difficult for mobile personnel to use successfully, and the need for additional security systems only adds to that concern. For non-mobile users, battery life isn’t as much of an issue (as they’re going to be near a power outlet in many cases).  Security, though, is still a huge concern.  Unless they are on Windows Mobile devices exclusively (no iPhones, no Droids, etc), they’re going to need additional server solutions to be safe.

My prediction is that BES will stay in the Enterprise space for quite some time.  We may see Windows Mobile, Android an WebOS take over more of the marketplace, but until these two issues are significantly improved, they will remain the minority for corporate mobile messaging.

Friday Poll: Smartphones for Exchange Active Sync

This week, let us know which device(s) you use to access your email, contacts and calendar items on an Exchange Server.  Note, for the purposes of this poll, we’re just talking phones that are officially supporting Exchange Active Sync in some way.

 

 

Last week’s poll results:

It would seem that AD DNS and a combination of AD and 3rd-party DNS are neck and neck in terms of folks using them for Exchange Servers.  Using only 3rd-Party was popular, but only about 1/2 has popular as either of the other 2 choices.

Net Neutrality and EAS

Mobile messaging and collaboration makes for a big, bright world in business today. What was once the domain of a single service provider (Research in Motion - RIM) has evolved into a robust set of platforms to convey email, appointments and contacts from one device to another.  Blackberries, Windows Mobile devices, iPhones, Android phones and so many other systems can communicate either directly or through a proxy to a Microsoft Exchange platform.  This unleashes the workforce and allows for your people to be where they need to be in order to work, instead of where they have to be just to talk to each other through the email system.

Net Neutrality is the idea that no matter what the network provider offers in terms of services and software, you should be able to use the devices of your choice and the platforms of your choice on those networks.  It’s a great theory, but putting it into practice is causing some issues along the way.  The FCC set forth a set of basic rules that they wanted carriers to follow, and in the greater sphere of comments, they were well received.  They recently added in two more proposed rules that directly impact cellular networks (digital broadband) and the services that run across it – including Exchange Active Sync (EAS).

You can get a rundown of the entire proposed rule set in this article, but the two that directly impact EAS most are:

5. Broadband providers cannot block or degrade lawful traffic over their networks, favor certain content or applications over others and cannot "disfavor an Internet service just because it competes with a similar service offered by that broadband provider."

On the surface, this looks like a standard anti-competitive rule.  In reality, however, many service providers in the cellular world are viciously blocking competing technologies, and their claim is that forcing neutrality will destroy their business.  EAS is a great example of this phenomenon, as not that long ago many providers didn’t allow that traffic on their mobile networks.  Mostly, this was due to the fact that they wanted to pus their own version of enterprise email synchronization (such as Sprint’s ill-fated attempt on the earlier Palm Treo devices).  Eventually, the need to allow this traffic or lose business to other devices and networks overrode the desire to use and sell their own platform, but that took a great deal of time, and lead to quite a bit of bad press and back-end attempts to circumvent the blocks.  By forcing mobile providers to allow all valid and legal traffic, the atmosphere for open communication standards will grow and more people will be able to take advantage of more technologies.

6.Broadband providers must be transparent about the service they are providing and how they are running their networks.

Proprietary networks are nothing new, but trying to create an EAS client for a phone on a network that actively blocks your ability to figure out how it sends and receives data makes this close to impossible.  Some providers have blocked all traffic they do not wish to have on their networks by simply making it very difficult – or nearly impossible – to figure out how a 3rd-party tool can possibly communicate with it.

I’m of two minds on these proposed rules.  On one side, EAS and other technologies require open, transparent communications platforms to work. Exchange can communicate with a whole world of different vendors’ mobile applications, but only if those apps can talk to the Exchange Server.  On the other side, competition drives better software and platforms.  If it wasn’t for all the things you can only do (or could only do) on an iPhone, RIM and Google would never have had the impetus to push their own platforms to new heights, and we’d still be staring at plain-text emails on black and white Blackberry devices.

It’s going to be a very loud fall season as the mobile providers and the FCC battle out these proposed rules.  The end result will have a huge effect, either good or bad, on how flexible and feasible your mobile Exchange platform plans will be. Competition is a good thing, but it cannot be forced on the market at the expense of profits.  There must be a way to balance these scales, and it will need to be found before Net Neutrality can be forged in the mobile marketplace.

 

 

Update on Wildcard certificates

Not that long ago I talked about using wildcard certificates to allow you to move OWA and ActiveSync services from one physical server to another.  Since single certificates are assigned to a single server, failing over or moving to another server would cause the clients to suddenly lose SSL connectivity, as the certificate would not match up, and ActiveSync devices cannot pop up the error about a non-secure connection. OWA can, but it can be troublesome with end-users who suddenly start seeing security warnings.

Following up on this theory of using a domain-assigned wildcard certificate, research has shown that older Windows Mobile devices (WM 5 or earlier) cannot leverage these types of certificates at all.  WM 6 and higher can leverage this technology, but earlier versions were not coded with the required information to recognize that a certificate could possibly be assigned to more than one physical server or networked device.

So, for those using WM 6, OWA and Outlook Anywhere, you can use wildcard certificates to allow for services to move from server to server as required.  For those using earlier versions of WM (or the 3G iPhone - though the jury is still out on that one), you must use server-specific certificates, and re-configure the devices' ActiveSync connection if the server itself moves. 

None of this impacts Blackberries, as they authenticate via the RIM network, and not directly to the Exchange servers.  If you're using Blackberries, wildcard certificates offer the ability for all other mobile systems (OWA, Outlook Anywhere, etc) to move with your servers in the event of a loss of a particular physical machine, while RIM will handle moving the Blackberry devices.

Long story short, if you're on WM 5 or earlier, be ready for a few support calls when you need to move the services or fail over between servers - even if you use wildcard certificates.  If your users are on the new iPhone systems, be sure to keep a close watch on Apple's forums, as new information is being discovered every day.

Get wild with wildcard certificates

Most organizations that are considering securing their email systems are also looking at SSL certificates to aid in that effort.  Security certificates allow for encrypted communications using Outlook Web Access, Outlook Anywhere (RPC over HTTPS) and ActiveSync devices like Windows Mobile Smartphones. The issue is that a normal SSL certificate is bound to a single server, which means you'd have to obtain a signed certificate from a provider for each server you want to put into the solution.

You could use self-signed certificates to get around the issue of having to purchase individual certificates, but only at a cost.  Many applications will not accept self-signed certificates, and even Microsoft-controlled systems like OWA will kick up several layers of security errors - which will increase support headaches for you and your staff.

Alternately, you can obtain a Wildcard Certificate from a provider, which will allow you to use one certificate for multiple servers in your organization.  These certificates are more expensive than single-server options, but can give you much more flexibility with things like server rebuilds, migrations, and failover.  The only restriction is that the servers will have to be part of the same organization. That means that all the servers will have to be part of the same domain and/or forest in the sense of Active Directory.

Wildcard certificates can be defined at either the organizational level - such as *.wildcarddomain.com - or masked at another level, www*.wildcarddomain.com for example.  With the first example, all server identities that are part of wilddcarddomain.com will be able to share the certificate.  In the second, www1, www2 and even wwweb.wildcarddomain.com will be able to share the masked certificate.  Which you use will depend on the depth of security you are looking to implement, as more specific masks allow for less chance of someone spoofing the certificate for a foreign machine.

Once you install the wildcard certificates, you can allow services to move between servers within the same organization without breaking security. This can be extremely helpful for both migrations and disaster recovery, as you can have both of the servers shielded under the same certificate, and therefore you will not get naming errors when the users move or fail over. 

In a worst-case scenario, you can use single-server certificates on a migration or failover target, but your end users will get errors about the certificate being valid, but assigned to a different server name than the one they are connecting to.  You can then purchase another certificate after the fact and assign it to the target server to remove the error if/when needed.  However, wildcard certificates give a much better option for flexibility to you and your team.