Can anyone tell me which BES IT policy option controls the radio being disabled when the device first starts up. I have been given an IT policy which when applied to a user causes the radio on the device to be off by default when it starts up, requiring the user to activate it every time (after entering his password). When the default policy is applied this does not happen, so it is an option in the IT policy that has caused it. Does anyone know which of the options this is?
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.
Can anyone tell me what the difference is between the BES epxress and small business edition is? From what I have read they are both identical in capabilities and also both have a 15 user limit. But the BES express edition is free and comes with 1 user license and SBE costs about £800 but comes with 5 user licenses. Buying a 5 user CAL pack costs about £350 (from what I have seen). So if there is no difference why would anyone buy the SBE when they could get the Express edition free and just add 5 more licenses for about £350?
Is there any fundamental difference between express and SBE?
I am trying to push out an app from the BES to Blackberry Device. I know everything works fine because it has worked previously. I now have an older version of the application and I have created a Software Configuration for it (I have removed the original version of the app and re-indexed). I have also completely wiped the previous (although newer) version of the app from the device. Now when I assign the Software Configuration to the user the Blackberry Manager reports that a downgrade is required, which makes sense since the previously installed version was newer than this one, but since I have completely wiped this version from the device and the BM how does it still know which version was previously installed?
Is the information stored in the database and if so in which table/tables is this information stored?
Does the device maintain some sort of record of which version it previously had installed (I removed the previous version using javaloader if that makes a difference)?
The main reason I am asking this question is because the older version of the app won't push out to the device and I guess it is because it still thinks that I have a newer version installed, so I want to totally wipe all memory of the newer version from both the device and the BES. If I rebuild the app and give it a newer version number the push works fine.
Any suggestions??