[ctpuk]

Hi.

I have a "required" app that's deployed to about 200 users. I need to remove it from all of them with a staged approach (say 30 handhelds at a time) and then install a new version. I have to do it this way - they can't co-exist on the same handset and there's no upgrade as such.

Unfortunately, I'm struggling. Removing the user from the SW conf (SW conf is group assigned and users dropped into groups) doesn't remove it from a handheld.

So I wondered if there was a way for me to assign a different software configuration to the 30 users at a time which will disallow, and thus uninstall, the app. I can't find a way to do this and there will be big trouble if I cause disruption to the users and handhelds who rely on this app.

Am I missing something dead obvious here?

Thanks in advance,

Chris.

[MisterGriffiths]

Have you tried first changing the disposition of the software config from Required to Optional.

Are you permitted to ask your users to then delete the app themselves or does this have to be done without their interaction?

[ctpuk]

@MisterGriffiths - thanks for your reply. Most appreciated. Unfortunately, asking the users to uninstall themselves isn't an option. However, I've finally got this sorted now!

Steps taken: -

3 groups in place with the following purposes (with appropriate s/w configs and policies applied to each)...
1 - original version of software REQUIRED
2 - original version of software DISALLOWED
3 - new version of software REQUIRED

All these apps need to have custom Application Control Policies. The thing I couldn't figure out was how to give myself the option to disallow the original app. I eventually realised I could add a custom disallowed ACP to the application under Manage Applications, so I did that.

I then reviewed Software configurations, configuring the 3 as per the groups above.

The situation is that I can now do a staged deployment of the new version and keep track of where the users are up to in the whole original / uninstall / new version process.

I'll grab 30 users from group 1 and put them into the uninstall group (group 2). I'll leave them there for an hour or so then review each user's deployment tasks. Once uninstall shows as complete, I'll move the users into the new app group (group 3) to have the new version deployed.

One thing I learned along the way... I didn't fully appreciate the whole "unlisted applications" thing. So when creating a test software config I, at one stage, set "disposition for unlisted applications" to "disallowed". This forcibly removed every 3rd party app from my device other than those explicitly defined in that s/w configuration (thankfully I only tested on mine!), including 3rd party apps that are on the device as standard (e.g. yahoo chat, google talk, twitter, facebook, bb app world, etc). This is probably just my naivety and lack of experience on display to be honest so I expect most of you are probably thinking "duurrrrr... of course it'd do that"... but just in case you're on the same page as me... learn from my mistake!

Thanks,

Chris.

[MisterGriffiths]

Chris, I don't think you need to worry about any duuurrrr'ing from us. We've all had those moments with BES I am sure.

I've been in the somewhat fortunate position of never having to replace an app on a device but when I undoubtedly do in the future, I will be checking back at this thread to note what you did.

[Boo-meringue]

Originally Posted by ctpuk

@MisterGriffiths - thanks for your reply. Most
One thing I learned along the way... I didn't fully appreciate the whole "unlisted applications" thing. So when creating a test software config I, at one stage, set "disposition for unlisted applications" to "disallowed". This forcibly removed every 3rd party app from my device other than those explicitly defined in that s/w configuration (thankfully I only tested on mine!), including 3rd party apps that are on the device as standard (e.g. yahoo chat, google talk, twitter, facebook, bb app world, etc). This is probably just my naivety and lack of experience on display to be honest so I expect most of you are probably thinking "duurrrrr... of course it'd do that"... but just in case you're on the same page as me... learn from my mistake!

The exact same thing has happened to me, except I didn't have the sense to do it on a test handset first. That was fun!

What I do with our apps is ensure that all of their software configs are set to OPTIONAL, rather than REQUIRED. Optional rolls out the app in the exact same way, but allows the apps to be removed in a more straightforward fashion.

Don't know if this applies to your situation (you mention you have custom ACPs, how many different layers of control is it possible to implement, RIM?!), but I've found it saves a lot of grief.

[ctpuk]

@MisterGriffiths - thanks for the solidarity! I still hold firm in the opinion that BAS is a step backwards from the MMC approach of BES 4.x. It's way too convoluted for my liking.

@Boo-meringue - I agree in principle. Unfortunately, this app is required for audit purposes - we can't give users the ability to remove it.

[MisterGriffiths]

Originally Posted by ctpuk

@MisterGriffiths - thanks for the solidarity! I still hold firm in the opinion that BAS is a step backwards from the MMC approach of BES 4.x. It's way too convoluted for my liking.

@Boo-meringue - I agree in principle. Unfortunately, this app is required for audit purposes - we can't give users the ability to remove it.

For me the BAS is a breakthrough. We have separate Admin people across the globe who all require access to BES and having to set them up with an MMC was a right royal pain in the rear. I do agree though the BAS needs improving. Good first stab by RIM though.

[freakinvibe]

This forcibly removed every 3rd party app from my device other than those explicitly defined in that s/w configuration (thankfully I only tested on mine!), including 3rd party apps that are on the device as standard (e.g. yahoo chat, google talk, twitter, facebook, bb app world, etc).

This used to be a problem, but I think it was solved with the latest BES version & policy update:

http://www.blackberryforums.com/bes-...ia-os-6-a.html

[ctpuk]

Originally Posted by freakinvibe

This used to be a problem, but I think it was solved with the latest BES version & policy update:

I think it's by design, to be honest. My mistake by opting for unlisted apps to be disallowed for that software config.

[ctpuk]

Another question about assigning software configs...

If I remove an app (through the disallow method) can I add the user to a new software configuration before they complete handheld restart (i.e. as soon as I can see that the removal has been successful from the tasks)?

What I'm asking really is will there be an attempt to install the app regardless of restart status or will that be halted until the restart for the previous removal has been completed?

FYI - the app I'm removing always prompts for a restart.