[Frank Castle]

Hi,

I have been trying to update all my users who are using Bloomberg client on Blackberry. I have everything indexed and setup properly and the package pushes fine to users who don't have an exsisting client, anyone who has the older client though just sits on Upgrade Required.

Any help would be great!

jeff

[ladydi]

my personal opinion? you're screwed. I went through the same thing when I thought I wanted to use a whitelist instead of IT policy to deny 3rd party app install. I was using google maps to test. I had the same experience and after a month of converstions with RIM, they told me it was by design that the app push didn't do updates to existing software. To save on data usage charges they said. I countered with I am in the US and have truly unlimited data so I would like the app push to work reasonably. We left off with me requesting that they tell me where in the DB I can hack the switch that makes BES think the app already exists and RIM ignoring me.

Is is deleting the original app and not installing the new one?

[Inphektion]

I've had this randomly with a few users on various apps. sometimes kicking off a remote enterprise activation fixes it, maybe give that a try.

[Frank Castle]

I'm going to have to side with ladydi .. I've been beating this up and 5 calls into T-Support is not getting me anywhere .. it just doesn't update if the App is already installed (regardless if the push is newer then the one installed)

I hope future BES SP, releases make this feature more robust as now it's somewhat have baked.

Has anyone use software configurations to UPDATE software already on the device successfully?

[Inphektion]

yes i do it all the time. did you upgrade the ver numb in the .alx.
if enterprise activation didn't work you could set a remove policy on the old one and then the install policy on the new one.
what version BES you on? The software push stuff got a lot better for me on 4.1.4

[DarkWater]

4.1.4 for the Exchange platform anyway.. has a manual command to initiate a push of software. It's called "Deploy Applications" and if I remember right it is under IT Admin.

Could also attempt that. But Inphektion is right, if the alx lists the same version number than it won't push in any case.

[hdawg]

DarkWater, have you seen any docs on this new command? I cant find anything on it.

[DarkWater]

Originally Posted by hdawg

DarkWater, have you seen any docs on this new command? I cant find anything on it.

Unfortunately it is not documented, I have already looked.

It does the same thing as the regular poll but immediately for the specific user.

[mvdwerf]

I'm having the exact same problem with the Bloomberg app.

Initial pushes work fine, but devices requiring an upgrade show "upgrade required" but nothing happens.

After installing the updated app on the BES and running loader /reindex the new version does show up in the BES Manager.

The devices that already have the old version installed receive a popup windows asking the users to restart the device. After the restart, the Bloomberg icon disappears from the desktop, but the app still shows up in the Applications list under Advanced Options.

When I try to force the application by using the "Deploy Applications" command from the BES Manager, the policy log shows:

Send Application to device failed for entryid 488, "FF Device Reported a general failure installing the module"

(one line for each of the COD modules that make up the Bloomberg app)

Manually removing the old app from the device also does not work. The new app still doesn't get pushed.

Has anyone found a solution for this yet?

[Frank Castle]

What I wound up doing was deleting the whole bloomberg config and starting from stratch. One of the older bloomberg clients did note that it had an issue with wireless deployment.

The process I've used for the last couple "version upgrades"

Delete the folder with the old files (as well the package cache location)
copy the new files into the share
index
wait 4 hours
anyone that has the config assign should get the update pushed.

I've seen the symptom you outlined and believe it's something with bloomberg than anything wrong on the BES side.

[zip]

When you're having this problem, is the application disposition set to Optional or Required?

-zip

[mvdwerf]

@jletendre: I tried your procedure when trying to upgrade from the december 2007 to the januari 2008 release, but it didn't work. The strange thing is that the new RepliGo Viewer application was installed, but the Bloomberg app was not upgraded.

@zip: I have the application disposition set to "required".

I want to prevent users from installing their own applications, so I set it up as follows:

- Allow Third Party Applications to be installed set to TRUE in the users' policy
- Created a Disallow All Applications policy and assigned that to the top-level in the Software Configuration
- Created an Allow Bloomberg Application policy and assigned that to the Bloomberg app in the Software Configuration

I found this procedure in another thread and this way you can control which third party apps to allow and which not to allow.

