How to Configure Google Workspace Directory Sync (GCDS) Object Exclusions

The Synchronization Disaster

When an enterprise migrates to Google Workspace, they rarely abandon their on-premise Microsoft Active Directory (AD). Instead, they use Google Cloud Directory Sync (GCDS) to create a one-way mirror. GCDS connects to the local AD via LDAP, reads every user, group, and organizational unit, and replicates them into Google Workspace in the cloud.

This is highly efficient, but it contains a hidden danger: Destructive Synchronization. By default, GCDS assumes that Active Directory is the absolute source of truth. If a user account or an email group exists in Google Workspace but does NOT exist in the on-premise Active Directory, GCDS will assume it is an unauthorized anomaly and delete it from Google Workspace during the next sync cycle.

This becomes catastrophic if your company uses Google Workspace for external collaboration. If your marketing team creates a Google Group called [email protected] directly in the Google Admin Console, the next time GCDS runs, it won’t find that group in the local AD, and it will instantly delete the group, breaking communication for the entire project. To prevent this, you must configure strict Object Exclusions in the Configuration Manager.

Step 1: Launching the Configuration Manager

GCDS is not configured in the cloud; it is a Java application that runs on a physical server (or VM) inside your network, usually on the same server acting as a Domain Controller.

1. Log into the Windows Server hosting GCDS.
2. Open the Configuration Manager application.
3. Load your existing XML configuration file (e.g., sync_config.xml).

Step 2: Defining User Exclusions

If you have Super Administrator accounts in Google Workspace (like [email protected]) that intentionally do not exist in Active Directory for security reasons, you must exclude them.

1. In the left-hand navigation pane, click on Google Domain Configuration and expand it.
2. Click on Exclusion Rules.
3. Click the Add Exclusion Rule button.
4. Type: Select User Email Address.
5. Match Type: Select Exact Match.
6. Rule: Type [email protected].
7. Click OK.

(Pro-Tip: If you have an entire OU of cloud-only accounts, you can change the Match Type to Regular Expression and exclude everything under a specific path, or use a prefix match like ^cloud-.*).

Step 3: Defining Group Exclusions

This is the most common failure point. Cloud-native Google Groups must be protected.

1. Stay in the Exclusion Rules section.
2. Click Add Exclusion Rule.
3. Type: Select Group Email Address.
4. Match Type: Select Regular Expression.
5. Rule: If your company prefixes all cloud-only groups with “ext-“, you would type: ^ext-.*@yourcorp\.com$
6. Click OK.

Step 4: The Simulation (Dry Run)

Before you ever apply an updated XML file to a production environment, you must simulate the synchronization. If your regex is slightly wrong, you could still accidentally delete thousands of objects.

1. In the left-hand navigation pane, click on Sync.
2. Click the Simulate Sync button.

GCDS will now query the local AD, query Google Workspace, and build a mathematical model of the changes it would make. It will output a massive text log.

Step 5: Analyzing the Output

You must meticulously read the Simulation Log, specifically the Proposed Deletions section.

• Look at the Users to be deleted list. Ensure your super-admin account is NOT on this list.
• Look at the Groups to be deleted list. Ensure external-contractors is NOT on this list.

If the simulation shows exactly 0 proposed deletions for your protected objects, your Exclusion Rules are syntactically perfect. You can now click Sync & Apply Changes to commit the configuration to the live environment, ensuring your cloud-native infrastructure is permanently shielded from the ruthless one-way mirror of Active Directory.