The plans for May 2013
If all goes according to plan, RIM will release BES 10 in May 2013, unifying BDS, MDS, and UDS into one server. BES 5 (for legacy devices) will remain a separate server that can be managed by BES 10's admin console; operationally, they all will seem to be one server. BES 5 remains as a separate server mainly to let IT continue to use the BES servers already in operation and later remove them without affecting the rest of the BlackBerry management tools when all pre-BlackBerry 10 devices are retired.
But don't confuse "unified server" with "universal policies." iOS and Android devices will not support the same policies as BlackBerry 10 and PlayBook devices, which won't support the same policies as legacy BlackBerrys. Some policies will be universal because all four platforms -- BlackBerry 5 through 7, BlackBerry 10/PlayBook, iOS, and Android -- happen to support them. But BlackBerrys new and old alike support several hundred policies, versus a couple dozen for Android (it varies from device to device) and about 50 for iOS.
Holleran says you should expect BlackBerry 10 to support the vast majority of current BES policies. Some will go away because they become part of the OS itself, such as enabling the Balance service. Others may go away because hardware differences make them irrelevant, though he declined to give examples.
iOS and Android devices will gain more management capabilities in UDS than the current UDS offers, likely through the introduction of a managed client for those platforms, similar to what established MDM providers Good Technology and MobileIron do. Holleran said it's too soon to have determined exactly what new management capabilities will be added for iOS and Android devices within those client apps.
How EAS fits in
I've seen a lot of confusion around RIM's adoption of EAS. That's because EAS is used in two different ways.
First, you can use EAS policies in Microsoft Exchange or other server to manage a BlackBerry PlayBook or BlackBerry 10 device, just as you would an iOS or Android device. It's no longer a choice between using BES or nothing. Thus, smaller businesses will be able to manage BlackBerry 10 devices the same way they do their iOS and Android devices, using the same management tool they already have.
Second, BES 10 uses the EAS conduit to route its traffic between Exchange (or other server) and BES. In the familiar BES world, RIM is simply switching from its own communications protocol to the nearly universal EAS one. But the communication remains encrypted and does not mean BES 10 is using EAS policies. It is using just the EAS communications protocol.
In fact, Holleran explains that if you connect a BlackBerry 10 device to Exchange via BES 10, all EAS policies are automatically turned off except remote wipe. Instead, BES 10 policies are used. That prevents conflicts between EAS policies that may be set for non-BlackBerry users conflicting with BES policies set for BlackBerry users.
So why is remote wipe not disabled as well and replaced with the BES equivalent? Because a remote wipe is usually an urgent action that you don't want to slow down by having whoever in IT is on call having to check whether to use BES instead of Exchange. Plus, if a person is being unexpectedly terminated, has unexpectedly resigned, or is under suspicion of being a spy, you want to be able to issue the remote wipe to all devices at once, which you can do from Exchange.
Of course, these scenarios assume you have BlackBerry management via BES and non-BlackBerry management via Exchange or an MDM tool -- a common scenario today that RIM hopes will become less common if it can convince enterprises to consolidate all their device management under BES 10.
This article, "RIM's road map to unified mobile management," was originally published at InfoWorld.com. Read more of Galen Gruman's Mobile Edge blog and follow the latest developments in mobile technology at InfoWorld.com. Follow Galen's mobile musings on Twitter at MobileGalen. For the latest business technology news, follow InfoWorld.com on Twitter.