Now when I upgrade the app, the old version disappears from the icon list, but is still listed under Advanced Options -> Applications. The device also gives a popup message stating that an application is no longer allowed and asks for a restart. Even after restarting the new version is not pushed. Also, the old version can still be seen in the Applications list, but it can be removed manually. After manually removing it, the new version is still not being pushed.

[eekman]

Hi,

We're having the same issue with the new Bloomberg version.
We pushed out several versions before and had the same issue with the september 2007 version which was corrected in the next version as can be read from the change log.

What I am curious about is the subfolders that are created during the Bloomberg Install:
- 4.0.2
- 4.1
- 4.2
- 4.2.1
- 4.3

It seems Bloomberg has an OS API File (com_bloomberg_osapi.cod) per OS version. How does this get pushed to the client? I could not find any information in the Bloomberg docs which relates to these directories. Even the POLC log file does not show any of these dirs.

Also the last time we had problems with the Bloomberg push, we needed to rebuild the software configuration to make it work again.

[eekman]

To add to my previous post as editing does not seem to work for me:

The thing is that the new version has to be pushed to the BlackBerry's before January 25th according to Bloomberg because otherwise the BlackBerry's will not be able to connect to Bloomberg anymore due to a new conmnection system they implemented.

Any help is much appreciated!

[msmithcanyon]

