Missing 'mailboxsite'

Site ‘mailboxsite’ is not yet available on selected relay. Awaiting notification of availability.

We deployed an action, by selecting targeted machines. All but two of the systems are reporting a Status for the action. While investigating one of the machines still showing , I noticed the entry quoted above in the client logs when I sent a Force Refresh command to the Endpoint. This seems to imply to me that the Relay doesn’t have the “Mailbox” content for this machine. The content is in a Custom Site. When I search the log files on the client (grep.exe) looking for the Action ID, I find a “DownloadPing command received (ID=242091)” but there is no other evidence that it has evaluated anything to do with the Action.

Any suggestions on next steps?

Did your client receive the force refresh and did you try restarting the relay if there is one?

I’d also try restarting the clients.

When I sent the Force Refresh command it received it. I could see it in the logs, that’s when I noticed the error.

I just tried to send a “Force Relay autoselect” action to the machine, and it reflected the GatherActionMV command, but indicated “GatherHashMV command received. No matching site”, again, this was a targeted action. I’ll try it with a modified relevance of (Computer Name = “blahblah”) targeting All Computers to avoid the Client Mailbox issue to see if it will correctly register with another Relay.

Targeting “All Computers” but adding a (Computer Name as string as lowercase = “blahblah”) to the Relevance clause for the action allowed me to force the Relay selection process. Let’s see if that causes the client to properly register with the Relay and for the Mailbox site to be created.

No luck. I sent another Refresh command to the machine and it still can’t seem to find it’s Mailbox site.

1 Like

Is this a new client?, or is this a client that definitely was working previously, but is not now? (if so has it been upgraded to a new BES Client version recently?)

We have seen this issue. The time I can remember this happening was on Macs and only for new clients. The client’s mailbox would never be created, so it would never work. Completely removing the client and reinstalling it fixed the issue, so it seemed as though the problem was with the client telling the system to create it’s mailbox in the first place was the problem. (if I remember correctly)

1 Like

This is a Windows 7 machine running the 9.0.649.0 client.

The group that supports the workstation has indicated that they already removed the BES Client and re-installed it, but they apparently didn’t remove the ‘detritus’ so I’ll have they try it again, but suggest that they make sure that they delete the Registry Keys and the BES Client folder before re-installing the client.

I guess there is also this: https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Endpoint%20Manager/page/TEM%20Remove%20Utility

Yeah. I created an Analysis to locate the impacted machines, and had the Support team for those machines use the Removal Tool. Problem solved.

1 Like

The message indicated is due to one of two reasons…

  1. this endpoint has never had a mailbox action taken on it
  2. the endpoint changed relays and the new relay needs to get the mailboxsite for this specific endpoint and notify the client that it got it.

It seems that the Computer never generated its mailbox. When I examined the system, it still listed its mailbox as “0” rather than the Computer ID. I wrote an Analysis to find any others like this.

2 systems showed a mailbox number of “0”. Using the Remover tool and reinstalling the client resolved the issue on the first machine, we’ll see about the other in the morning.

1 Like

Can you share the analysis/relevance here or at http://bigfix.me/ ?

It definitely sounds like Tim is experiencing the same issue I experienced a while ago. It seemed that the mailbox site was never created even though there were actions targeting the client specifically that should have used its mailbox, and these actions would never work.

I think we also found that the client could be stopped, a file or so deleted, then restarted, which also solved the problem. I can’t remember the details offhand.

If it comes back to you, in a flash of insight, please let me know. If so, I imagine a Task could be written to detect the issue and perform the remediation auto-magically.

I wonder if your resolution had anything to do with the SiteData file that lives in the mailboxsite? Or did it involve deleting the mailboxsite folder itself?

...\BES Client\__BESData\mailboxsite\__Local\SiteData
1 Like

I’d be a little nervous about a task that would do this as an open action, but yes I imagine one could be created for easier remediation.

I think where we had the issue, the mailbox site didn’t exist on the client either, so it wouldn’t be there to delete. (not positive)

Part of my issue is that I am not aware of any machines that have this issue currently, and the main problems were being reported on machines that I don’t have access to. Luckily there was one nearby we were able to investigate, but it has been resolved for quite a while now, so I’m not sure my co-workers would remember either.

That could be possible. The mailbox is matched to the computer ID. The message will always pop up the first time a client talks to a new relay as that relay hasn’t fetched the mailbox yet (but will and then notify the client if there is any mailbox to fetch)

So if no mailbox actions have been taken against the specific computer ID, there is no mailbox to fetch.

jgstew: I believe the issue you had was addressed in 9.2.1 but not sure if any other patches got help in that area.

1 Like