rhinonowbot

The Trials And Tribulations Of The Blackberry Desktop Manager For Mac

BlackBerry Ltd: Company Gone Bad Brief background. The Situation Company Rebrand and takes on Apple head on -Established in 1984 as Research In Motion Limited by Mike Lazaridis -Headquaters is based in Waterloo, Ontario, Canada -Work with other companies in the late 90's to make wireless data network into a two-way paging and wireless e-mail network.Product got it's name from the resemblance of the keyboard's keys to the druplets of the blackberry fruit -Popular with business and governments thanks to it's encryption (Outlawed in several countries) Evolution of the Blackberry devices Trials and Tribulations: Beggining of the End? The Golden years Early Success What brand smartphone do you have? Apple iPhone Android-based device Windows-based phone Blackberry What do you like about your smartphone? Features Hardware (CPU, screensize, camera, etc.) Applications (games, social media, video sharing, etc.).

  1. The Trials And Tribulations Of The Blackberry Desktop Manager For Mac Windows 10

With pre-BlackBerry 10 handhelds still so prevalent in the enterprise today, it is a natural choice to keep an existing Black Berry Enterprise Server (BES) 5 infrastructure when upgrading to Exchange 2013. Even considering that BlackBerry 10’s ActiveSync-based synchronization is much more efficient and less resource intensive than RPC/MAPI used by BES 5, not all corporations can justify investing in replacing all their handhelds with BlackBerry 10 (and possibly deploying BES 10), or another platform such as Android, iOS, or Windows Phone.

In this blog, I will share the trials and tribulations I experienced on a recent customer engagement trying to make BES 5 work while migrating an Exchange 2007 organization to on-premises Exchange 2013. At the end, I will summarize the steps you should follow in order to make BES 5 work with Exchange 2013. Scenario The customer originally had an Exchange 2007-based organization with approximately 3,600 mailbox-enabled users, a single hub/CAS server and two standalone mailbox servers (no high availability). A single BES 5 server running on Windows Server 2008 Standard 32-bit served nearly 600 BES 5 users, with mailbox sizes ranging from a few megabytes up to 25 GB.

Life was good for all Exchange 2007 (BES and non-BES) users. Before deploying Exchange 2013 we confirmed that BES 5 was supported by checking the.

There we found a note saying that Exchange 2013 “stand-alone” is supported starting from BES 5.04 MR2. The KB33406 article had the following note: “Standalone configuration refers to a BlackBerry Enterprise Server instance servicing only Exchange 2013 mailboxes.

If running Microsoft Exchange in mixed mode, a separate BlackBerry Enterprise Server instance will be required to service pre-Microsoft Exchange Server 2013 mailboxes.” Note: Unfortunately, after a long and painful journey we figured out that this is not exactly the case. Even if you have a BES 5 instance serving only Exchange 2013 mailboxes, there are multiple steps you need to follow in order to make them coexist properly, some of them are undocumented and some are scattered among multiple KB articles. Ga-8i915pl-g drivers for mac.

It is interesting to note that BlackBerry updated KB33406 and it no longer shows the “stand-alone” definition. It just mentions: “For more information on supported configurations of the BlackBerry Enterprise Server, see the Compatibility Matrix”. However, the Compatibility Matrix still shows that only Exchange 2013 “stand-alone” is supported starting from BES 5.04 MR2.

Because of that note on KB33406 we decided reconfigure the existing BES instance to connect to Exchange 2013 and to migrate all BES users to Exchange 2013 on the same batch (cutover migration). We deployed a highly available two-DAG Exchange 2013 configuration with each server having all roles collocated. Afterwards, we followed all procedures documented by Blackberry to configure BES 5 to work with Exchange 2013 “stand-alone”: 1. Installed the latest Maintenance Release for BES 5 SP4 (5.04). Installed the latest “recommended” (by ) MAPI/CDO v6.5.8320.0 from May 2013 Update on the BES 5 server. Moved the BESAdmin account to Exchange 2013 4. Assigned the required permissions for the BESAdmin account to all Exchange 2013 databases.

