SOTI Pulse Logo

What is the best way to manage packges in large organizations?

IS
Ian Stuart
Cross Country Couriers

Hello,

Moreso a general management question, curious what others do. We are starting to get from a casual SOTI user to running nearly a thousand devices in the future. We have around 6 or 7 apps we push to devices that regularly require updates. In the past I've been simply using separate kiosk profiles and then a package profile (so 2 per device) with each of our locations having a dedicated package profile. That way, we could test package updates in one location before pushing it out to the rest.

However updating 40 locations individually for packages is a pain. So I was thinking of just having a test package profile, and then a production package profile and applying the test to one to an OU while deassigning the prod profile. But removing profiles, adding new ones and switching it around seems risky.

Other possibility is having a package profile for each of our apps, and setting the packages to never uninstall upon revocation. Then, for testing, I could just deassign it from all locations and assign it to our testing, then switch it back to all location for prod. Devices with the app shouldn't have it removed, but then again I'm not sure I want to test that on a large scale.

TL;DR how do people manage dozens of locations as well as multiple kiosks/packages profiles in SOTI efficiently?

soti management organization
5 years ago
SOTI MobiControl
ANSWERS
SB
Simon Breuer
5 years ago (edited 5 years ago)

You don't need to be worry. The option "do not uninstall packages on revocation" works perfectly for us.

We use a single profile for each set of applications and we duplicated these profiles for each branch of OUs.

When publishing new apps we build a new profile and before assigning it to an OU, we revoke the old profile. The apps remain on the devices and are updated when the new profile is assigned.

Works very well and without any problems.

IS
Ian Stuart
5 years ago

Good to know, thanks! That's an interesting method... so do you just clone each profile and then deploy it with the latest version of your packages? Also I believe you need to have the "do not uninstall on profile revocation" checked in SOTI's package builder in addition to the profile.

RC
Raymond Chan Diamond Contributor
5 years ago

There is no best way for every large organization.  It depends on how the device group hierachy is structured, whether different users/devices need to run same/different versions of the same app, whether profile filter or other advance profile deployment options are used or not, etc.  If properly planned and designed, I personally believe the best approach is one that maximize reuse subject to depliyment flexibility/expandability required.

Duplicating same profile into separate profile for each OU does not encourage re-use and can be a nightmare if there are many apps and many OU.  On the other hand, AE apps that support appconfig compliant app-configuration and need to be dynamically configured for different sets of devices need to be deployed with separate profiles.

Also, what Simon Breuer suggested did not guarantee in-place upgrade of new version of an app and can thus cause loss of application data after upgrade.

IS
Ian Stuart
5 years ago

I know it is dependent on each organization, I just know we need a better way.

Currently I don't use any profile filtering since I haven't found a use for it. Basically, for the majority of our devices, they are all under one main OU and then separated by location. Each location uses all the same apps but we need separate OU's to keep them all organized by physical location.

We develop a few apps in house and deploy them first to a testing OU and then sometimes one live location before pushing out to everyone else. But updating the version of a single package for 40+ profiles (a profile for each location) takes way too long. As Raymond said I need a way to maximize payloads per profile without compromising my ability to deploy tests and updates to existing applications, also without modifying production devices.

SB
Simon Breuer
5 years ago

@Ian: Yes, we are cloning each profile and assign them to the different OUs.

So, if an OU wants to have an update it is easy done, because the other OUs aren't affected.

I don't know, if the option "do not uninstall on profile revocation" must be set in profile AND package. We are doing it both. Just to be safe. ;)

Similar Discussions