[niceonedave]

Hi, I am having problems with OTA deployment of a bespoke application that we have written. I have read loads of threads elsewhere and I have got mixed help, but for my particular case none of it has really helped. So I thought I would explain my exact situation and try and get some help here.

I am running BES version 4.1.5 (Bundle 79) for Microsoft Exchange. The application we have written is split into 5 modules, which we control, and another 4 modules which are 3rd party libraries that we require. So for our modules the version numbers are regularly changing but for the others they are pretty much always going to remain the same.

We have an alx file set up that identifies all of the files required and in fact I am able to create a software configuration and deploy the application with no problems. What I am trying to do however is maintain multiple versions of our application on the BES and be able to select which version I want to deploy to each user. I have tried this a number of ways (as I said I have read lots of other threads with solutions to this problem) but each seems to come with its own problem.

First of all I tried just creating different configurations for each version of the application, but because they each had the same application ID the BES informed me that I couldn't do this.

I read somewhere that the solution was to create a second shared folder (e.g. \Program Files\Common Files\RIM) and add the apploader stuff and the new version of the app to this folder. I could then create a second software configuration that would have the same application ID. The result of this seemed promising to start with. When I changed the config that was assigned to a user the new version was pushed out fine. But afterwards the BES reported that the device state was invalid, which meant I couldn't push anything else until I reactivated the device. I guess this is because the first config was never set to disallowed so the old version wasn't removed and the device essentially reported that it had multiple versions of the same application installed.

The next suggestion I got was to change the application ID for each version, e.g. to include the version number. This meant that each version of the application could be included in a single configuration and I could set one to disallowed and the other to required. Initially this worked and the first version was deployed. But when I switched (i.e. the old version became disallowed and the new version required) the BES reported upgrade required and removed the old version. The device restarts and the old version is gone but the new version is not pushed out. I checked the BES and it still said Upgrade Required. I checked the log files and found:

[40000] (11/12 09:50:27.397):{0xEB8} {abc@abc.com, PIN=1234, UserId=2}SCS::PollDBQueueNewRequests - Queuing POLL_FOR_MISSING_APPS request
[40000] (11/12 09:50:28.241):{0xE9C} RequestHandler::PollForMissingApps: Starting Poll For Missing Apps.
[40304] (11/12 09:50:28.241):{0xE90} WorkerThreadPool:: ThreadProc(): Thread released with empty queue
[40000] (11/12 09:50:28.241):{0xE9C} SCS::RemoveAppDeliveryRequests - No App Delivery Requests purged for User id 2
[30000] (11/12 09:50:28.960):{0xE9C} Discard duplicate module group "name" on device
[30000] (11/12 09:50:28.960):{0xE9C} Discard duplicate module group "name" on device
[40000] (11/12 09:50:29.163):{0xE9C} RequestHandler::PollForMissingApps: Completed Poll For Missing Apps, elapsed time 0.922 seconds.

(You will notice I have removed actual names and email addresses etc for privacy reasons. But one question: where does the name of the module group come from? In my case it is close to the application ID but doesn't include the version number that I added at the end in order to get it to work. Is that information embedded in a COD file or something??)

So it is reporting a duplicate module group on the device? What does this mean? I checked the device properties (as reported on the BES) and it confirms that the modules with the old version numbers are still present on the device. So the application has been removed but not the modules?? I checked the device and the modules are gone, so it is just the BES reporting that they are still there?? I checked the database and it has the modules in questions in the SyncDeviceMgmt table. If I delete these from the DB the BES changes to report Install Required, and low and behold the new version of the app is pushed out.

So at the end of all that, my question is: does anyone have any other suggestions of how to handle upgrading our bespoke application OTA from the BES? Or can anyone point out something I am doing wrong in what I described above that might solve the problems I am having? I guess the question is why does the database maintain that the modules are on the device after they are removed?

Thanks for any help you can provide.

[niceonedave]

Nobody has any ideas?

[niceonedave]

Should I take the lack of replies to this question to mean that nobody knows how to successfully manage multiple versions of the same application on the BES, or is it just that my specific case detailed above has left everybody confised?

[cyclmpc]

While my environment is not as complicated with multiple modules, I have run multiple versions of the same application with my software configurations. I have done this with the RSA app and DTEinHand app. This was in my recent BES 4.1.6 set up. I have recently moved to 5.0.

As you stated, I also created a secondary shared folder. It was the only way to add the same named application to the BES without it telling you it was the same app. In fact, for my own testing purposes and multiple versions on platforms, I created a 3rd shared folder. I did run into your issue where the BES would register a invalid state on a hh. I usually found this to be the case when I would change a configuration and apply a new configuration somewhat immediately. I think this seems to be what you experienced. In order to get around this, I had to do the following, remove the software configuration from the hh. Then delete the application from the hh. Then after a period of time (I started with overnight and worked it down to about 3-4 hours), I would run an "Update Configurations Check Status" on the unit. If the check status came back as "OK", I was good to go. If not, run through the steps again with a blank configuration. After that time period, I was able to reassign the software configuration and push out any of the version to the hh without a problem.

Hope that helps you.

[niceonedave]

Thanks for the response, I will give what you suggested a try. Just one question though: you said you remove the software config from the HH then delete the application. How did you delete it? Was it done one the HH itself or did you use another software configuration with the disposition set to dissallowed?

[cyclmpc]

I removed it from the HH. I found that another software configuration with the disallowed option or another app control policy just added to the mix. I try and keep things simple, since I'm a simple guy.

[niceonedave]

Thanks, that is probably my stumbling block then. I am looking to do it in a way that totally avoids any sort of user interaction, i.e. I can just change the software config for a user and he gets the new version without having to worry about deleting anything first. But I appreciate the comment about giving some time between changes, I normally do things immediately, so maybe I will give that a go. Thanks

[cyclmpc]

Changing the app control policy to disallow should work. It's worked for me in the past, don't get me wrong. I just tried to put as much in my control as possible. Stuff never works as fast as you'd like it, especially during testing. Good luck.

[bulletooth]

Does the control app policy = Disallow remove applications or does it just hide it from view of the user? I'd like to know if it will remove the modules for that applciation that I want to remove.

Thanks