I am using the following relevance to check for existence in an AD group.
exists ((names of groups of it) of (logged on users of active directory)) whose (it as lowercase is contained by set of “automation_pega_ana”)
The problem is that I have a couple of users who are not in the group that are showing as relevant. It has been over 12 hours since they were not in the AD group, if they were ever in it, and they are still appearing as relevant.
Any chance there is a second user session logged on who is a member of the group?
There is only one user logged on. I checked other user profiles on the machines and they are not in the group either.
I need to start over with this thread because reading it again, it does not make sense.
I am trying to use active directory inspectors in relevance to determine a logged on user’s membership in an active directory security group. Then if a user is in the active directory security group, they are relevant to receive a Bigfix task.
The relevance in the task is:
exists ((names of groups of it) of (logged on users of active directory)) whose (it as lowercase is contained by set of “automation_pega_ana_branch”) AND exists logged on user.
I created an empty fixlet, with just the relevance above thinking that the number of applicable machines should be roughly the same as the number of members of the security group, less users who are not logged on. Well, the result is that almost half of the users are missing from the fixlet.
I have zeroed in on a couple of the missing users. I have used the analysis, “Active Directory Security Groups and Organizational Units” to see that Bigfix does see these users in the active directory security group, but the computer is still not being evaluated as relevant.
Has anyone else tried doing software deployment based on users membership in a security group? If so, has it worked for you?
I’m afraid I don’t have much to add, but I know it can be frustrating talking to yourself so I thought I’d pipe in here anyway.
What I can say is that I haven’t seen any customers deploying software based on the user’s group memberships. Computer group memberships, yes, but not user groups.
Thanks Jason I really appreciate the response. I was beginning to think that everyone had dropped Bigfix and gone to a competitor.
I did have a development. I removed the “exists logged on user” from the relevance and I got better results.
exists ((names of groups of it) of (logged on users of active directory)) whose (it as lowercase is contained by set of “automation_pega_ana_branch”) AND exists logged on user.
I have no idea why removing exists logged on user would make a difference.
Now I am dealing with 38 users out of 251 who are in the AD Group, but Bigfix is not seeing them in the group. At least I can see why they are not evaluating true for my test fixlet.
I have a meeting with L3 tomorrow morning. Hopefully, we can get to the bottom of the issue.
Hopefully support can help you clarify the situation.
The AD Relevance for Security group membership I typically use in BigFix is:
( ((exists value whose(it as lowercase = "TESTGROUP1" as lowercase ) of components whose(type of it="CN") of distinguished names ((distinguished names of groups of it; distinguished names of it) of logged on users of it))) of active directory)
See if that return different results to you initial relevance.
fyi, if you want to make it easier to read and post relevance on the forum, enter x4 spaces before your relevance statement 
e.g.
exists logged on user
vs
exists logged on userI found where the AD cache is on the BES client:
C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__Global\ADCache
Now the next step is to find out how the AD cache is populated. There appears to be a problem in some cases populating the AD Cache.
The AD cache on the client is supposed to refresh automatically in any of the following cases:
1. Every 12 hours.
2. Log on
3. BES Client restart.
In our environment, the ADcache is only getting refreshed on BES Client restart. It is getting refreshed for the computer account every 12 hours, but not the logged on user account. The modified date of xml files in the following directory on the client, indicate when they were last refreshed.
C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__Global\ADCachewe had something similar in our environment especially with the current pandemic and people working from home.
what we did is the the following
creating these properties provide us with more flexibility when creating actions and we want to target certain groups.
Hope this helps.
@dgendera, It is already long chat, I had to pipe in as i am on same situation were i require relevance.
could you help provide the relevance for the points which you have mentioned. I have a same case in my environment.
create folllowing 2 properties
ad_groupmembership_users which contains all the groups that user is member
ad_groupmembership_computers which contains all the groups that computer is member