I have seen on several occasions where I kick off a fixlet in a site that has a limited amount of machines in it (by subscription), but when the fixlet gathers the computers it needs to run against, it is adding machines that are NOT in the site. They return back eventually with an (Invalid site context. The Fixlet site may no longer exist.) but it sure makes my heart jump seeing those pop in…
Can anybody explain this to me?
Nobody on this one? Am I the only one experiencing this? Below a screenshot of an action against a site with NO server subscribed…
I believe I have seen this before, but I don’t know that I have recently, and I have no idea why this happens.
It isn’t running on them, which is what should happen, but it is a mystery as why they are showing up at all. It seems that the client is seeing the action and evaluating it, but correctly rejecting it based upon the site subscription.
You might try to “Send Refresh” to any clients doing this to see if that helps in the future. I’d also take a look at the client logs.
What is the version of the client on these systems that are doing this? How are the actions being targeted? What is the major version of your root server? (8 or 9+?)
I’m going to guess that you are targeting the action by a property or automatic group and those clients are included by the targeting relevance but excluded by the site subscription relevance.
I’m on 9.2, all clients are 9 or higher and did send a refresh. The interesting part is that it only happens with certain fixlets/tasks.
I am targeting by a property (Dynamic) but the action is in a site with only workstations as the subscription. The server you see in the list are not even IN the site as subscribers…
But would the property you are targeting by include the servers?
Yes, but they are not in the site… so it should not apply, or show as an target…
It is a target due to the property, but it is “not relevant” due to not being in the site, which is what is meant by “invalid site context”.
The person who takes the action will distribute it to every endpoint that can see their actionsite not just the origin fixlet site so that could be the reason.
So if endpoints A B and C are managed by Op1 and A and B are subscribed to the site where your fixlets are that are showing relevant and Op1 takes the action by a Dynamic target then endpoint C will also see this action and probably give an error that its not subscribed to the site. This should be the “” you get if you hover over that error it should expand.
@Alan, that is what I suspected, but not the desired result though… otherwise, what is the purpose of putting specific actions in specific sites? Also, it doesn’t seem to do it for every action within the site, which is what has me confused. The site membership should be “first” relevance filter to the target and thus the action should be never applicable (visual or not) to the non-members of the site.
Hope I explained it correctly?
I believe what you are explaining is what is happening, it is just happening later on and reporting back that it happened.
That reply goes in my books as one of the best explanations on this site 
It is a signal that is basically telling you that the ONLY reason it did not run on these endpoints is due to the site subscription relevance and that had you copied the action into the Master Action Site, and then TAKEN ACTION with the same targeting criteria, then it would have run on these endpoints, but it is not going to because of the site subscription… but perhaps in another case you wanted/expected it to run on those endpoints and would like to know why it didn’t.
I think this is mostly a case of a poorly written error message.
Tell me which one! I have a never ending quest to fix those things 
So actions go to the “takers” actionsite always. You can’t actually put them in any site. Whatever operator took the action it will either go to the opsite of that operator (actionsite if they are a Master Operator) or the mailbox site if the endpoint can do that.
The action however retains the concept of the effective site its running in. For example if you took an action from a fixlet in BES Support, when the action runs it can access items within the BES Support site (its site context for this action) no matter which actionsite it is running from.
Does that help?
“invalid site context” I believe is the error message that is kicking off this conversation.
It is probably more of a warning than an error, and it sounds more significant than it is.
It would be interesting if the error included a URL to documentation about it.
So basically that’s too technical an error message?
Something like “Origin site not found: action not taken” or something to the effect?
That is much better. Perhaps:
WARNING: Origin site not found: action not taken (invalid site context)
I’m not sure if adding “WARNING” is better or worse… but it would be nice to know that this is not necessarily an error as much as it is an explanation of what happened… the problem is if this same result is returned by a client to an action in the Master ActionSite taken by a Master Operator, then this is not just a warning and is a serious problem, which may not be obvious. It is also a sign of a potential problem if you get this error message from a client while taking an action in your OpSite and you have management rights over the client in question.
Even better is if the error message was clickable in the console and the URL would take you to some sort of IBM document with explanation that references this conversation we are having now.
Also, I think it is not always clear that this error message is coming from the perspective of the BES Client that reported it and not the Console itself. I think it helps a bit to understand that it is the client that has the invalid site context.