Possible for Session Relevance to Reference Fixlet ID's?

(imported topic written by tscott91)

In order to address updating laptops and PC’s that don’t support WOL after hours, I send out a blank/empty action with a message with something like “Please leave computer powered on and at the CTRL+ALT+DEL screen tonight as updates are ready to be applied.”

Then, in the relevance I put the relevance lanquage of the fixlet I want to apply… IE: I will copy / paste the relevance for XP SP3 and put it into my blank “message” action and it will automatically pop the message up on PC’s that need XP SP3 and let them know to leave their PC’s on… Then I create another action to actually install the patch…

What I was wondering was if there was a way in my “message” fixlet for the relevance to be something as easy as “If applicable FixletID 13501”…

This would be a lot easier then going into each fixlet / patch I want to deploy and copy the relevance out of them…

Hope this makes sense!

Thanks, Tom

(imported comment written by Lee Wei)

Tom,

I just want to make sure you know that when you copy the Relevances a Fixlet, you should right-click and do a “Create Custom Copy”. The Relevance tab allows you to copy the combined Relevance statement, rather than having to piece the fragments together.

Back to your original question, this statement should work:

exists values whose (it = "1004619") of 
headers "X-Fixlet-ID" of relevant fixlets of 
sites whose (name of it = "Enterprise Security")

Note that the Fixlet ID plus the Site will make it unique, so we need to include the Site filter.

Enterprise Security is equivalent to “Patches for Windows (English)”. The other site names should be straight forward.

Lee Wei

(imported comment written by tscott91)

Thanks a lot Lee.

Yea, I did the create custom copy to get the relevance.

Tom

(imported comment written by tscott91)

Ok, so on a PC that I know needs Office 2003 SP3 I put this into the debugger and get false:

q:exists values whose (it = “38117”) of headers “X-Fixlet-ID” of relevant fixlets of sites whose (name of it = “Enterprise Security”)

A: False

I have confirmed that the above fixlet is valid and needed on the PC in question.

Any ideas?

Thanks!

(imported comment written by Lee Wei)

Tom,

This relevance is understood only by the actual BigFix Clients.

The Relevance Debugger is a standalone tool that does not have the information. Hence the incorrect results.

To do an actual test, you can either:

It will send the commands directly to the BigFix Client. However, note that the response time feels slow because the BigFix Client is

designed to evaluate at it’s own pace.

  • Put the relevance in a Retrieved Property or Fixlet and have them evaluate at the Clients.

Lee Wei

(imported comment written by tscott91)

Ok, so I ran the below relevance in the client api tester and it came back true, however, in the actual fixlet it’s showing 0 computers as relevant…

Here it is:

exists values whose (it = “38117”) of headers “X-Fixlet-ID” of relevant fixlets of sites whose (name of it = “Enterprise Security”) OR exists values whose (it = “56201”) of headers “X-Fixlet-ID” of relevant fixlets of sites whose (name of it = “Enterprise Security”) OR exists values whose (it = “29213”) of headers “X-Fixlet-ID” of relevant fixlets of sites whose (name of it = “Enterprise Security”)

(imported comment written by Lee Wei)

We will have to investigate that as Fixlet reporting issues such as:

  • Did we give it enough time for the Client to respond.
  • Is the UDP notification getting through to the Client, potentially blocked by firewalls.
  • Is the Client report posting getting back to the server correctly.

If the BES Client API Tester returns true on the computer, then we would expect the Fixlet to be the same.

(imported comment written by tscott91)

  1. I’ve waited days and not clients are reporting relevant.

  2. Nothing is getting blocked by any firewall as all my other fixlets to all clients are working correctly.

  3. Yes. See below:

    At 12:17:41 -0400 -
    Gather merging new file C:\Program Files\BigFix Enterprise\BES Client__BESData\actionsite\Action 10345.fxf
    At 12:17:41 -0400 - actionsite (http://PATCH-FS.domain.net:52311/cgi-bin/bfgather.exe/actionsite)
    Successful Synchronization with FixSite (version 12982) - 'http://patch-fs.domain.net:52311/cgi-bin/bfenterprise/BESGatherMirror.exe?url=http://PATCH-FS.domain.net:52311/cgi-bin/bfgather.exe/actionsite
    At 12:17:47 -0400 -
    Report posted successfully.

Action 10345 is the action with the relevance… I copied and pasted the exact relevance in the client API tester that I pulled the above log for and it comes back TRUE.

(imported comment written by Lee Wei)

Probably worth a call to tech support to have your systems check out.

(imported comment written by sthull)

Hi Tom,

You’ve run into a limitation of the ‘relevant fixlets’ inspector. It can be used in a property that the client can evaluate, but not in fixlet relevance. Trying to use it in this fashion creates a potential chicken and egg scenario where the client has to be able to say which fixlets are currently relevance, while trying to determine if the current fixlet is relevant. So that’s why it won’t work.

Regards,

Steve

(imported comment written by Lee Wei)

Thanks Steve.

Tom,

Sorry that I should tested this in a Fixlet for you first.

Lee Wei

(imported comment written by tscott91)

No worries.

Thanks fellas.