What I did to get around this (I'm lucky to have a small user base of about 150 of which only a small percentage use BB)...

Set the disposition to Optional on the current software config and then sent out upgrade instructions to the users (basically...log in, and choose upgrade). The bad part is all the firewall acceptions you have to click through.

I wanted to do it all wirelessly, but I've had too many issues with application removal/upgrades that it wasn't worth it. When our test BES is up, I will test some various scenarios and see what happens.

[eekman]

The only workaround we found is to disable whitelisting temporarily.
Whitelisting is specified using "Deny" on "Application Software" level.

Bloomberg has confirmed this is an issue in the software and have prepared an update which will be released soon.

The thing is when using whitelisting only one version of the com_bloomberg_osapi.cod is supported by OTA install.

Aother workaround is to open up bloomberg.alx and remove all references to 'com_bloomberg_osapi' in sub directories and just leave in the one from the root directory. This will deploy the OS 4.0 version of 'com_bloomberg_osapi', which is upward compatible.

[msmithcanyon]

This whole updating of their software is horrible. Today, we had a bunch of users who try to log in with the old version and all they get is "Your version is too old" and you have no option to upgrade. You have to manually uninstall the old version, then go to the web URL to download the latest version to the device.

The reason is, if you just place the newest version of Bloomberg on the BES, it deploys and installs correct, but when you launch it, there is some osapi error! Such junk! They should fix this before cutting off old versions.

[msmithcanyon]

Originally Posted by eekman

The only workaround we found is to disable whitelisting temporarily.
Whitelisting is specified using "Deny" on "Application Software" level.

Bloomberg has confirmed this is an issue in the software and have prepared an update which will be released soon.

The thing is when using whitelisting only one version of the com_bloomberg_osapi.cod is supported by OTA install.

Aother workaround is to open up bloomberg.alx and remove all references to 'com_bloomberg_osapi' in sub directories and just leave in the one from the root directory. This will deploy the OS 4.0 version of 'com_bloomberg_osapi', which is upward compatible.

Can you explain in a little more detail what edits you did to the alx file?

<loader version="1.0">
<!-- Bloomberg for BlackBerry -->
<application id="com.bloomberg.ax.mobile">
<name>Bloomberg</name>
<description>Bloomberg Apps for BlackBerry</description>
<version>1.8.1.12</version>
<vendor>BloombergLP</vendor>
<copyright>Copyright (c) 2008 Bloomberg</copyright>
<fileset Java="1.0">
<directory/>
<files>
com_bloomberg_bblib.cod
com_bloomberg_transport.cod
com_bloomberg_launcher.cod
com_bloomberg_msg.cod
com_bloomberg_top.cod
com_bloomberg_mkt.cod
com_bloomberg_wei.cod
com_bloomberg_quote.cod
com_bloomberg_chart.cod
com_bloomberg_ib.cod
com_bloomberg_alrt.cod
com_bloomberg_blawlib.cod
com_bloomberg_people.cod
com_bloomberg_transportlib.cod
com_bloomberg_fly.cod
com_bloomberg_dine.cod
com_bloomberg_bbuilib.cod
com_bloomberg_monitor.cod
com_bloomberg_blaw.cod
com_bloomberg_tk.cod
com_bloomberg_eco.cod
com_bloomberg_appframe.cod
com_bloomberg_evts.cod
com_bloomberg_tklib.cod
com_bloomberg_citator.cod
com_bloomberg_viewlib.cod
com_bloomberg_personalmonitors.cod
</files>
</fileset>

<!-- CODs with OS-specific code.
Must never be installed on BlackBerrys
running an OS version lower than the target OS. -->
<fileset Java="1.0">
<directory _blackberryVersion="[4.0,4.0.2)"/>
<directory _blackberryVersion="[4.0.2,4.1)">4.0.2</directory>
<directory _blackberryVersion="[4.1,4.2)">4.1</directory>
<directory _blackberryVersion="[4.2,4.2.1)">4.2</directory>
<directory _blackberryVersion="[4.2.1,4.3)">4.2.1</directory>
<directory _blackberryVersion="[4.3,)">4.3</directory>
<files>
com_bloomberg_osapi.cod
</files>
</fileset>
</application>

<!-- RepliGo document viewer (PDF, TXT, DOC, XLS, PNG, HTML, etc.) -->
<application id="RepliGoProEnterprise">
<name >
RepliGo Pro Enterprise Edition
</name>
<description >
RepliGo Professional Enterprise Edition
</description>
<version >
2.1.0.10
</version>
<vendor >
Cerience Corporation
</vendor>
<copyright >
Copyright © 2007 Cerience Corporation
</copyright>
<fileset Java="1.0">
<directory >
</directory>
<files >
RepliGoProResource.cod
RepliGoProJava.cod
RepliGoProMisc.cod
RepliGoProEnterprise.cod
</files>
</fileset>
</application>
</loader>

[spiggy]

Hey everyone.

Nice to see I'm not the only one struggling with Bloomberg. Still, wished the thing behaved like all other apps I send.

Some trial and error have helped me figure out how it all works, but time learned me that Bloomberg just change installation procedures (as eekman stated, the new 4, 4.1, 4.xx folders) as they want. It just sucks in a managed environment and there is almost no support whatsoever.

Now my question: Managed to get most of my user's devices to the new version, but I have one user that keeps getting "net.rim.device.api.system.CoverageStatusListe ner" not found while trying to launch the application. Resend of service books don't do anything, my BES tells me the soft is up to date now and all seems fine by my side.

The device is a 8707

u4.10.316 (Platform 3.0.0.4D
Cryptographic Kernel u3.8.3.7
MicroEdition Configuration CLDC-11
MicroEdition Profile.MDP-2.0
MicroEdition JTWI version:1.0
MicroEdition Media Version: 1.1
MicroEdition PIM version: 1.0

Anyone any idea what I can try for getting this Hong Kong user up and running ?

Thx in advance.
Peter

[bscanlon]

In regards to the OSAPI.cod. The .alx file tells the desktop manager, or the OTA push indexing program that a specific module should be isntalled for each OS version, ie 4.1 gets osapi_4_1, 4.2 gets 0SAPI_4_2. This works fine for Desktop manager or standard OTA pushes.
- The problems start if you are using the application policies to white list software installations, ie you disable all applicatinos at the top level, and then specifically allow Bloomberg. The reason for this is an indexing bug with RIM's loader.exe /index progrm. The program generates two XML files, pkgDBcache.xml and specification.pkg. The pkgDBcache.xml contains a hash for each module in the package, and the specification.pkg contains the .cod lcations. The specification.pkg xml file generates correctly, which is why the desktop manger and a simple OTA push work fine. Unfourtunately the pkhDBcache xml file only contains a hash for the OSAPI.cod that exists in the root, and does not generate a hash for the os specific subfolders.
- The result of this is that the BES Policy service will queue up and send down the software to your users devices, once there though, the Application Policy will compare the hash tables and reject the software because it does not match your white list (unless by chance you pushed to a 4.0 device, then it will work fine) As mentioned above the way around this is to only package the 4.0 OSAPI which is forward compatible.