EPM filter not working for on-prem sync group to EntraID

There is a process that syncs entra groups to the local machine. Unless this process occurs, any group changes will not be seen on the device. You can logout and back in, reboot, or issue an endpointutility.exe /aad command to kick off the sync process. That has been my experience when seeing this issue. Hope this helps.

Missing in the guides.

EPM checks based on the endpoints local cached group memberships from Active Directory or Entra Active Directory. Often times it’s easiest to have the user log out and back into their machine to have to group memberships updated and allow EPM to recognize those changes.

​​​​​​​

@Austin Lawson , have done that a couple of times. I know that when I sign in, EPM can leverage and check my cached local AD group membership but when I add an EntraID group as my filter (which uses GUID, not SID), it cannot seem to recognize it.

Thanks @Jens Hansen , I did run the endpointutility.exe /aad a couple of times already and it showed as “Successful” but it is still not getting filtered. Is there any way for me to check how EPM actually queries a user’s group membership to check on the filters being defined? 

Hi @Jasper  Make sure you log off and back on, that is still a requirement for now.
The old school way was simply from an standard Command Prompt run “whoami \all” that would give you all the Group memberships from AD, and you would be able to validate it. For Entra ID it’s different, I don’t think you can do it directly from the client side with out tools. If you are a Hybrid joined domain, you could fall back to ON Prem AD Groups, that would resolve the issue for matching your filters, but require that you get the AD Connector installed on a resource that is allowed to browse AD. Check the local users & Groups and your account also might show here also. (this is an On-prem account)
 

In order to use groups for Workstyle filtering, EPM uses two different mechanisms. 

For On-Prem Active Directory and local groups, this data is natively cached on the endpoint after a successful logon. EPM does not actively perform any operation to update or refresh this itself, but simply consumes the data that the O/S provides. Changes to group memberships may be available to EPM during a login session, but logging off and back on again is a good practice to confirm this has occurred. 

As Jens notes, this information is available to review using the whoami /groups command.  

For Entra ID groups, this group membership data is not cached locally by the O/S, so in order to leverage it for the purposes of Workstyle filtering, EPM needs to create and maintain its own client-side cache of that membership data. 

This client-side cache is within the agent’s protected container in %ProgramData% and is updated at user login, and as Josh noted, can be manually refreshed using the endpoint utility included as part of the Agent. 

However, this will only pull Entra groups if you are logging on with your Entra UPN, as it needs to use this to identify the account and resolve the groups. If you are authenticating against AD, you will not have Entra groups associated with the sync’d identity - so for workstyle targeting with hybrid environments we recommend adding both on-prem AD groups and Entra ID groups to your filters.  

To complete the picture, the client-side cache is pulling the membership data from a cache in PM Cloud, to allow us to quickly provide this data back to the endpoint, rather than having to make a Just-In-Time request to Entra itself. This cache is periodically updated (e.g., pulling back all groups so you can select them as filters), but updates groups which are referenced in Workstyle filters every 10 minutes. You can also manually force either of these syncs via the PM Cloud UI, if required. 

In terms of troubleshooting, after confirming you are authenticating against Entra when logging into the endpoint, I would ensure that you have your PM Cloud cache updated, perform the client-side cache update (either by logging out and back in, or using the endpoint utility) and then inspecting the agent’s group membership cache to confirm whether it is present. 

If you are still facing issues, then I would certainly suggest you reach out to the support team to help investigate further. 

Would it be possible to get a tool to validate client side cache of the Entra ID Groups?

Hi Jens, the cache is essentially just a set of files which represent the Entra groups for a given user in their GUID format. You can certainly write a simple script to just return the list of GUIDs currently present in the cache, but a dedicated tool isn’t required. 

Obviously the usual caveats apply that the cache location is protected by anti-tamper, so you would need to either run your script as a true admin or elevate it via EPM using a custom token with tamper protection disabled. 
 

GUID’s are more than sufficient for people to validate if the groups are present.
Then since groups are already known by PWS Cloud, do a compared of GUIDs and return the names to the EPM App maybe? We only need to focus on the groups used in the filters of the workstyles in this case.