Unable to Find Site ID for URL

[mbartosh]

I have the following errors in the log file of the top level relays. The error repeats every minute. These errors do not occur in the lower level relays, but only the top level relays. One thing I would like to understand is what file is the relay looking in to find reference to the missing site. There is no reference to the missing sites in the bfemapfile.xml or the gatherstate.xml.

/cgi-bin/bfenterprise/besgathermirror.exe/-siteversion (3876) - Unable to find site id for URL: http://servername:52311/cgi-bin/bfgather.exe/opsite77

[FDA]

The problem seems related to an operator that has been deleted. One of the agent did not receive the action of “revoking the management rights” for the deleted operator. The following link contains a procedure to remove the problematic site reference:

https://www.ibm.com/support/pages/clear-out-obsolete-and-problematic-site-references-which-cause-too-many-sockets-remain-open-timewait-state-relays

(There should be the same article in the HCL support page, but I am unable to find right now. )

[mbartosh]

The problem is that I have 480 lower level relays. I don’t want to do a gather reset on all of them. I have created an analysis that should find all of the lower level relays that need to be reset, but it is not finding any. That is why I ask the question, what is triggering the error messages on the top level relays. There really needs to be a better way to trace this problem.

Here is the analysis to find relays that need to be reset.

if (exists relay service and not exist main gather service) then (if (exist file "c:\program files (x86)\bigfix enterprise\bes relay\logfile.txt_0") then (if (exists lines whose (it contains "Unable to find site id for URL") of file "c:\program files (x86)\bigfix enterprise\bes relay\logfile.txt_0") then ("there’s a client with old masthead under this relay") else ("all client of this relay have current masthead")) else ("logfile.txt_0 Does Not Exist, Adjust value of _BESRelay_HTTPServer_LogFileSizeLimit to be below " & size of file "c:\program files (x86)\bigfix enterprise\bes relay\logfile.txt" as string)) else ("not a relay")

[FDA]

There are some additonal steps (relay settings) that you could take to attempt to automatic recover the missing site gather problem. I suggest you open a ticket to involve the service people to further help here

[mbartosh]

I am being told that the old opsites are in the ActionSite.afxm file on one of the clients. I have added a check for the sha1 of the ActionSite.afxm file to see if it is different on the clients.

if windows of operating system then sha1 of file "ActionSite.afxm" of (parent folder of client) else sha1 of file "/etc/opt/BESClient/actionsite.afxm"

There really should be a built in analysis to find out-of-date actionsite.afxm files. Shouldn’t there?

[mbartosh]

Here is the response I got from L3 Support.

first of all we need to outline that the message “class NotASignedMessage” for few opsites doesn’t prevent the correct working of the BigFix environment.

The standard way to fix this error message is to run the iem command to propagate the operators again.

However, in case the DSA is not configured in the customer environment, starting from 9.5.7 we have an hidden feature that, if enabled, will automatically fix this kind of error message.
The feature exposes the following client setting that, when enabled on the BigFix Server, triggers the unsubscription of the missing opsites:

_BESGather_UnsubscribeSiteOnDBError default 0
1: automatically create the unsubscription action for sites not in DB
0: do nothing

I am going to try the setting on the Bigfix Server.

[mbartosh]

Setting the setting _BESGather_UnsubscribeSiteOnDBError = 1 on the root server did not do any good.

Turning on verbose logging on one of the head relays that was displaying the error “unable to find site id for url” in the relay.txt log revealed the subordinate relay that was forwarding the error. This enabled me to write the following analysis that exposed all of the relays that needed to be reset. Here is how to turn on verbose logging: https://hclpnpsupport.service-now.com/csm/?id=kb_article&sysparm_article=KB0023389

(exists (following texts of lasts "/bfgather.exe/" of preceding texts of firsts "</" of lines of file "c:\program files (x86)\bigfix enterprise\bes relay\Mirror Server\Inbox\bfemapfile.xml") whose (it is contained by set of ("opsite77";"opsite252")))

Then I copied a fixlet from Bigfix me that resets relays. https://bigfix.me/fixlet/details/6256 There were a couple of changes required to the fixlet to get it to run. It was originally written in 2009. This would be a good task to have available in BES Support.

Be aware that when you reset a relay, there is about 1 GB of data copied to the relay. At least that is the case in my environment.

[vovnih]

Can you elaborate on what changes you made to the fixlet?

[mbartosh]

I had to hard code the path to bfsites. It wasn’t correct from the registry location given.

// waithidden cmd.exe /C rmdir "{value "ContentLocation" of key "HKLM\SOFTWARE\BigFix\Enterprise Server\GatherService" of registry}" /S /Q

waithidden cmd.exe /C rmdir "c:\Program Files (x86)\BigFix Enterprise\BES Relay\wwwrootbes\bfmirror\bfsites" /S /Q

[vovnih]

Thank you for your quick response!

[jbruns2017]

Still seeing this in 10.0.6.84. Any new developments?

Would rather not have our besrelay logs filling with this noise.