Windows 7 BES Clients missing from BES Console

(imported topic written by SSW_Computing91)

We’ve been testing BigFix in our computer lab and ran into a problem with one specific setup. We have three ways of adding computers to groups: if they are part of an Active Directory OU, if they have an IP address from a static range, or if we manually install the client and set a registry value to set the group. The first two groups work fine, but Windows 7 computers that are not on a domain, have no static IP, and are using the registry fix method do not show up on the BES Console in any group. The registry fix method works fine with Windows XP machines in the same environment, and BES Clients on Windows 7 computers report just fine as long as the computers are either on the domain or have a static IP from our range. We have checked the logs and it seems that all the clients (including the one on the Windows 7 computer) connect to the BigFix Server, but the client on the Windows 7 computer does not recognize any user as an administrator (while other clients recognize only the proper user based on the group the BES Client is in). Is there something about Windows 7 that causes problems for BigFix checking the registry value that we set, or is the problem caused by something else? What information would be helpful in troubleshooting this?

(imported comment written by StacyLee)

If you are consistent with setting the registry on both x64 and x86 machines there should not be any differences between computers in the domain or not. Our primary method for computer grouping is registry values, they are set at the time of install with a special wrapper we created to go around the bigfix installer.

What is the path you are setting the registry value?

How are you setting it? reg file, manually, through bigfix…

(imported comment written by SSW_Computing91)

Thanks for the quick reply. We are setting the registry value with a reg file. Here are its contents:

Windows Registry Editor Version 5.00   [HKEY_LOCAL_MACHINE\SOFTWARE\UCBerkeley\BigFix] 
"BigFixPrimaryGroup"=
"000"

We’ve verified that the value is set on both Windows XP and Windows 7 machines, both in x64 and x86 configurations, but it’s like the registry value is being ignored by Windows 7 installations of the BES Client.

(imported comment written by StacyLee)

We place our key group in:

HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\Settings\Client\SU Group

this way it can be edited directly from BigFix by right clicking on computer and edit settings. This makes it consistent for both mac and windows by embedding it into the BigFix registry hive.

However it should still work since we have a similiar key in HKLM\Software\Stanford

is “BigFixPrimaryGroup”=“000” a REG_SZ type string value? , also can you post the relevance you are using to identify the property used in the console.

(imported comment written by SSW_Computing91)

The “BigFixPrimaryGroup”=“000” is a REG_SZ type string on all computers. Here’s the relevance clause for one of our groups:

( version of client >= 
"6.0.0.0" ) AND ( exists 

true whose ( 

if 

true then ( Value 
"BigFixPrimaryGroup" of Key 
"HKLM\SOFTWARE\UCBerkeley\BigFix" of registry = 
"041" ) 

else 

false ) )

And the corresponding relevance expression:

Value 
"BigFixPrimaryGroup" of Key 
"HKLM\SOFTWARE\UCBerkeley\BigFix" of registry = 
"041"

The Windows permissions for the registry key seem to be set correctly to allow reading by the BES Client on all computers.

(imported comment written by StacyLee)

The code looks OK. Are you running the BES agent something other than SYSTEM?

Have you tried running Q/A or relevance debugger on the local machine not on the domain?

(imported comment written by SSW_Computing91)

Thanks! Testing the relevance clause with the relevance debugger on the target Win7 computer helped reveal the problem. Even though the key was clearly being set, the relevance clause was still evaluating to ‘false’. The problem is that running the .reg file puts the key into

HKEY_LOCAL_MACHINE\SOFTWARE\UCBerkeley\BigFix

, but when the BigFix agent, a 32-bit application, checks for the value of the key, the OS translates the request to check

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\UCBerkeley\BigFix

instead. Putting the group number key into

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\UCBerkeley\BigFix

fixed the problem as the relevance clause is being evaluated to ‘true’ and the Clients properly show up in the BigFix Enterprise Console.

I guess this is just something that BES Administrators that deal with mixed 32-bit and 64-bit environments have to keep in mind. Thanks for the help.

(imported comment written by StacyLee)

If you want to keep the key there you still can just adjust your code as follows:(add the word ‘native’ in front of registry)

( exists true whose ( if true then ( Value “BigFixPrimaryGroup” of Key “HKLM\SOFTWARE\UCBerkeley\BigFix” of native registry = “041” ) else false ) )

Value “BigFixPrimaryGroup” of Key “HKLM\SOFTWARE\UCBerkeley\BigFix” of native registry = “041”

check out page 11 of http://support.bigfix.com/fixlet/documents/Windows%20Inspectors%2080_101123.pdf