Well, in order to effect the changes made to the remote agent, you have too. There is a way to fool the app into thinking it has been restarted via physical server restart, and while I've used it before to buy some time, the servers have ALWAYS been restarted...you will have to find proper downtime to do this in.
That is the recommendation.
You can remove the entry below from the registry (do this on your own!):
Open the registry and search for a key called XXXXX and delete it before starting up the RAWS agent.
Remember, the server needs to be restarted...you need to find the time to do so.
We have tried to reduce reboot requirements in the more recent BE versions , however as well as kernel level drivers (such as Client Side Dedup capability, OFO etc) we can often need to reboot if something like a .net update is needed. As the requirements can vary from individual computer to individual computer this is why we cannot say whether or not a reboot is needed until you try it.
BTW it is not good practice to apply updates without reboots (to any software not just our agents) The reason why you should reboot after making changes is that if something goes wrong where the problem is only seen after a reboot, if you have made a small number of changes (or only 1) it might be easier to troubleshoot or undo the change than if you have 2-3 months worth of changes and then reboot and have a problem.
As such by all means try the info in VJware's link but you should plan a reboot sooner rather than later.
At the moment, Windows Server 2012 R2, with SQL Server 2014 SP2, current agent version 14.1.1786 need update to 14.2.1180. Reboot SQL server can not be in the next 60 days. What to do?
You run the risk of the following:
* Backups completing with exceptions, and these would need to be investigated as it could render all, or some, of your backup set unrestorable;
* Backups succeeding, but with no guarantee they're accurate or if there are problems during the backup;
* Backups that fail <-- and that should be your concern.
I'd recommend making sure your Backup Exec Server has FP2 installed so that when you patch the agent on your SQL server it is the latest patch as otherwise you will have to patch again and a 60 day lead time might prove annoying if you have to apply two sets of patches.
Also you may need to do some education with whoever is setting the lead times for changes (including reboots) as we currently expect to release a set of patches approximately every 3 months which means you can expect to be doing change requests every 3 months to apply the latest updates.
I disagree with the suggestion to remove the reboot keys from the registry. Doing so often will allow services to start with mismatched binaries. That can lead to untested results and unusual crashes! The installer only sets this key when patched files cannot be updated without a server restart. Following this suggestion is highly discouraged! (Steps down from the soapbox)...
This entire thread should be corrected and the details of the reg key be removed. Nick has clearly shared the reasons for which this should not be done and only puts you at risk of a crash, and who knows what will happen from that point.
BnR Product Managment
Skip St. Pierre
Regardless of your nationality, you are always allowed to muck around with your backups. Just be prepared to explain to your boss why there is no backup to restore when it is needed.
I checked everything:
Based on the feedback from Nick Elmer and Skip St Pierre I have censored the exact registry key from this thread.
Please do not repost details of the key