<not relevant> - but it is the second time

[gdeschodt]

Just wondering what may cause this…
We have a simple relevance statement checking citrix receiver’s version < x (“as version” on both sides of the comparison), and checking OS type and the presence of a cookie… Nothing special, been done a million times before. The job has sat a long time looking for targets so presumably all listed are relevant.

It works first time on about 95% of the targets, and 5% report “non relevant”. Sure the job is time limited to 4 hours overnight, but I don’t think that’s the issue.

I remoted onto those PCs at random, ran the relevance in QNA locally and it was True. I repushed to them with and without relevance as a test, in all cases it worked perfectly fine… The same fixlet that was not relevant yesterday worked fine today.

What would cause relevance to return an incorrect “not relevant” response at one time and not the next day ? All subsequent repushes have worked (with the same relevance). Network latency ? Could it be something funky as the time for the push had expired when the PC was getting looked at ? (doesn’t seem right to me, I’d expect not reported - but there are no time stamps on not relevant responses) Can the inspectors sort of give up mid process? I’m really curious here (especially as my ex-SCCM colleague is using any excuse to badmouth bigfix)

[JasonWalker]

There are a lot of potential causes for that, but I think we’d really need to see the relevance that you’re using to really speculate on it.
I’d first suspect anything that relies on a user context possibly reporting Not Relevant when there is no user logged in on the endpoint.

[JasonWalker]

I don’t think it would be based on your action time constraints - if that was the case we’e expect either an “Expired” result or no result at all. “Expired” is a valid response if the action was evaluated after the time expired (in the local client time zone) and before the action expires on the server (action stays open at the server until that “local time” passes for the latest time zone on Earth, which I think is either UTC+1400 or UTC+1430)

[ageorgiev]

If someone in our environment reports this same problem, first thing I would ask is “are you targeting machines across multiple timezones and have you accounted for the End Times in all timezones?”. If you submit an action that has End Time that is already in the passed on some machines it will automatically mark the action as “Not Relevant” on those while it will execute fine on machines in all other timezones…Eventually, once the action is expired on all machines it will turn to Expired but while it is active against any of the machines it will show “Not Relevant” to all that it is passed it…

[gdeschodt]

I appreciate the prompt replies… there’s nothing user context specific or time zone specific - those are medical machines that are always ON and always logged on with a shadow account (and a user account on top of that for SSO but we aren’t targeting user stuff here). There is an end time for the action but I would expect “expired” instead of “not relevant” as Jason indicated.

Not my relevance - I just added “as version” at some point to be sure :

(((exists file “C:\Program Files (x86)\Citrix\ICA Client\Receiver\receiver.exe”) and (version of file “C:\Program Files (x86)\Citrix\ICA Client\Receiver\receiver.exe” as version < “19.12.7000.8” as version)) AND (not exists file “C:\Windows\ITFS\Installer\Citrix_CU7\Citrix_Success.txt”)) AND (not exists file “C:\Windows\ITFS\Installer\Citrix_CU7\Citrix_CU7.txt”)

Again super basic and it works 100% …in the end ! but only 90-95% initially and a redo of 5-10% that come back “not relevant” - which are all relevant when I remote in person dropping that string in QNA locally or when the push is attempted a second time…Worse, my colleague is reattempting a second identical push later in the night and those PCs that were not relevant the first time still come back “not relevant”, so twice in 2 hours. I do it the next morning when he complains to me, zero issues.

Nothing special above, I believe the 2 cookies are getting written post install by whoever built this, for tracking purposes I imagine (and they are indeed not there)- I verified the relevance works (if not the most elegant, as it’s not using “Whose / version of it”, but still it returns true and I did not think messing with that would matter since QNA doesn’t care - maybe I’m wrong?). Thanks guys !

[AlanM]

The natural comparators are present for comparing a version and a string so you do not need the “as version” - see https://developer.bigfix.com/relevance/reference/version.html#version-less-string-boolean
One thing thats much easier to do would be the following to combine the first parts of your expression.

exists file “C:\Program Files (x86)\Citrix\ICA Client\Receiver\receiver.exe” whose (version of it <  “19.12.7000.8”) AND (not exists file “C:\Windows\ITFS\Installer\Citrix_CU7\Citrix_Success.txt”)) AND (not exists file “C:\Windows\ITFS\Installer\Citrix_CU7\Citrix_CU7.txt”)

Are there other relevance items that could be making your action non relevant like an installer running? So there are 3 conditions here, only one is a version check, the other two are file existence so are you sure of the element that is failing?

[gdeschodt]

Thank Alan,
Yeah I knew someone was gonna say it’d be prettier with “exists file whose version < blah” (not my fixlet, LOL)… But realistically, this should not make any difference, and again, it works on 95% round 1 and 100% round 2. There’s ZERO else in the relevance, the cookies are indeed not there because the fixlet never ran and they are created last - and when you go onto the PC locally and QNA the relevance locally, it reports true, so the relevance is fine but it not reporting correctly to the console right away… It’s like a temp glitch in interpretation, and it resolves itself on subsequent pushes (though after several hours only).

In truth (related or not?), this week I’ve also seen this very same push - when scheduled for later - immediately report 300/500 PCs “not relevant”, and slowly, over the space of an hour, change that status to “waiting” (correctly). So it seems to me we have a hangup on relevance inspectors reporting up the chain, somewhere…

Meanwhile I’ll prettify with a whose/it if the owner lets me… just in case. but it doesn’t make sense to me.

[vk.khurava]

I am assuming your relevance is always TRUE then these could be the possibilities -

1. Action Schedule timing vs target device current timing.
2. Client slow to evaluate or busy
3. Default _BESClient_Resource_SleepNormal & _BESClient_Resource_WorkNormal not sufficient for the client to process the content
4. MO actions are getting priority over normal operator action

And for detailed investigation, I would suggest open a case with product support.