Managing BlackBerry Configuration Settings Remotely - Part Three

To begin, of course, a Disclaimer: The BES SQL database is the heart of your BES environment. Making changes to it outside of the UI is not supported by RIM and can do irreparable harm to your entire BES environment. The following is for informational purposes only, and I am not responsible for the thousands of midnight telephone calls you will get from your BlackBerry users when an errant SQL command has rendered your BES servers mere hunks of plastic and metal, and transmogrified into a CLM [career limiting move]. I for one will not be implementing these findings in my production environment! Now, onto to the madness...

Since we have discovered where the configuration setting "Hide Sent Messages" lives in the SQL database, let's try to modify it and get it pushed out to the device. First, let's reset the option back to the default of "No" and restart the wireless to get it changed in the SQL database. Here is the device screenshot showing the default settings:


And here is the SQL data, showing that the '1' has been changed back to a '0':

0x350000010101000001010001000300010200051E0001000600020008
01000100090102000B000002000C020002000D000001000E00000000

Now, let's use a SQL command to update this string to change the '0' back to a '1':


Perhaps if we restart the wireless on the device the change will sync down?



Alas and alack, the change did not come down. Oh well, that would have been too easy. Let's take a deeper look into the SQL tables to see where we can go from here. I see a promising table named SyncConfig...and it appears to... wait for it... hold the Synchronization Configuration settings! Just what we need:

I see there are many lines associated with UserConfigId 9, which is my single test user. I also see a column titled SyncDataSourceId, I wonder what the numbers in this column refer to?

After doing some digging I discover the SyncDataSource table, which contains mappings between the numbers in the SyncDataSourceId column and the names of these sources.


What we are interested in would be the Backup data source, or number 11109, as this is what we are working with. This leads us to row 102 in the SyncConfig table.

Now the question becomes, what do the other columns in this table mean, and what can we do with them? SyncType and ConflictResolution appear especially intriguing given what we are trying to accomplish here.

By changing some settings on the device and watching the effect on this table for other unrelated rows, I discovered that the SyncType field has three options available:

1 = Server to Device
2 = Device to Server
3 = Bi-directional

In our case, the 11109 Backup row in this table indicates '3', or Bi-Directional sync. I would have expected to see this set to '2' for one way backups from device to server only. However '3' may make sense, as the backup is from device to server for the most part, but can be from server to device when changing devices for instance.

Similar to SyncType, the ConflictResolution column appears to have two options available:

0 = Server Wins
1 = Device Wins

Our row 102 shows a '0' in this column, which again is a little unexpected as I assumed that the server side was a backup to what is on the device, so the device should always win in a conflict. Perhaps there are good reasons for these non-obvious settings that I am not aware of.

In any case, we have still updated the data in the SyncBackupRestore table but it has not sync'ed to the device, even though the sync settings shown above indicate that a) sync is bidirectional and b) the server will win on a conflict. So really this should just work without any changes, however we need to figure out some way of 'kicking' off a sync.

We know that when you disable and then re-enable synchronization from the device or BES manager for other functions such as Address Book, it will kick off an initial sync. The issue here is that there is no way through the GUI of the device (or the BES Manager) to kick off a Backup sync, as this is an underlying process not available to the end user or administrator.

Why don't we try to just flip the ServerEnabled setting from 1 to 0, and then back to 1 to see if this does it:


Unfortunately, looking at the logs it doesn't appear that this trick did anything. I see the following lines in both the SYNC and CBCK logs:

[46077] (01/31 13:09:36.021):{0x1178} [SYNC-Gate] Finished user config change check. No change detected.
[40039] (01/31 13:20:21.856):{0x1EE0} CheckResponseRcvd - no changes detected for any users.

Let's move on and try to change another field, how about we try to change the SyncType from '3' (bi-directional) to '1' (server to device):


Wow! Within a minute or so of making this change there was a flurry of activity in the SYNC and CBCK logs. I notice this line as well:

[46078] (01/31 13:26:53.092):{0x1178} [SYNC-Gate] Finished user config change check. Change detected.

Turns out this triggered a full synchronization, such that everything on both sides was compared and the changes pushed down to the device. Going back into our Message List Options screen, we are presented with:





As Dora would say, "Lo Hicimos! We did it!"






So in summary, we were able to push this change to the device by doing the following:

1) Locating the option in the data string of the particular settings database within SyncBackupRestore
2) Updating the data string with the particular option set, via SQL commands
3) Modifying the SyncType from '3' to '1'

Now, like a good boy scout, we must remember to clean up after ourselves. To get this to work we had to break the default SyncType, so let's set it back to '3' so that any future changes on the device continue to be backed up:


Next Up: Decoding the Data string in the "Message List Options" database to map out all the different option settings.