At one of our locations, an upgrade to ePO 5.10 was made by standing up a new server and exporting keys, configurations, tasks, etc to the new system. The new system was registered on the old and systems were transfered.
Unfortunately, in the process a step was missed. The imported agent-server key was not set to master. The agent-server key with the new system was not removed.
To correct this, I am thinking of:
1) Set the imported key, with the majority of systems, to master
2) For all of the Windows systems using the new key, reinstall the agent built after setting the old key to master.
3) For the handful of Linux systems using the new key, either uninstall and reinstall the agent built with the old imported key, or extract the files to allow use of maconfig to reset
Before I go down this path, I wanted to check if there is any other remedy.
thanks
(sorry for the blank post - hit return instead of shift)
Solved! Go to Solution.
No need to reinstall agents at all unless they can't communicate. The imported key is not necessary to be made master, but that is your choice. Don't remove any keys until all agents are reporting to the one you want them to as master.
1) Set the imported key, with the majority of systems, to master - that is fine
2) For all of the Windows systems using the new key, reinstall the agent built after setting the old key to master. - not necessary at all. Check in latest agent key updater package and use update task to have clients update automatically to new key.
3) For the handful of Linux systems using the new key, either uninstall and reinstall the agent built with the old imported key, or extract the files to allow use of maconfig to reset - no need to reinstall, use agent key updater package. That is what it is for, update communication keys.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
What is the exact question or problem? Yes, there are 2 keys - a legacy key as well as 1024 and 2048 bit key when not in fips mode.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Sorry - I fat-fingered and the empty post was put! I was editing while you relied. My apologies
No need to reinstall agents at all unless they can't communicate. The imported key is not necessary to be made master, but that is your choice. Don't remove any keys until all agents are reporting to the one you want them to as master.
1) Set the imported key, with the majority of systems, to master - that is fine
2) For all of the Windows systems using the new key, reinstall the agent built after setting the old key to master. - not necessary at all. Check in latest agent key updater package and use update task to have clients update automatically to new key.
3) For the handful of Linux systems using the new key, either uninstall and reinstall the agent built with the old imported key, or extract the files to allow use of maconfig to reset - no need to reinstall, use agent key updater package. That is what it is for, update communication keys.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Thank you for the procedure. Of the 170 systems on the key we will retire, only 36 remain after the update. We expect we will need to visit those computers to investigate why they are not communicating.
Just a follow up
Consolidation of the keys is working fine. We created an Agent Key Update task as a McAfee Update client task to easily apply to systems. It does not seem to work as well on the RHEL systems since they are not communicating with the ePO. A ./cmdagent -p or ./cmdagent -f will return a 505 on the failing systems.
For those systems we removed ENSL and removed MA followed by a fresh install of the agent package, exported after the master key was set. They are working fine, however, it is tedious to visit each system to do this. We cannot send an EEDK package because the systems are not responding, plus since the Linux agents are at the same version, I do not know how to make the installer re-install the same version.
I did try a maconfig to provision as managed using the 6 files with SiteList.xml and keys, but that did not have the impact I expected. So we resorted to remove and reinstall.
I am curious is there is a better recommendation.
I don't know what agent you are running, but you might try upgrading it instead of removing/reinstall. What was the result of the maconfig command? Do you have the maconfig log?
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Upgrading would be perfect, but we are held to the versions that we get approved through our change process. The team was using 5.6.2. For the Linux systems that would not respond, we removed ENSL manually and removed the agent manually, followed by a install of the new agent install.sh.
Even with a shell script to automate the uninstalls and install, logging into each system, running the process, was tedious. After the agent was communicating, a client task to install ENSL was assigned to the newly communicating systems.
My two wishes are that a mode exists for the Linux install that can install over, or repair, an agent install of the same version; and that the ePO deploy-an-agent would accommodate the "-r" flag for the install script.
That would be good to submit as a per - kb60021
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA