[shaptoni]

I am experiencing issues with managing applications on BES 5.

I am able to create an application control policy and deploy applications but when I come to removing/updating applications, the jobs end up in “Running” state or “optimized out” or “not ready to deliver”

Example:
Deploy Bloomberg v1.10 – successful
Remove Bloomberg v1.10 – “not ready to deliver”
Replace v1.10 with v1.11 – “Running”

I cant see anything wrong with my config and don’t understand why attempting to remove Bloomberg results in “not ready to deliver”
The logs don’t seem to be showing me anything obvious.
Can anyone point me in the right direction here?
Thanks

[Dubdub]

Moved to a more appropriate section

[noname]

If the application needs to be installed as soon as possible, configure the application deployment schedule (before assigning software configuration to the users) by completing the following steps:

1. On the left pane, under Devices, expand Deployment jobs.
2. Click Specify Job Schedule Settings.
3. Click Edit Job Schedule Settings.
4. Set the Default Delay to one minute (this can be left as default).
5. Click Save All.

Note: The Deploy Now option no longer exists for BES 5.0 unlike BES 4.1.

For Job Task status, refer below:-
KB18284-Job Task status descriptions in the BlackBerry Administration Service console

[shaptoni]

Thanks for the response, however, I am not worried about the speed of delivery.

My issue is that I am unable to even remove applications, example:
Task ID Task type Task Task dependency Optimizing task Status
532 Application Removing 531 Not ready to deliver More...

The task is still running now, how is it possible that I was able to add the application but now cannot remove/upgrade it?

Not policy/permission changes have been made
Any more ideas?

Thanks

[shaptoni]

This is a known issue:

See KB23685 "BlackBerry Application Service Jobs and Tasks are not being processed"

However, I needed to create a script to delete JobTasks and JobTaskDependencies

Hopefully v5.0.3 will fix this

[arjey]

Hi Shaptoni,

I was just going a quick Google search - I have ran into the same issue where the remove task will stay on "Not ready to deliver", but when the install of the new version of Bloomberg happens (v11.2) - it will turn to a failure as the it will notice that the BlackBerry device still contains some modules of the old version that are similar, if not the same, on the new version. I am yet to come up with a consistent workaround on the issue. I have tried removing them from the group and waiting it out as the domain policy has "No third party apps" set to enable - so it will send a remove que from there. I have also tried a 3 group process where you have the original group that has the old version of Bloomberg, another group that just has RepliGo and the same policy as the original prod Bloomberg group but has the old version of Bloomberg set to disallow rather than required so it will send a remove command that way and the third group having the new version of Bloomberg installed.

This is a known issue with 5.0.2 MR1 - It states this in the Release Notes. I have been back and forth with RIM T-Support which have been very helpful with trying to find a workaround. This issue has been resolved in 5.0.2 MR3

Shaptoni - Are you able to share the query you ran against the database with me? I'm curious to see what it changes table wise..

I have also found that the error is consistent with 9700 devices, but for the older devices like 8100 pearl's for example running on 4.2.1 firmware it will work fine.

I'm leaning more towards the fact that the device.xml and vendor.xml files need to be updated on the server, but other applications send fine.

[arjey]

Another note - another way to kill pending tasks on a user is to move them to another server.. If anyone else has any other way of performing this - besides running a query against the database, let me know!

I'm yet to find a consistent workaround! It's doing my head in!

[shaptoni]

thanks for your comments arjey, here is the script that I ran:

--------------------------------------------------------------------------
begin tran
declare @jobid int
set @jobid = nnn

delete from [BASJobTaskDependencies] where taskid in (select taskid from dbo.BASJobTasks where jobid = @jobid)
delete from [BASJobTaskDependencies] where dependentontaskid in (select taskid from dbo.BASJobTasks where jobid = @jobid)
delete from [BASJobTaskDependencies] where taskid in (select taskid from BASJobTasks where OptimizedOutByTaskId in (select taskid from dbo.BASJobTasks where jobid = @jobid))
delete from [BASJobTaskDependencies] where dependentontaskid in (select taskid from BASJobTasks where OptimizedOutByTaskId in (select taskid from dbo.BASJobTasks where jobid = @jobid))

delete from BASJobTasks where OptimizedOutByTaskId in (select taskid from dbo.BASJobTasks where jobid = @jobid)
delete from BASJobTasks where jobid = @jobid

delete from dbo.BASJobs where jobid = @jobid
--------------------------------------------------------------------------

only "commit" if it works for you!

[JabbaTH]

Originally Posted by arjey

Another note - another way to kill pending tasks on a user is to move them to another server.. If anyone else has any other way of performing this - besides running a query against the database, let me know!

Incidentally you don't need to have a second server. Select user, select Switch BlackBery user to different server, existing server is only option, select yes to switch user and cause all tasks to fail.

Worked for me!

[arjey]

or you could do that!

I've done even more research and testing on this issue and I can re-produce it quiet easily. What actually happens is that - the application is supposed to set a que to remove itself and then send out/install the new version. But what is happening is the install que will send first and the remove que will go out second thus will cause the job task to fail the install que as there is a version already on the device and because the remove que is a dependent task it will turn back a dependency failure on the job tasks list. then you will re-send the application which will include IT policy and everytime you send it you will see a massive dependency task list for the new task you have just created.. (hope that didn't confuse you too much).

I have a script I'm going to run soon to test that it will remove the dependency que and I can start fresh by using a different method without having to update the applications manually.

[pfowler]

Our application seems to occasionally fall into this same problem of being stuck in the deploy queue. I'll try some of these tricks to see if it can resolve it next time a customer support call comes in.