What is the best way to manage packges in large organizations?
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.
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.
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.
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.
@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. ;)