Hi Ken,

 Sounds like there may be some issue with the alert in this instance. If you haven’t one already please open a support case for a more thorough investigation.

Kind regards,

Vance Sicherman

Commvault Support

Ticket 240408-789 created.

Update: This issue has been escalated to the development team.

Hi Ken,

What a bad experience that you had following an upgrade to FR34 ,but thanks for sharing this with the community. Do you already know why you had to restart all clients following the upgrade? Was this after the upgrade of the CommServe backend or after the upgrade of the client agent? 

Onno

Hell Onno,

The upgrade problem that required reboots was centered around the client upgrades. According to the support analyst that handled ticket 240405-412 for this issue, the cause was “a .dll file being held open during the upgrade process” and the solution was to reboot the affected clients. The vast majority of clients (maybe 80%) needed to be rebooted.

Our plan for future Feature Set upgrades is to perform them during change outages just in case there’s a need for a reboot. To be honest, waiting until an outage window is best practice so I share the blame of having to reboot production servers during the week. Since we have a strategy to deal with the need for reboots during future Feature Set updates, my real concern with this post is the alert emails.

Ken

Do you happen to recall which .DLL library file it was? Sounds like something related to a dotNET update or at least something related to the OS or was it an external process that caused the lock on the DLL?

Other recommendation I can give you is to first update supporting management systems or systems in a test environment before moving to production also on client level. We use this as a best practices and it has saved us from running into big problems several times already. 

The analyst I worked with never specified which DLL file was the problem.

Also: We don’t have a test environment for CommVault.

Ken

Ok. That is a pity. I was also not pointing to a specific test environment for Commvault, but was pointing to clients who act as test clients for business application or supporting management systems like patch servers or jump boxes. E.g. something on where you can verify that the installation or update of the client side agent is executed without unexpected side-effects. 

Since the partially upgraded clients wouldn’t back up following the upgrade of the CommServer, I *assumed* that non-upgraded clients would have also failed to back up.  If that’s true then there’d be no advantage to upgrading non-prod clients first.  Perhaps I am mistaken.  I’ll keep your suggestion in mind the next time I do an upgrade.

Ken

I don't understand, but maybe I'm interpreting it incorrectly. You upgraded the backend en started the upgrade on the first batch of clients which in the end failed to backup. You then already know the current state which is not ok, right? So, upgrading the remainders doesn't make sense then if you already know the first batch caused unwanted side-effects rights?

Good morning,

I upgraded the CommVault backend servers and then upgraded all clients simultaneously. Those clients that didn’t fully get upgraded then failed to process backups.  I *assume* that computers running the old client would also fail to back up.

Update: This problem has been resolved.  I am told by the support analyst handling ticket 240408-789 that this is a known issue with 11.34.20. The solution is to upgrade to 11.34.22.

I have put the 11.34.22 patch in and the problem has been resolved.

Ken

Can you only get .22 by starting a case or is it available for download?  I can’t seem to find it and I have the exact same issues you did.  

I used the java client and went into the root of the tree view on the left and did right-click > All Tasks > Add/Remove Software > Download Software. In the screen that appears, I selected Select Release and specified 11.34 Maintenance Release 22. There was no special permissions as far as I know.

Ken

Yeah, I have the job kicked off and running, it is just taking forever.  It has been two hours.  

My upgrade from 11.32 to 11.34 feature update took a long time and multiple clients needed reboots for the upgrade to complete.  The 11.34.20 to 11.34.22 maintenance update ran pretty quickly for me - maybe 20 minutes(?).

Ken