Keep installed package from uninstalling

Keep installed package from uninstalling

I downloaded soti surf from soti download page and then uploaded to server

added package to profile where it installed on the devices within that profile

 

Can I keep Soti from uninstalling Surf if I move the device to another profile that doesn't have

the surf package added?

 

I guess is what I'm looking for is to have surf installed and make sure it doesn't uninstall because

our users require that surf be installed

 

Note: on version 11 of soti there was a deployment rule with option:  Uninstall contents upon rule

deletion:  I use to set that to No and when I moved the device to another group it didn't uninstall

the package

  • 29 November 2020
  • SOTI surf
  • 14 Answers
  • 0 Upvote
  • 2 Followers
  • 534 Views
    • 14 Answers
    • 0 Upvote
    • 2 Followers

14 Answers

Order By:   Standard | Newest | Votes
Raymond Chan | posted this 01 December 2020

Each device group can have multiple profiles, and each such profile may have different, hopefully non-conflcting, configuration payload(s)/package(s) included.

 

How policies/packages shoud be broken down in one or more profiles depends very much on how the device group hiearchy is architected ,and also on the management use cases and business work-flow.

 

If  you have the same  .pcg package deployed with profile to both the source and destination device-groups of a device to be moved, then the package should not get uninstalled and then subsequently re-installed after the move.

 

 

  • 2
  • 0
larry | posted this 01 December 2020

are you saying I can apply more than one profile to a group?

  • 2
  • 0
Bhav | posted this 30 November 2020

You could just have a profile containing the surf package only. Assign it to the folders that require surf to always be installed. 

If (like me), you require different Surf settings applied to different folders, then just create surf settings profiles and assign accordingly.

  • 1
  • 0
Raymond Chan | posted this 30 November 2020

Yes.

  • 1
  • 0
larry | posted this 30 November 2020

so since I didn't use package builder I don't have this option, maybe I should just build a package with my downloaded file and do it that way if I want this option to not remove if the device is moved to another group.

  • 1
  • 0
Matt Dermody | posted this 30 November 2020

To Raymond's point, there is an option within the Package builder to configure an APK contained within the package to not uninstall upon un-assignment. This could help you solve your specific problem, however I tend to avoid leveraging that particular configuration and to instead get used to the default behavior that SOTI has for Profile Assignment. There is a lot of power in the Assignment principal and the fact that SOTI will automatically remove or undo an operation that was performed when a device is moved from one group to another and the assignments change.

 

Selecting the parameter to leave an APK installed is a relatively hidden configuration that changes that default behavior. I don't think there would be any visual indicator of any kind that the particular package was designed in that way, and there is no evidence left behind that a package was once installed, but the contents were left behind. Therefore, you wouldn't have any console based visibility to which devices have had Surf installed, other than manually keeping track of them yourself through the various folder moves.

 

If Surf is being uninstalled right now because a device is moving between groups or assignments and you instead want it to remain installed then it sounds like you should instead readjust your Profiles and assignments so that does not happen. If you gave us more detail about your group and Profile assignment structure we could probably point you in the right direction. 

  • 1
  • 0
larry | posted this 01 December 2020

I'm thinking maybe I do this:

We have some mc9300 devices which all come with android and will need soti surf

so my group is called mc9300 which I assign the soti install profile

my subgroups might be by department and will have another profile for other settings

when ever anyone moves a device between profiles it will not remove surf

  • 0
  • 0
larry | posted this 30 November 2020

having thought about what you said I do see some advantages in leaving set as default behavior

for example say I want the browser upgraded on these devices, I could move them to a profle

that doesn't have that package applied and it would remove, then I could move to profile that

has the newer version and it would install that

  • 0
  • 0
larry | posted this 30 November 2020

one more quick question

how about if the "package is deleted" will it uninstall on the devices that has it installed

thanks

  • 0
  • 0
larry | posted this 30 November 2020

I just created the package from the downloaded file for practice and saw this option:

"do not uninstall the file when profile is deleted"

 

Is this what you were referring to

 

thanks

  • 0
  • 0
larry | posted this 30 November 2020

along with power comes with making a mistake, say I forgot and deleted the package, then it uninstalls from all my devices that that had it installed resulted in a lot of help desk calls, I'm just trying to put in a safe method where the package stays installed regardless, I can always create a package to uninstall the application if needed

  • 0
  • 0
larry | posted this 30 November 2020

the package shows up as: net.soti.surf

  • 0
  • 0
larry | posted this 30 November 2020

I downloaded soti surf to my drive then uploaded to the soti server.

Surf_15.2.1.6.apk

 

I guess the bad thing about going this route is:

If I accidently delete the package then it uninstalls on all my devices, yikes

or If I move a device to another group that has a profile without this package

it will also remove the package

  • 0
  • 0
Raymond Chan | posted this 30 November 2020

Did you use Package studio to create your .pcg package? Or used the automatic  pcg generation introduced in MobiControl v15.x?

 

  • 0
  • 0

Give us your feedback
Give us your feedback
Feedback