Deploying Rhino v6 and managing its updates

Hi, my company carries a couple hundred Rhino v5/v6 licences which are managed using Zoo

We are about to start planning our deployment of v6 using SCCM, which we also did previously with v5 and its updates and service releases.

Moving forward with v6 we are contemplating allowing the auto upgrade feature in v6, as we have really struggled keeping the 1000+ machines up to date with v5

  • I noted that there is an update frequency option for Service Release and Service Release Candidate. I guess these are ‘production’ and ‘beta’ releases?

  • Are local administrative rights required to download these?

  • If the user downloads the beta and finds there are issues with the build, is there an automated rollback process, or it’s a case of manually uninstalling and reinstalling the previous stable build?

  • In terms of packaging up Rhino v6 and future SR’s. How often are these released, every 2 – 3 months?

  • If we decide to carry on deploying Rhino updates via SCCM, are we able to turn off the update feature meaning our Rhino users cannot manually upgrade to either Service Release or Service Release Candidate

Thanks’ in advance

Richard

Release candidates are available for early testing of the service release. We use the terms WIP (Work-In-Progress) and BETA before we release a new version of Rhino. We strive to make each service release better than the previous one (more stable, with less bugs). But every time a human touches the source code, there’s a chance they’ll introduce a bug. We put out Release Candidate builds so that willing customers can try them and give us feedback. The Release Candidate process lasts about four weeks, and we release new service releases every four weeks.

Admin rights are required to install Rhino.

No, they’ll have to uninstall the release candidate and reinstall from the stable download link on our web site.

Every four weeks.

The best way to do that is to disable the McNeel Update Service after installing on the user’s machine.

thanks, but could you share the registry key that disables autoupdate? as we will be packaging and deploying Rhino using SCCM as the target base will be 1000+

Was this ever answered - as to how to disable the autoupdate feature in Rhino 6 - I have this deployed to a Lab and would prefer it to not prompt users to update. Alternatively is there a way to download and deploy updates?

I’ve been glad about the updates. Thank you.

It would be ever nicer if there were an option to either delete the update after installtion, or copy it into the Downloads folder, as many Rhino users likely have about a gigabyte in their folder:
C:\ProgramData\McNeel\McNeelUpdate\DownloadCache/

As far as I know, there is no reason you can’t delete the downloaded install file from wherever it resides after the installation is complete, or move it to anywhere you wish. As an offline user I manually download the file to an online computer, move it to the offline computer and run it. After a number of WIP, beta, RC or release installs I get the unsightly file buildup you mention and go on a cleaning binge where I get rid of all the older ones. Rhino keeps on running and the computer does too. I usually leave the current one around “just in case”.

I do delete them.

As, I stated, I think it would be elegant–if not handy if the updater either deleted them, or gave the user an option of move them into the Download folder.

From my standpoint: having to manually delete a 252MB file mitigates the value of having an automatic updater, to some extent.