Solved

Prevent client from installing updates not working with bSkipUpdate additional setting


Userlevel 1
Badge +6

I’m trying to prevent updates from being installed on a specific client.  It is an older client that needs to stay on v9 because the iDA is no longer supported.

I am following the suggestion posted here:

Is there any way to prevent updates and upgrades from being pushed to a client? | Community (commvault.com)

I created the Additional Setting at the client level to test, and then kicked off an Update Software job.  The job ran and it didn’t seem to honor this setting as it showed “Update In Progress” and eventually failed out due to another issue on the box.

Can we verify that this should work on v11.24.69, and that the key is correct [bSkipUpdate]?  

I also attempted to use the Excluded Machines list from Software Configuration but that didn’t seem to work either (it says on that screen that the list only applies to automatically discovered machines, so I assume this was originally used for install software jobs where there were automatic discovery rules).

Also wondering which log I would see this bSkipUpdate being logged in?  I’m assuming it is on the client side so that it would prevent someone who logged in and ran a service pack interactively.  But even with that additional setting and the hostname listed in the excluded machines, the install updates job still proceeded.  What can we do to blacklist these clients so that update attempts fail?

icon

Best answer by Remi Sprangers 24 November 2022, 16:16

View original

13 replies

Userlevel 6
Badge +15

Hi @RobAbate,
 

My research on this key indicates that it is only applicable in FR25+ environments.

So as you are on FR24, it won’t work. 


For now, if you are using a scheduled job to trigger updates, you can just exclude the clients you do not want updated automatically from it. If you do manual updates and push to ‘all clients’, you’ll have to manually disable the clients you do not want updated unfortunately.

 

Hopefully this helps!


Chris

 

Userlevel 1
Badge +6

That’s unfortunate. We do not schedule any updates.  And the goal here was to block installation of updates, no matter which option was used (interactive install by logging on to the client, manual push from the GUI, etc).  It seems like all of these other options which sound like they should/would work just give us the false impression that it would be blocked.

Looks like I’ll have to continue to research and find a way to screw up some registry key so that updates won’t apply.

We were hoping that this key would also work on v9, since the goal is to make sure that these v9 clients are NOT updated.  I’m not sure if they key that supposedly works on SP25 would do anything with our scenario where the clients are on v9.

Any other ideas??

Userlevel 7
Badge +23

@RobAbate , I would suggest openi9ng a support case to see if a) they can backport the fix or b) find another solution.

Once you do, share the case number here so I can track it.

Thanks!

Userlevel 1
Badge +6

I was posting here to avoid opening a ticket, since I know that they’re not going to put out a v9 fix to prevent that v9 client from getting updated.  Was hoping someone knew of a method that actually worked, as the Exclude List seems to only apply to auto-discovery for client installs and this key supposedly needs SP25, which sort of defeats the purpose of the key if I need to update in order to prevent updates…

Anyone have any ideas on something I could do so that any future updates would break and not be able to be installed?  I’m going to have to play in the lab and see what I can come up with.

Userlevel 6
Badge +15

Hi @RobAbate,


Apologies, I should have been clearer. I believe this key will work if your Commserve is on FR25+. Clients can remain on their older (current) versions. 

When you said you tried the key already and it skipped, you added this thru the JAVA Console for the V9 client correct? This is by right clicking Client > Properties > Advanced > Additional settings? 

I’m keen to confirm if the key was actually applied and appeared in the registry on the V9 client (location here: HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\UpdateFlags). I only ask because for V9, we didn’t have ‘additional settings’ tab, it was called ‘registry keys’.. so I want to confirm if the key was actually deployed and there isn’t anything funky going on. 


If the key is there, then when time permits, all you need to do is update the Commserve to a SP25+ feature release (ideally FR28) and then the key should work. 


Thanks,

Chris 

 

Userlevel 1
Badge +6

I wouldn’t dare to try the key on a v9 client!  I had tried it on a v11.24.69 client and it didn’t work.  I would not risk messing up a v9 client until I was confident that this worked.

And like I said, I wanted a solution where it didn’t matter whether the user installed the service pack via Java GUI, or interactively by logging on to the client.

My fear would be they see that pushing out from the GUI and it failed, so then they would try to log in and run it with bootstrapper.  So I wanted a solution that would block any/all install attempts on the client, no matter which method was used.

Userlevel 1
Badge +5

Hi @RobAbate,

Only way I can think of is following.

Go to Control Panel - Add/Remove Software and on the second Tab “Remote Software Cache” add a dummy client and deselect “Enable Remote Software Cache”. So, this dummy client doesn't have a valid software cache

Create a new client group and associate all clients that you want to prevent for update. This so you know which clients won't get updated.

On these clients go to the Version Tab of the Client Properties and under “Update Information” select the dummy client as Cache Source.

Unfortunate I'm not able to test, but I think this should work as the software cache doesn't exist the update should fail.

Hope it helps.

Kind regards,

Remi  

Userlevel 1
Badge +6

Thanks Remi!
I’ll have to give this a try.

I just hope that the software isn’t going to try to be smarter than me and realize that the cache is empty and kick off a download job automatically.  If it does, I’ll just delete setup.exe or some other files from the cache and see if it gives an error like we expect when we run the install updates job.

Userlevel 1
Badge +5

Hi @RobAbate,

 

I was able to check following.

I use an existing client (else you can't select it for remote software cache) and left out the “enable” option.

 

When I now perform a “Download and Sync Cache” or a “Copy Software”, just check the options tab that this client is not selected. It should not be visible as the cache is not enabled.

 

 

 

Here I enabled the software cache on that client and when now performing a Copy Software operation the client is visible.

 

 

Hope it helps.

Kind regards,

Remi

Userlevel 1
Badge +6

Sounds good!  Thank you for testing this out, Remi!  I appreciate it.

Userlevel 1
Badge +6

I pushed out some updates on an environment yesterday and noticed a new JPR for some of the clients which I have never seen before.


It said “client is configured to skip the upgrade”

 

Except we tried so many things that I’m not sure which one actually worked to make these clients skip upgrade.

 

Does anyone know how this undocumented feature works?  I tried in the lab to put the machines under Excluded Machines in Add/Remove Software Config - but that did not produce this JPR.

 

 

Badge +2

Hi, 

I reopen this topic because we just migrated from Commvault 11.25 to 11.32 and since the server migration, i see a lot of updates of multiple client (laptop), is there a way to disable this automatic updates ? 

Can we still use bskipupdates flags ? and can we put this additionnal settings on root level ? 

 

Thanks

Userlevel 6
Badge +17


Go under Manage | System | Maintenance | Upgrade Software Schedules and make sure any System Created Upgrade schedules have been disabled.  I would not expect an upgrade to have activated them, but worth making sure they’re disabled.

Thanks,
Scott
 

Reply