Friday, March 6, 2009
Moving 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!
Thursday, January 8, 2009
Software Configuration Push Problems Wrapup
Well 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!)
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.
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.
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.
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 Automatic BlackBerry Device Management Enabled setting to False, clicking OK, waiting 1 minute, then going back in and setting it to True. 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.
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.
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.
Hope this little learning experience helps you all out there as much as it has me.
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.
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.
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.
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 Automatic BlackBerry Device Management Enabled setting to False, clicking OK, waiting 1 minute, then going back in and setting it to True. 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.
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.
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.
Hope this little learning experience helps you all out there as much as it has me.
Subscribe to:
Posts (Atom)