Relevance returning undisplayable result when evaluating reg subkey

(imported topic written by murtasma91)

I’m trying to create a custom client property that will be used to determine the support level for a workstation. What we want is a task that has 3 actions that sets the custom property to a certian value depending on the action selected. From these 3 actions will will create a standing offer so users can select what support level they want their workstation to be placed in.

This all works correctly but once a setting has been chosen for the custom setting we want all three of the tasks to show up as not relevant. If a user wishes to change their support level in the future they will need to contact the support staff so they can remove the custom property from the client workstation thus making the 3 standing offers relevant again.

We thought it would be as simple as editing the computer settings, selecting the custom setting and pressing the delete button. This however doesn’t work as inteded because the delete button only removes the “value” subkey but leaves the effective date subkey behind (I’m sure this is by deisgn).

The other 2 actions still show up as relevant after a user selects a support level so in order to change this behavior I am working on creating some custom relevance for the tasks that actually look for the precesne of the “value” subkey instead of the following relevance

not exists setting 
"_Support_Level" of client

(This expression returns false even if you use the delete button under computer settings since it leaves behind the effective date subkey under the Client settings section in the portion of the registry that contains BigFix client information)

I am testing on Windows 7 64 bit

The following expression works as intended

not exists value 
"value" of key 
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry

however the following expression retruns results incorrectly

not exists value 
"value" of key 
"HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry

I need to evaluate both of these keys since the BigFix client stores information in the registry at a different location if it’s a 32 or 64 bit OS.

The syntax for both of these expressions are the same, the 64 bit path works as inteded but when I manually create these Keys and Subkeys in my registry hive for where the 32 bit version would be stored I keep getting incorrect values. When I view the graphical breakdown of the following expression on a 64 bit OS

not exists value 
"value" of key 
"HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry

I get a undisplayable result message under the “value” and “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client_Support_Level” portions of the expression

Why is this happening? This is just a simple query to test for the existances of a key.

UPDATE: Just tested the following code on a Win 7 32 bit machine

not exists value 
"value" of key 
"HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry

On a 32 bit Win 7 machine this returned the correct value. Looks like there may be a bug in the BigFix client when evaluating keys under the Software\BigFix key on a 64 bit os.

(imported comment written by MattBoyd)

I don’t think looking in the registry is the right way to go. Does this return false?

not exists values of settings “_Support_Level” of client

(imported comment written by murtasma91)

After some further relevance tweaking I’ve come up with some code that seems to evaluate properly.

if (if (name of operating system as lowercase contains "win") then (x64 of operating system) else (Architecture of Operating System contains "64")) then not exists value "value" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry else not exists value "value" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\_Support_Level" of registry

I’m still very interested in why the relevance debugger seems to have issues evaulating keys under the Software\BigFix key on a 64 bit os.

(imported comment written by murtasma91)

boyd

I don’t think looking in the registry is the right way to go. Does this return false?

not exists values of settings “_Support_Level” of client

Unfortantly that’s what I tried using first but if you define the custom setting _Support_Level and later edit the computer settings and delete this value the above relevance returns back incorrectly. I think what’s happening is the bigifx client is looking for the exsitance of the key Software\BigFix\EnterpriseClient\Settings\Client_Support_Level instead of Software\BigFix\EnterpriseClient\Settings\Client_Support_Level\value.

When you use the delete button it only removes the value key but leaves the _Support_Level key behind.

(imported comment written by MattBoyd)

Hey murtasma,

Are you sure you tried it with +not exists

values of settings

“_Support_Level” of client + and not +not exists

(imported comment written by murtasma91)

That’s the relevance I was using. If you look at the two attached screenshots you should notice the problem.

Snap 4

This is what the registry looks like after you delete the BigFix client setting _Support_Level. Notice the effective date subkey is still present but the value subkey is gone.

Snap 5 is the results of the expression

Notice how it evaulates to false when it should really be true since there is actually no value set for the custom property _Support_Level

(imported comment written by MattBoyd)

Hey murtasma,

I’m not sure why you’re having problems on a Win7 64-bit machine with this relevance. With WoW 64-bit redirection in Windows, there are some registry keys that are virtualized. When 32-bit processes query values under “HKLM\Software” they are redirected to “HKLM\Software\Wow3264Node” instead. Therefore, this relevance should work on both 32-bit and 64-bit systems:

not exists values “value” of keys “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client_Support_Level” of registry

I tested it on my 64-bit Win7 workstation and it worked fine.

What’s also interesting is that

not exists values of settings “_Support_Level”

isn’t working for you. This is definitely working for me. I tested it on one of the BES settings (again, on a 64-bit Win7 workstation) and it returned true after I used the “Edit Computer Settings” dialog to delete the setting. The timestamp value for that setting is still in the registry, just as you indicated.

What version of the BES client are you running? 8.0?

(imported comment written by SystemAdmin)

As Boyd said, its best to avoid referencing the registry directly for client settings (the idea behind them is that they abstract away the specifics of how they are stored).

The odd thing is, the expression

not exists values of settings "_Support_Level" of client

should totally work (and infact is how do handle this in our applications). Just to make sure i wasnt going mad i confirmed this on my own deployment.

I suspect we are overlooking something simple (though your screen shots look straight forward enough). Are you sure your registry view is refreshed (maybe some stray action set the value when you weren’t looking), you have the right computer, right version of QNA, all that good stuff?

-Zak