tag:blogger.com,1999:blog-85425324894562004732024-03-12T17:28:25.149-07:00BlackBerry Enterprise Server on Domino DiscussionUnknownnoreply@blogger.comBlogger52125tag:blogger.com,1999:blog-8542532489456200473.post-80995648336563956012009-03-06T06:18:00.000-08:002009-03-06T06:20:23.618-08:00Moving On...Well today is my last day working on Domino systems, so I guess it is the last day for this blog as well. I have had fun probing the inner workings of Domino as it relates to BES, however all good things must come to an end, and I will soon be going back to the dark side. Adieu!Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-8542532489456200473.post-14047335076728260132009-01-08T13:22:00.000-08:002009-01-08T13:38:33.234-08:00Software Configuration Push Problems WrapupWell here is the upshot of pushing an application to ~1500 Blackberrys: About 50 of them will not receive the app for a variety of reasons. (Which is actually not too bad considering the complexity and fragility of all the pieces involved in a wireless software deployment!)<br /><br />First, check the Last Contact Time for the user's BES account. I have about 8 of these guys who haven't been heard from in weeks or months, they are probably on maternity / paternity leave or have been fired but not deleted from the BES. Ignore these guys for now.<br /><br />Second, ensure there is enough memory on the device via the BES Manager. If the device reports 1MB free then it probably won't install the app. If the last date status was reported is way in the past, the device probably doesn't have enough memory to even report daily status anymore.<br /><br />Then, check that the device's Hardware information is reported in the BES Manager. Some devices only have there "Secured Boot ROM" entry there, which means the hardware is not reporting correctly, and is reporting a hardware ID of 0x00000000. The BES doesn't see this number in the device.xml and won't push the app to it. This happens alot with Verizon devices, especially the 8300 models, but I have seen a few with T-Mobile 8700's as well. In this case the only thing I have discovered that fixes it is to upgrade to a later OS, such as 4.5.<br /><br />If memory is plentiful and hardware info is there (and of course your device.xml is updated), then I have found that there may be a mismatch between the Applications / Modules reported by BES Manager and what is actually on the device. Many times the BES Manager will report multiple modules with different version numbers, but the device is actually just fine. In this case we need to clear the BES Manager device info. The best way to do this is to go into the PIM Sync Options of the user and set the <span style="font-weight: bold;">Automatic BlackBerry Device Management Enabled</span> setting to <span style="font-weight: bold;">False</span>, clicking OK, waiting 1 minute, then going back in and setting it to <span style="font-weight: bold;">True</span>. This will clear the data from the SQL tables, and when set back to True, will request that the device repopulate the information with fresh data. When this is done, after a few minutes, often the software push will begin to work.<br /><br />On some devices I set the above setting back to True and I never get back any device information! In this case the Desktop (SYNC) service book on the device seems to be corrupted, and having the user delete it and undelete it restores everything just fine. Then the push works.<br /><br />Please note that deleting the user's BES account, recreating it, wiping the device, and reactivating will most likely fix all the above issues. However in our environment it is imperative that our attorneys have as little down time as possible, so fixing these issues behind the scenes is a lifesaver.<br /><br />Hope this little learning experience helps you all out there as much as it has me.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-8542532489456200473.post-35780038611588348182008-12-23T07:13:00.000-08:002008-12-23T07:19:48.953-08:00Software Configuration Push Problems cont'd...Another issue I discovered is the following:<br /><br />1. I audit all of our devices to ensure the memory is above 3MB before pushing the software, to avoid causing their devices to delete all their mail. How to do this is another post in itself!<br /><br />2. We send these users emails on how to clean up the device.<br /><br />3. I got some emails back saying they had plenty of memory free already!<br /><br />4. I checked and found that the Device information had not been updated in 6 months or more! I was working with old data for some users!<br /><br />Here is my theory:<br /><br />Once you get to a very small amount of memory on the BB, the Handheld Agent will stop reporting back to the server it's details on a daily basis. Fortunately there was an easy fix for most of these guys, and that is to set "Automatic BlackBerry Device Management Enabled" to FALSE, wait a few minutes, then set it back to true. What this does is delete all the device information for that user from the SQL database, then when you turn it back on it refreshes it directly from the device. If there is enough memory available you will get new info. If memory is still low you will not get any info back.<br /><br />Interesting side note: The refreshed device information will only reflect when the Handheld Agent last collected the data, not the "right now" state. So if you get todays info it may be from 5 or 7AM, not from 11AM when you changed the settings.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-17202467634983146272008-12-23T07:05:00.001-08:002008-12-23T07:13:23.929-08:00Software Configuration Push Problems (SCPP's)Ok here I am again after a long bout of laziness. Anyway I am working on deploying a piece of software to all our devices and am running into fun issues. Here is one of them:<br /><br />8330 Curves on Verizon running 4.2 or 4.3 OS, for some reason, do not publish their hardware details to the BES. In fact they don't even publish it if you are connected over USB to the device via BlackBerry Manager. The Hardware ID is just 0x00000000.<br /><br />This is a problem because when you push software it checks the device model against the device.xml file in the AppLoader directory above the actual software package. If it doesn't find it then you get an error in the POLC log about HHCM_DEVICE_NOT_SUPPORTED and to Update your device.xml.<br /><br />The issue of course is not the device.xml, but that the Hardware ID is not there for this device.<br /><br />I found that upgrading from 4.2 or 4.3 OS to 4.5 will publish all the gory hardware details and software pushes will work again.<br /><br />I wonder if it is stupid Verizon wanting to hide the hardware from everyone but themselves (like they do with GPS) or just an bug in their version of OS 4.2 / 4.3. Either way seems it is resolved in 4.5.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-6228826852472291942008-05-07T09:37:00.000-07:002008-05-07T10:30:19.486-07:00ITAdminQueue - EXPOSED!A pretty cool new feature appeared in 4.1 SP5, resulting in a new tab called Software Configuration Status within the BlackBerry Manager application:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEq6EsyN4gbMt_xz_qePT-_kylJGwzTtHg99694lgH-pzKSic51NPAEi_Nfh_Z5n1Fr_w-GsWZr4j6Da9eqatB_hw4TlftoCI6E5O0qroarThHQjr-8eF7mLe46bJL3lKuK87tiOuB_1E/s1600-h/SCS.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEq6EsyN4gbMt_xz_qePT-_kylJGwzTtHg99694lgH-pzKSic51NPAEi_Nfh_Z5n1Fr_w-GsWZr4j6Da9eqatB_hw4TlftoCI6E5O0qroarThHQjr-8eF7mLe46bJL3lKuK87tiOuB_1E/s400/SCS.JPG" alt="" id="BLOGGER_PHOTO_ID_5197679123416165010" border="0" /></a><br />This tab shows a view of the previously hidden ITAdminQueue table in the SQL database, which contains all sorts of back end commands that are queued up / in process to the BlackBerry handhelds.<br /><br />The view above results from setting the software configuration of my test BlackBerry to a pre-configured RSA SecurID application, turning the wireless off, and manually pushing it out via the "Deploy Software" command. You can see there are two entries listed under this new tab, which don't show a whole lot of information. I assume because they are simply queued, and have not errored out yet.<br /><br />Here are the corresponding ITAdminQueue rows in the actual SQL table:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3XLf371_SmTKtm1EEOPjdPbQgj80XEbG3-7Pbik92ZXUgDsXm_Co5RyeQkH1Lm6jHYWApiUQBV1pIOeimhuqb8h2vkRnDgym3qxxtiwhMSkWrG2ZhTUsAzHSbG1qOCz_IJ0028JF5lNU/s1600-h/ITAQtable.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3XLf371_SmTKtm1EEOPjdPbQgj80XEbG3-7Pbik92ZXUgDsXm_Co5RyeQkH1Lm6jHYWApiUQBV1pIOeimhuqb8h2vkRnDgym3qxxtiwhMSkWrG2ZhTUsAzHSbG1qOCz_IJ0028JF5lNU/s400/ITAQtable.JPG" alt="" id="BLOGGER_PHOTO_ID_5197683113440783026" border="0" /></a><span style="text-decoration: underline;"><br /></span>Note that the first entry is actually listed with a Command column number of 129. This corresponds to the BES Policy service's SEND_APC_ITPOLICY command. The IT Policy is always sent first whenever an application is delivered, as it includes any software application policies you have created. As these policies need to be applied before the app is installed, sometimes there are errors applying the IT policy - which can prevent an app from being delivered successfully.<br /><br />Note also that this IT Policy command does not show up in the Software Configuration Status tab, which leads me to believe this tab is built using a filter to only show software application entries, not the whole table.<br /><br />Below this row there are two additional rows listed, both showing the Command column set to 128. 128 corresponds to the SEND_APC_APP command, so these are the commands to send the application itself. Note that these rows in the SQL table do not have a Time Sent value, but the IT Policy does. More proof that the app will not be sent until the IT Policy is applied successfully.<br /><br />One interesting thing is that the app I was pushing contained only one .cod file, so why two SEND_APC_APP commands / rows? Looking into the Policy log we find something interesting:<br /><br /><span style="font-size:85%;"><span style="font-family:arial;">Queuing the package RSA SecurID, consisting of 1 modules in 2 parts.</span></span><br /><br />So I think this this one .cod module is split into 2 parts for transmission to the BlackBerry, for what reason I do not know. Perhaps it was too big to send all at once?<br /><br />Although this new tab of information is helpful, I see it does not allow you to delete any queued commands. Some software push issues have been resolved by running the following SQL script:<br /><br /><span style="font-size:85%;"><span style="font-family:arial;">osql -S [SQLServerName] -d [DBName] -U [SQLLogin] -P [SQLPassword] -Q "delete from ITAdminQueue where (command = 128 or command = 129) and status = 6"</span></span><br /><br />This command will clear all SEND_APC_ITPOLICY and SEND_APC_APP entries with a status of 6, which designates an error; this allows future pushes to proceed properly.<br /><br />Some other BES Admins have recommended just deleting all rows referencing a particular PIN number to resolve issues with an individual BlackBerry not receiving an application properly. I cannot vouch for this method however, as I have not used it. I do occasionally run the SQL script above during standard maintenance of our BES environment, or if a particular application push problem occurs.<br /><br />From RIM's documentation, here are some error codes you might see in this new tab:<br /><br /> * Device timed out waiting for module<br /> * Device reported insufficient memory to install module<br /> * Device reported insufficient privileges to install module<br /> * Device reported Invalid Version in packet, supported version is %s<br /> * Device reported that there was an Incomplete Module<br /> * Device reported that the Module Save Failed<br /> * Device reported a general failure installing the module<br /> * Incomplete ACK data for APPD request<br /> * Device reported a %s error while installing module<br /> * Device Reported Data Format Error in packet while installing module<br /> * Device Reported Invalid Command while installing module<br /> * Device Reported Insufficient Body Data while installing module<br /> * Device Reported Invalid Module Hash while installing module<br /> * Device Reported Invalid App Data Length while installing module<br /> * Device Reported Insufficient App Data while installing module<br /><br />You can check out the support article, KB15470, for more information on these messages and there resolutions.<br /><br />I am sure that this new tab will help in resolving future application push issues, however I am also sure that some manual cleaning of the ITAdminQueue table will still be needed occasionally as well!Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-5845058975220976892008-05-06T11:01:00.001-07:002008-05-06T11:05:28.420-07:00Heading to WES 2008Well I know some of you who read this blog will be at WES this year, looking forward to meeting all of you in addition to the great bunch of BES Admin folks that convened last year.<br /><br />Generally our meeting place was in the right rear of the solutions showcase but we may also be hanging out around the BoxTone lounge, check out the WES 2008 thread on www.blackberryforums.com BES Admin corner for the latest details...<br /><br />Hoping to see you there!Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-74855219500057251742008-05-05T11:57:00.000-07:002008-05-05T12:12:36.475-07:00Address Book Contact Labels and the BlackBerryHad an interesting issue crop up today with an end user who changed the contact labels associated with an address book entry. Here is the default when you click the Edit Contact Labels button within your address book entry form:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj43B1J5vCvYT-N1r3ArYJ-VkUQcWb9OXKi-EH72M2NRqSWY4OZxmn1s8MAWiM0PN2-f6tnSqWO4xCPKxFko7KU1JwO-GNvsBZbAGcWsHqY73uAAIThErUC-cZ3UWaOkfvhcGwc3OePoKo/s1600-h/Labels.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj43B1J5vCvYT-N1r3ArYJ-VkUQcWb9OXKi-EH72M2NRqSWY4OZxmn1s8MAWiM0PN2-f6tnSqWO4xCPKxFko7KU1JwO-GNvsBZbAGcWsHqY73uAAIThErUC-cZ3UWaOkfvhcGwc3OePoKo/s400/Labels.JPG" alt="" id="BLOGGER_PHOTO_ID_5196970550673179826" border="0" /></a><br />This person had modified the labels to reflect different information, for example changing the Pager label to Home Phone #2. The problem is that the label change does not sync over to the BlackBerry, which shows the Label still listed under Pager.<br /><br />I called RIM and verified this is the way it should work, as the underlying field name does not change, and RIM maps to the field name, and not the changeable display name.<br /><br />I understand the issue and agree with RIM's assessment, however this is one of those gray areas where it is difficult to determine who is responsible for the issue. Is it Lotus for providing the (perhaps unwise) ability to change display names to something that is completely different from what the underlying field name reflects? Or is it RIM for not supporting this Lotus Notes feature, even though it may not be the best of features to have from a data integrity standpoint.<br /><br />As is generally the case, it is perhaps a little of both, which is why these things tend not to get fixed as each side points to the other and neither will take the responsibility to address it.<br /><br />This is not that big of a deal to me, and personally I agree with RIM's assessment that their sync engine should map to the field name and not a nebulous display name that can be changed at will by the end user.<br /><br />However, this is just a small example of the types of conflicts that can happen when you have two separate software entities interacting with each other, creating a no-man's land of responsibility with the customer trapped in the middle.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-8542532489456200473.post-80262795012116030412008-03-28T07:04:00.000-07:002008-03-28T07:22:35.049-07:00IT Policy Removal OptionsFor 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.<br /><br />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.<br /><br />Which leads to...<br /><br />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 <span style="font-style: italic;">mostly </span>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.<br /><br />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:<br /><br />http://besdomino.blogspot.com/2007/10/remove-it-policy-new-feature-of-41-sp4.html<br /><br />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.<br /><br />Strangely, the utility does not list version numbers, so you just have to look for the available option:<br /><br /><span style="font-family: arial;font-size:85%;" > resettofactory<br /> Reset IT policy to factory settings<br /></span><br />...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:<br /><br />c:\javaloader -u resettofactory<br /><br />The future of IT policy removal is a bright one, indeed.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-29731310822841590302008-03-21T12:55:00.000-07:002008-03-21T13:10:56.888-07:00Multiple BlackBerrys per Mailfile?Answer: Yes with some caveats.<br /><br />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.<br /><br />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.<br /><br />Notes:<br /><br />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.<br /><br />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. :)]<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Other than these caveats, I have not seen any issues with this in our environment.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-8542532489456200473.post-44610024493291663512008-02-11T09:52:00.000-08:002008-02-13T09:11:13.473-08:00Managing 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'.<br /><br />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.<br /><br />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.<br /><br />This listening process constitutes a 'server' on the device, so upon installation we see the following firewall popup:<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEGPS1ciEqphs4gZre1jacBmnNlUaGxEBzyPULDIXL_YKf8FsYAWiJYAmkq7SUrUhlax7Uhn2l6hRfE8mQt6loW7LF6mTgJ35734u5l74gWe4g51iUV4s_8fj0m7X7avWgJuVNCySAY9w/s1600-h/SecurID.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEGPS1ciEqphs4gZre1jacBmnNlUaGxEBzyPULDIXL_YKf8FsYAWiJYAmkq7SUrUhlax7Uhn2l6hRfE8mQt6loW7LF6mTgJ35734u5l74gWe4g51iUV4s_8fj0m7X7avWgJuVNCySAY9w/s400/SecurID.JPG" alt="" id="BLOGGER_PHOTO_ID_5165785163761738498" border="0" /></a><br />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.<br /><br />So is it possible to:<br /><br />1) Set the 'Allow' rule in the device's 'Firewall Settings' database in SQL<br />2) Push the 'Firewall Settings' configuration down to the device<br />3) Push the application and have it immediately begin listening for a token without user input?<br /><br />Let's find out!<br /><br />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.<br /><br />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:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYdECNrzqdQUMP00egnar_KL1T_fLMAsFToJJlASClnwI92VH7HU0euT-Q430UNjqHBDRmGZZHWiOz4aTA51wOIh83gNeUfErT1NUqI7UAehN58EjzxdWGYKfr53yVH9r1MX4g7qehTok/s1600-h/checked.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYdECNrzqdQUMP00egnar_KL1T_fLMAsFToJJlASClnwI92VH7HU0euT-Q430UNjqHBDRmGZZHWiOz4aTA51wOIh83gNeUfErT1NUqI7UAehN58EjzxdWGYKfr53yVH9r1MX4g7qehTok/s400/checked.JPG" alt="" id="BLOGGER_PHOTO_ID_5165816203490386722" border="0" /></a><br />... voila! I do see something coming through to the server:<br /><br /><span style="font-size:85%;">[60000] (02/11 11:50:51.111):{0x1710} [ODBCRecord::DoSetValue] DATA = "DbVersion[0] Data[0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000] UserConfigID[17] DatabaseName[Firewall Options] UID[1] ".</span><br /><br />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!<br /><br />So let's now reset everything and query the 'Firewall Options' configuration to see the default value as compared to the updated settings:<br /><br /><span style="font-size:85%;">0x1100000005000004000003000002000001000000 (Default)<br />0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 (RSA Allowed)</span><br /><br />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.<br /><br />If we reset the app, then choose 'Deny' here is what the string becomes:<br /><br /><span style="font-size:85%;">0x270000010107536563757249440001046874747000060000000005000004000003000002000001000000<br /></span><br />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:<br /><br /><span style="font-size:85%;">use BESConfig<br />UPDATE SyncBackupRestore SET Data=0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 WHERE UserConfigID = 17 AND DatabaseName = 'Firewall Options'<br />UPDATE SyncConfig set SyncType=1 WHERE UserConfigId = 17 AND SyncDataSourceId=11109<br />go</span><br /><br />Now we reload the application, and...<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCEBuZ2jUypmf1nRxZecMRZxKFNLq-kfS8yrrQ0jrzqMmdXSVbk5IeyLODqVc8DSGZjJiLFOIMtDeTPOtUOqsQ1szUDgfwEXA2kW6q-M1neq3J1aMMBb0nM8rV3EGIBz01j6Cq8NWcOus/s1600-h/bummer.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCEBuZ2jUypmf1nRxZecMRZxKFNLq-kfS8yrrQ0jrzqMmdXSVbk5IeyLODqVc8DSGZjJiLFOIMtDeTPOtUOqsQ1szUDgfwEXA2kW6q-M1neq3J1aMMBb0nM8rV3EGIBz01j6Cq8NWcOus/s400/bummer.JPG" alt="" id="BLOGGER_PHOTO_ID_5165814906410263314" border="0" /></a><br />Bummer.<br /><br />Guess I'll have to keep digging on this one...<br /><br />[Update 2/13/08]<br />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!<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRR3NaBaw5UIe2FavteeYs8x-DVu8gyPNfadOpedO3IkYIi7CgwVBwHlYZrZ2sK0mGSNHsX-e-lTHR4v0DiZOUz9hsWk0lCzidNL9RpNrKz2zPWp39VOksPjkJSiHCFeZBi3Sih2tc-G4/s1600-h/apppolicy.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRR3NaBaw5UIe2FavteeYs8x-DVu8gyPNfadOpedO3IkYIi7CgwVBwHlYZrZ2sK0mGSNHsX-e-lTHR4v0DiZOUz9hsWk0lCzidNL9RpNrKz2zPWp39VOksPjkJSiHCFeZBi3Sih2tc-G4/s400/apppolicy.JPG" alt="" id="BLOGGER_PHOTO_ID_5166513152128475954" border="0" /></a><br /><br />I have tested this and it works flawlessly. Thanks AC!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-57629474963499212332008-02-06T10:37:00.000-08:002008-02-07T14:01:53.563-08:00Managing BlackBerry Configuration Settings Remotely - Putting it all TogetherNow 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:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi22gldyuCtoCQXiCEuvBpV7HdRMvacCGVHrxWZA9t5K3g1X3-TBZKh8CEHbPi7wjVgjvVyJhAoSbVxquN84G-wqz8K85d3k2R-prjlVWRFz5oyxv_4f7_xm4fsSbJ7sVljmy6hbPXqaS0/s1600-h/before.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi22gldyuCtoCQXiCEuvBpV7HdRMvacCGVHrxWZA9t5K3g1X3-TBZKh8CEHbPi7wjVgjvVyJhAoSbVxquN84G-wqz8K85d3k2R-prjlVWRFz5oyxv_4f7_xm4fsSbJ7sVljmy6hbPXqaS0/s400/before.JPG" alt="" id="BLOGGER_PHOTO_ID_5164357671169577874" border="0" /></a><br />Now let's push down some common changes to our device settings:<br /><br />1. [Messages Options / General Options] <span style="font-weight: bold;">Hide Filed Messages = Yes</span> (default = No)<br />2. [Messages Options / General Options] <span style="font-weight: bold;">Hide Sent Messages = Yes</span> (default = No)<br />3. [Messages Options / General Options] <span style="font-weight: bold;">Keep Messages = Forever</span> (default = 30 Days)<br />4. [Messages Options / Email Reconciliation] <span style="font-weight: bold;">Delete On = Mailbox & Handheld</span> (default = Handheld)<br />5. [Calendar Options] <span style="font-weight: bold;">Initial View = Week</span> (default = Day)<br />6. [Calendar Options] <span style="font-weight: bold;">Keep Appointments = Forever</span> (default = 60 Days)<br />7. [Address Book Options] <span style="font-weight: bold;">Sort By = Last Name</span> (default = First Name)<br />8. [Options / Date/Time] <span style="font-weight: bold;">Time Zone = Central Time (-6)</span> (default = Casablanca (GMT))<br />9. [Options / Screen/Keyboard] <span style="font-weight: bold;">Backlight Timeout = 2 Min.</span> (default = 30 Sec.)<br /><br />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) :<br /><br /><span style=";font-family:verdana;font-size:85%;" >use BESConfig<br />UPDATE SyncBackupRestore SET Data = 0x550000010101000001010101000301010800014465736B746F70000A000<br />2543336323538313330000100030101000A00020005FFFF01000601020008<br />01000100090102000B000002000C000002000D000001000E00000000<br />WHERE UserConfigID = 15 AND DatabaseName = 'Message List Options'<br />UPDATE SyncBackupRestore SET Data = 0x270000000000001C02FC0300000000010000000F0000000101000500000<br />00100FFFF0000000F00000001 WHERE UserConfigID = 15 AND DatabaseName = 'Calendar Options'<br />UPDATE SyncBackupRestore SET Data = 0x0A000001010100000000000100 WHERE UserConfigID = 15 AND DatabaseName = 'Address Book Options'<br />UPDATE SyncBackupRestore SET Data = 0x040001000000000400021400000001000302 WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -447168820<br />UPDATE SyncBackupRestore SET Data = 0x1000019A71C67ACBC67AB400000002000000000E00018131D8CDC28BB8<br />B90000000700000D0001D30CB969B820BFDD0000000600100001C2C1986B<br />11CE32B000000002000000780D0001BDAAFA49FFAD48CC00000006011000<br />013E3CBC03163D39CF00000002000001C24F0001CB2088784AFC39CC0000<br />000000416A6176613A2F6E65742E72696D2E6465766963652E7468656D652<br />E626264696D656E73696F6E5F7A656E5F333230783234305F772E5468656D<br />65466163746F72790D0001416028234B233EA70000000600100001F5006E1<br />93847CE260000000200000001100001BD91E3D465E4816900000002000000<br />00100001EBB9DE74CE5F773800000002000000322600011F0091A81B93E1C<br />30000000000186E65745F72696D5F6170706C69636174696F6E5F6D656E75<br />08000138D4D5F7DC80C5472E0001DA36AA198C1233A40000000000206E65<br />745F72696D5F62625F70726F66696C65735F6170702E50726F66696C65734<br />F00019B05812B5A1A15DC0000000000416A6176613A2F6E65742E72696D2<br />E6465766963652E7468656D652E626264696D656E73696F6E5F7A656E5F33<br />3230783234305F772E5468656D65466163746F72790D0001F33AFBD074DB0<br />7F100000006001000016B506A6FCD9D596A00000002000000011000012ECB<br />C575BEF57F3E00000002000000C80D0001094AC736D16697C800000006001<br />000011762E2440C4D5D510000000200000064080001E8D6CB484814CA60<br />WHERE UserConfigID = 15 AND DatabaseName = 'Options' AND UID = -1321243196<br />UPDATE SyncConfig set SyncType=1 WHERE UserConfigId=15 AND SyncDataSourceId=11109<br />go</span><br /><br />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. [<span style="font-size:85%;"><span style="font-family:verdana;">sleep 120</span></span>] Now back to our handheld... it appears that all changes (in green boxes) have been picked up:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvle4UarPThkGFFmJsLeKvpgkNJ2YeyO9BLrhXLfQ9QQ5juaJpVL5fxMDd4Km8Zq2DyB6ZTKnSBrKamdGHRWyqUDBGwMquAb0NrmiQRTv0DGyJoWSJp9W1HUvLDbozzl5cX1GfZcQD6PA/s1600-h/after.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvle4UarPThkGFFmJsLeKvpgkNJ2YeyO9BLrhXLfQ9QQ5juaJpVL5fxMDd4Km8Zq2DyB6ZTKnSBrKamdGHRWyqUDBGwMquAb0NrmiQRTv0DGyJoWSJp9W1HUvLDbozzl5cX1GfZcQD6PA/s400/after.JPG" alt="" id="BLOGGER_PHOTO_ID_5164360462898320290" border="0" /></a><br />Now we must be sure to run the following command to restore the device to server synchronization:<br /><span style="font-size:85%;"><br /><span style="font-family:verdana;">UPDATE SyncConfig set SyncType=3 WHERE UserConfigId=15 AND SyncDataSourceId=11109</span><br /><br /></span>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.<br /><br />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.:<br /><br /><span style=";font-family:verdana;font-size:85%;" >osql -S sqlservername.company.com -U sqlaccountname -P sqlpassword -i PushSettings.sql</span><br /><br />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!Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-68122384891790955972008-02-04T09:59:00.000-08:002008-02-04T08:00:11.278-08:00Managing BlackBerry Configuration Settings Remotely - Part FiveHere are the options for the Calendar, first with default settings, then with the individual options enabled along with the resulting Data string:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqC2hxR-o5nYp1M_GRZzBvNcV2g0zLpq-oCBsspSp03Hfh4FSDSXUNJJlK4mCGa7KV_ECO6fJcslEfCZ8TjZi-U6txUaYxAJ6P_qT8pOrGh8wAdPq1IqqSAYZtOuCpLqexZ_qHwekdm4E/s1600-h/CalendarDefaults.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqC2hxR-o5nYp1M_GRZzBvNcV2g0zLpq-oCBsspSp03Hfh4FSDSXUNJJlK4mCGa7KV_ECO6fJcslEfCZ8TjZi-U6txUaYxAJ6P_qT8pOrGh8wAdPq1IqqSAYZtOuCpLqexZ_qHwekdm4E/s400/CalendarDefaults.JPG" alt="" id="BLOGGER_PHOTO_ID_5162112507080364882" border="0" /></a><br /><span style="font-size:85%;">[Default Settings Above]<br />0x270000FFFFFFFF1C02FC030000000001000000<br />0F0000000001000500000001003C000000000F00000001<br /><br />[Initial View: Week]<br />0x270000000000001C02FC030000000001000000<br />0F0000000</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">01000500000001003C000000000F00000001<br /><br />[Initial View: Month]<br />0x270000000000001C02FC030000000001000000<br />0F0000000</span><span style="font-weight: bold;font-size:85%;" >2</span><span style="font-size:85%;">01000500000001003C000000000F00000001<br /><br />[Initial View: Agenda]<br />0x270000000000001C02FC030000000001000000<br />0F0000000</span><span style="font-weight: bold;font-size:85%;" >3</span><span style="font-size:85%;">01000500000001003C000000000F00000001<br /><br />[Initial View: Last]<br />0x270000000000001C02FC030000000001000000<br />0F0000000</span><span style="font-weight: bold;font-size:85%;" >4</span><span style="font-size:85%;">01000500000001003C000000000F00000001<br /><br />[Enable Quick Entry: No]<br />0x270000000000001C02FC030000000001000000<br />0F000000000</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;">000500000001003C000000000F00000001<br /><br />[Default Reminder: None]<br />0x270000000000001C02FC030000000001000000<br /></span><span style="font-weight: bold;font-size:85%;" >FFFFFFFF</span><span style="font-size:85%;">0001000500000001003C000000000F00000001<br /><br />[Default Reminder: 0 Min]<br />0x270000000000001C02FC030000000001000000<br />0</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;">0000000001000500000001003C000000000F00000001<br /><br />[Default Reminder: 1 Hour]<br />0x270000000000001C02FC030000000001000000<br />0</span><span style="font-weight: bold;font-size:85%;" >3C</span><span style="font-size:85%;">000000001000500000001003C000000000F00000001<br />(Minutes in hex: 3C = 60 decimal)<br /><br />[Default Reminder: 1 Week]<br />0x270000000000001C02FC030000000001000000<br />0</span><span style="font-weight: bold;font-size:85%;" >6027</span><span style="font-size:85%;">0000001000500000001003C000000000F00000001<br />(Minutes in transposed hex: 2760 = 10080 decimal ; 10080/ 60 = 168 hours / 24 = 7 days)<br /><br />[Snooze: None]<br />0x270000000000001C02FC030000000001000000<br />0F000000000100</span><span style="font-weight: bold;font-size:85%;" >FFFFFFFF</span><span style="font-size:85%;">01003C000000000F00000001<br /><br />[Snooze: 1 Min]<br />0x270000000000001C02FC030000000001000000<br />0F0000000001000</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">00000001003C000000000F00000001<br /><br />[Snooze: 10 Min]<br />0x270000000000001C02FC030000000001000000<br />0F0000000001000</span><span style="font-weight: bold;font-size:85%;" >A</span><span style="font-size:85%;">00000001003C000000000F00000001<br /><br />[Snooze: 30 Min]<br />0x270000000000001C02FC030000000001000000<br />0F000000000100</span><span style="font-weight: bold;font-size:85%;" >1E</span><span style="font-size:85%;">00000001003C000000000F00000001<br /><br />[Start of Day: 8 AM]<br />0x27000000000000</span><span style="font-weight: bold;font-size:85%;" >E001</span><span style="font-size:85%;">FC030000000001000000<br />0F0000000001000500000001003C000000000F00000001<br />(Minutes past midnight in transposed hex: 01E0 = 480 decimal ; 480/60 = 8 hours)<br /><br />[End of Day: 6 PM]<br />0x270000000000001C02</span><span style="font-weight: bold;font-size:85%;" >3804</span><span style="font-size:85%;">0000000001000000<br />0F0000000001000500000001003C000000000F00000001<br />(Same as above, 0438 = 1080 decimal ; 1080/60 = 18 hours or 6 PM}<br /><br />[First Day of Week: Mon]<br />0x2700000</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">0000001C02FC030000000001000000<br />0F0000000001000500000001003C000000000F00000001<br /><br />[First Day of Week: Tue]<br />0x2700000</span><span style="font-weight: bold;font-size:85%;" >2</span><span style="font-size:85%;">0000001C02FC030000000001000000<br />0F0000000001000500000001003C000000000F00000001<br /><br />[Confirm Delete: No]<br />0x270000000000001C02FC030000000000000000<br />0F0000000001000500000001003C000000000F00000001<br /><br />[Show Free Time in Agenda View: No]<br />0x270000000000001C02FC030000000001000000<br />0F0000000001000500000001003C0000000</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">0F00000001<br /><br />[Show End Time in Agenda View: No]<br />0x270000000000001C02FC030000000001000000<br />0F0000000001000500000001003C000000000F0000000</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;"><br /><br />[Keep Appointments: 15 Days]<br />0x270000000000001C02FC030000000001000000<br />0F000000000100050000000100</span><span style="font-weight: bold;font-size:85%;" >0F</span><span style="font-size:85%;">000000000F00000001<br /><br />[Keep Appointments: Forever]<br />0x270000000000001C02FC030000000001000000<br />0F000000000100050000000100</span><span style="font-weight: bold;font-size:85%;" >FFFF</span><span style="font-size:85%;">0000000F00000001<br /><br />[Wireless Synchronization: No]<br />0x270000000000001C02FC030000000001000000<br />0F000000000100050000000</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;">003C000000000F00000001<br /><br />[Show Tasks: Yes]<br />0x270000000000001C02FC030000000001000000<br />0F0000000001000500000001003C000</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">00000F00000001<br /></span><br /><br />Now for the Address Book:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhieDzzDAPYxNBxCpuRe3B1MozfbpzbIngz0DoLhKo1rC8UAlMgF6o1RH1h73fyhDa_Q-dvwcQJRuTN-5rHEyo1aLiXUbcXTnTvegchCrcWpFjkhsdIc2AgR4x3i7gdSJe7wSeoYqJT5vg/s1600-h/AddressBookDefaults.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhieDzzDAPYxNBxCpuRe3B1MozfbpzbIngz0DoLhKo1rC8UAlMgF6o1RH1h73fyhDa_Q-dvwcQJRuTN-5rHEyo1aLiXUbcXTnTvegchCrcWpFjkhsdIc2AgR4x3i7gdSJe7wSeoYqJT5vg/s400/AddressBookDefaults.JPG" alt="" id="BLOGGER_PHOTO_ID_5162127801458905970" border="0" /></a><br /><span style="font-size:85%;">[Default Settings Above]<br />0x0A000001010000000000000100<br /><br />[Sort By: Last Name]<br />0x0A000001010</span><span style="font-weight: bold;font-size:85%;" >1</span><span style="font-size:85%;">00000000000100<br /><br />[Sort By: Company]<br />0x0A000001010</span><span style="font-weight: bold;font-size:85%;" >2</span><span style="font-size:85%;">00000000000100<br /><br />[Confirm Delete: No]<br />0x0A0000010</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;">0000000000000100<br /><br />[Allow Duplicate Names: No]<br />0x0A000000010000000000000100<br /><br />[Wireless Synchronization: No]<br />0x0A000001010000000000000</span><span style="font-weight: bold;font-size:85%;" >0</span><span style="font-size:85%;">00</span><br /><br /><br />And finally, Tasks:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxLR4zz91Nc4ohqq5yuxSz7UpHB8gggL2qhr-Ds3sCqu4hSg50gEXYa1rbMbeme4FUBnVMQVVkUys6yw6tE77noGvuOPeNFwmKqRdTPw3KUp7jASKWa-thPCx9d1QF8nu7IXWhIEJ_eRs/s1600-h/TasksDefaults.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxLR4zz91Nc4ohqq5yuxSz7UpHB8gggL2qhr-Ds3sCqu4hSg50gEXYa1rbMbeme4FUBnVMQVVkUys6yw6tE77noGvuOPeNFwmKqRdTPw3KUp7jASKWa-thPCx9d1QF8nu7IXWhIEJ_eRs/s400/TasksDefaults.JPG" alt="" id="BLOGGER_PHOTO_ID_5162128510128509826" border="0" /></a><br /><span style="font-size:85%;">[Default Settings Above]<br />0x0F000000000000000000000101FFFFFFFF01<br /><br />[Sort By: Priority]<br />0x0F00000<span style="font-weight: bold;">1</span>000000000000000101FFFFFFFF01<br /><br />[Sort By: Due Date]<br />0x0F00000<span style="font-weight: bold;">2</span>000000000000000101FFFFFFFF01<br /><br />[Sort By: Status]<br />0x0F00000<span style="font-weight: bold;">3</span>000000000000000101FFFFFFFF01<br /><br />[Confirm Delete: No]<br />0x0F000000000000000000000<span style="font-weight: bold;">0</span>01FFFFFFFF01<br /><br />[Snooze: 1 Min]<br />0x0F000000000000000000000101<span style="font-weight: bold;">01000000</span>01<br /><br />[Snooze: 10 Min]<br />0x0F000000000000000000000101<span style="font-weight: bold;">0A000000</span>01<br /><br />[Snooze: 30 Min]<br />0x0F000000000000000000000101<span style="font-weight: bold;">1E000000</span>01<br /><br />[Wireless Synchronization: No]<br />0x0F000000000000000000000101FFFFFFFF0<span style="font-weight: bold;">0<br /><br /><span style="font-size:100%;"><br /><br /></span></span></span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-18609271576429571352008-01-31T12:03:00.000-08:002008-02-01T12:19:57.776-08:00Managing BlackBerry Configuration Settings Remotely - Part FourNow 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:<br /><br /><br /><span style="font-size:85%;">Default Message List / General Options settings:<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrJ9qJ3eJ-IM4wBK8fboKZcsMG6p0zVYknI3BJCG9evomh90ZfL2Ly-cYAzXhMtenf8XYN7nntrU2JHLB9PRqtVjEUecbkrGqx1QHhpLwRRd2QEaGFS1ij6EsTjKYbMUz8dR6-KvE23W4/s1600-h/MailGeneralDefaults.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrJ9qJ3eJ-IM4wBK8fboKZcsMG6p0zVYknI3BJCG9evomh90ZfL2Ly-cYAzXhMtenf8XYN7nntrU2JHLB9PRqtVjEUecbkrGqx1QHhpLwRRd2QEaGFS1ij6EsTjKYbMUz8dR6-KvE23W4/s400/MailGeneralDefaults.JPG" alt="" id="BLOGGER_PHOTO_ID_5162108774753784642" border="0" /></a><br /><span style="font-size:85%;">[Data String for Defaults above]<br /></span><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display Time: NO]</span><br /><span style="font-size:85%;">0x3500000<span style="font-weight: bold;">0</span>0101000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display Name: NO]</span><br /><span style="font-size:85%;">0x350000010<span style="font-weight: bold;">0</span>01000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display Message Header On: 1 line]</span><br /><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B0<span style="font-weight: bold;">1</span>0002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display Message Header On: 2 lines]<br /></span><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B0<span style="font-weight: bold;">2</span>0002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display Message Count: None]<br /></span><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />0<span style="font-weight: bold;">0</span>000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Display New Message Indicator: No]<br /></span><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090<span style="font-weight: bold;">0</span>02000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Confirm Delete: No]<br /></span><span style="font-size:85%;">0x35000001010100000101000<span style="font-weight: bold;">0</span>000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Hide Filed Messages: YES]<br /></span><span style="font-size:85%;">0x350000010101000001010<span style="font-weight: bold;">1</span>01000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Hide Sent Messages: YES]<br /></span><span style="font-size:85%;">0x350000010101000001010001000301010200051E000100060<span style="font-weight: bold;">1</span>020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Make PIN Messages Level 1: No]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030<span style="font-weight: bold;">0</span>010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Auto More: No]<br /></span><span style="font-size:85%;">0x3500000101010000010100010003010<span style="font-weight: bold;">0</span>0200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 15 Days]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">0F</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 2 Months]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">3C</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 3 Months]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">5A</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 4 Months]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">78</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 5 Months]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">96</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: 6 Months]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">B4</span>0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [Keep Messages: Forever]<br /></span><span style="font-size:85%;">0x35000001010100000101000100030101020005<span style="font-weight: bold;">FFFF</span>01000600020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [SMS and Email Inboxes: Combined]</span><br /><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C0<span style="font-weight: bold;">1</span>0002000D000001000E00000000<br /><br /></span><span style="font-size:85%;"> [SMS and Email Inboxes: Separate]</span><br /><span style="font-size:85%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C0<span style="font-weight: bold;">2</span>0002000D000001000E00000000</span><br /><br /><br />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.<br /><br />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.<br /><br />Next: Calendar, Address Book, and Tasks options database settings.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-26018648886550436872008-01-31T09:39:00.000-08:002008-02-01T07:32:39.280-08:00Managing BlackBerry Configuration Settings Remotely - Part Three<span style="font-style: italic;">To begin, of course, a Disclaimer</span>: 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 <span style="font-weight: bold;">not </span>be implementing these findings in my production environment! Now, onto to the madness...<br /><br />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:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQHd5BI78pkj_nCmE3i5ihbUqH0oEZmejI3jYQ2a1ogDhR6LC86RXXMxaYM69bzUNSSt97zXFBLpWObzt-eTgUp4E5pd7blcnjtl_p7QqV6HBbIUpRhVBkvSmVMr79DpgqxRMD_VKySUU/s1600-h/BBScreen1.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQHd5BI78pkj_nCmE3i5ihbUqH0oEZmejI3jYQ2a1ogDhR6LC86RXXMxaYM69bzUNSSt97zXFBLpWObzt-eTgUp4E5pd7blcnjtl_p7QqV6HBbIUpRhVBkvSmVMr79DpgqxRMD_VKySUU/s400/BBScreen1.JPG" alt="" id="BLOGGER_PHOTO_ID_5161698605377016450" border="0" /></a><br />And here is the SQL data, showing that the '1' has been changed back to a '0':<br /><br />0x350000010101000001010001000300010200051E0001000600020008<br />01000100090102000B000002000C020002000D000001000E00000000<br /><br />Now, let's use a SQL command to update this string to change the '0' back to a '1':<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi2OKiP6dH26GmdojU03mJYABIH_nagWELttFhVTTmkszGG3MndB16HmCqkXLk4SzM_258YCYsaD1V_3V58ksf6ttHHpu7B-PEG2YC51d-E677lM9KPMd6rRMhNWn14juopqmYTz82fxk/s1600-h/SQLUpdate.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi2OKiP6dH26GmdojU03mJYABIH_nagWELttFhVTTmkszGG3MndB16HmCqkXLk4SzM_258YCYsaD1V_3V58ksf6ttHHpu7B-PEG2YC51d-E677lM9KPMd6rRMhNWn14juopqmYTz82fxk/s400/SQLUpdate.JPG" alt="" id="BLOGGER_PHOTO_ID_5161702350588498578" border="0" /></a><br />Perhaps if we restart the wireless on the device the change will sync down?<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiY96jXAIUaTubNLZYoyvwhytXUXcYjsQ-Yl0ZPmNCiE1mekioe3gVWQHFPkr4lnjDTyoJlRAQYMX5hjEZVmf73ZRm63UknI18xeOs-oSVcAd8n-S-ncKmURS2fJ1JeysXyaMoVOl-5M4E/s1600-h/BBScreen1.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiY96jXAIUaTubNLZYoyvwhytXUXcYjsQ-Yl0ZPmNCiE1mekioe3gVWQHFPkr4lnjDTyoJlRAQYMX5hjEZVmf73ZRm63UknI18xeOs-oSVcAd8n-S-ncKmURS2fJ1JeysXyaMoVOl-5M4E/s400/BBScreen1.JPG" alt="" id="BLOGGER_PHOTO_ID_5161708393607484066" border="0" /></a><br /><br />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 <span style="font-style: italic;">SyncConfig</span>...and it appears to... wait for it... hold the Synchronization Configuration settings! Just what we need:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCddgAC3vqyPVa5CEW6s-YIK7rIxy55dtUTQTO8kaYIyyk2GakCMQmE6nC8O_TR8qNfGYM2TbJTf_ygV6SlwaIjV2H6ZfgTZuoifkFIowyP-96kH6lrJKDXhBGYd7sB5eoKDFUPr9NAlw/s1600-h/SyncConfig.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCddgAC3vqyPVa5CEW6s-YIK7rIxy55dtUTQTO8kaYIyyk2GakCMQmE6nC8O_TR8qNfGYM2TbJTf_ygV6SlwaIjV2H6ZfgTZuoifkFIowyP-96kH6lrJKDXhBGYd7sB5eoKDFUPr9NAlw/s400/SyncConfig.JPG" alt="" id="BLOGGER_PHOTO_ID_5161709561838588594" border="0" /></a>I see there are many lines associated with <span style="font-style: italic;">UserConfigId </span>9, which is my single test user. I also see a column titled <span style="font-style: italic;">SyncDataSourceId</span>, I wonder what the numbers in this column refer to?<br /><br />After doing some digging I discover the <span style="font-style: italic;">SyncDataSource </span>table, which contains mappings between the numbers in the <span style="font-style: italic;">SyncDataSourceId </span>column and the names of these sources.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8lI0sZvNwXdV-ZyfnaHym5accusvgLTtg80ZBFrowAcaOPnc6B73QmHO_Xs0MRI4ULe6sfk513-qEJzfHF8Y-vwUQrCaTUPw-heDBZn8WcYqXQoI1OrJtw5EJIZdKagFX2sRkqsfEuGo/s1600-h/SyncDataSource.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8lI0sZvNwXdV-ZyfnaHym5accusvgLTtg80ZBFrowAcaOPnc6B73QmHO_Xs0MRI4ULe6sfk513-qEJzfHF8Y-vwUQrCaTUPw-heDBZn8WcYqXQoI1OrJtw5EJIZdKagFX2sRkqsfEuGo/s400/SyncDataSource.JPG" alt="" id="BLOGGER_PHOTO_ID_5161710317752832706" border="0" /></a><br />What we are interested in would be the <span style="font-style: italic;">Backup </span>data source, or number 11109, as this is what we are working with. This leads us to row 102 in the <span style="font-style: italic;">SyncConfig </span>table.<br /><br />Now the question becomes, what do the other columns in this table mean, and what can we do with them? <span style="font-style: italic;">SyncType </span>and <span style="font-style: italic;">ConflictResolution </span>appear especially intriguing given what we are trying to accomplish here.<br /><br />By changing some settings on the device and watching the effect on this table for other unrelated rows, I discovered that the <span style="font-style: italic;">SyncType </span>field has three options available:<br /><br />1 = Server to Device<br />2 = Device to Server<br />3 = Bi-directional<br /><br />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.<br /><br />Similar to <span style="font-style: italic;">SyncType</span>, the <span style="font-style: italic;">ConflictResolution </span>column appears to have two options available:<br /><br />0 = Server Wins<br />1 = Device Wins<br /><br />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.<br /><br />In any case, we have still updated the data in the <span style="font-style: italic;">SyncBackupRestore </span>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.<br /><br />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.<br /><br />Why don't we try to just flip the <span style="font-style: italic;">ServerEnabled </span>setting from 1 to 0, and then back to 1 to see if this does it:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjtZncrW7433z41dMEpDCaWDXBTi2utOryQhCHJ_4Z8NfEqPJeoXdwLMLDnvHRT5o57_cKKdzIfJRgF_gF-Zi9d5_oXAjThxqnC3aZFNHdimsYjGXSiOjcGyhyphenhyphen_dxOftOoHSXSbBbwAvs/s1600-h/SyncConfigUpdate.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjtZncrW7433z41dMEpDCaWDXBTi2utOryQhCHJ_4Z8NfEqPJeoXdwLMLDnvHRT5o57_cKKdzIfJRgF_gF-Zi9d5_oXAjThxqnC3aZFNHdimsYjGXSiOjcGyhyphenhyphen_dxOftOoHSXSbBbwAvs/s400/SyncConfigUpdate.JPG" alt="" id="BLOGGER_PHOTO_ID_5161718980701868754" border="0" /></a><br />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:<br /><br />[46077] (01/31 13:09:36.021):{0x1178} [SYNC-Gate] Finished user config change check. No change detected.<br />[40039] (01/31 13:20:21.856):{0x1EE0} CheckResponseRcvd - no changes detected for any users.<br /><br />Let's move on and try to change another field, how about we try to change the <span style="font-style: italic;">SyncType </span>from '3' (bi-directional) to '1' (server to device):<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeEqGwVD1QqYpJkCmiA13M1KKBnad3tKPGFgQOtqwwKAq-llPDakQBMuVF3Btzanvgrev-D4nPZruhRvdbHrwZXSyFsVkVczmgyPHTfpTv1bBl0M5aHhcvKXB_Q8PCSCmBtc5I4VS34NU/s1600-h/SyncConfigUpdate2.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeEqGwVD1QqYpJkCmiA13M1KKBnad3tKPGFgQOtqwwKAq-llPDakQBMuVF3Btzanvgrev-D4nPZruhRvdbHrwZXSyFsVkVczmgyPHTfpTv1bBl0M5aHhcvKXB_Q8PCSCmBtc5I4VS34NU/s400/SyncConfigUpdate2.JPG" alt="" id="BLOGGER_PHOTO_ID_5161725337253466850" border="0" /></a><br />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:<br /><br />[46078] (01/31 13:26:53.092):{0x1178} [SYNC-Gate] Finished user config change check. Change detected.<br /><br />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:<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifU89U8rgTuQ67sqG6hRepbsj_-qJ1UF3TQXo-qBX8JVEE52vAQHmpPOanPTKwpQENUoXdDnfVsCbslDJkJtC542Syf3UbZR-2A-D4OQQgxqa_uG8lEVtSMhGN5AdFf4Ss1Ij-3FOqbeQ/s1600-h/BBScreen2.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifU89U8rgTuQ67sqG6hRepbsj_-qJ1UF3TQXo-qBX8JVEE52vAQHmpPOanPTKwpQENUoXdDnfVsCbslDJkJtC542Syf3UbZR-2A-D4OQQgxqa_uG8lEVtSMhGN5AdFf4Ss1Ij-3FOqbeQ/s400/BBScreen2.JPG" alt="" id="BLOGGER_PHOTO_ID_5161726518369473282" border="0" /></a><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBj6zeIbF2zChpbcf-Lv9rqIDSv8LtloO9rX8O_cu0WY3uPi5oRp4pKFJv-nUZU2YEgjTrl8Q64MXF6440i4DtS1F9pqSTOxKAnueEfm3OsZUpT11Sdbelc3AJnoiZ9Kas-p8AmztQwKE/s1600-h/616~Dora-The-Explorer-Posters.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBj6zeIbF2zChpbcf-Lv9rqIDSv8LtloO9rX8O_cu0WY3uPi5oRp4pKFJv-nUZU2YEgjTrl8Q64MXF6440i4DtS1F9pqSTOxKAnueEfm3OsZUpT11Sdbelc3AJnoiZ9Kas-p8AmztQwKE/s400/616~Dora-The-Explorer-Posters.jpg" alt="" id="BLOGGER_PHOTO_ID_5161727020880646930" border="0" /></a><br />As Dora would say, "<span style="font-weight: bold;">Lo Hicimos! We did it!</span>"<br /><br /><br /><br /><br /><br /><br />So in summary, we were able to push this change to the device by doing the following:<br /><br />1) Locating the option in the data string of the particular settings database within <span style="font-style: italic;">SyncBackupRestore</span><br />2) Updating the data string with the particular option set, via SQL commands<br />3) Modifying the <span style="font-style: italic;">SyncType </span>from '3' to '1'<br /><br />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 <span style="font-style: italic;">SyncType</span>, so let's set it back to '3' so that any future changes on the device continue to be backed up:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1LpIrGf5c_D-uNUNN-iw-Le-_ErfZUTNEqwZBotWjJIhRD877JLIxxe7SI7AI57MUmRWVJfaTk2jy_EapKkhm5ubYPZn1ZvU24AgRsMUqplYl3DEgz23fDkd-Y0_jn8LO4nIoccKsH0g/s1600-h/SyncConfigUpdate3.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1LpIrGf5c_D-uNUNN-iw-Le-_ErfZUTNEqwZBotWjJIhRD877JLIxxe7SI7AI57MUmRWVJfaTk2jy_EapKkhm5ubYPZn1ZvU24AgRsMUqplYl3DEgz23fDkd-Y0_jn8LO4nIoccKsH0g/s400/SyncConfigUpdate3.JPG" alt="" id="BLOGGER_PHOTO_ID_5161729542026449714" border="0" /></a><br />Next Up: Decoding the Data string in the "Message List Options" database to map out all the different option settings.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-10413199494273870272008-01-30T12:58:00.001-08:002008-01-31T09:39:15.574-08:00Managing BlackBerry Configuration Settings Remotely - Part TwoOK so let's dive in and see what we can do with the SQL table SyncBackupRestore. First of all it looks like there are separate entries for different types of settings. Let's start with the entry for <span style="font-style: italic;">Message List Options</span><span> for <span style="font-style: italic;">UserConfigId </span>#9, which is the only user in this test environment</span>:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYipJzo3jgRsVUWXPOcMAOn-HLramJAHX-_LCH6mH4xoVgQE9T4D5sl4qPwLmr8pMeEgy_BPEXP03IqKSH8VyRzeEzELu5ffFpCmk-uERUEUogfPRe39q9px_2FMbeqj0LChOw-wMn70I/s1600-h/SyncBackupRestore.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYipJzo3jgRsVUWXPOcMAOn-HLramJAHX-_LCH6mH4xoVgQE9T4D5sl4qPwLmr8pMeEgy_BPEXP03IqKSH8VyRzeEzELu5ffFpCmk-uERUEUogfPRe39q9px_2FMbeqj0LChOw-wMn70I/s400/SyncBackupRestore.JPG" alt="" id="BLOGGER_PHOTO_ID_5161379278853526114" border="0" /></a><br />It looks like the Data column is encoded in some sort of binary format, let's see if we can use OSQL to see what's in there:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhukAB7jSOtMSVr0s2VDa8G6VClhVyPg1BonbeW2vgrit9675vDU1ps9dETqiwxLkAQXqN9WB6JGDUHPbrrXacPbgIuYqw5IrQv7qHVPiLbn_uSc-e0zmTNiR2uzuiIuWRLwyAIfh8vFt8/s1600-h/SyncBackupRestoreOSQL.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhukAB7jSOtMSVr0s2VDa8G6VClhVyPg1BonbeW2vgrit9675vDU1ps9dETqiwxLkAQXqN9WB6JGDUHPbrrXacPbgIuYqw5IrQv7qHVPiLbn_uSc-e0zmTNiR2uzuiIuWRLwyAIfh8vFt8/s400/SyncBackupRestoreOSQL.JPG" alt="" id="BLOGGER_PHOTO_ID_5161383294647947890" border="0" /></a><br />So after a bunch of header information we finally see the data string, and it looks like this:<br /><br /><span style="font-size:100%;">0x350000010101000001010001000301010200051E0001000600020008<br />01000100090102000B000002000C000002000D000001000E00000000</span><br /><br /><img src="file:///C:/DOCUME%7E1/mahoward/LOCALS%7E1/Temp/moz-screenshot.jpg" alt="" />As it exists now, this string represents the state of the options for the Message List, i.e. the Messages screen on the BlackBerry. The best way to discover what pieces control which device settings is to change an option on the device, wait for it to get synced up to the server, then check this string again to see what is different.<br /><br />We will first test by changing a single option on the BlackBerry, <span style="font-style: italic;">Hide Sent Messages</span> from the default of <span style="font-weight: bold;">No </span>to <span style="font-weight: bold;">Yes</span> (a common enough request!). Now the issue is waiting for the device's backup agent to push the change to the BES server, however I discover to my pleasant surprise that turning off the antenna and turning it back on will trigger the handheld agent to push any device changes up to the server. (Restarting the BlackBerry has the same effect).<br /><br />I have been using the Unix "tail" utility to follow the BES server's CBCK log file (Backup connector), which is set to the debug logging level of 7 through the registry (4 is the max via the UI). When the device connects to the network we see the following update come through:<br /><span style="font-size:100%;"><br /></span><span style="font-size:100%;">[60000] (01/30 14:26:07.086):{0x151C} [ODBCRecord::DoSetValue] DATA = "DbVersion[1] Data(first 32 bytes)[0x350000010101000001010001000300010200051E000100060102000801000100] UserConfigID[9] DatabaseName[Message List Options] UID[1] ".<br /><br />This log entry only shows the first 32 bytes of the updated field, so we have to go back to the OSQL utility to display the full field again, and it is now set to the following:<br /><br />0x350000010101000001010001000301010200051E000100060<span style="font-weight: bold;">1</span>020008<br />01000100090102000B000002000C000002000D000001000E00000000<br /><br />The only change in this string is the highlighted '1' near the end of the first line has now been changed from a '0' previously. This leads us to believe that this number controls the <span style="font-style: italic;">Hide Sent Messages</span></span><span style="font-size:100%;"> option on the device, and that modifying it from '0' to '1' enables it.<br /></span><br />In the next post we will try to update this field in the SQL database and (somehow!) get that update pushed to the handheld.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-19461598584515784552008-01-30T12:28:00.000-08:002008-01-30T12:48:10.580-08:00Managing BlackBerry Configuration Settings Remotely - Part OneMuch of the configuration of <span class="blsp-spelling-error" id="SPELLING_ERROR_0">BlackBerry</span> devices can be controlled through IT Policy options, especially those having to do with security. However there are many more configuration options available on the device that don't have IT Policy <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">correlates</span>. In these cases it can be difficult to control the user experience or to enforce standard organizational settings.<br /><br />There are a few options to automate the configuration of these device settings:<br /><br />1) Configure a <span class="blsp-spelling-error" id="SPELLING_ERROR_2">BlackBerry</span> with your custom settings, then back it up to a .<span class="blsp-spelling-error" id="SPELLING_ERROR_3">IPD</span> file. For each new <span class="blsp-spelling-error" id="SPELLING_ERROR_4">BlackBerry</span> deployed, restore the .<span class="blsp-spelling-error" id="SPELLING_ERROR_5">IPD</span> file before activation.<br /><br />2) Configure a <span class="blsp-spelling-error" id="SPELLING_ERROR_6">BlackBerry</span> with your custom settings, then assign it to the new user's account. Then activate a new <span class="blsp-spelling-error" id="SPELLING_ERROR_7">BlackBerry</span> against the same account, which will inherit the device configuration settings from the old device.<br /><br />These options can set an initial standard, however they cannot be changed remotely or locked down and enforced over time. The <span class="blsp-spelling-error" id="SPELLING_ERROR_8">BlackBerry</span> device user will have the ability to modify these settings and break the standard.<br /><br />The fact that option #2 above exists tells us that the device configuration settings <span style="font-style: italic;">are </span>stored within the <span class="blsp-spelling-error" id="SPELLING_ERROR_9">BES</span> environment, as that is how swapping in brand new device for a user can inherit all the old device's settings. Unfortunately the location of these settings is not easily accessible to the <span class="blsp-spelling-error" id="SPELLING_ERROR_10">BES</span> Administrator, as this function was really only designed for backup and restoration purposes.<br /><br />However... if we can figure out where these settings are stored perhaps we can modify them somehow from the back end, and push them down to the device. We know that most configuration information is stored in the central <span class="blsp-spelling-error" id="SPELLING_ERROR_11">SQL</span> database, so this is where the configuration must be stored as well.<br /><br />Peeking around my test environment I discovered a table in the database called <span style="font-weight: bold; font-style: italic;"><span class="blsp-spelling-error" id="SPELLING_ERROR_12">SyncBackupRestore</span></span>. It appears that much of the device's configuration settings are stored in this table. In the next post we will dig deeper into this table to discover what it holds and how perhaps we can modify it and push the changes to a remote BlackBerry.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-65766192074778326512008-01-23T10:40:00.001-08:002008-01-23T11:41:33.517-08:00BlackBerry Lookup - The Details (Updated for 4.1 SP4)After doing some troubleshooting on lookups the other day I discovered that there are now some additional fields that are returned via lookup, that were not there back in the 4.0 days when I posted my first post on this over a year ago.<br /><br />Specifically, the Home Address fields have now been added, which is nice. Here is a lookup result that includes as the data the Notes Person document field names that the lookup pulls from for reference:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU9oYsTYl6C30oDJ7YeuoBTAHQcM16IB9_pBS6OFbBWGDY0b56cWRRwV9fY3nKcJiwusEnFRS9qJmV_KutNc2PIulKYiJ9zCxHhRiNYmauKmssmYhEj40f2HlHQR2UavgefYiXV8NoHLw/s1600-h/Lookup4.1.4.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU9oYsTYl6C30oDJ7YeuoBTAHQcM16IB9_pBS6OFbBWGDY0b56cWRRwV9fY3nKcJiwusEnFRS9qJmV_KutNc2PIulKYiJ9zCxHhRiNYmauKmssmYhEj40f2HlHQR2UavgefYiXV8NoHLw/s400/Lookup4.1.4.jpg" alt="" id="BLOGGER_PHOTO_ID_5158745149641085458" border="0" /></a><br />Please note two missing items from this lookup:<br /><br />1) PIN is missing due to the test Person document not having a BlackBerry device<br /><br />2) The "Fax: OfficeFAXPhoneNumber" lookup result is missing, though populated in the Person document. This is due to a known issue introduced in SP4 MR1 and scheduled to be fixed in SP5.<br /><br /><br />Now, onto something interesting that I wasn't aware of before. You are able to customize the lookup results to a certain extent, by using the 4 "User Defined x" fields present in the "Edit PIM Sync Global Field Mappings" command from the BES Manager. [I didn't think this was an option as I always thought that the Global Field Mappings had to do with Address Book synchronization, I never thought they would impact the lookup results.]<br /><br />Simply choose an unmapped field, drop down the Device Field column field and choose one of the User Defined fields to assign it to:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmAm1jwqWHXLLQJT1-NM2njug7h5dO8SUOxr04Hg5ktydi0L7wkWSkXOWcZKuvWwxJJGV45S46wIK5AeiQ0RkNzc5DCjiIfDAUt-ZX5jfefrMlYhmsi9WwX9lYh3ehPHc6bLrulFxb5n4/s1600-h/PIMSync.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmAm1jwqWHXLLQJT1-NM2njug7h5dO8SUOxr04Hg5ktydi0L7wkWSkXOWcZKuvWwxJJGV45S46wIK5AeiQ0RkNzc5DCjiIfDAUt-ZX5jfefrMlYhmsi9WwX9lYh3ehPHc6bLrulFxb5n4/s400/PIMSync.JPG" alt="" id="BLOGGER_PHOTO_ID_5158759421817410130" border="0" /></a><br />In my test environment I have assigned the following custom fields:<br /><br />User Defined 1 --> Assistant<br />User Defined 1 --> Manager<br />User Defined 1 --> Spouse<br />User Defined 1 --> Children<br /><br />When I do this, I get the following lookup result:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvdH_m8F3Si2dmmLBuqpNM3YLtSEHjsP21vSE6ZDc1lWRE-oCmJbslzvxnI91j0XcfdLuqmPcetcCzd2mnGMENJqa6LH_MNCGh66PM7CwIm3yWMr9_gQ2Ku5iHevw0aP4puVrfmG04gQk/s1600-h/Lookup4.1.4B.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvdH_m8F3Si2dmmLBuqpNM3YLtSEHjsP21vSE6ZDc1lWRE-oCmJbslzvxnI91j0XcfdLuqmPcetcCzd2mnGMENJqa6LH_MNCGh66PM7CwIm3yWMr9_gQ2Ku5iHevw0aP4puVrfmG04gQk/s400/Lookup4.1.4B.JPG" alt="" id="BLOGGER_PHOTO_ID_5158753864129729058" border="0" /></a>I see the Assistant, Manager, and Spouse fields, but not the Children field I mapped. Perhaps there is an issue with the "User Defined 4" field not working correctly for lookups. Let me change the mapping of this field to "Department" and see what happens:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPDWHMju3dUofKIL9jRs9GR8v1Ou4n2D2OMQXPERq-rs2F3bTwAAv33sdrzJopNRV6LXAwQfzhCaW1oM5byXfuz5qn9N2wVggGR-rXwFS5ZUyNkVb0J0XOoeQtXUNPeiSbNO7MLWt9iE4/s1600-h/Lookup4.1.4C.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPDWHMju3dUofKIL9jRs9GR8v1Ou4n2D2OMQXPERq-rs2F3bTwAAv33sdrzJopNRV6LXAwQfzhCaW1oM5byXfuz5qn9N2wVggGR-rXwFS5ZUyNkVb0J0XOoeQtXUNPeiSbNO7MLWt9iE4/s400/Lookup4.1.4C.JPG" alt="" id="BLOGGER_PHOTO_ID_5158755105375277618" border="0" /></a>Interestingly, the Department field does come over. So perhaps it is not an issue with the "User Defined 4" field , but with the Children field not working correctly.<br /><br />On a final note, the Comments field on the Person document can be multiple lines and all lines will show up on the BlackBerry lookup. So instead of the "User1:" etc mapping above you can create freeform text lines in the Comments field if you need them on the BlackBerry lookup. For example, I added two additional lines to the Comments field in the Person document, and here they are on the lookup:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuRcRPQ5XSNLC7KvNOo9qahcdGVS96tp2VGkBh6GUaYgXHcAux1PygO4urS8Sllrma20dCIq0bzZo-uqICWxyIdOj974Z_9lWZ9_9TWF8D8AKx5EW4-GNo4t6fJdUUoRZm3q9B7WxRuDA/s1600-h/Lookup4.1.4D.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuRcRPQ5XSNLC7KvNOo9qahcdGVS96tp2VGkBh6GUaYgXHcAux1PygO4urS8Sllrma20dCIq0bzZo-uqICWxyIdOj974Z_9lWZ9_9TWF8D8AKx5EW4-GNo4t6fJdUUoRZm3q9B7WxRuDA/s400/Lookup4.1.4D.JPG" alt="" id="BLOGGER_PHOTO_ID_5158756355210760770" border="0" /></a>I'm not sure what the limit on the number of lines or characters are for the free form text Comments field. I was able to put 60 lines of information in that field and they were all returned to the BlackBerry on a lookup, so there is quite a bit of information that could be stored here.<br /><br />Well I hope this helps you customize your lookups so that you can give your users better information directly on their device. Now the greater problem is how to get all this good information from other sources, such as the HR database, into the Person documents in names.nsf in the first place. (Luckily for me that heavy lifting job was already done by our development team for another project.) Good luck!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-65369147255408376532008-01-22T10:19:00.000-08:002008-01-22T10:42:08.117-08:00Lookup Strangeness -> "Reset PIM Sync Global Field Mapping" is the FixI recently discovered that our BlackBerry lookups were returning some bad information. Our addressing information was coming up wrong, in that the Home Address header was missing, replaced by a second Work Address header. Also, the information in the home address fields was limited just to city and country.<br /><br />Here is what we were seeing (fields filled with dummy info for testing):<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKLLhEtP6aHDgc093wboNt5co_fNhyphenhyphenqMIyKHcn2_oNPQKNw0wNxRaDvHZ9Rku0ImuD1ni4-UNCr_K4PdJ78oKA7I-icQtdd37mKsBBG-OYwcX3sV4D__CnaWirsooOehNbq6BbT2E617w/s1600-h/BBscreen-mahoward-2.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKLLhEtP6aHDgc093wboNt5co_fNhyphenhyphenqMIyKHcn2_oNPQKNw0wNxRaDvHZ9Rku0ImuD1ni4-UNCr_K4PdJ78oKA7I-icQtdd37mKsBBG-OYwcX3sV4D__CnaWirsooOehNbq6BbT2E617w/s400/BBscreen-mahoward-2.JPG" alt="" id="BLOGGER_PHOTO_ID_5158369944083490418" border="0" /></a><br />The last address is actually the two home address fields city and country, but labeled as a second Work Address. I had never seen this before, at least this was working properly a few months ago. We have a secondary BES infrastructure in the EU, totally separate, but alas this was occuring there too, which pointed to a Domino problem.<br /><br />I assumed this must be due to some corruption or weird customization in the names.nsf, where the BES pulls this information from. However copying and pasting my person document into my test BES environment, then doing a lookup from a test device, returned all the proper information! Puzzling...<br /><br />It is difficult to explain this issue to RIM support, and they also could not recreate the solution in their environment. On a whim, I decided to investigate the "Reset PIM Sync Global Field Mapping" command. After testing this in the test environment and determining that this command would not reset user's custom address book mappings, I ran it. Guess what? All lookup problems solved:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbCi4JZ-mq98ibS9nBaMy8APJJpn3qDUraVxPVciSFDEGdkEYQBROQAk9NEgpVd530FIgGA9nVv94kTXn4twe5FXNcaR_cyb460Mc_-ga6E24SG2KFDbFAR8AhfrsPEzRbcY7N7gST96E/s1600-h/BBscreen-mahoward-1.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbCi4JZ-mq98ibS9nBaMy8APJJpn3qDUraVxPVciSFDEGdkEYQBROQAk9NEgpVd530FIgGA9nVv94kTXn4twe5FXNcaR_cyb460Mc_-ga6E24SG2KFDbFAR8AhfrsPEzRbcY7N7gST96E/s400/BBscreen-mahoward-1.JPG" alt="" id="BLOGGER_PHOTO_ID_5158371168149169794" border="0" /></a>The Home Address is now properly labeled, and although blanked out above, the fields for street address, state, and zip code now appear along with city and country.<br /><br />This solution points to the address book mappings being off kilter within the BES SQL database, but how did that happen? We don't touch them. And since both of our completely separate BES environments experienced the issue, I must believe that a particular upgrade path (we keep versions the same in US and EU) caused this mis-mapping.<br /><br />Easy solution to a strange issue!<br /><br />p.s. I discovered some other interesting lookup related information during this search that I will discuss in an upcoming post.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-67969934604806959222008-01-16T09:19:00.000-08:002008-01-16T10:17:21.496-08:00How to Recover* from a Total Loss of BESMgmt SQL database (* with caveats...)The BESMgmt SQL database is the heart of the Blackberry Enterprise environment. Without it, BES servers will continue to deliver mail but no meaningful changes can be made, or BES services restarted, until it is back up.<br /><br />The only piece of the BES environment that is out of my control is the database, which is hosted and managed by our SQL team. Although I have full confidence in their replication, backup, and recovery plans, I still need to plan for the (hopefully very remote) possibility that the SQL db might go bye-bye someday.<br /><br />Until now, this worst case scenario resulted in an "oh well, everybody will have to reactivate their devices" DR plan. I dread the day I have to say this to the CIO!<br /><br />Recently, however I got wind of the idea of using the <span style="font-weight: bold;">nbesmigration.exe</span> utility for DR purposes. This utility was originally designed to populate user accounts in the 4.0 SQL database from a version 2.2 profiles database. Since the 4.x environment still maintains a BlackBerryProfiles notes database on each server, the tool could theoretically be used to re-create the user accounts from these profile entries into a brand new SQL database.<br /><br />While running the tool in testing, I noticed the following text as part of the built-in help:<br /><br /><span style="font-size:78%;">BlackBerry Enterprise Server(c) for Lotus Domino(c) Migration Tool, Version 4.1<br />Copyright (c) Research In Motion, Ltd. 2004, 2006. All rights reserved.<br />Modification date: May 8 2007<br /><br />Usage: NBESMigration.exe [options]<br /><br />This tool can be used to migrate entries from BESD 2.2.x Profiles database to BESMgmt database (UserConfig table). For migration, create the database first using CreateDB, create a server entry in ServerConfig, and run this tool from your BESD server's Domino directory.<br /><br />This tool can also used for disaster recovery or fixup purposes on already installed BESD server (4.0 and up). Shut down the BES, and run this tool from your BESD server's Domino directory. The tool will check all user docs in Profiles DB, create entries, if needed, in BESMgmt DB (UserConfig table), and it will link entries using SQLID field.<br /></span><br />From the text it appears that this tool does support a limited form of DR. Good news! So to test, I did the following in my test environment:<br /><br />1. Detach the BES SQL db and drop all connections.<br /><br />2. Stop BES server task and services.<br /><br />3. Run the BlackBerry Congfiguration Utility and choose the Change Database option.<br /><br />4. Enter a different database name, thus creating a brand new database.<br /><br />5. Re-enter CAL and SRP information, but do not restart services.<br /><br />6. From the tools subdirectory of the BES 4.1 installation share, copy the nbesmigration.exe executable to the c:\lotus\domino directory<br /><br />7. Run the following command <span style="font-style: italic;">nbesmigration -d: "[SQL Server name]" "[SQL DB name]" -u: [SQL login] [password].</span> In my case this command line looked like this:<br /><br /><div style="text-align: center;"><span style="font-size:85%;">nbesmigration -d: "SQLTEST01" "BESMgmtTest" -u: besdbowner besdbpassword</span><br /></div><br /> The tool indicated that it found my one test account and migrated it successfully.<br /><br />8. Restart the BES server task and services.<br /><br />The server fired up and I was able to immediately send and receive messages, and do lookups from my device! So this is a great way to recover basic functionality in the case of a total loss of the SQL db.<br /><br />Keep in mind that you need some information documented and handy to provide to the configuration wizard:<br /><ul><li>CAL licenses</li><li>SRP ID's</li><li>SRP Authorization keys</li></ul>Now, for the caveats:<br /><ul><li>IT Policies are reset to defaults (!)<br /></li><li>PIM Sync Mappings are reset to defaults</li><li>Email Settings are reset to defaults</li><li>Probably a bunch of other stuff is gone or reset to defaults</li></ul>Although some of the other stuff is fixable, I was unable to successfully apply the default IT policy or a newly created IT policy in the new enviroment, even when it was named the same as the old IT policy. It always came back with an error. On the other hand, when I switched DB's back to the original, the original IT policy was able to be re-applied successfully.<br /><br />The upshot is that this is a last-last-resort option to get mail flowing to the devices without having everyone reactivate. If you can later restore the original SQL DB and switch back to it, then IT Policies, PIM Sync settings, etc, can be restored back to their original good state.<br /><br />If you can never get the original DB back, however, then you might have to move forward and find some creative solutions to the problems above. If the solution does eventually require handheld reactivation, well then at least you can control and stage it on your terms, without having hundreds of people screaming at you to get their BlackBerry email fixed!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-8109561026517420542008-01-15T08:01:00.000-08:002008-01-15T08:30:37.485-08:00Last Handheld Contact Times - Bogus?This is a useful field to know when the last time the server talked to the handheld... until I started to suspect this information, as there were contact times very recently with handhelds that I knew were disabled.<br /><br />To test this out I turned off my BlackBerry and restarted the BES task. The last handheld contact time updated to the current time, with the device turned off in front of me! See the below screenshot, showing last contact time of 1/15/2008 10:16:51AM, when the device was turned off at about 10:10 AM.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijfavCYuePbAqvpz7OD943bGSltN0xHZ2qT-fNEaPoOIPDzRFYzH-6OTXGfdOaIVmfVLqqYAsnp0gh7NICOKgJotIXa2XqIZUaSlliYA94yFBlKU1UWM4y58Zz0vPRhhdF3uSUfA23hHw/s1600-h/LastContactBogus.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijfavCYuePbAqvpz7OD943bGSltN0xHZ2qT-fNEaPoOIPDzRFYzH-6OTXGfdOaIVmfVLqqYAsnp0gh7NICOKgJotIXa2XqIZUaSlliYA94yFBlKU1UWM4y58Zz0vPRhhdF3uSUfA23hHw/s400/LastContactBogus.JPG" alt="" id="BLOGGER_PHOTO_ID_5155740139903116898" border="0" /></a><br />To see why this is updating, I checked the MAGT logs for activity on my account during this time:<br /><br /><span style="font-size:85%;">[40000] (01/15 10:16:51.733):{0xB04} {Test User/Domain} Sending PIM Transaction to Sync Server, Tag 225 (config request)<br />[40000] (01/15 10:16:51.733):{0x1F9C} [BIPP] Send data, Tag=225<br />[40000] (01/15 10:16:51.748):{0x19E0} [BIPP] Received status DELIVERED, Tag=225<br />[40392] (01/15 10:16:51.748):{0xB04} {Test User/Domain} SRP: TID=225, type PIMSYNC returned DELIVERED<br />[40000] (01/15 10:16:51.748):{0x19E0} [BIPP] Received datagram, Tag=436<br />[40076] (01/15 10:16:51.748):{0xB04} {Test User/Domain} SendStatusToWirelessNetworkUsingSRP SendQ, TID=436<br />[40400] (01/15 10:16:51.748):{0xB04} {Test User/Domain} Received datagram with content type agent_sync, TID=436, for user Test User/Domain<br />[40000] (01/15 10:16:51.748):{0x1F9C} [BIPP] Send status DATA_ACCEPTED, Tag=436</span><br /><br />The only activity that occured was an internal communication to the Sync server, and what looks like a request to perform a handheld agent sync. Note that both transactions appear to show successful connections with the device, however these are only internal communications between components on the BES server itself. Perhaps the time of successful <span style="font-style: italic;">internal </span>communication is being reported?<br /><br />In any case, it appears that this is quite a bogus field which provides no useful real world information.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-58968900236656540442007-11-02T12:59:00.000-07:002007-11-02T13:42:42.492-07:00MDS What?MDS stands for Mobile Data Service, and it is a service that allows you to access other data sources (mostly Internet / Intranet browsing) via your BlackBerry.<br /><br />In BES 4.1, however, MDS has turned into a many-headed hydra. What we know of as "BlackBerry Mobile Data Service" in 4.0 is now inexplicably called the "BlackBerry MDS Connection Service" in 4.1. Meanwhile, there are a whole bunch of new MDS related services:<br /><br />•BlackBerry MDS Application Integration Service<br />•BlackBerry MDS Data Optimization Service<br />•BlackBerry MDS Provisioning Service<br />•BlackBerry MDS Administrative and Management Service<br />•BlackBerry® MDS Studio Application Repository<br /><br />But wait, there's more! The new MDS stuff also requires a brand new SQL db running on the same SQL server as the BESMgmt database, which can results in permission issues when creating without the proper authority.<br /><br />All of the above services & database are related to the new 4.1 software deployment environment installed when you choose the upgrade option called:<br /><br />"BlackBerry Enterprise Server with MDS Services and Components"<br /><br />But really, this whole new "MDS" software deployment infrastructure is not needed at the initial upgrade from 4.0 to 4.1. To avoid complexity, you can leave this whole new set of services out of the upgrade. Later, you can install the new MDS stuff on a separate server if you like, as it was made to be modular and have one separate MDS instance serve many BES servers.<br /><br />The confusing part is that if you run the upgrade, you get these two choices:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3ggq8dkC0YJS1cn1s6KxOrCfbzZh5u7tg5gcW486d7NcY_qfc-6uJdn6dTFndzafEwxrikFfWjyOw2l0ug0Nt6NO4-RVhS7xeRVodDzcpavFB3zoXofZfJif0tQDlKgLTA1Zt6Ewe6hg/s1600-h/Upgrade.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3ggq8dkC0YJS1cn1s6KxOrCfbzZh5u7tg5gcW486d7NcY_qfc-6uJdn6dTFndzafEwxrikFfWjyOw2l0ug0Nt6NO4-RVhS7xeRVodDzcpavFB3zoXofZfJif0tQDlKgLTA1Zt6Ewe6hg/s400/Upgrade.JPG" alt="" id="BLOGGER_PHOTO_ID_5128345958887113586" border="0" /></a><br />If I do not know *exactly* what this means, I will by default choose the second option, "BlackBerry Enterprise Server with MDS Services and Components", because I want to keep my MDS service from 4.0, right?<br /><br />Wrong... choosing the first option will give you the same 4.0 MDS (renamed MDS Connection Service) while avoiding the complexity of installing the new whiz-bang MDS software deployment stuff.<br /><br />In a nutshell: if you want to greatly simplify your 4.0 -> 4.1 upgrade, opt for the first install method selected in the picture above. You will lose no MDS functionality from the 4.0 perspective, and can add on the new stuff later when you are ready and comfortable with 4.1.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-8542532489456200473.post-35361431585232189312007-11-01T07:09:00.000-07:002007-11-01T07:22:24.594-07:00Malformed Message Crashes BES 4.1 SP4The idea that a malformed message will crash a BES server is nothing new - service packs have taken care of these issues many times in the past. I apparently discovered another one, as one of my servers crashed twice just after midnight last night.<br /><br />Fortunately Domino restarted itself and was back up and operational in minutes (thanks transaction logging!). After the second crash, however, it did not crash again. Usually the BES will keep trying to re-read the malformed message and crash over and over until you figure out the message and delete it from the user's mailfile, but not this time.<br /><br />From the logs I see the attempts to read which resulted in crashes:<br /><br /><img src="file:///C:/DOCUME%7E1/mahoward/LOCALS%7E1/Temp/moz-screenshot.jpg" alt="" /><img src="file:///C:/DOCUME%7E1/mahoward/LOCALS%7E1/Temp/moz-screenshot-1.jpg" alt="" /><img src="file:///C:/DOCUME%7E1/mahoward/LOCALS%7E1/Temp/moz-screenshot-2.jpg" alt="" /><span style="font-size:85%;">[40000] (11/01 00:00:44.858):{0x19B0} {User} [Mailfile], ModifiedByName detected change<br />[40000] (11/01 00:00:44.905):{0x19B0} {User} [Mailfile], fetching modified documents since 11/01/2007 12:00:43 AM<br /><br />..[CRASH HERE!]..<br /><br />[40000] (11/01 00:05:02.452):{0x1830} {User} [Mailfile], ModifiedByName detected change<br />[40000] (11/01 00:05:02.452):{0x1830} {User} [Mailfile], fetching modified documents since 11/01/2007 12:00:43 AM<br /><br />..[CRASH HERE!]..</span><br /><br />But on the third attempt I see this:<br /><br /><span style="font-size:85%;">[40000] (11/01 00:08:10.515):{0x1640} {User} [Mailfile], fetching modified documents since 11/01/2007 12:00:43 AM<br />[20039] (11/01 00:08:10.530):{0x1640} {User} Already attempted to open NID=3DAF2 for user User: Message has been quarantined, skipping now</span><br /><br />Nice job RIM! This quarantining feature allowed me to stay peacefully asleep instead of having to get up and hunt down the offending message.<br /><br />BTW, the message in question was a digest from a mailing list which included a BinHex encoded MIME part <span style="font-style: italic;">in the body of the message</span>:<br /><br /><span style="font-size:85%;">--B_3276667131_13573<br />Content-type: application/mac-binhex40; name="[Filename].doc"<br />Content-disposition: attachment;<br /> filename="[Filename].doc"<br /><br />(This file must be converted with BinHex 4.0)<br />:(8K[G#p1Eh3J9A"NBA4P)#dJ5R9XH5!R-$FZC'pM!&Fi3Nj08eG%!*!%UJ#3"GN<br />Jd-m4i+'a'Z%!N"!q!!-!r[m*!!B!N!X"!*!$8!#3#"!!!&)!N!-"!*!$r[q3!`#<br />3"%m!N!2rN2rrN,(XTF%!Kf%*"!!!q"+r!*!&!4%!!3!"!!B!!28L!!!1!'TLDQ+<br />`Zl#l!*!5#33@!#3d!!$Df3%!fYN"!28F!*!Hrrm2!*!*rrm2!*!*rrm2!*!4L!#<br /></span><br /><br />I am pretty sure this is the part that utterly confused the BES since:<br /><br />a) it was in the body<br /><br />and<br /><br />b) was a binhex part, which I have seen trouble with in prior BES versions even when it was properly encoded.<br /><br />Looking through the release notes for 4.1 SP4 MR2, I see the following:<br /><br /><span style="font-size:85%;">*SDR 135729 In BlackBerry Enterprise Server Version 4.1 SP4, if a message contained truncated or incorrectly encoded data, the BlackBerry Enterprise Server might have stopped responding. In BlackBerry Enterprise Server Version 4.1 SP4 MR2 and later, this issue is resolved.</span><br /><br />I love to see this - it means I don't have to report the issue to RIM, someone else already has! Also I can tell my manager when he asks about the crashes that it is already fixed in the next maintenance release, which we will now plan on deploying.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-12141450056944300422007-10-24T10:18:00.001-07:002007-10-24T10:24:46.352-07:00Decoding the BlackBerry State DatabaseSo we all know that state database correlates the messages in the mailfile with the messages on the BlackBerry. The way it does this is by creating a separate entry in the state database for each email the BES sees in the mailfile. Each of these entries has exactly the same UNID as the original email in the state database.<br /><br />Now I am trying to decode the MessageState field in the state database entries. Searching through my own state database, I find all of the following various "state codes" under the MessageState field:<br /><br />0<br />1<br />2<br />3<br />4<br />5<br />7<br />8<br />9<br />10<br />13<br />14<br />17<br /><br />That's alot of "states" a message can be in!<br /><br />I have started testing and have determined the first couple:<br /><br />2: Email has been queued / sent to wireless network but not received by device yet<br />3: Email not redirected to handheld (redirection disabled)<br />4: Email has been delivered to device<br /><br />It will be tough to figure out the rest, though! I will update this doc as I discover them...Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8542532489456200473.post-32532293504303326122007-10-08T10:34:00.000-07:002007-10-08T11:13:23.675-07:00Remove IT Policy - New Feature of 4.1 SP4 / OS 4.2.2We now have an easy way to remove the applied IT Policy from a handheld, which was previously locked to the device even after you wiped it.<br /><br />If you have 4.1 SP4 and a device with OS 4.2.2 or greater, here is how to remove the IT policy and set the device to a true factory default state:<br /><br />1) Create a new IT policy (or modify an existing policy) and set the <span style="font-weight: bold;">Remote Wipe Reset to Factory Defaults</span> setting in the <span style="font-weight: bold;">Security Policy</span> group to <span style="font-weight: bold;">True</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3dc2p5mQlAuNTakUKRfzlrsj28biAw_t3TugB-dh6TvrsdLFulLJu4_5kjQXhTfgPNItewW7ksKaD8pdpt_J_iENeEX8-ZRnfVqpe00qJEaYoiBZWpT6i6fsE3lym9MgpcDi0hIA4vw/s1600-h/ITPolicyRemoval.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3dc2p5mQlAuNTakUKRfzlrsj28biAw_t3TugB-dh6TvrsdLFulLJu4_5kjQXhTfgPNItewW7ksKaD8pdpt_J_iENeEX8-ZRnfVqpe00qJEaYoiBZWpT6i6fsE3lym9MgpcDi0hIA4vw/s320/ITPolicyRemoval.JPG" alt="" id="BLOGGER_PHOTO_ID_5119030603907502834" border="0" /></a><br /><br />2) Assign this IT policy to a particular user account<br />3) Send the command "Erase Data and Disable Handheld"<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_fqVVjihh_g6zDp-Hxkee0JC0yVxBIfXzoci0J6VJ4NNVr5OkYJSkfKi2yHRdezGWzu-yDx0GS1bXOOJHCmLm4KHmKvBY_rairVuDxqUit3dbnU7M8DF8dwiFI7RpSTP5SgdHmceRfsc/s1600-h/ITPolicyRemoval2.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_fqVVjihh_g6zDp-Hxkee0JC0yVxBIfXzoci0J6VJ4NNVr5OkYJSkfKi2yHRdezGWzu-yDx0GS1bXOOJHCmLm4KHmKvBY_rairVuDxqUit3dbnU7M8DF8dwiFI7RpSTP5SgdHmceRfsc/s320/ITPolicyRemoval2.JPG" alt="" id="BLOGGER_PHOTO_ID_5119022804246893282" border="0" /></a><br /><br />4) Verify receipt of command by device under "IT Policy Status"Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8542532489456200473.post-2432233798656698712007-09-27T06:14:00.001-07:002007-09-27T06:23:06.118-07:00Update on Comcast's Man in the Middle Attacks on Lotus NotesFor those of you Notes client users suffering from Comcast's "filtering", there is a <a href="http://kkanarski.blogspot.com/2007/09/comcast-filtering-lotus-notes-update.html"> great post by my colleague Kevin Kanarski</a> who has details of packet captures that result from sending an email with a 6MB attachment from a Notes client using the Internet connection.<br /><br />These captures, from both ends, clearly show that Comcast is imitating both the client and server in sending RST [reset] packets to the other end of the connection. Neither the client nor the server generated any RST packets, so this is definitely shady behavior by Comcast.Unknownnoreply@blogger.com0