GCDS no longer adding/removing users based on group membership

[alexgrutza]

Prior versions of GCDS, with synced groups, it would sync current AD users in a group to the corresponding google group. That appears to be not working anymore. Can anyone else confirm this? Or am I just missing something? As mentioned, it used to perform the add/removes via gcds, but appears it does not anymore..

[alexgrutza]

It appears adding worked earlier today, but I have removed a person from a synced AD group and am trying to rerun gcds and it's not picking up the removal of said person from google group (since they were removed from ad group they should be removed from google group as well)

[alexgrutza]

I've even made sure the thresholds were bumped all the way up to 80% and no change. I'm hoping it's a bug for removals in the newer version of gcds

[alexgrutza]

This is from the trace log file. 36 users in AD group, but in Google there are 60 users. Something isn't right. I can see that a user I removed today is still listed as being a member of the specific group in AD, so it appears to be a caching issue or a gcds database issue. 

Anyone have any idea how to clear that? When I run gcds (via gui or cli) I use the "clear cache" option every time so I'm at a loss..

[Kim_Nilsson]

Did it fix itself after waiting a while?

When you check the Google Group via API (GAM or other tool), does it actually show that the user is removed?

Sometimes the admin interface and API are reporting different info, often with a delay.

[alexgrutza]

Someone in an EDUCAUSE forum just posted this same issue. Using GAM it shows this person is still in the group in which they should be removed from.

[alexgrutza]

I've opened a GCDS case with google just now - lets see where that goes..

[alexgrutza]

The issue is likely related to the Directory API and GCDS bug where when GCDS created a google group it set the "adminCreated" to false, which is what GCDS relies on to sync AD groups to their corresponding Google groups.

It appears on June 1st they will be fixing this bug and there may be some unexpected or increase in processing of changes through GCDS.

I'm waiting on Google Support to confirm that this is the issue we're seeing, and if they're able to make the change on the backend (which they'll do June 1st anyways) as it's a read-only value to my knowledge. 

The reason I am 99.999% certain this is the bug/issue is that several groups were created through GCDS and all but the one group in question have adminCreated be True. All the groups were created at the same time during the same run, so it would be odd that GCDS would make 5/6 groups True and 1/6 false..

--

Dear Google Workspace for Education administrator,

You are receiving this communication because your organization uses Google Cloud Directory Sync (GCDS).

We’re writing to let you know about the upcoming updates to Directory API and GCDS. This update ensures that your synchronization process correctly identifies and includes security groups created directly in the Google Admin console, starting June 1, 2026.

We’ve provided additional information to guide you through this change and how it impacts your environments.

What this means for your organization

Key changes: Previously, a technical issue in the Directory API prevented some security groups created in the Admin console from receiving the "adminCreated” flag. Because GCDS uses this flag to determine which groups it should manage, these groups were often omitted from the sync scope.

Starting June 1, 2026:

• Directory API Update: The API will now correctly flag security groups created directly in the Admin console as adminCreated.
• GCDS Sync Scope: During future synchronizations, GCDS will recognize these groups. If they fall within your defined Search Rules, GCDS will attempt to manage them, including synchronizing their members from your LDAP directory.

Potential impact:

• New Sync Scope: Security groups newly created in the Admin console starting June 1, 2026 that were previously ignored will now be evaluated by the GCDS sync engine.
• Unintended Deletions: If your GCDS Google Group deletion policy is set to "Delete Google Workspace groups not found in LDAP", GCDS may now attempt to delete these newly recognized security groups if a matching group does not exist in your LDAP server.
• Membership Overwrites: For groups now recognized by the sync, GCDS will update the membership list to match your LDAP source, which may overwrite any memberships previously added manually in the Admin console.

What you need to do

Action advised:

1. Review Sync Settings: Review your GCDS Google Group configuration, specifically the deletion policies under the "Google Group Search Rule" and "General" tabs.
2. Perform a Simulated Sync: After the fix is deployed, run a Simulated Sync to identify if any existing security groups are now being flagged for deletion or modification before attempting an actual sync.
3. Update Exclusion Rules: If you have security groups in Google Workspace that you do not want GCDS to manage or delete, implement Google Group Exclusion Rules to protect them.

Timelines:

This update will take effect in 35 days. Ensure your configuration is reviewed and updated by June 1, 2026 to avoid any unintended data loss.

We’re here to help

For more information on managing groups and exclusion rules, refer to our 

If you have questions, or require additional help, please contact (Issue Number: 489456912).

Thanks for choosing Google Workspace for Education.

– The Google Workspace for Education Team

[alexgrutza · Accepted solution]

TLDR: Any issue the bug caused before April 30th 2026 will not be rectified automatically.

Per google support:
Our investigation into the underlying bug (b/381813526) is complete, to avoid unexpected data loss for thousands of other customers who may rely on the current behavior, there is no automatic system-wide backfill for groups created before April 30, 2026 but please don’t worry, we have a workaround.

While all groups created moving forward will be correctly identified automatically, our systems do not automatically update existing groups to avoid causing unexpected changes for other organizations. However, we can manually adjust this setting for your specific groups from our end to ensure they are correctly included in future syncs.

To get this resolved for you, please perform the following steps:

-List the Groups: Please reply to this email with a list of the email addresses for all affected groups that are currently not updating memberships correctly.

-Wait for Confirmation: Once I have this list, I will coordinate with our engineering team to manually update the internal settings for these groups. I will notify you as soon as this is completed.

-Run a New Sync: After you receive my confirmation, simply run your synchronization tool again. It will then recognize these groups correctly and process the necessary removals.

In the meantime, your plan to use a manual export and update process is an excellent temporary workaround to keep your groups accurate. We really appreciate your cooperation in this regard.

[Kim_Nilsson]

Thanks for the update, Alex.