BlackBerry Enterprise Server (BES)

Aloha! I am back blogging after a holiday in Hawaii…

I was working with a client who had an end user with a calendar pre-population issue.   Recurring calendar appointments did not pre-populate after resetting the calendar nor after an enterprise activation.

Via  a command prompt, I ran the Calendar Synchronization Tool located under the tools sub-folder in the BES installation media folder C:\Research In Motion\BlackBerry Enterprise Server 5.0.3\bundle0033\tools.  I ran each command below:

TraitTool -user affecteduser@mycompany.com-trait ExchangeSmartSyncEnable -set true
TraitTool -user affecteduser@mycompany.com -trait ExchangeSmartSyncSchedule -set Daily
TraitTool -user affecteduser@mycompany.com -trait ExchangeSmartSyncDays -set 365
TraitTool -user affecteduser@mycompany.com-trait ExchangeSmartSyncTriggerHour -set 23
TraitTool -user affecteduser@mycompany.com-trait ExchangeSmartSyncSendUpdate -set true

This command ExchangeSmartSyncDays indicates how many days in the future BES will scan the user’s calendar and populate the device.  By default it is set to 30 days.  After the commands executes, you can see the smart sync kick off with the following log line in the MAGT log:

[40000] (01/26 23:07:00.338):{0x2A00} {affecteduser@mycompany.com} SmartSyncFireOff – SmartSync triggered – SyncDays=365, Sched=Daily, SendUpdate=1

It took 7 minutes to complete and we can see the additional 41 calendar appointments sent to the device:

[40583] (01/26 23:07:08.197):{0x19E4} {affecteduser@mycompany.com}  Sending packet to device, Size=60, Tag=11088654, TransactionId=-819881007
[40279] (01/26 23:07:08.197):{0x19E4} {affecteduser@mycompany.com} SubmitToRelaySendQ, Tag=11088654
[30249] (01/26 23:07:08.275):{0x19E4} {affecteduser@mycompany.com} Sending 15 calendar entries to the device, size=15642
[40583] (01/26 23:07:08.275):{0x19E4} {affecteduser@mycompany.com} Sending packet to device, Size=15679, Tag=11088655, TransactionId=-819881006
[40279] (01/26 23:07:08.275):{0x19E4} {affecteduser@mycompany.com} SubmitToRelaySendQ, Tag=11088655
[30249] (01/26 23:07:08.291):{0x19E4} {affecteduser@mycompany.com} Sending 11 calendar entries to the device, size=15241
[40583] (01/26 23:07:08.291):{0x19E4} {affecteduser@mycompany.com} Sending packet to device, Size=15278, Tag=11088656, TransactionId=-819881005
[40279] (01/26 23:07:08.291):{0x19E4} {affecteduser@mycompany.com} SubmitToRelaySendQ, Tag=11088656
[30249] (01/26 23:07:08.322):{0x19E4} {affecteduser@mycompany.com} Sending 15 calendar entries to the device, size=3933
[40583] (01/26 23:07:08.322):{0x19E4} {affecteduser@mycompany.com} Sending packet to device, Size=3970, Tag=11088657, TransactionId=-819881004
[40279] (01/26 23:07:08.322):{0x19E4} {affecteduser@mycompany.com} SubmitToRelaySendQ, Tag=11088657
[40000] (01/26 23:07:08.322):{0x19E4} {affecteduser@mycompany.com} Sending CAL_SLOW_SYNC_DONE to device. SessionID=1327637227, Record counts=41

For more information, check out these KBs:

What is the BlackBerry Calendar Synchronization Tool ?

How to use the BlackBerry Calendar Synchronization Tool (Traittool.exe)

RIM is reporting an issue with a new feature in Exchange 2010 SP2.  The feature concerns the implementation of Address Book Policies which provides Global Address List (GAL) segmentation and customization of the GAL in Outlook and OWA.  When performing an address lookup from the BlackBerry, BES cannot filter based on Address Book Policies since the service account has access to the default GAL.  If address lookups on the device need to be restricted, they can only be restricted by company name.   Refer to this knowledge base article, KB15923, for more information.

I am working with a customer with a 5.0.3 BES.  Over the last few months, 9780′s and 9800′s, about 20 users in total, would get  software updates on the device.  On the device when attempting to update the software, a message prompt displays indicating that software updates has been disabled by your administrator.   In the BlackBerry Administration Service web console, the BlackBerry device deployment setting was set to Yes:

So why were certain handhelds receiving software updates when they should not?  Checked the IT Policy and under the Wireless Software tab we see the following settings:

After an escalation with RIM Software development, there is an issue with BAS that hides certain IT policy settings when the the BlackBerry device deployment setting was set to Yes.  By setting it to No there are additional IT policy settings under the wireless software tab.

The Allow Security Updates setting is set to Allow All by default.  This setting will override the BAS setting.  So, until the issue is fixed this setting has to be set to Accept None along with Allow Non Enterprise Upgrade set to No.    This issue is being tracked by the following DevTask: DT2515469.

Have a happy new year!!!

