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?
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…
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.
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.
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.
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