BES 4.x Out of Office Agent Integration Breaks when Mailfile owner set to Editor in ACL (Update: Fixed in 4.1 SP5!!!)

Do you use the Out of Office functionality that is integrated into the BlackBerry? It's a wonderful feature, unless you have followed IBM's recommendations on security and limited your mailfile access to Editor.

How could this possibly affect the Out of Office agent usage from the BlackBerry you ask? Well let me tell you it took me quite awhile to figure this out. I'll start from the beginning.

The Out of Office agent is an agent that runs in your mailfile, and when enabled responds to people who send you mail while you are out. In versions of Domino prior to R6 "Manager" mailfile access was required in order to enable this agent. A specific field "$AssistFlags" in the agent was set to "E" to signify that the agent was enabled, and the "E" was removed from this field to signify that the agent was disabled.

For Domino R6 and later, however, a mechanism was put into place which allowed an organization to ratchet down user level access to Editor, which tightened up security and also reduced helpdesk calls about users deleting their own mailfiles and other ridiculous things that happen when users have too much power.

However, with Editor access users would no longer be able to enable / disable their out of office agents. A workaround was developed - a complex one which I will try not to go into here in too much detail - which allowed for the AdminP process to assign this access to the user. This involved adding a field called "$AssistFlags2" (creative, no?) to the agent.

The purpose of this flag was to tell R6 clients and above whether the agent was enabled or disabled, regardless of whether the "E" was in the older "$AssistFlags" field. New agent icons were added, so now instead of seeing only a checkmark to signify enabled or a red circle-X to signify disabled, you would now see an additional "check-5" icon.

This "check-5" icon signifies that the agent is enabled for R5 and below, but disabled for R6 and above! Yes I know this is ridiculous but that is how software coding is sometimes.

The fields would be set as follows (you can ignore the small "s" in $AssistFlags, I am not sure what that is for but appears to be unrelated to the agent status):

$AssistFlags = Es
$AssistFlags2 = D





These field settings mean that the agent is disabled for R6 and later, who know to check the $AssistFlags2 field for the real status, but enabled for prior versions that didn't know about the $AssistFlags2 field and ignored it, using the "E" in $AssistFlags.

The problem here is that the BES server acts as if it were an R5 or prior Notes client in this regard. When enabling or disabling the agent, it adds or removes an "E" from the $AssistFlags field, and completely ignores the $AssistFlags2 field.

Assuming the AdminP process has run properly the first time and setup your Editor level OOO agent access, the consequences of this are the following:

1) OOO is currently disabled, the agent icon shows a "check-5", and the fields are set to :

$AssistFlags = Es
$AssistFlags2 = D

2) A user enables the OOO agent from the BlackBerry. The BES server attempts to set the $AssistFlags field to "E", sees that it is already there, and then does nothing. The BES server does not, however, remove the "D" from $AssistFlags2, so we have the same result:

$AssistFlags = Es
$AssistFlags2 = D

The R6 Domino Mail server will use the "D" value and not run the agent, the Lotus Notes R6 client will also see the "D" value and show the agent as disabled, yet the BlackBerry shows that it is enabled. So we have a remote user who thinks the agent is activated, gets back into the office 2 weeks later, and discovers that it never sent a single message out. Bad!

Another issue comes into play as well, in the following sequence of events:

1) OOO is currently disabled, the agent icon shows a "check-5", and the fields are set to :

$AssistFlags = Es
$AssistFlags2 = D

2) OOO is enabled by the Lotus Notes R6 client, which leaves the $AssistFlags field alone but removes the $AssistFlags2 field. This change now shows the agent icon as a "check", and the fields are set to:

$AssistFlags = Es
[$AssistFlags2 field deleted]




2) A user disables the OOO agent from the BlackBerry. The BES server removes the "E" from the $AssistFlags field, however it does NOT create/populate the $AssistFlags2 field with a "D" to tell R6 clients that the agent is disabled.

$AssistFlags = s
[$AssistFlags2 field still missing]




3) The next time the user enables the OOO agent using the Lotus Notes R6 client, an interesting thing will happen, it will kick off the AdminP process once again to enable the agent for Editor level access. You see the familiar blue text and the enabling of the agent requires a delay to implement.

I believe it does this because the BES, when disabling the agent, for some unknown reason also clears the "Run on Behalf of" field, which is needed to allow the agent to run as the user:


In addition to this, when AdminP finally processes the request, grants the access, and enables the agent, the BES server does not pick up this change, for reasons which escape me at this point.

So the result of this sequence is an OOO agent that is enabled on the mail server, shows as enabled on the R6 Notes client, but shows as disabled on the BlackBerry device. This is also bad.


Here is what I believe needs to be done to resolve these issues:

1) Modify the BES server logic such that it acts like an R6 client, that is aware of the $AssistFlags2 field and modifies it instead of (or in addition to) the outdated R5 $AssistFlags field. Of course this might necessitate the minimum Domino mail server level be at R6 or higher, but since we are coming up on R8 and even R6 support is expiring, I don't see this as a huge issue.

2) Ensure the BES server logic does not clear the "Run on Behalf Of" agent field when disabling the OOO agent.

3) Ensure that changes made to the OOO agent by the AdminP process are picked up by the BES server, such that the Domino Mail Server/Notes Client and the BlackBerry device are always in sync as to the status of the OOO agent.


Until these issues are addressed, I see no easy way of programmatically blocking my users from using the OOO functionality on the BlackBerry device, which results in the above issues. My last resort is to send a mass email saying that the BlackBerry OOO feature (which people love) is broken and to always use the Notes client. Unfortunately this will result in higher helpdesk calls, since we always have people leave the office who forget to enable their OOO and end up calling us to enable it for them.

