The AD change needs to make it to the machine. We normally have the user log out and back in to pull the group change. If this involves entra groups, logging out and back in also kicks off the Azure sync process.

oh okay, these are on prem AD groups. So on BI, we dnt need to run any group synchronization?

While I can’t speak for various BI processes as I run the PMC SaaS solution, if the group is already defined in the policy that is applied on the machine, the user needs to log out and back in so the group membership changes take effect for the user.

An easy way to validate local groups on your client. Logon as the user who is still getting the wrong Policy(Workstyle) open a command prompt and get the result of “whoami /all” this will tell you if the user is still considered a member of that group. BI group sync is irrelevant for this.

To refresh the group fast, you can do a gpupdate /force from the normal command prompt, make sure the Domain controllers are accessible, if home you need to be on VPN. the log off and back on.

Just to confirm, this works exactly the same for BI - the policy contains the reference to the target user group, so providing the policy has been applied, once the user group change is reflected on the endpoint - the correct workstyle will apply. 

Obviously the caveat here is that the user needs to have line of sight to a domain controller when logging on, if a user is off network this update will not occur unless you have a VPN connection established before the logon actually occurs. 

I’m not 100% certain whether a gpupdate /force works to refresh groups, but one other way is to clear the kerberos ticket by doing:

klist purge

Then you need to browse to a domain resource like a share and it should update. You can check it has using:

klist tgt

klist purge

klist tgt

Oh okay, What we are seeing is that when the user is already part of the group and then we apply the group as filter, the policy applies. But when user is removed from group, the policy still is being applied.

Also when we removed the group as filter and removed the user from group, and then re applied the group as filter, and then readded the user into the AD group, logged off and logged on, the policy still didnt get applied. When checked with whoami/all, the enduser group didnt appear. But when we did net user <username> /domain , it was present. Also gpupdate /force didn't fetch the end user group.When we restart the machine, the policy gets applied. Will try the kerberos purge as well and see the behavior. 

Also just to highlight, the user is connected to network and there is no issue seen when username or computer filter is used. There is no VPN while testing, we are currently within the network.This is onprem BI with onprem AD