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.

The cached group membership data in PM Cloud isn’t exposed as it isn’t required for normal operation, but you could certainly compare the client-side cached GUIDs against the groups that are assigned to the user within Entra. 

@Paul , I am assuming that the client-side cached folder you mentioned, is  the AzureADCache folder that automatically gets created inside ProgramData\Avecto? My API is able to read and sync the EntraID group but is not showing the cached folder on any of my endpoint.

Hi @Jasper - if the PM Cloud configuration is in place (I’m assuming you are using PM Cloud based upon some of you previous comments) and has synced etc, then the most obvious issue is that we are unable to identify the user to correctly return their associated groups.  

Can you confirm that your users are logging into their endpoint with an Entra ID account, rather than a local admin account against a DC? Also, for my reference, are the users sync’d from AD, native Entra or external users invited into the Entra tenant you have integrated?

Hi @Paul , that is correct. we are using PM Cloud.

Users are logging into their endpoints against on-prem DC (not local admins) and these user accounts get syncd from AD to EntraID as well including their group memberships

Hi @Jasper, 

In that case, it’s very likely this will be where the issue is coming from. EPM is attempting to query the group membership data from PM Cloud using the UPN of the logged on user.

For most customers their local AD domain UPN and the UPN of the synchronized accounts in Entra are different, so whilst we might log in with john.smith@ad.local, that account exists in Entra as john.smoth@corporate.domain.  Obviously if we ask PM Cloud for ‘john.smith@ad.local’, that UPN doesn’t exist so no group data is returned to the cache. 

The information was a little buried in my reply, but as I noted earlier, for workstyle targeting with hybrid-joined environments we recommend adding both on-prem AD groups and Entra ID groups to your workstyle filters, so that however you user logs in (against an AD domain controller or Entra) they should get the correct experience.  

If some of that doesn’t hold true for your environment, then perhaps the issue lies elsewhere, but that seems like the most likely cause based upon what you’ve described.