Check your OA XPL configuration.... ovconfchg -edit 

Hi Asaf,

  I'm not sure what you are referring:

[sec.core]  = CORE_ID=<correct agent ID>

[sec.core.auth] = MANAGER=<correct manager hostname>

MANAGER_ID=<correct manager ID>

I do not see anything in xpl.nt that would refer to an agent ID, please advise.

[xpl.net]

On number of occasions, we got into trouble due to obsolete entries in mgr.conf on agent. Worths a check.

If are you referring to the Flexible Management configuration, the FQDN is not there.  If not, please provide the command to verify.

Yes flexible Management.  So you are right if its FQDN/coreid is not there then this not the case.

I would run ovconfget and grep for the old server name. It should be somewhere there.

Thanks for that info.

I see when I do an ovconget | grep <BAD HOSTNAME>

I get 

OPC_BACKUP_MGR=<BAD HOSTNAME>

When I do an ovconfchg -edit, I do not see OPC_BACKUP_MGR under [eaagt] section as expected.

What should I do to get rid of the OPC_BACKUP_MGR <BAD HOSTNAME>?

Thanks,

S.

I performed an 

ovconfchg -ns eaagt -set OPC_BACKUP_MGRS <correct FQDN>

stopped the agent 

~ovc -kill

~opcagt -stop

Restarted the agent

~ovc -start

~opcagt -cleanstart

The agent is no longer buffering for  <BAD HOSTNAME>

Thanks for the help!!

For reference,

Configuring the Backup Server - Operations Agent

and clearing the value..

ovconfchg - Operations Agent

Hello,

I'm not 100% sure I understand your questionL

Is there a way to get the agent ID CA_<ID>_4096 with only the hostname?

If you mean something like CA_myservername_4096 rather than CA_fe043c44-9aa1-4bf7-98a1-bde286b8311e_4096 then it's is possible and requires some plannig.  

These certificates are used when agents, SIS or other OBM servers (plus a few other things) connect to OBM.  The idea with these certificates is that they are created and managed by OBM itself.  In most cases, it's not something you need to worry about too much, at least that's the idea.  That's why this certificate step is automated.  It's detailed here: https://docs.microfocus.com/doc/Operations_Bridge_Manager/24.2/CertificatesSectionOverview.  PLease note, these certificates are not to be confused with certificates which are running on the Load Balancer which allows operators to log into the OBM Console.

It works like this - every agent and server is identified using a coreid, which is really just a UUID.  When a agent or server is installed, a coreid is created with a unique reference.  You can see this UUID for the agent by running /opt/OV/bin/ovcoreid. 

You can also see the OBM server's coreid but running the command "ovcoreid -ovrg server".  Historically, other software components shared the same infrastructure that OA12/OBM uses.  You can view the coreid and the certificate name by using "-ovrg" (OpenView Resource Group) with a "server" instance, thus:

# /opt/OV/bin/ovcoreid -ovrg server
92a740ec-25e6-75e5-03ec-aad013c9d86a

# /opt/OV/bin/ovcert -list -ovrg server
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
| 92a740ec-25e6-75e5-03ec-aad013c9d86a (*) |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048 (*) |
+---------------------------------------------------------+

The name of the certificate is the Sunject CN.  In almost every respect, the name of the certificate doesn't really matter as it's only used by OBM, OA12, SiS (...).  In order to define the OBM instance the ovcoreid is used to name the certificate. This is what it looks like, this example, looking at the -ovrg server certificate store:

# /opt/OV/bin/ovcert -certinfo CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048 -ovrg server

Type : X509Certificate
Subject CN : CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048
Subject DN : L: puegcsvm72311.swinfra.net
O: ITOM
OU: OpenView
CN: CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048
Issuer CN : CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048
Issuer DN : L: puegcsvm72311.swinfra.net
O: ITOM
OU: OpenView
CN: CA_92a740ec-25e6-75e5-03ec-aad013c9d86a_2048
Serial no. : 872543A75BA497C1880C5163A632D5F3
CRL Dist Point : puegcsvm72311.swinfra.net/myca.crl
Valid from : 07/29/2024 11:45:13 AM GMT
Valid to : 07/25/2044 11:45:13 AM GMT
Hash (SHA256) : 71:9D:66:D8:0B:0C:95:E4:01:68:45:D0:9D:E2:15:B2:8A:42:B1:B6:F5:7B:31:07:77:BC:B9:3E:6C:E8:52:B6
Key Length : 2048

GIven a choice, I would not change from this certificate because it's really not seen by anybody except OA12 and OBM administrators, however, if you want to change this you can : https://docs.microfocus.com/doc/Operations_Bridge_Manager/2019.11/PN/Using_Third_Party_Certificate_Authority_with_OBM_and_Operations_Agent

Changing the root certificate on the OBM isn't something you can really just do, as this will cause problems over your whole OA12 ecosystem.  If there is a certificate problem, you'll see lots of errors in System.txt. 

I don't think the name of the server within the certificate is going to cause you a problem, therefore I would like to suggest contacting Opentext support who can help you get your issue resolved.