Fixlet action fails since upgrade to BigFix 8

(imported topic written by SystemAdmin)

We have a fixlet which performed exactly as expected under version 7, but now fails under 8. The piece of the action script is failing:

setting “_BESClient_Comm_CommandPollEnable”="{(if (name of registration server as string contains “xxx.xxx.xxx.xxx”) then (“1”) else (""))}" on “{now}” for client

The xxx.xxx.xxx.xxx is of course the ip address of one of our DMZ relays. Anyone have an idea of why this would start failing after the upgrade?

(imported comment written by BenKus)

Hmm… Not sure… maybe use the Client API Tester to see if you can evaluate the expression and see if it gives an error?

Ben

(imported comment written by SystemAdmin)

It this still the current version of the tester or has an 8.0 version been released / will it make a difference in the result?

http://www.leewei.com/bigfix/prod/clientapi/BigFix_Client_API_Tester_72522.msi

Ignore this - I found the “official” connctor web page @ http://support.bigfix.com/labs/apitester.html. I also read Lee’s updated post on the forum (http://forum.bigfix.com/viewtopic.php?id=2756) which states it works correctly with 8.0

(imported comment written by SystemAdmin)

So running that through the API Tester spits back “Error: This expression contained a character which is not allowed.”

We haven’t changed the fixlet so I am assuming something changed between version 7 and 8 that now prevents this from running.

As for the API Tester, even a textbook example “setting “_BESClient_Comm_CommandPollEnable”=“1” on “{now}” for client” fails with “Error: The operator “on” is not defined.”

(imported comment written by BenKus)

The API Tester only evaluates relevance so you should try only the stuff between the {}

Ben

(imported comment written by SystemAdmin)

Ben, why do I feel like you are leading my down the path of obvious :slight_smile:

So in testing just the relevance between the {} brackets, it all checks out ok. Will support be able to help with this? I believe be got this logic from them when we were setting up the DMZ relays. At this point I am either missing the obvious (as I stated above!) or there is some bug that needs to be killed.

(imported comment written by BenKus)

Maybe look in the client logs to see if it tells you why the action is failing?

Ben

(imported comment written by SystemAdmin)

The action that fails logs this:

At 16:14:46 -0400 - actionsite (http://bigfixserver.domain.local:52311/cgi-bin/bfgather.exe/actionsite)

Command failed (invalid setting value) setting “_BESClient_Comm_CommandPollEnable”="" on “Mon, 27 Sep 2010 16:14:46 -0400” for client (fixlet 4515)

(imported comment written by BenKus)

Ah…

Set it to “0” instead of blank…

I think 8.0 has a more sophisticated error checking to make sure you are using appropriate settings values.

Ben

(imported comment written by SystemAdmin)

I’ll try this tomorrow, if it works, I owe ya. Are there any updated docs on the changes in 8?

(imported comment written by BenKus)

This is a pretty detailed list:

http://support.bigfix.com/bes/changes/fullchangelist-80.txt

Ben

(imported comment written by SystemAdmin)

I guess “Clients now report action failures when attempting to set client settings below or above the min or max values. Prevents an issue where actions would reapply infinitely when an out of range value was specified. (issue #20443)” is probably the entry that pertains. I didn’t realize a missing value was considered below the range. I thought it would be treated as if the setting just did not exist at all. Thanks Again Ben.