Filtering and Scoping

By default, Connect Sync synchronizes every user, group, contact, and computer in your AD forest to Entra ID. In practice, you almost always need to narrow that scope. Service accounts, test accounts, decommissioned OUs, and non-personal objects should not pollute your cloud directory.

Connect Sync provides three filtering layers. They stack with logical AND - an object must pass all active filters to be synchronized.

Filtering Layers

Domain-Based Filtering

Selects which AD domains within a forest are in scope. Configure this through the Connect wizard’s “Domain and OU filtering” page.

When to use: When you have domains in your forest that should be entirely excluded from sync (lab domains, legacy domains being decommissioned).

How to apply: Re-run the Connect wizard, navigate to “Domain and OU filtering,” and uncheck domains you want excluded.

OU-Based Filtering

Selects which organizational units within each domain are in scope. This is the most common filtering method.

When to use: When specific OUs contain objects that should not sync (service account OUs, staging OUs, computer OUs you do not need in the cloud).

How to apply: Same wizard page as domain filtering. Expand the domain tree and uncheck the OUs you want excluded.

Gotcha: OU renames break filtering. Connect Sync stores the OU’s distinguished name (DN) in its inclusion list. If you rename an OU in AD, the DN changes and the OU silently drops out of sync scope. After any OU rename, re-run the wizard and re-select the renamed OU.

Gotcha: New OUs. In versions 1.1.524.0 and later, you can choose whether new OUs are automatically included or excluded. In older versions, new OUs sync by default.

Attribute-Based Filtering

Uses sync rules to include or exclude individual objects based on attribute values. This is the most flexible method.

When to use: When you need object-level control that OU structure alone cannot provide. Examples: exclude all users with extensionAttribute15 = "NoSync", include only users where department = "Sales".

How it works: Attribute filtering uses the cloudFiltered metaverse attribute. The logic is:

• If cloudFiltered is True, the object is excluded from sync to Entra ID.
• If cloudFiltered is absent or NULL, the object is included.
• Never set cloudFiltered to False in a default rule - only set it in custom rules that implement positive filtering.

Practical Examples

Negative Filtering: “Do Not Sync These”

Exclude specific objects while syncing everything else. This is the simpler and more common pattern.

Scenario: Exclude all users where extensionAttribute15 = "NoSync".

Steps:

1. Open the Synchronization Rules Editor on the Connect server.
2. Create a new inbound rule with a descriptive name (e.g., “In from AD - User DoNotSyncFilter”).
3. Set the CS object type to User, MV object type to Person, link type to Join.
4. Set precedence to a value not used by other rules (e.g., 50 - lower than 100 but higher than default rules).
5. Add a scoping filter: extensionAttribute15 EQUAL NoSync.
6. Skip join rules.
7. Add a transformation: flow type Constant, target attribute cloudFiltered, source value True.
8. Save the rule and run a full synchronization.

Objects matching the filter get cloudFiltered = True in the metaverse, which prevents outbound sync to Entra ID.

Positive Filtering: “Only Sync These”

Include specific objects and exclude everything else. This requires two rules.

Scenario: Only sync users where department = "Sales".

Rule 1 - Include rule (precedence 51):

• Scoping filter: department EQUAL Sales
• Transformation: cloudFiltered = False (constant)

Rule 2 - Catch-all exclude rule (precedence 99):

• No scoping filter (matches everything)
• Transformation: cloudFiltered = True (constant)

Rule 1 has higher precedence (lower number) than Rule 2. Sales users match Rule 1 and get cloudFiltered = False. Everyone else falls through to Rule 2 and gets cloudFiltered = True.

Warning: When using positive filtering, be careful not to exclude critical system objects, replication conflict objects, or the Connect Sync service accounts. Always test with a full sync preview before exporting.

Group-Based Filtering

Group-based filtering is a special case available only during initial installation via the custom wizard. You specify an AD group, and only its direct members sync. This is intended for pilot deployments.

Limitations:

• Only supports direct group membership - nested groups are not resolved.
• Cannot be re-enabled once disabled.
• Not supported for production use.
• If using multi-forest sync, the user and all related objects (FSPs, resource accounts, mail contacts) must all be in the group.

After your pilot, switch to OU-based or attribute-based filtering for production.

Applying and Verifying Filter Changes

After any filtering change:

1. Disable the scheduler before making changes:

   Set-ADSyncScheduler -SyncCycleEnabled $false
   

2. Run a full import on affected connectors (domain/OU changes) or a full sync (attribute filter changes).

3. Preview before exporting. Use csexport to dump pending changes to a CSV:

   csexport "contoso.com - AAD" %temp%\export.xml /f:x
   CSExportAnalyzer %temp%\export.xml > %temp%\export.csv
   

   Review the CSV in Excel. Look for unexpected deletes.

4. Check the accidental delete threshold. By default, Connect Sync blocks exports that would delete more than 500 objects. If your filter change legitimately removes many objects, you need to temporarily adjust or disable this protection.

5. Export once you are satisfied the changes are correct.

6. Re-enable the scheduler:

   Set-ADSyncScheduler -SyncCycleEnabled $true
   

Common Filtering Mistakes