RIM updated their Compatibility matrix on December 12th to include the new MAPI/CDO version 6.5.8244.0.  It is the recommended MAPI/CDO version for 5.0. SP3.  The previous version of MAPI 6.5.8211.0 is still supported.

On December 5, 2011, MS released SP2 for Exchange 2010.   RIM still has not updated their Compatibility Matrix but the new MAPI/CDO release last week was probably in response to SP2 for Exchange 2010 release.

I will update this post if there are reported issues with BES and Exchange 2010 SP2.

A few days ago Microsoft released a new version of MAPI/CDO.   The version number is 6.5.8244.0.  I have not seen any RIM Knowledge Based articles concerning this new version of MAPI/CDO nor has the Compatibility Matrix for MS Exchange  has been updated with the new version.   I will keep you posted.

Today RIM announced BlackBerry Mobile Fusion which will provide multiple device management for BlackBerry, Android, and iOS platforms.  Mobile Fusion will provide a similar web base console like the BlackBerry Administration Service (BAS) in BES 5.0.x.  This new mobile management system should extend BES life cycle and provide inclusive management for the invasion of Android and iOS devices and tablets penetrating the enterprise marketplace.

It seems RIM realizes that it is more profitable providing software and business solutions like IBM than just hardware.   Plus, with Bring Your Own Device (BYOD) to work, RIM can now support the slew of Android devices and tablets along with the iPhone and iPad.  I hope to take part in the beta program for BlackBerry Mobile Fusion and see what features it has.

If I get into the beta program, I will blog about BlackBerry Mobile Fusion.

A major shift in 6.0 and 7.0 handheld code  is simplified web browsing.  In previous versions of handheld code, under the browser options, the type of browser could be selected such as BlackBerry Browser (MDS CS), or the Internet browser.  Since there is no option to choose, there can be issues when a 6.0 or 7.0 handheld attempts to access an internal secure site.

A client reported an issue with logging into a custom made application.  There were 3 users affected one from Thunder Bay and the other two from Saskatchewan.  From the handheld logs, I saw a tcp request for a secure internal website along with the error message-Access Denied: Insecure SSL Request.  Changed the TLS option on the handheld from proxy to handheld and there was no change.   After investigating, I found this KB on RIM’s website: KB24144

I created a test IT Policy  based on RIM’s KB23712 and I used .mycompany.com as the website for the IT policy.  The policy applied to the device but it didn’t work. After several trials, I specified the entire URL, https://mycompany.com:443. The updated IT policy applied and the end user was able to login into the application.

The one puzzling factor about this issue was the client’s IT policy prohibited other browsers so I don’t see how the handheld could pass the request over the Internet browser instead of using MDS for BES.

Other Resources:
BlackBerry Browser Selecting Browser Transport

Working with a customer who had an issue with message flow.  The messaging agents crashed reporting error code 5402.  In addition the MAGT logs were reporting the following error message:

[10000] (11/08 14:04:29.549):{0×178} i64GetConn: COM Error 0×80004005 – Unspecified error – Source: “Microsoft OLE DB Provider for SQL Server” – Description “Login timeout expired” – Command “i64GetConn”

Found out from the Active Directory team that there was a domain controller having issues with locking out accounts.  Fortunately, the BlackBerry Service account was not locked out but it did prevent the BESadmin account from authenticating to the remote SQL box.

The issue with the domain controller involved an journal wrap issue which was affecting NetLogon.  The domain controller had incomplete sysvol entries and issues with replication.  The fix was to regenerate the DC’s sysvol and reboot it.  After the reboot, SQL was able to authenticate BlackBerry Services then the messaging agents fired up and message flow returned!

For additional information about Sysvol and FRS, check out these links:

• How to troubleshoot Journal Wrap Issues
• How to rebuild the SysVol tree

Since RIM offered free downloads for the BlackBerry Service outage, a number of clients inquired about preventing 3rd party downloads of applications.   One client has two in house apps they push out to 1300 users.

In the release notes for BES 5.0 SP3, Dev Task 890899 fixed an issue in BAS:

If you applied the Disallow Third Party Application Downloads IT policy rule to a BlackBerry device, the BlackBerry Administration Service created a job task to remove existing third-party and RIM add-on applications associated with software configurations from the device. (DT 890899)

From my interpretation of this DT,  you can now apply the Disallow IT policy rule and any 3rd party application in a software configuration will not be removed from devices.  Well, that is not the case.  In my test environment BAS removed the two in house apps from the device since they were not RIM signed apps.

The least impacting workaround is to Disable AppWorld since most BlackBerry apps are downloaded through AppWorld.  This IT policy change does not prevent end users to download via OTA link from the Browser.   To lock down devices completely, you have to set the disposition for unlisted applications in the software configuration to Disallow.  This action will remove any 3rd party app including Facebook and Twitter from the device and prevent further downloads.  My client found this approach too drastic.

Since apps are specified in a software configuration they should be pushed to the device regardless of the Disallow 3rd party app rule.  I will pursue this with RIM’s escalation team.