mcfadder 09 - Page 8 - Developer IT

Managing BES Software Configurations

- by DaveJohnston

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} {[email protected], 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.

Search Results

Search found 1513 results on 61 pages for 'mcfadder 09'.

Page 8/61 | < Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15 | Next Page >

- by DaveJohnston

- by swati

- by Trip

- by gabboshow

- by yangumi

- by vovaxo

- by user561793

- by Kay Singian

- by buecking

- by shantanu

- by user210335

- by chandan

- by chandan

- by Michal Bozydar Pawlowski

- by zeroconf

- by user2131844

- by forellana

- by Yusuke.Yamamoto

- by ewwhite

- by Shiraz Bhaiji

- by The Colour Of Heartache

- by NuclearDog

- by coneybeare

- by cYrus

- by vrynxzent

< Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15 | Next Page >