For security reasons, the IT Policy assigned to a device cannot be removed, even if the device is wiped. It is like a permanent tattoo. Like tattoos, however, they can be removed with a long and painful procedure. At least that is the way it used to be, nowadays we have more options. Let's go over them.
1) Wipe the device. Although the IT policy still exists on the device, the wipe process opens a "window" where an activation against another corporate BES server can overwrite the IT Policy with the new one. So for moves between organizations, you can only replace one policy with another, you cannot overwrite. For people who purchase previously corporate BlackBerry's on EBay for personal use this has been quite a hassle, as they are stuck with the old corporate policy which may be locked down significantly.
Which leads to...
2) Use the policy.bin file to clear the policy. This is a long and messy procedure (which I will not get into here) which mostly gets rid of the old policy, using the pre 4.0 method of a policy.bin file and Desktop Manager. I don't like this method because of the time it takes, and the lack of being in a known consistent state at the end. It is not really "just like new" when this is done, but can be enough for most people.
3) This is a new one. With a device OS later than 4.2.2, you can use the "Remote Wipe Reset to Factory Defaults" procedure documented in an older post here:
http://besdomino.blogspot.com/2007/10/remove-it-policy-new-feature-of-41-sp4.html
4) This is also a new method, which does not require an IT Policy assignment or a BES server at all, just the Javaloader utility in the RIM developer tools download. Note that an OS of 4.3.0 or higher is required, and the Javaloader utility itself must be the latest version.
Strangely, the utility does not list version numbers, so you just have to look for the available option:
resettofactory
Reset IT policy to factory settings
...when you run the executable without parameters to see if it supports it. If it does, then this command will wipe the IT Policy right off, and set it back to default:
c:\javaloader -u resettofactory
The future of IT policy removal is a bright one, indeed.
Friday, March 28, 2008
Friday, March 21, 2008
Multiple BlackBerrys per Mailfile?
Answer: Yes with some caveats.
First, you need to have fully separate BES environments, i.e. at least 2 SQL back end databases. This is easy for us as we have an EU BES environment on it's own SQL database.
If we need to set up an additional handheld for an end user, whether they need it temporarily for an assistant, or need to test a new device, then we add their account to the other BES environment and activate their device as normal. Since BlackBerrys are international devices there is no problem getting back to the device here in the U.S to finish activation.
Notes:
1) BlackBerry activation can take considerably longer due to the WAN if you are using another continents environment like we are. Don't freak out if it takes a few hours.
2) If you are doing OTA activation, temporarily disable the original BES account as it might pick up the activation email and discard it, leaving your remote BES server waiting forever. [BES servers are selfish and will NOC-block you if you let them. :)]
3) If these requests becomes common, you might want to think about a secondary local BES environment, perhaps running with an integrated MSDE, to support this service. Of course you need an additional SRP to do this.
4) Remember that these accounts cannot be failed/moved over to other local BES servers in a DR scenario, as they are on a separate database.
5) Don't forget about these "ex-pat" accounts if on a foreign BES server. The local admins may not ever delete them b/c they don't know who they are. So you should keep track of them and delete them when it looks like the service was cancelled or otherwise abandoned.
Other than these caveats, I have not seen any issues with this in our environment.
First, you need to have fully separate BES environments, i.e. at least 2 SQL back end databases. This is easy for us as we have an EU BES environment on it's own SQL database.
If we need to set up an additional handheld for an end user, whether they need it temporarily for an assistant, or need to test a new device, then we add their account to the other BES environment and activate their device as normal. Since BlackBerrys are international devices there is no problem getting back to the device here in the U.S to finish activation.
Notes:
1) BlackBerry activation can take considerably longer due to the WAN if you are using another continents environment like we are. Don't freak out if it takes a few hours.
2) If you are doing OTA activation, temporarily disable the original BES account as it might pick up the activation email and discard it, leaving your remote BES server waiting forever. [BES servers are selfish and will NOC-block you if you let them. :)]
3) If these requests becomes common, you might want to think about a secondary local BES environment, perhaps running with an integrated MSDE, to support this service. Of course you need an additional SRP to do this.
4) Remember that these accounts cannot be failed/moved over to other local BES servers in a DR scenario, as they are on a separate database.
5) Don't forget about these "ex-pat" accounts if on a foreign BES server. The local admins may not ever delete them b/c they don't know who they are. So you should keep track of them and delete them when it looks like the service was cancelled or otherwise abandoned.
Other than these caveats, I have not seen any issues with this in our environment.
Monday, February 11, 2008
Managing the BlackBerry Device Firewall Remotely... Possible?
Over the past few weeks as I was playing with setting device options remotely, I made a few mental notes when encountering databases (i.e. configurations) backed up to the SQL db. One of these was 'Firewall Options'.
I particularly noted this one because I have been looking for a solution to the firewall popups that appear on our user's devices. Overall of course the firewall is a good thing, but I like to keep the experience of our users seamless whenever possible, and incomprehensible (to the user) firewall popups do not make for a seamless experience.
One example of this is the RSA SecurID software for our BlackBerry devices, which we deploy so our users do not need to carry around a hardware token. The first thing this software does when installed on the device is listen for a software token which is wirelessly pushed to the device via a separate app.
This listening process constitutes a 'server' on the device, so upon installation we see the following firewall popup:
Now if I am pushing this software from the server to a device out in the field, then based on this screen the end user will be confused as to what to do. 80% of the time they may choose correctly and scroll down to click allow, but that other 20% may result in a support call.
So is it possible to:
1) Set the 'Allow' rule in the device's 'Firewall Settings' database in SQL
2) Push the 'Firewall Settings' configuration down to the device
3) Push the application and have it immediately begin listening for a token without user input?
Let's find out!
First we will monitor the SYNC log again to see if anything gets backed up to the server when an option on this firewall prompt is selected.
The first thing I notice is that if I leave the "Don't ask this again for:" box unchecked, then nothing happens... I see no log entries on the server side. If I reset the app and enable the listener again, this time choosing to check the box, however:
... voila! I do see something coming through to the server:
[60000] (02/11 11:50:51.111):{0x1710} [ODBCRecord::DoSetValue] DATA = "DbVersion[0] Data[0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000] UserConfigID[17] DatabaseName[Firewall Options] UID[1] ".
This tells me that my hunch was correct, and that any saved settings are stored in the 'Firewall Options' configuration, and therefore backed up to the server. Good news!
So let's now reset everything and query the 'Firewall Options' configuration to see the default value as compared to the updated settings:
0x1100000005000004000003000002000001000000 (Default)
0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 (RSA Allowed)
It looks like the first numbers were changed from 11 to 27, then a bunch of numbers were inserted, extending the configuration string. I am guessing that this new set of numbers uniquely identifies the SecurID server application and the 'Allow' setting I chose.
If we reset the app, then choose 'Deny' here is what the string becomes:
0x270000010107536563757249440001046874747000060000000005000004000003000002000001000000
Everything is the same except for a single number, the '2' about 2/3 of the way through the string has changed to a '6'. So perhaps a '2' means allow, and a '6' means deny. Let's try clearing everything out, and then pushing the 'allow' string to the device before the software push:
use BESConfig
UPDATE SyncBackupRestore SET Data=0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 WHERE UserConfigID = 17 AND DatabaseName = 'Firewall Options'
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId = 17 AND SyncDataSourceId=11109
go
Now we reload the application, and...
Bummer.
Guess I'll have to keep digging on this one...
[Update 2/13/08]
I have been gently reminded of the use of application control policies by a fellow blackberryforums.com member, ACJones. By setting a policy on the software configuration for the RSA SecurID software, and modifying the 'Internal Network Connections' option from 'Prompt' to 'Allow', you can avoid the initial firewall prompt completely upon OTA installation!
I have tested this and it works flawlessly. Thanks AC!
I particularly noted this one because I have been looking for a solution to the firewall popups that appear on our user's devices. Overall of course the firewall is a good thing, but I like to keep the experience of our users seamless whenever possible, and incomprehensible (to the user) firewall popups do not make for a seamless experience.
One example of this is the RSA SecurID software for our BlackBerry devices, which we deploy so our users do not need to carry around a hardware token. The first thing this software does when installed on the device is listen for a software token which is wirelessly pushed to the device via a separate app.
This listening process constitutes a 'server' on the device, so upon installation we see the following firewall popup:
Now if I am pushing this software from the server to a device out in the field, then based on this screen the end user will be confused as to what to do. 80% of the time they may choose correctly and scroll down to click allow, but that other 20% may result in a support call.
So is it possible to:
1) Set the 'Allow' rule in the device's 'Firewall Settings' database in SQL
2) Push the 'Firewall Settings' configuration down to the device
3) Push the application and have it immediately begin listening for a token without user input?
Let's find out!
First we will monitor the SYNC log again to see if anything gets backed up to the server when an option on this firewall prompt is selected.
The first thing I notice is that if I leave the "Don't ask this again for:" box unchecked, then nothing happens... I see no log entries on the server side. If I reset the app and enable the listener again, this time choosing to check the box, however:
... voila! I do see something coming through to the server:
[60000] (02/11 11:50:51.111):{0x1710} [ODBCRecord::DoSetValue] DATA = "DbVersion[0] Data[0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000] UserConfigID[17] DatabaseName[Firewall Options] UID[1] ".
This tells me that my hunch was correct, and that any saved settings are stored in the 'Firewall Options' configuration, and therefore backed up to the server. Good news!
So let's now reset everything and query the 'Firewall Options' configuration to see the default value as compared to the updated settings:
0x1100000005000004000003000002000001000000 (Default)
0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 (RSA Allowed)
It looks like the first numbers were changed from 11 to 27, then a bunch of numbers were inserted, extending the configuration string. I am guessing that this new set of numbers uniquely identifies the SecurID server application and the 'Allow' setting I chose.
If we reset the app, then choose 'Deny' here is what the string becomes:
0x270000010107536563757249440001046874747000060000000005000004000003000002000001000000
Everything is the same except for a single number, the '2' about 2/3 of the way through the string has changed to a '6'. So perhaps a '2' means allow, and a '6' means deny. Let's try clearing everything out, and then pushing the 'allow' string to the device before the software push:
use BESConfig
UPDATE SyncBackupRestore SET Data=0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 WHERE UserConfigID = 17 AND DatabaseName = 'Firewall Options'
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId = 17 AND SyncDataSourceId=11109
go
Now we reload the application, and...
Bummer.
Guess I'll have to keep digging on this one...
[Update 2/13/08]
I have been gently reminded of the use of application control policies by a fellow blackberryforums.com member, ACJones. By setting a policy on the software configuration for the RSA SecurID software, and modifying the 'Internal Network Connections' option from 'Prompt' to 'Allow', you can avoid the initial firewall prompt completely upon OTA installation!
I have tested this and it works flawlessly. Thanks AC!
Wednesday, February 6, 2008
Managing BlackBerry Configuration Settings Remotely - Putting it all Together
Now that we know how to update the device settings, let's see how it works in a real world scenario. I have just nuked, reloaded, and reactivated my test 8700g with 4.2 OS - here is the before shot of the relevant configuration screens:
Now let's push down some common changes to our device settings:
1. [Messages Options / General Options] Hide Filed Messages = Yes (default = No)
2. [Messages Options / General Options] Hide Sent Messages = Yes (default = No)
3. [Messages Options / General Options] Keep Messages = Forever (default = 30 Days)
4. [Messages Options / Email Reconciliation] Delete On = Mailbox & Handheld (default = Handheld)
5. [Calendar Options] Initial View = Week (default = Day)
6. [Calendar Options] Keep Appointments = Forever (default = 60 Days)
7. [Address Book Options] Sort By = Last Name (default = First Name)
8. [Options / Date/Time] Time Zone = Central Time (-6) (default = Casablanca (GMT))
9. [Options / Screen/Keyboard] Backlight Timeout = 2 Min. (default = 30 Sec.)
These modifications will require the following sequence of SQL updates (you will need to replace the '15' UserConfigID with your target account's UserConfigID in your SQL DB) :
use BESConfig
UPDATE SyncBackupRestore SET Data = 0x550000010101000001010101000301010800014465736B746F70000A000
2543336323538313330000100030101000A00020005FFFF01000601020008
01000100090102000B000002000C000002000D000001000E00000000
WHERE UserConfigID = 15 AND DatabaseName = 'Message List Options'
UPDATE SyncBackupRestore SET Data = 0x270000000000001C02FC0300000000010000000F0000000101000500000
00100FFFF0000000F00000001 WHERE UserConfigID = 15 AND DatabaseName = 'Calendar Options'
UPDATE SyncBackupRestore SET Data = 0x0A000001010100000000000100 WHERE UserConfigID = 15 AND DatabaseName = 'Address Book Options'
UPDATE SyncBackupRestore SET Data = 0x040001000000000400021400000001000302 WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -447168820
UPDATE SyncBackupRestore SET Data = 0x1000019A71C67ACBC67AB400000002000000000E00018131D8CDC28BB8
B90000000700000D0001D30CB969B820BFDD0000000600100001C2C1986B
11CE32B000000002000000780D0001BDAAFA49FFAD48CC00000006011000
013E3CBC03163D39CF00000002000001C24F0001CB2088784AFC39CC0000
000000416A6176613A2F6E65742E72696D2E6465766963652E7468656D652
E626264696D656E73696F6E5F7A656E5F333230783234305F772E5468656D
65466163746F72790D0001416028234B233EA70000000600100001F5006E1
93847CE260000000200000001100001BD91E3D465E4816900000002000000
00100001EBB9DE74CE5F773800000002000000322600011F0091A81B93E1C
30000000000186E65745F72696D5F6170706C69636174696F6E5F6D656E75
08000138D4D5F7DC80C5472E0001DA36AA198C1233A40000000000206E65
745F72696D5F62625F70726F66696C65735F6170702E50726F66696C65734
F00019B05812B5A1A15DC0000000000416A6176613A2F6E65742E72696D2
E6465766963652E7468656D652E626264696D656E73696F6E5F7A656E5F33
3230783234305F772E5468656D65466163746F72790D0001F33AFBD074DB0
7F100000006001000016B506A6FCD9D596A00000002000000011000012ECB
C575BEF57F3E00000002000000C80D0001094AC736D16697C800000006001
000011762E2440C4D5D510000000200000064080001E8D6CB484814CA60
WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -1321243196
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId=15 AND SyncDataSourceId=11109
go
This will kick off a one way sync from the server to the device, pushing all the configuration databases managed by the Backup component. It will take less than a minute for the SYNC process to pick up on this change, and about another 30 seconds or so to re-sync all the settings. [sleep 120] Now back to our handheld... it appears that all changes (in green boxes) have been picked up:
Now we must be sure to run the following command to restore the device to server synchronization:
UPDATE SyncConfig set SyncType=3 WHERE UserConfigId=15 AND SyncDataSourceId=11109
If we didn't do this, then any configuration updates from the handheld would not be backed up to the server. Actually, this might be an interesting option to employ for some firms who want total control over the handheld... one could schedule a daily push to refresh settings to the organizational standard settings to discourage end-user customization.
All of these commands could be easily scripted by putting them in a text file such as 'PushSettings.sql' and using the OSQL command's -i switch, i.e.:
osql -S sqlservername.company.com -U sqlaccountname -P sqlpassword -i PushSettings.sql
So that's it... We've gone down the rabbit hole into the depths of the BES SQL DB in order to discover some of it's secrets, and we came away with a method of pushing normally hidden device configuration settings over the air. Have fun, but remember to backup your SQL database regularly and TEST TEST TEST your scripts outside of production first!
Now let's push down some common changes to our device settings:
1. [Messages Options / General Options] Hide Filed Messages = Yes (default = No)
2. [Messages Options / General Options] Hide Sent Messages = Yes (default = No)
3. [Messages Options / General Options] Keep Messages = Forever (default = 30 Days)
4. [Messages Options / Email Reconciliation] Delete On = Mailbox & Handheld (default = Handheld)
5. [Calendar Options] Initial View = Week (default = Day)
6. [Calendar Options] Keep Appointments = Forever (default = 60 Days)
7. [Address Book Options] Sort By = Last Name (default = First Name)
8. [Options / Date/Time] Time Zone = Central Time (-6) (default = Casablanca (GMT))
9. [Options / Screen/Keyboard] Backlight Timeout = 2 Min. (default = 30 Sec.)
These modifications will require the following sequence of SQL updates (you will need to replace the '15' UserConfigID with your target account's UserConfigID in your SQL DB) :
use BESConfig
UPDATE SyncBackupRestore SET Data = 0x550000010101000001010101000301010800014465736B746F70000A000
2543336323538313330000100030101000A00020005FFFF01000601020008
01000100090102000B000002000C000002000D000001000E00000000
WHERE UserConfigID = 15 AND DatabaseName = 'Message List Options'
UPDATE SyncBackupRestore SET Data = 0x270000000000001C02FC0300000000010000000F0000000101000500000
00100FFFF0000000F00000001 WHERE UserConfigID = 15 AND DatabaseName = 'Calendar Options'
UPDATE SyncBackupRestore SET Data = 0x0A000001010100000000000100 WHERE UserConfigID = 15 AND DatabaseName = 'Address Book Options'
UPDATE SyncBackupRestore SET Data = 0x040001000000000400021400000001000302 WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -447168820
UPDATE SyncBackupRestore SET Data = 0x1000019A71C67ACBC67AB400000002000000000E00018131D8CDC28BB8
B90000000700000D0001D30CB969B820BFDD0000000600100001C2C1986B
11CE32B000000002000000780D0001BDAAFA49FFAD48CC00000006011000
013E3CBC03163D39CF00000002000001C24F0001CB2088784AFC39CC0000
000000416A6176613A2F6E65742E72696D2E6465766963652E7468656D652
E626264696D656E73696F6E5F7A656E5F333230783234305F772E5468656D
65466163746F72790D0001416028234B233EA70000000600100001F5006E1
93847CE260000000200000001100001BD91E3D465E4816900000002000000
00100001EBB9DE74CE5F773800000002000000322600011F0091A81B93E1C
30000000000186E65745F72696D5F6170706C69636174696F6E5F6D656E75
08000138D4D5F7DC80C5472E0001DA36AA198C1233A40000000000206E65
745F72696D5F62625F70726F66696C65735F6170702E50726F66696C65734
F00019B05812B5A1A15DC0000000000416A6176613A2F6E65742E72696D2
E6465766963652E7468656D652E626264696D656E73696F6E5F7A656E5F33
3230783234305F772E5468656D65466163746F72790D0001F33AFBD074DB0
7F100000006001000016B506A6FCD9D596A00000002000000011000012ECB
C575BEF57F3E00000002000000C80D0001094AC736D16697C800000006001
000011762E2440C4D5D510000000200000064080001E8D6CB484814CA60
WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -1321243196
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId=15 AND SyncDataSourceId=11109
go
This will kick off a one way sync from the server to the device, pushing all the configuration databases managed by the Backup component. It will take less than a minute for the SYNC process to pick up on this change, and about another 30 seconds or so to re-sync all the settings. [sleep 120] Now back to our handheld... it appears that all changes (in green boxes) have been picked up:
Now we must be sure to run the following command to restore the device to server synchronization:
UPDATE SyncConfig set SyncType=3 WHERE UserConfigId=15 AND SyncDataSourceId=11109
If we didn't do this, then any configuration updates from the handheld would not be backed up to the server. Actually, this might be an interesting option to employ for some firms who want total control over the handheld... one could schedule a daily push to refresh settings to the organizational standard settings to discourage end-user customization.
All of these commands could be easily scripted by putting them in a text file such as 'PushSettings.sql' and using the OSQL command's -i switch, i.e.:
osql -S sqlservername.company.com -U sqlaccountname -P sqlpassword -i PushSettings.sql
So that's it... We've gone down the rabbit hole into the depths of the BES SQL DB in order to discover some of it's secrets, and we came away with a method of pushing normally hidden device configuration settings over the air. Have fun, but remember to backup your SQL database regularly and TEST TEST TEST your scripts outside of production first!
Monday, February 4, 2008
Managing BlackBerry Configuration Settings Remotely - Part Five
Here are the options for the Calendar, first with default settings, then with the individual options enabled along with the resulting Data string:
[Default Settings Above]
0x270000FFFFFFFF1C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[Initial View: Week]
0x270000000000001C02FC030000000001000000
0F0000000101000500000001003C000000000F00000001
[Initial View: Month]
0x270000000000001C02FC030000000001000000
0F0000000201000500000001003C000000000F00000001
[Initial View: Agenda]
0x270000000000001C02FC030000000001000000
0F0000000301000500000001003C000000000F00000001
[Initial View: Last]
0x270000000000001C02FC030000000001000000
0F0000000401000500000001003C000000000F00000001
[Enable Quick Entry: No]
0x270000000000001C02FC030000000001000000
0F0000000000000500000001003C000000000F00000001
[Default Reminder: None]
0x270000000000001C02FC030000000001000000
FFFFFFFF0001000500000001003C000000000F00000001
[Default Reminder: 0 Min]
0x270000000000001C02FC030000000001000000
000000000001000500000001003C000000000F00000001
[Default Reminder: 1 Hour]
0x270000000000001C02FC030000000001000000
03C000000001000500000001003C000000000F00000001
(Minutes in hex: 3C = 60 decimal)
[Default Reminder: 1 Week]
0x270000000000001C02FC030000000001000000
060270000001000500000001003C000000000F00000001
(Minutes in transposed hex: 2760 = 10080 decimal ; 10080/ 60 = 168 hours / 24 = 7 days)
[Snooze: None]
0x270000000000001C02FC030000000001000000
0F000000000100FFFFFFFF01003C000000000F00000001
[Snooze: 1 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000100000001003C000000000F00000001
[Snooze: 10 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000A00000001003C000000000F00000001
[Snooze: 30 Min]
0x270000000000001C02FC030000000001000000
0F0000000001001E00000001003C000000000F00000001
[Start of Day: 8 AM]
0x27000000000000E001FC030000000001000000
0F0000000001000500000001003C000000000F00000001
(Minutes past midnight in transposed hex: 01E0 = 480 decimal ; 480/60 = 8 hours)
[End of Day: 6 PM]
0x270000000000001C0238040000000001000000
0F0000000001000500000001003C000000000F00000001
(Same as above, 0438 = 1080 decimal ; 1080/60 = 18 hours or 6 PM}
[First Day of Week: Mon]
0x270000010000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[First Day of Week: Tue]
0x270000020000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[Confirm Delete: No]
0x270000000000001C02FC030000000000000000
0F0000000001000500000001003C000000000F00000001
[Show Free Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000010F00000001
[Show End Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000000
[Keep Appointments: 15 Days]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001000F000000000F00000001
[Keep Appointments: Forever]
0x270000000000001C02FC030000000001000000
0F000000000100050000000100FFFF0000000F00000001
[Wireless Synchronization: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000000003C000000000F00000001
[Show Tasks: Yes]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000100000F00000001
Now for the Address Book:
[Default Settings Above]
0x0A000001010000000000000100
[Sort By: Last Name]
0x0A000001010100000000000100
[Sort By: Company]
0x0A000001010200000000000100
[Confirm Delete: No]
0x0A000001000000000000000100
[Allow Duplicate Names: No]
0x0A000000010000000000000100
[Wireless Synchronization: No]
0x0A000001010000000000000000
And finally, Tasks:
[Default Settings Above]
0x0F000000000000000000000101FFFFFFFF01
[Sort By: Priority]
0x0F000001000000000000000101FFFFFFFF01
[Sort By: Due Date]
0x0F000002000000000000000101FFFFFFFF01
[Sort By: Status]
0x0F000003000000000000000101FFFFFFFF01
[Confirm Delete: No]
0x0F000000000000000000000001FFFFFFFF01
[Snooze: 1 Min]
0x0F0000000000000000000001010100000001
[Snooze: 10 Min]
0x0F0000000000000000000001010A00000001
[Snooze: 30 Min]
0x0F0000000000000000000001011E00000001
[Wireless Synchronization: No]
0x0F000000000000000000000101FFFFFFFF00
[Default Settings Above]
0x270000FFFFFFFF1C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[Initial View: Week]
0x270000000000001C02FC030000000001000000
0F0000000101000500000001003C000000000F00000001
[Initial View: Month]
0x270000000000001C02FC030000000001000000
0F0000000201000500000001003C000000000F00000001
[Initial View: Agenda]
0x270000000000001C02FC030000000001000000
0F0000000301000500000001003C000000000F00000001
[Initial View: Last]
0x270000000000001C02FC030000000001000000
0F0000000401000500000001003C000000000F00000001
[Enable Quick Entry: No]
0x270000000000001C02FC030000000001000000
0F0000000000000500000001003C000000000F00000001
[Default Reminder: None]
0x270000000000001C02FC030000000001000000
FFFFFFFF0001000500000001003C000000000F00000001
[Default Reminder: 0 Min]
0x270000000000001C02FC030000000001000000
000000000001000500000001003C000000000F00000001
[Default Reminder: 1 Hour]
0x270000000000001C02FC030000000001000000
03C000000001000500000001003C000000000F00000001
(Minutes in hex: 3C = 60 decimal)
[Default Reminder: 1 Week]
0x270000000000001C02FC030000000001000000
060270000001000500000001003C000000000F00000001
(Minutes in transposed hex: 2760 = 10080 decimal ; 10080/ 60 = 168 hours / 24 = 7 days)
[Snooze: None]
0x270000000000001C02FC030000000001000000
0F000000000100FFFFFFFF01003C000000000F00000001
[Snooze: 1 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000100000001003C000000000F00000001
[Snooze: 10 Min]
0x270000000000001C02FC030000000001000000
0F0000000001000A00000001003C000000000F00000001
[Snooze: 30 Min]
0x270000000000001C02FC030000000001000000
0F0000000001001E00000001003C000000000F00000001
[Start of Day: 8 AM]
0x27000000000000E001FC030000000001000000
0F0000000001000500000001003C000000000F00000001
(Minutes past midnight in transposed hex: 01E0 = 480 decimal ; 480/60 = 8 hours)
[End of Day: 6 PM]
0x270000000000001C0238040000000001000000
0F0000000001000500000001003C000000000F00000001
(Same as above, 0438 = 1080 decimal ; 1080/60 = 18 hours or 6 PM}
[First Day of Week: Mon]
0x270000010000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[First Day of Week: Tue]
0x270000020000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000001
[Confirm Delete: No]
0x270000000000001C02FC030000000000000000
0F0000000001000500000001003C000000000F00000001
[Show Free Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000010F00000001
[Show End Time in Agenda View: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000000000F00000000
[Keep Appointments: 15 Days]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001000F000000000F00000001
[Keep Appointments: Forever]
0x270000000000001C02FC030000000001000000
0F000000000100050000000100FFFF0000000F00000001
[Wireless Synchronization: No]
0x270000000000001C02FC030000000001000000
0F0000000001000500000000003C000000000F00000001
[Show Tasks: Yes]
0x270000000000001C02FC030000000001000000
0F0000000001000500000001003C000100000F00000001
Now for the Address Book:
[Default Settings Above]
0x0A000001010000000000000100
[Sort By: Last Name]
0x0A000001010100000000000100
[Sort By: Company]
0x0A000001010200000000000100
[Confirm Delete: No]
0x0A000001000000000000000100
[Allow Duplicate Names: No]
0x0A000000010000000000000100
[Wireless Synchronization: No]
0x0A000001010000000000000000
And finally, Tasks:
[Default Settings Above]
0x0F000000000000000000000101FFFFFFFF01
[Sort By: Priority]
0x0F000001000000000000000101FFFFFFFF01
[Sort By: Due Date]
0x0F000002000000000000000101FFFFFFFF01
[Sort By: Status]
0x0F000003000000000000000101FFFFFFFF01
[Confirm Delete: No]
0x0F000000000000000000000001FFFFFFFF01
[Snooze: 1 Min]
0x0F0000000000000000000001010100000001
[Snooze: 10 Min]
0x0F0000000000000000000001010A00000001
[Snooze: 30 Min]
0x0F0000000000000000000001011E00000001
[Wireless Synchronization: No]
0x0F000000000000000000000101FFFFFFFF00
Thursday, January 31, 2008
Managing BlackBerry Configuration Settings Remotely - Part Four
Now that we know how to update the settings on the device, here is a screenshot showing the default settings, and a list of Data strings with all the different Message List 'General Settings' options:
Default Message List / General Options settings:
[Data String for Defaults above]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Time: NO]
0x350000000101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Name: NO]
0x350000010001000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Message Header On: 1 line]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B010002000C000002000D000001000E00000000
[Display Message Header On: 2 lines]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B020002000C000002000D000001000E00000000
[Display Message Count: None]
0x350000010101000001010001000301010200051E0001000600020008
00000100090102000B000002000C000002000D000001000E00000000
[Display New Message Indicator: No]
0x350000010101000001010001000301010200051E0001000600020008
01000100090002000B000002000C000002000D000001000E00000000
[Confirm Delete: No]
0x350000010101000001010000000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Hide Filed Messages: YES]
0x350000010101000001010101000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Hide Sent Messages: YES]
0x350000010101000001010001000301010200051E0001000601020008
01000100090102000B000002000C000002000D000001000E00000000
[Make PIN Messages Level 1: No]
0x350000010101000001010001000300010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Auto More: No]
0x350000010101000001010001000301000200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 15 Days]
0x350000010101000001010001000301010200050F0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 2 Months]
0x350000010101000001010001000301010200053C0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 3 Months]
0x350000010101000001010001000301010200055A0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 4 Months]
0x35000001010100000101000100030101020005780001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 5 Months]
0x35000001010100000101000100030101020005960001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 6 Months]
0x35000001010100000101000100030101020005B40001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: Forever]
0x35000001010100000101000100030101020005FFFF01000600020008
01000100090102000B000002000C000002000D000001000E00000000
[SMS and Email Inboxes: Combined]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C010002000D000001000E00000000
[SMS and Email Inboxes: Separate]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C020002000D000001000E00000000
The first line contains all the default settings from my test device which is an 8700g with the 4.2 OS software. The latter lines are the defaults with only the option shown enabled. The highlighted numbers in the rows show which number controls the setting in that row.
Keep in mind that this may be different from what you see depending upon your device type and OS version, however I suspect they would be similar if not the same for the same OS version.
Next: Calendar, Address Book, and Tasks options database settings.
Default Message List / General Options settings:
[Data String for Defaults above]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Time: NO]
0x350000000101000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Name: NO]
0x350000010001000001010001000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Display Message Header On: 1 line]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B010002000C000002000D000001000E00000000
[Display Message Header On: 2 lines]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B020002000C000002000D000001000E00000000
[Display Message Count: None]
0x350000010101000001010001000301010200051E0001000600020008
00000100090102000B000002000C000002000D000001000E00000000
[Display New Message Indicator: No]
0x350000010101000001010001000301010200051E0001000600020008
01000100090002000B000002000C000002000D000001000E00000000
[Confirm Delete: No]
0x350000010101000001010000000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Hide Filed Messages: YES]
0x350000010101000001010101000301010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Hide Sent Messages: YES]
0x350000010101000001010001000301010200051E0001000601020008
01000100090102000B000002000C000002000D000001000E00000000
[Make PIN Messages Level 1: No]
0x350000010101000001010001000300010200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Auto More: No]
0x350000010101000001010001000301000200051E0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 15 Days]
0x350000010101000001010001000301010200050F0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 2 Months]
0x350000010101000001010001000301010200053C0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 3 Months]
0x350000010101000001010001000301010200055A0001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 4 Months]
0x35000001010100000101000100030101020005780001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 5 Months]
0x35000001010100000101000100030101020005960001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: 6 Months]
0x35000001010100000101000100030101020005B40001000600020008
01000100090102000B000002000C000002000D000001000E00000000
[Keep Messages: Forever]
0x35000001010100000101000100030101020005FFFF01000600020008
01000100090102000B000002000C000002000D000001000E00000000
[SMS and Email Inboxes: Combined]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C010002000D000001000E00000000
[SMS and Email Inboxes: Separate]
0x350000010101000001010001000301010200051E0001000600020008
01000100090102000B000002000C020002000D000001000E00000000
The first line contains all the default settings from my test device which is an 8700g with the 4.2 OS software. The latter lines are the defaults with only the option shown enabled. The highlighted numbers in the rows show which number controls the setting in that row.
Keep in mind that this may be different from what you see depending upon your device type and OS version, however I suspect they would be similar if not the same for the same OS version.
Next: Calendar, Address Book, and Tasks options database settings.
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.
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.
Subscribe to:
Posts (Atom)