Welcome to Kraft Kennedy

Over the last few months, there have been numerous reports of significant BES message delivery delays when running Exchange 2010, sometimes in excess of 20 minutes.  In addition to the primary symptom of message delivery delays to BES handhelds, environments experiencing this issue saw extremely high RPC Averaged Latency during periods of high BES utilization.  Despite being generously sized for RAM on Exchange 2010 Mailbox servers already, many firms dramatically increased RAM in their Mailbox servers to compensate for this issue, with amounts totaling 36 GB for 500 active BES users in many cases.  More information on some of the history and user experience with this issue can be found here.

While there were a number of technical reasons for this problem, a primary reason was changes to named properties in Exchange 2010.  To avoid legacy issues with finite numbers of named properties (see my previous blog post for some more information), functionality was changed in Exchange 2010 such that named properties are now stored per mailbox instead of per database and anonymous headers are not promoted so as to avoid issues with reaching the finite limits.  Since BES leverages a number of named properties for its own functionality, the latter caused some significant performance delays when BES attempted to query non-promoted named properties.

Microsoft and RIM have been working very closely together to remediate this issue and I’m happy to announce that some significant progress has been made.  If you are experiencing this problem currently, upgrading to MAPI/CDO 1.2.3 on your BES (see here) and BES itself to 5.0.2 Maintenance Release 4 (see here) should provide significant improvement on the BES functionality side.  Additional updates from Microsoft and RIM will be coming in the near future but, in the interim, these updates should help improve performance dramatically.

Update: The new MAPI/CDO was released as an updated version of 1.2.1, not version 1.2.3 as expected.  When downloading and installing the new MAPI/CDO, make sure you are installing version 1.2.1 dated 2/25/2011 and versioned 6.5.8211.0 (not the one dated 12/9/2009 and versioned 6.5.8147).  The link above will direct you to the correct version.

Research In Motion has released new guidance for the BlackBerry Enterprise Server (BES) service account after upgrading to Exchange 2010 Service Pack 1.  While BES does not yet formally support SP1, it can work with a few changes to the custom Throttling Policy created for the BES service account.  Please note that, while BES can work with Exchange 2010 SP1, you must strongly consider RIM’s current support statement before completing an upgrade to SP1.  It is strongly encouraged to wait for formal support from RIM before upgrading a production Exchange 2010 environment to SP1 if BES is a critical application in your environment.
Continue reading…

One of our SPG consultants, Joe Szabo, recently noticed an issue where even though it looked like our BES 5.0 server should be prepopulating users’ new Blackberry devices with 200 previous email messages it, was not doing so.  In the Blackberry Administration console, he expanded BlackBerry Solution Topology > BlackBerry Domain > Component view > Email and checked to ensure that the server was set to prepopulate 200 previous messages.  Joe did some research and found that by default Blackberry only prepopulates messages for new users on their first Enterprise Activation.  It will not prepopulate messages if those existing users activate a new Blackberry device.

To force prepopulation for all users, Joe added the following registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Agents]
“ForceMsgPrepopOnActivation”=dword:00000001
“ForceMsgPrepopDays”=dword:0000000e
“ForceMsgPrepopMessages”=dword:000002ee

On an x64 server, you would add these entries under:

[HKEY_LOCAL_MACHINE\Software\WOW6432Node\Research In Motion\BlackBerry Enterprise Server\Agents]

We have confirmed that this works for BES 5.0, but it should work for older BES versions as well.

I have been using the Nexus One with Android 2.1 for a month and a half in order to get a good insight into the real workings on the Android operating system. To sum up my experience the Nexus One phone is a great piece of hardware but the Android OS still has a long way to go in order to be as functional as a Blackberry or an iPhone.

Continue reading…

Research in Motion (RIM) offers two ways of writing applications for BlackBerry devices–Native Java, and the Microsoft Visual Studio plugin.  As a VB.Net developer, I was tempted to go the Visual Studio plugin approach, but I decided against it for the following reasons:

• It’s geared more towards rapid forms-based applications that communicate by web services.
• It requires the user to be on a BlackBerry Enterprise Server.
• It does not provide access to all of the APIs and BlackBerry features that you get with Java; for example, camera, phone, Bluetooth, address book, GPS, BlackBerry Maps, and BlackBerry Message features.
• It doesn’t support the BlackBerry Storm touch screen and accelerometer.
• Debugging and deployment is more difficult, and the Visual Studio plugin only comes with a BlackBerry Bold simulator.  The Java tools come with a BlackBerry Storm simulator.

For these reasons, to be able to debug for the Storm, and to have access to the entire BlackBerry library, I decided to go with the Java approach.  The transition is quite easy, once you get the development environment in place and write your first test application.  The BlackBerry website has a lot of good information for developers, if you’re able to find it.

I found that this page has everything you need to get started developing BlackBerry applications:

http://na.blackberry.com/eng/developers/resources/tutorials.jsp#tab_tab_development

Rather than copy and paste information from their guides, I’ll just point out some of the things I wish were clearer in each document.

Continue reading…