If anyone out there can shed additional light on this issue or possible workarounds, feel free to let me know. I am also actively working on this with RIM, and hope to have it recreated in their environment and logged as an SDR so that it may be addressed in a future service pack.

GPS Reporting to BES Server in 4.1 SP3 IT Policy

Upon upgrading to 4.1 SP3, I noticed that the IT Policy has a new Policy Group named "Location Based Services". Under this new group are the following options:



Disable BlackBerry Maps: (Default: False, Requires: Device code 4.0.0 and higher)

Enable Enterprise Location Tracking: (Default: False, Requires: Device code 4.2.1 and higher)

Enterprise Location Tracking User Prompt: (Default: "Your Location is now being tracked at the server", Requires: Device code 4.0.0 and higher)

Enterprise Location Tracking Interval: (Default: 15 Minutes, Requires: Device code 4.2.1 and higher)

I was very excited to see these built in options, which allow tracking via GPS without having to purchase a third party solution. I enabled the tracking, leaving the interval set to 15 minutes, but changing the apparently mandatory notification to "Please call (312) XXX-XXXX to return this device." This serves the purpose of providing some sort of notification, but not letting the user know that their device location is being tracked. I named this policy "Device Tracker" so that I can use this to locate stolen devices, it is not used as a general purpose policy.

I then applied this policy to single user who uses a BlackBerry 8800 device at code level 4.2.1. Everything works great... except for the fact that I have no idea where the GPS information is logged to on the BES server. I would suspect the SQL server in a device related table, but cannot find anything.

I have asked RIM and am awaiting a response... I guess they are not sure either where this information is stored. Once this tiny issue is sorted out I am going to have some fun with Google Maps mashups, making tracking lost or stolen devices that much easier.

BES Domino 4.0 / 4.1 Interoperability Issues - Updated 6/1/07

I upgraded one of my main BES servers to 4.1 SP3 HF1 last weekend, but left the other two at 4.0 SP6 HF4. Since the DB Schema was upgraded, we needed to upgrade all of our BB Manager workstations to 4.1 as well.

Now, we are seeing an issue where, using the locally installed 4.1 Manager, we cannot provision a new user added to one of the 4.0 servers using the USB cable. The service books get assigned but the rest of activation / synchronization / prepopulation does not kick off. Wireless activation of new users on the 4.0 servers also seems erratic.

BTW, this upgrade was performed after getting the word at WES that 4.0 and 4.1 servers sharing the same SQL database is OK, since they have many larger accounts than ours and they can't expect them to upgrade 10's of servers at the same time.

Well apparently it is OK for existing users but not newly added users! RIM's tech's response now is: Well it can work but it is not recommended, and the "workaround" is to upgrade the remaining servers to 4.1.

Update 6/1/07: Apparently the tech I spoke with on this issue was incorrect, RIM verifies that they fully support a mixed 4.0/4.1 environment as they told me at WES just a few weeks ago. This issue with USB activation has to do with an identified bug in the 4.1 SP3 BlackBerry Manager console, which is fixed in the upcoming 4.1 SP4, but also can be worked around by downgrading to the 4.1 SP2 Manager console. Thanks to RIM for clarifying this for me.

BlackBerry ID Numbers... MOST of them

BlackBerry devices are multifunction, convergence devices. This being the case, they have multiple methods for identifying the different parts that make up the device. Here is a guide to the different serial / ID numbers used by the different components that make up the BlackBerry device:

Model: 4 digits + letter, tied to hardware, identifies hardware type (digits / letter) & carrier (letter)

PIN (Personal Identification Number): 8 Hex characters, tied to hardware, used for routing within the RIM network

IMEI (International Mobile Equipment Identity): 15 digits, tied to hardware, used to identify a
GSM device

Phone Number: Variable, tied to SIM card, used for voice calling (duh)

IMSI (International Mobile Subscriber Identity): 19 digits, tied to SIM card, used to identify a particular carrier account

FCC ID (Federal Communications Commission ID): 9 alpha digits (starts with L6A for RIM), tied to hardware, used to register wireless device with government agency

BT MAC (Bluetooth Media Access Control): 6 Hex pairs, tied to hardware, used to identify Bluetooth personal area network device

Missing Device Phone Number fields in BB Manager

This is a simple question that has devolved into a mini research project ( like so many do!)

We are trying to reconcile carrier billing info with active BlackBerry users, and are finding many SIM card accounts we are paying data plans for but we don't know who is using the device or where it is.

I use the BB Manager to find devices by carrier phone number which is easy most of the time, however many accounts (229 out of 1905 or about 12%) do not have the "phone number" field populated in BB Manager, these are the accounts I am trying to track down.

Results so far:

1. I have discovered that the "My Number:" field at the top of the Phone app pulls directly from the SIM card's "Phone number" field. If present in the Phone app display, the "My Number:" field then populates the BB Manager account "Phone Number" field in the SQL database.

2. Interestingly, this field can be user edited via Options / Advanced / SIM Card / Edit SIM Phone Number. Also interestingly, it appears to be a display field only and does not change the phone number that the SIM card actually uses.

3. Normally this SIM Card "Phone Number" field is populated by the carrier during the provisioning process, and before they ship the SIM Card out. In some cases, however, they sloppily forget this step which results in a missing SIM card field, and thus an "Unknown Number" on the Phone app display, however the SIM & voice calling work just fine, as again the true number is encoded into the SIM and unrelated to the "Phone Number" SIM display field.

4. It is easy enough for the end user to edit and add their phone number if nonexistent, or change it if the number associated with the SIM is changed by the carrier.

The issue for me is that I don't want to try to contact >200 users and have them run through a manual process of adding this field with the proper number. I am looking for an automated way of pushing it out. There doesn't appear to be any hack for this, so I will have to contact the wireless carrier's and see if they have a solution.