Update application (ConfigManager)

[it-aperam]

Hello,

When an application (e.g Google Chrome) is updated, it comes with new version and create a NEW application object in ConfigManager.

Is it possible to have an option to have applications "upgradeable" in case of new versions ?

Means i think :

• no version number in application name
• no version in user collection name
• keep file history or clean binaries folder ???? (no idea)
• what about optional reference RZ.........

The idea is to spread new updated on TESTERS, but automatically, without deleting old group and application and else ... Having smooth upgrade process on common applications.

Thanks by advance

[dc911x]

Great idea but wouldn't it be better to create the new application and copy the assignments from the previous version to the new version and remove the assignments from the old version? You could prompt to ask to delete the old version after you copied the assignments but I would rather not delete or overwrite those versions. These changes would require a new permission to read the groups that are tied to the applications. Even more ideal would be that you could add groups from the R4Intune.exe when it detects you're creating a new application, so no need to even login and set the permissions.

edit: mhm no idea how I missed the "ConfigManager" part and though this was intune but I think it would work similarly although I have no ConfigManager experience to really tell.

[it-aperam]

Thanks for answer, but the idea is clearly to have ZERO maintenance and tasks (except validation of update in RuckZuck). For example, with Google Chrome, once package deployed, in only 1 click update will be spread ! No groups or else manipulation...

For little teams (without people dedicated to that) it will be very very great !

Any luck to have this kind of feature ?

[joenevd]

@rzander @it-aperam I think rzander already has a part of the solution. If you make a package for Intune / SCCM that uses rzget to install the application, you would always install the latest version available. You'd only need to create a solution for updating.

For updating, you could add a task schedule to daily check for the update of your application using rzget.

Last part to think about is detection, because if you check on file version, you would break detection after an update.

@rzander what do you think?

[rzander]

If you are using RZGet.exe to update Software with a Scheduled-Task or an SCCM Package, just make sure that the devices will not update all at the same time !!! I have the Situation where "someone" does generate 20k Requests every two hours which cause the backend service to crash...

For ZERO Maintenance, check out https://romawo.com

[joenevd]

If you are using RZGet.exe to update Software with a Scheduled-Task or an SCCM Package, just make sure that the devices will not update all at the same time !!! I have the Situation where "someone" does generate 20k Requests every two hours which cause the backend service to crash...

@rzander We could use our RMM software to send the command to endpoints, that would be better than a scheduled task.

20k requests every 2 hours is heavy. I noticed you get sponsored by IT companies, which assumes your solution is being used professionally. What is your opinion about using your solution like that?

[rzander]

The "public" RuckZuck Service is free to use, but has limited capacity... Creating SCCM/Intune Packages with RuckZuck does not generate load as the content and installation will be handled by SCCM/Intune. If you are using RZGet or if you accessing the API directly, you must be aware that the resources are limited and there is no guarantied service... As a company, you should consider to: a) become a Sponsor , which allows to scale the environment... b) use romawo.com which is the commercial part of ruckzuck but provides a separate infrastructure and optionally a CDN cache for the binaries (downloads will come from a single CDN source and not from the vendors) c) request a dedicated ruckzuck environment..