Created a Throttling Policy and assigned it to the BESAdmin account , which means “remove all throttling” for the BESAdmin account. Configured BES to leverage Exchange Web Services for Calendaring. Configured BES to leverage RPC/HTTP. On “Task 2”, we’ve chosen “Standalone Mode” because the BES instance would service only Exchange 2013 users: RPCHTTPProxyMapBES REGSZ =.=Where outlook.domain.com is the Outlook Anywhere FQDN. Migrated a pilot BES user to Exchange 2013 and tested. Migrated all BES user to Exchange 2013 and used Exchange’s built-in mailbox auto-provisioning to evenly distribute the mailboxes amongst all mailbox databases. Migrated additional non-BES users to Exchange 2013.

Minor Issues Even after following all documented steps, we experienced multiple issues trying to make BES 5 work with Exchange 2013. Let’s start with the easy ones: 1.

We could not reconfigure the MAPI profile for the BESAdmin account. We figured out the MAPI/CDO v6.5.8320.0 (from May 2013) recommended by did not work. The BES Server Configuration tool could not connect to Exchange 2013 and failed the “Check Name” operation for the BESAdmin account. For our surprise, the previous version from February/2013 worked like a charm.

If you experience this issue, please remove MAPI/CDO v6.5. 8320.0 (May 2013) from your BES server and install the previous one from February/2013, v8.03.0. Meeting invitations from external senders started to be delivered as regular email messages. To fix this issue, set the users’ Calendar Processing ProcessExternalMeetingMessages parameter to $true. You should also make sure that AutomateProcessing and AddNewRequestsTentatively are set to $true. Tribulations Now is when the email experience went really bad, not only from the BlackBerry handheld, but also from the Outlook 2010/2013 clients. Users started complaining about:.

Emails delivery being delayed for several minutes (sometimes hours) on their handhelds. Failures (red “x”) while trying to send emails from their handhelds. Calendar and contacts not synchronizing to their handhelds. Sluggish Outlook client, for online mode users (BES and non-BES users). Frequent Outlook disconnects, for cached mode users (BES and non-BES users). Troubleshooting with Microsoft A quick investigation on the MSExchanegIS Store RPC Average RPC Latency performance counter for all mailbox databases showed high averages and multiple spikes reaching unbelievable marks like 98,231 milliseconds = 98.321 seconds (!!!), as shown in the figure below (EXCHSRV01): The RPC Average RPC Latency performance counter indicates the RPC latency, in milliseconds, averaged for all operations in the last 1,024 packets.

It should not be over 100ms for cached mode environments and 50ms for online mode ones. Since BES 5 is 100% online mode, the average should never go over 50ms. A Perfmon capture from another server (EXCHSRV02) shows averages way over 50ms, such as the one below indicating 438ms: Initially, we thought that something could be wrong on the Exchange and/or AD side.

Usually, high RPC Average RPC Latencies are caused by disk bottlenecks, network latencies, and LDAP search latencies (underperformed domain controllers). After numerous hours with Microsoft’s Premier Support collecting Perfmon logs and process dumps, no bottleneck or latency could be identified.

TheMac

After analyzing a memory dump for an Information Store Work Thread, the Microsoft Premier Escalation Engineers detected the BESAdmin user generating an excessive number of calls to the QueryRow function. Troubleshooting with BlackBerry We decided to call BlackBerry support in order to try to identify if something was wrong on the BES side.

The Trials And Tribulations Of The Blackberry Desktop Manager For Mac Windows 10

At first, we identified that BES was not using the right Exchange server name while trying to access the users’ mailbox. Exchange 2013 uses the user’s mailbox GUID (along with along with a domain suffix), and no longer the FQDN of an RPC endpoint, as the mailbox server name in a client MAPI profile.