Collector upgrades failing

That is a odd one I haven't seen. The credential field I believe is the encrypted creds/password that the collector uses to communicate with the portal. The creds changes every 24 hours when the collector restarts itself so you don't need to force it. I've had to manually fix it in the past when a collector was rolled back from a DR test or VM snapshot. Was something like that done? You can fix that by copying it from the portal's collector config page to the actual config files on the collector server. But if you are running into that problem, I would expect your collectors to eventually go offline regardless of the upgrade. What version are the collectors now? Are the collectors able to rotate their credentials daily without issue with the current version? Does the cred value in the portal match the creds in the actual collector config files?

7 hours ago, Mike Moniz said:

That is a odd one I haven't seen. The credential field I believe is the encrypted creds/password that the collector uses to communicate with the portal. The creds changes every 24 hours when the collector restarts itself so you don't need to force it. I've had to manually fix it in the past when a collector was rolled back from a DR test or VM snapshot. Was something like that done? You can fix that by copying it from the portal's collector config page to the actual config files on the collector server. But if you are running into that problem, I would expect your collectors to eventually go offline regardless of the upgrade. What version are the collectors now? Are the collectors able to rotate their credentials daily without issue with the current version? Does the cred value in the portal match the creds in the actual collector config files?

 

Hey Mike,

Even post 24 hours still the same issue, these boxes have never had a restore done whats even more strange the collecotr config page for agent.conf is the exact same credentials as whats on the agent it self if I SSH/RDP in and check.

One was 29.003 the other was 30.001

I do understand they go offline briefly during upgrade as they gotta extract data ect 

And you're not doing anything funky by manually touching the config files? You might try using the UI to edit the config file with something innocuous (starting with a #). This will cause the config to be pushed anew to the collector and a process restart. That might flush out any weirdness with the local config file.

On 12/22/2021 at 5:15 AM, Michael Baker said:

Yesterday when attempting to upgrade a Windows collector we hit an issue:

Errors found in agent.conf. Please check the following configurations: file=agent.conf, key=credential, expected=...., actual=....

This morning when attempting to upgrade a Linux collector.. Same issue again

Errors found in agent.conf. Please check the following configurations: file=agent.conf, key=credential, expected=...., actual=...

We opened a support case and the reply was pretty much reinstall the collector this is not a easy solution when we have 74 collectors deployed in several locations that are not always easily accessible and its very time consuming eg 31.002 I done the install (Windows)) it wanted proxy I gave it proxy it refused to accept it so i said configure later.. Then open the configure agent application.. Put proxy in there press save "Cannot decrypt credentials".. Last resort I had to open the agent.conf and manually put the proxy settings in place.

Maybe someone can shed light on a way to force the credentials to update or something?

Merry Xmas to you all btw!

Hi Michael,

I just joined LM COMMUNITY & saw ur post , when collector upgrade fails from LM UI sometime the reason 

Is carbon black security issue , in this case login into windows collector uninstall the LM S/W THEN download the 

Collector file from LM UI and transfer it to collector jost andbinstall it there , if carbon block u here then u hav to 

Mark carbon black policy to Low enforcement the. Only u wil b able to upgrade collector