RCA Satellites should be able to be updated from the Console rather than manually.

August 18, 2014 18:17

After manually upgrading a 100 server infrastructure with the 8.10.0003 patch, why isn't there functionality in the RCA console to import a Satellite patch to the Core and execute the stage it to the satellites and remotely install it on the satellites?

You would have to have it done in stages: 1. Import the patch 2. Stage the patch to the satellite 3. Execute the patch. In my mind, the staging should be done in advance of installation and it should be done so in a fashion that it doesn't flood the WAN while it copies to the Satellite. Execution needs to be done separately due to the possible scheduling restrictions imposed by a Change Management system.

Also, patches shouldn't require manual installation for desired components. If I need the 8.10.0003 patch PLUS the OS Management components, I should be able to select this from the console and then have the system update itself when I tell it too.

Supression of Reboots would be a necessary component.

Centralized reporting of success, failure, pending-reboots, etc. would be needed.

It is long past time to giving us this feature for maintaining our RCA infrastructure.

3 comments

Please sign in to leave a comment.

Previous 3 comments

Date Votes

Fazahath Baig

August 19, 2014 09:27

This is a functionality which will definitely make it easier to Manage and Maintain the Radia Client Automation and will automate the upgrade process or the process of applying hotfix.
1.
We can make use of the maintenance package to do this through .xpi and .xpr files. This will allow us to upgrade the satellites same as in case of agent upgrade or when applying the hotfix client machines. Extend the functionality of PRDMAINT to include Satellites, treat them as a client and upgrade and apply hotfixes.

2.
Instead of using RADDBUTIL/ ZEDMAMS to import these .xpi .xpr, make use of a single .msp/msi installer. Which is similar to the one used when applying the Cumulative patch update, this will import and replace all the files on CORE directories as well as on the CSDB.

3.
Cumulative patch release process needs to be streamlined in the same as above. With .msp/msi installer seperate for CORE, and one for OSManager.
The packages related to Usage Manager can all be bundled in the same .msi/.msp installer but selectively applied based on the licensing.

4.
Admin tools patching can follow the same PRDMAINT maintenance package approach and packed in a single installer.

The above process will reduce the repetetive tasks of applying the patches on all satellites manually and will also minimise the human error.
It will automate the process and will be easier to plan and Test new patch deployments in the environment. Installer packaging will also allow for easier rollback in case of issues that arise as part of new patch deployment.

Michael Conwell

August 20, 2014 19:01

The biggest difference here is that PRDMAINT just blasts out and at least for my implementations we would need to be able to schedule servers - sometimes some servers are done on day 1, others on day 2, etc.

But the thought is the same. Centralized automated installations for the CAE infrastructure - rather than downloading MSI/MSP, manually running them, unzipping files in certain directories, replacing single files, etc. then repeating this process manually on each server.