SOTI Pulse Logo

Profile Shows as Installed (but the apk got deleted )

Solved
N
Nikos

Hello , 

I have a question. I am using profiles to install an apk on devices(zebra mc33). I am using  different profiles for the same application depending on the version (i do that because i have to update many devices and not all together). So for example i have a profile named (apkv3) and i want to upgrade on (apkv4)i will make a new profile named apkv4 and assign it to the devices i want to update (the apk wont install because the previous version is still there so i just revoke the profile v3 and force package reinstall v4. (i know its not optimal but it works for now ) . Today i assign the new profile on all devices in preparation for update ,and knowing it will not apply itself if i do not do it manually,  i also had some devices already updated on v4. The apk v4 that was already updated  got deleted while the package was showing as installed this did not happen all the updated devices but in some groups and i cannot see the reason (i had to force package re installation  on an already showing installed profile to fix the issue) Sorry for the wall of text.  

2 years ago
Android
ANSWERS
ZC
Zafer Cigdem
2 years ago

Hi Nikos,

I'm just wondering, do you have any other specific reason to not just update the package under the profile and assign a new version of the profile to the devices (as far as I know this is the best-case scenario)?

if you don't want to upgrade the package version in one shoot, you can divide the folders into some profiles or you can test this out by using some test devices by duplicating the profile first and then after verify it's working well you can deploy it to other devices.

Other than that, regarding your question you can check out below profile settings for your devices that whether to verify when the profile is deleted its apk is uninstalled or not.

I hope this helps.

Zafer 

N
Nikos
2 years ago

i am using this method cause i have the same profile package v3 for example in many different groups that do not update at the same time. When i tried by updating a single profile with the newer version of the apk. It did update in all device groups . I couldn't have a single Profile that some groups have the V3 and some other the v4 it did update all to v4. 

RC
Raymond Chan Diamond Contributor
2 years ago

According to what you described, I am sorry to say that your deployment methodology sounds chaotic.

You still haven't answered Zafer's question about whether the "uninstall options upon profile revocation" has been enabled in all or some of your profiles?   That will affect how things should or can be done.

BTW, do you know what is in-place upgrade?   Are you aware that uninstalling an old version completely and then installing a new version of the same app may result in lost user's application data (e.g. some UI preference, history, shortcut, etc.)?

If you have certain well-defined logic/criteria that CONSISTENTLY & SYSTEMATICALLY segment devices into FIXED DISJOINT groups that are to be upgraded at different times, then the first thing I would recommend you to do for smoother upgrade in the future is to have a separate profile for each such group.   Please be aware that each of this logical group can refer to one or more device-group(s) in MobiControl device group tree hierarchy.

ŁM
Łukasz Marciniak
2 years ago

Hello,

Create 2 new profiles.

V3 - contains ONLY  V3 .apk package

V4 - contains ONLY  V4 .apk package

Create  Main group and assign main profile with your default wifi etc. configuration. Create 2 subgroups (not virtual) inside main. 

Assign v3 and v4 profiles to v3 and v4 subgroups.

    • Main 
      • V3 subgroup
      • V4 subgroup

Device in V3 will obtain 2 profiles. Main and V3 .apk

Device in V4 will obtain 2 profiles. Main and V4 .apk

When you want to change. First move your devices to Main, go for a coffee (uninstall will take about 1-2 minutes), and finally move to V3 or V4.

When you change V3 directly to V4 sometimes device can stuck. The best method is to use intermediate MAIN group :)

RC
Raymond Chan Diamond Contributor
2 years ago

Hi Nikos,

I highly recommend you NOT to follow the approach Łukasz proposed.   It is too simplistic and impractical in most real implementations, in which each device group of the device-group tree hierarchy is usually deployed with different sets of profiles, policies/rules and advanced configurations.  Moving device between different group pairs thus implies change of different polices.  If you adopt Łukasz's approach for the upgrade management of ONE SINGLE managed app, then you have to create two sub-groups under each node of the device group tree to PREVENT erroneous revocation of deployed set of profiles, policies/rules and advanced configurations.  The situation gets even more chaotic if there are more than one app upgrade to manage.  In addition, there can be a lot of work manually selecting the correct devices to move between groups.  Finally, devices can be offline due to poor connection or device powered off.  Monitoring which devices having the app upgraded after moving them can add extra  administrative workload.

MD
Matt Dermody Diamond Contributor
2 years ago

Hi RC,

Do you have a better alternative? I actually use this strategy quite regularly and have had consistent success with it for controlling the roll out of an app upgrade by empowering end customers to migrate devices between folders when they're ready to upgrade. I found myself nodding along reading the proposed structure and process so I was surprised to see you so staunchly opposed to it. I completely agree that the current process OP is using is completely chaotic and not best practice but I find this proposal to otherwise make sense.

RS
Rafael Schäfer
2 years ago

Hmm, doesn't happen so often but in this case i fully agree to Raymond.

Why should moving between different groups makes sense? i mean we are talking about upgrading an app via profile(s), right?

So just add the correct filtering to the profile(s) and all is fine and no need to move devices.
And even then you cando it 2 ways:
1.: 1 Profile for the productivity and a second for testing and if tests are running fine change the package in productive profile from V3 to V4 and apps get updated.
2.: If you need to roll out in batches: 1 profile for productivity with the old version, 1 for testing and after tests are fine this will be added in addition to the 1 productivity profile to upgrade the apps in the steps you want. Both need correct filter criteria. (for example the old one can have a filter in it that it gets unassigned if app version is getting higher than the one included). So, finally again only 1 productivity profile.

For the second method you need to ensure the setting RC and Zafer already asked for.

And i personally prefer (enterprise) app policys if it's only the app to be deployed and no additional config files/scripts or so.

Solution
M
MPMOD@SOTI
2 years ago

Hi Nikos,

Thank you for posting on SOTI Pulse! 

I am glad to see that your issue was resolved. 

Please feel free to reach out to us if you have any further questions in the future.

Kind regards,

Technical Support Specialist | SOTI | +1 905.624.9828 | SOTI.net lDiscussion Forum | Log a Case Online l LinkedIn 

Similar Discussions