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.
Subscribe to:
Post Comments (Atom)
3 comments:
Hi Mark,
Have you any idea what is causing the duplicate entries in the SyncDeviceMgmt table?
I am having the same issue and although clearing the table resets the status, each time I push an updated app it ends up reverting to the Device State Invalid with the same old module version entry in the table.
Toggling the "Automatic BlackBerry Device Management Enabled " does seem to clear the table, bu tI'm seeing the single entry in SyncDeviceMgmt as the old module verion, then after a period of time another appears with the new version - back to Device State Invalid.
We, too are pushing out to lawyers, and so have the same aversion to user intervention :)
this is great information i really like this and i hope that every one will get help full this informatoin
Blackberry Mobiles
It was very help full for my new site…Tecno-mobiles phone in pakistan
Post a Comment