9.5.5 - Mailbox targetting issues

If I target my DSA server with a blank action (by computername), it doesnt get it. If i target all computers by dynamic property, it processes it immediately.
This is a new built DSA server on the latest 9.5.5 server and revision 196 of the client… All 9.2.5 components previously removed so essentially a brand new installation.
What I have noticed is theres a file located - C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\mailboxsite\__Local called FileLNew with contents -

<HTML><HEAD>
<TITLE> Configuration problem</TITLE>
</HEAD><BODY>
<H1>Error providing site directory.</H1>
The requested Fix site cannot be serviced by this server.<P>
Site not yet available: initiating first gather of site.(19)
</BODY></HTML>

The client log indicates the mailbox is not yet available -

 Site 'mailboxsite' is not yet available on selected relay.  Awaiting notification of availability.
   Successful Synchronization with site 'mailboxsite' (version 0) - 'http://myserver:myport/cgi-bin/bfgather.exe/mailboxsite78132801'

Before I reinstalled all components due to this issue, I reset the gather state which appeared to temporarily fix the issue but it appears to no longer work again.

Is this a bug with 9.5.5 ??

Has the new server completed a replication from the primary DSA yet?

Check for errors in: BES Server\FillDBData\FillDB.log

1 Like

I have never dealt with DSA so I am uncertain in general about this, but I would never let my ignorance get in the way of my providing some answer.

I believe this always happens the very first time a client requests it’s mailbox site from a new relay, which in this case would be the client on the root server talking to the DSA root server itself.

This should indicate that the problem is now fixed, but that doesn’t seem to address your issue.

Version 0 should mean that the mailbox site is empty at this point, and has nothing in it.

This seems like it could be the greater issue.

But this suggests to me that this might be normal and maybe it would work if this part worked.

I wonder if there is some issue with the DSA replication itself. ( RE: @JasonWalker 's comment )

Can you connect the console to this server and target an action to it there? I wonder if that would make a difference.


You may need to file a PMR with IBM for this: How to ask for product help: PMRs, RFEs, and more

@jgstew thanks for your comments.
I have never had an issue like this pre 9.5.5 …
I have subsequently been advised that by design, the DSA server should be configured as active - passive, not active - active meaning the server shouldnt present itself as a root server to other clients whilst the master is up and running. Again, this is news to me.
I will rebuild the DSA server keeping the root service disabled and see whether replication continues to work as expected. This way, I think, the DB will be replicated for failover but the server itself wont allow any clients to connect to it. I’m guessing this has nothing to do with the ‘mailboxing’ issue but if this is best practice for DSA, then it’s worth a go.
We backup SQL on a daily basis on the master, so DSA is not essential for us.
Hope I’m not missing anything here.

You still need to have the RootServer service enabled in order for replication to work, but you should limit clients from selecting the DSA server as a relay either via network firewall or the setting _BESRelay_Selection_AutoSelectableRelay=0. Only top-level relays should be configured manually to try and connect to the DSA server as their secondary or failover relay.

1 Like
_BESRelay_Selection_AutoSelectableRelay
 Default value: 1 (enabled)
 Use: Determines whether a relay is available for auto-selection. **Ignored if set on a BES Server.** Select value 0 to disable.

As the DSA presents itself as a BES Root Server, how do I get this value to work ?

Sorry, couldn’t recall if that one worked on a DSA replica, but if not, use these:

_BESClient_Relay_NameOverride (set to the name of a failover or preferred relay)
_BESRelay_Selection_RelayPriority=1
_BESRelay_Selection_RelayWeight=1

1 Like

Seems like this might be related: 9.5.x DSA ISSUES

Has anyone figured out a resolution for this issue? I am seeing this happen to a couple machines on and off in our test environment.

A couple clients on linux machines are not reporting in regularly. The last check in time does not update and the computer goes to gray in the bigfix client as if it is not checking in. If we do send an action to it it will execute the action, report in. It stops reporting in again after the action is over.

We are running 9.5.5 in a DSA environment. I don’t believe that DSA is the cause because the top level relay servers are communicating to the main server only. Replication is also healthy and I don;t see any errors in the logs.

I also do not really see anything in the client logs either. The onyl thing that sticks out in the client logs is the message “Site ‘mailboxsite’ is not yet available on selected relay. Awaiting notification of availability.”

How often does the client send a report to the server? The client writes a log entry every time it uploads a report.