This chapter covers Azure AD Connect sync rules and filtering, a critical area for the MS-102 exam. Understanding how objects and attributes flow from on-premises Active Directory to Azure AD is essential for identity synchronization. Approximately 10-15% of exam questions touch on sync rules, filtering, and related configuration. You will learn the mechanics of default rules, custom rules, scoping filters, and how to troubleshoot sync issues.
Jump to a section
Imagine a large postal sorting facility that receives mail from thousands of different sources, each with its own addressing format. Some letters have apartment numbers in different places, some use abbreviations, and some include middle initials. The facility uses a series of conveyor belts and sorting machines. The first machine (Azure AD Connect) picks up letters from the source post offices (on-premises directories) and dumps them onto the main belt. But before letters go to the final delivery trucks (Microsoft 365), they pass through a programmable sorting machine called the Sync Engine. This machine has a set of rules (sync rules) that check each letter. For example, a rule might say, "If the letter has a red stamp (department = Sales), route it to the Sales bin." Another rule might say, "If the letter's zip code starts with '9' (a specific domain), drop it into the trash (filtering)." The machine can also transform the address: if the letter says "Apt 4B" but the destination expects "Unit 4B", a rule rewrites it. The rules are ordered; a letter goes through rule 1, then 2, etc., and the first matching rule wins. If no rule matches, the letter is rejected. The facility also has a pre-sorter (filtering) that decides which letters even enter the main machine. For instance, it might block all letters from a certain source (OU) entirely. This analogy mirrors how Azure AD Connect syncs objects from on-premises AD to Azure AD, with sync rules governing attribute flow and filtering determining which objects are synchronized.
What Are Sync Rules and Why Do They Exist?
Azure AD Connect synchronizes identities from on-premises Active Directory to Azure AD. Sync rules define how attributes from on-premises objects map to attributes in Azure AD objects. They are the core logic that determines what gets written to the metaverse and then to the connector spaces. Without sync rules, there would be no transformation or flow of data.
The Sync Engine Architecture
Azure AD Connect uses a sync engine based on Microsoft Identity Manager (MIM). It has three main stages: - Import: Reads objects from the on-premises AD (source connector space) and Azure AD (target connector space). - Sync: Runs sync rules to update the metaverse. The metaverse is a staging area that holds a unified representation of all synchronized objects. - Export: Writes changes from the metaverse to the target connector spaces.
Sync rules operate during the Sync stage. They are evaluated in a specific order, and the first rule that matches determines the attribute flow.
Types of Sync Rules
There are two categories: - Inbound Sync Rules: Flow attributes from on-premises AD (or other connected directories) into the metaverse. - Outbound Sync Rules: Flow attributes from the metaverse to Azure AD.
Each rule has a precedence number (1-1000). Lower numbers have higher priority. The default rules shipped with Azure AD Connect have precedences like 100, 101, etc. Custom rules you create typically get higher numbers (e.g., 50, 60) so they override defaults.
Structure of a Sync Rule
A sync rule consists of: - Name: Descriptive string. - Description: Optional. - Connected System: Which connector (on-prem AD or Azure AD) the rule applies to. - Connected System Object Type: e.g., user, group, contact. - Metaverse Object Type: e.g., person, group. - Link Type: Join, Provision, or Sticky. - Precedence: Integer. - Scoping Filter: Conditions that must be met for the rule to apply (e.g., department equals Sales). - Join Rules: How to match objects between the connector space and metaverse (e.g., match on objectSid). - Transformations: Attribute flow mappings (source attribute -> target attribute) with optional flow type (Direct, Constant, Expression).
How Sync Rules Are Evaluated
During a sync cycle, the engine evaluates inbound rules first, then outbound rules. For each object, it checks rules in order of precedence. The first rule whose scoping filter matches the object is applied. If a rule has a join rule, it attempts to join the object to an existing metaverse object. If no join is possible, the rule may create a new metaverse object if the link type is "Provision".
Default Sync Rules
Out of the box, Azure AD Connect installs several default rules. Key ones for users: - In from AD – User Join: Joins on-premises user objects to metaverse person objects using the objectSid attribute. - In from AD – User Common: Flows common attributes like displayName, givenName, mail, etc. - Out to AAD – User Join: Joins metaverse person objects to Azure AD user objects using the cloudAnchor (immutableId). - Out to AAD – User Common: Flows attributes to Azure AD.
These rules have precedence values typically in the range 100-200. You can view them in the Synchronization Rules Editor.
Filtering: What Gets Synced
Filtering determines which objects from on-premises AD are synchronized to Azure AD. There are two main types:
Domain-based filtering: You can choose to sync only specific domains in a multi-domain forest.
OU-based filtering: You can exclude entire organizational units from synchronization. This is configured in the Azure AD Connect wizard or via the Synchronization Service Manager.
Attribute-based filtering: Using scoping filters in sync rules, you can filter objects based on attribute values (e.g., sync only users where department = Sales).
Group-based filtering: In Azure AD Connect version 1.1.524.0 and later, you can use group-based filtering to sync only members of specific security groups. This is configured during installation or via PowerShell.
Configuring OU Filtering
OU filtering is done in the Azure AD Connect wizard on the "Domain and OU filtering" page. You can uncheck OUs you don't want to sync. This creates a filter in the connector that prevents objects from those OUs from being imported. You can also configure it via the Synchronization Service Manager:
Open Synchronization Service Manager.
Select the on-premises AD connector.
Click "Configure Directory Partitions".
Select the domain and click "Containers".
Uncheck the OUs you want to exclude.
Note: OU filtering only applies to the initial import; if you later add objects to an excluded OU, they won't be synced until you include the OU.
Attribute-Based Filtering via Sync Rules
You can create a custom inbound sync rule with a scoping filter that excludes objects. For example, to exclude users with department = "Temp":
Create a new inbound sync rule with precedence lower than the default join rule (e.g., 50).
Set scoping filter: department EQUALS Temp.
Set link type to "Provision" but do not add any join rules. Instead, set the transformation to flow nothing. However, the proper way is to use the scoping filter to prevent the object from being provisioned. Actually, to filter out objects, you can create a rule that sets the metaverse object attribute to something that causes it to be filtered later, but the recommended approach is to use the built-in filtering options.
Better practice: Use the "Synchronization Rule Editor" to create a rule that sets the "cloudFiltered" attribute to True. In Azure AD Connect, if a metaverse object has the attribute "cloudFiltered" set to True, the outbound rule will not export it to Azure AD. This is a common exam topic.
How to Create a Custom Sync Rule
Open the Synchronization Rules Editor from the Start menu.
Click "Add New Rule".
Provide a name (e.g., "Custom – Filter Temp Users").
Select the connected system (on-prem AD).
Select object type (user).
Select metaverse object type (person).
Set link type (Join).
Set precedence (e.g., 50).
Configure scoping filter: e.g., department EQUALS Temp.
Configure join rules: usually you keep the same join as default (objectSid).
In transformations, add a transformation: FlowType = Expression, Source = something, Target = cloudFiltered, Expression = "True" (constant).
This will mark any user with department=Temp as cloudFiltered=True, and the outbound rule will skip them.
Verification and Troubleshooting
To verify sync rules:
Use the Synchronization Service Manager to view connector space objects and their attributes.
Use the "Search Connector Space" to find an object and see which rules applied.
Use PowerShell cmdlets like Get-ADSyncRule to list rules.
Use Get-ADSyncRunProfileResult to check sync cycle results.
Common issues:
Objects not syncing: Check OU filtering, scoping filters, and attribute errors.
Attribute not flowing: Check if a custom rule with higher precedence is overriding.
Duplicate objects: Check join rules and matching criteria.
Interaction with Related Technologies
Azure AD Connect Health: Monitors sync and provides alerts for errors.
Azure AD Connect Cloud Sync: An alternative for simpler scenarios, but sync rules are not as customizable.
Microsoft Identity Manager: The underlying engine; advanced customizations can be done via MIM.
Exam-Relevant Numbers and Defaults
Default sync rule precedence range: 100-200.
Custom rule precedence: 1-99 (to override defaults) or 200+ (to be overridden).
The attribute cloudFiltered is a Boolean attribute on metaverse person objects.
The default sync cycle runs every 30 minutes (configurable).
The staging mode can be used to test sync rules without impacting production.
Advanced: Expression Transformations
Sync rules support VB-like expressions for attribute flow. For example:
IIF(InStr([extensionAttribute1],"VIP")>0,"True","False")This sets cloudFiltered based on a condition. The exam may ask about expression syntax.
Summary of Key Concepts
Sync rules are ordered by precedence.
Scoping filters determine applicability.
Filtering can be done at domain, OU, group, or attribute level.
The cloudFiltered attribute is a metaverse attribute that prevents export to Azure AD.
Default rules handle most scenarios; custom rules are for exceptions.
This understanding is vital for configuring Azure AD Connect correctly and troubleshooting sync issues. The MS-102 exam expects you to know how to create and modify sync rules and how filtering works.
Install Azure AD Connect
Run the Azure AD Connect wizard on a server. Choose Express Settings (default) or Customize. For sync rules and filtering, Customize is required. During installation, you specify the on-premises AD forest and Azure AD tenant. The wizard creates default connectors and sync rules. The installation also sets up the Synchronization Service Manager and Synchronization Rules Editor tools. After installation, an initial sync cycle runs. You can verify success via the wizard or the Synchronization Service Manager.
Configure OU Filtering
In the Azure AD Connect wizard, on the 'Domain and OU filtering' page, you can uncheck OUs you want to exclude. Alternatively, after installation, open Synchronization Service Manager, select the on-premises AD connector, click 'Configure Directory Partitions', select the domain, click 'Containers', and uncheck OUs. This prevents objects in those OUs from being imported. Changes take effect on the next full import cycle. You can also set this via PowerShell using Set-ADSyncConnectorParameter.
Create a Custom Sync Rule
Open Synchronization Rules Editor. Click 'Add New Rule'. Fill in name, connected system (on-prem AD), object type (user), metaverse type (person), link type (Join), precedence (e.g., 50). On the 'Scoping filter' tab, add conditions like department EQUALS Temp. On the 'Transformations' tab, add a transformation: FlowType = Expression, Target = cloudFiltered, Source = (blank), Expression = "True". Click Save. This rule will apply before default rules and set cloudFiltered=True for matching users.
Run a Full Sync Cycle
After changing sync rules or filtering, you need to run a full sync to apply changes. In Synchronization Service Manager, select the on-premises AD connector, click 'Run', choose 'Full Synchronization'. Then run 'Full Synchronization' on the Azure AD connector. This forces a complete evaluation of all rules. Monitor the progress in the 'Operations' tab. Check for errors in the 'Sync Statistics'.
Verify Sync Results
Use Synchronization Service Manager to search for a specific user in the connector space. Right-click the object and select 'Properties'. Go to the 'Lineage' tab to see which sync rules applied. Check the metaverse object properties to see if cloudFiltered is set. Also, verify in Azure AD portal that the user is not present (if filtering). Use PowerShell: Get-ADSyncUser -Identity "username" | fl * to see sync details.
Scenario 1: Excluding Contractor Users from Azure AD
A large enterprise has 50,000 employees and 5,000 contractors. Contractors are in a specific OU (OU=Contractors,DC=contoso,DC=com). The company wants to sync only employees to Azure AD. They configure OU filtering to exclude the Contractors OU. This is done during installation or via Synchronization Service Manager. After configuration, they run a full sync. Contractors are no longer in Azure AD. However, if a contractor is moved to an employee OU, they will be synced. This is straightforward but has a limitation: if contractors are scattered across multiple OUs, OU filtering becomes cumbersome. In that case, attribute-based filtering using cloudFiltered is better.
Scenario 2: Selective Sync Based on Department
A company wants to sync only users with department = "Sales" or "Marketing" to Azure AD. They create a custom inbound sync rule with scoping filter: department EQUALS Sales OR department EQUALS Marketing. Then they set cloudFiltered = False (or leave default). Actually, to allow only those, they need to set cloudFiltered = True for all others. So they create a rule with lower precedence (e.g., 49) that sets cloudFiltered = True for all users, and then a higher precedence rule (e.g., 48) that sets cloudFiltered = False for Sales and Marketing. In production, this requires careful planning. The sync engine processes rules in order; the first matching rule wins. So the rule for Sales must have higher precedence (lower number) than the catch-all. This is a common exam scenario.
Scenario 3: Merging Two Forests with Different Attributes
After an acquisition, a company has two AD forests with different attribute schemas. They need to sync users from both forests to Azure AD, but map attributes differently. They create custom inbound sync rules for each forest. For Forest A, they map extensionAttribute1 to department; for Forest B, they map department directly. They also create join rules to match users across forests (e.g., using mail attribute). This requires careful join rule configuration to avoid duplicates. Performance considerations: with many custom rules, sync cycles may take longer. They also use staging mode to test before going live. Misconfiguration can lead to duplicate objects or missing attributes, so thorough testing is essential.
What MS-102 Tests on This Topic
Exam objective: 2.2 Implement and manage identity synchronization. Specifically, you need to know how to configure Azure AD Connect sync rules and filtering. The exam expects you to:
Understand the order of precedence and how scoping filters work.
Know how to create a custom sync rule to filter objects using cloudFiltered.
Differentiate between OU filtering, domain filtering, group-based filtering, and attribute-based filtering.
Know the default sync rules and their purposes.
Understand the sync cycle stages (Import, Sync, Export).
Common Wrong Answers and Why
"OU filtering is applied after sync rules." Reality: OU filtering is applied during import; objects from excluded OUs never enter the connector space, so sync rules never see them.
"You can filter users by setting the cloudFiltered attribute on the on-premises AD user object." Reality: cloudFiltered is a metaverse attribute, not an on-premises attribute. It is set via sync rule transformations.
"Changing sync rules requires a full import before taking effect." Reality: Changing sync rules requires a full sync (Synchronization), not necessarily a full import. However, if you change scoping filters or join rules, a full import may be needed to reload objects.
"Group-based filtering is configured in the Synchronization Rules Editor." Reality: Group-based filtering is configured during installation or via PowerShell, not in the Synchronization Rules Editor.
Specific Numbers and Terms on the Exam
Precedence values: Default rules are 100-200; custom rules should be <100 to override.
cloudFiltered attribute: Boolean, set to True to exclude from sync.
Sync cycle frequency: Every 30 minutes by default.
Staging mode: Enabled via wizard or PowerShell; prevents export.
Expression syntax: IIF, InStr, etc. Know that expressions are VB-like.
Edge Cases and Exceptions
If you create a sync rule with a scoping filter that matches no objects, the rule is never applied.
If two rules have the same precedence, the rule with the lowest GUID wins (but you should avoid duplicate precedence).
The cloudFiltered attribute is only evaluated by outbound rules; inbound rules can set it.
When using group-based filtering, only direct members of the group are synced; nested group members are not included unless the group is also synced.
How to Eliminate Wrong Answers
Understand the flow: Import -> Sync -> Export. Filtering at import (OU) prevents objects from ever being processed. Filtering at sync (cloudFiltered) prevents export.
Remember that sync rules are evaluated in order of precedence (lowest number first). The first matching rule wins.
Know that attribute-based filtering is done via sync rules, not via the Azure AD Connect wizard (except for the simple case of device writeback).
For group-based filtering, the group must be a security group and must be synced itself.
Mastering these points will help you answer scenario-based questions correctly.
Sync rules are evaluated in order of precedence; lower number = higher priority.
The cloudFiltered attribute is a Boolean metaverse attribute that prevents export to Azure AD.
OU filtering is applied during import; objects from excluded OUs are never processed by sync rules.
Default sync rules have precedence values between 100 and 200.
Custom sync rules should use precedence below 100 to override defaults.
Group-based filtering only syncs direct members of the specified security group.
After modifying sync rules or filtering, run a full synchronization cycle to apply changes.
The sync cycle runs every 30 minutes by default, but can be triggered manually.
Staging mode allows testing sync rules without exporting to Azure AD.
The Synchronization Rules Editor is used to create and modify sync rules.
These come up on the exam all the time. Here's how to tell them apart.
OU Filtering
Configures at connector level via Synchronization Service Manager or wizard.
Prevents objects from being imported into the connector space.
Simple to implement; no need to create custom sync rules.
Cannot filter based on dynamic conditions like department value.
Changes require a full import to take effect.
Attribute-Based Filtering (cloudFiltered)
Configures via custom sync rules in Synchronization Rules Editor.
Objects are imported but marked with cloudFiltered=True in metaverse.
Allows complex logic using expressions and multiple conditions.
Can filter on any attribute value, including custom attributes.
Changes require a full sync; no need for full import.
Mistake
OU filtering can be bypassed by moving an object to an included OU after initial sync.
Correct
OU filtering is evaluated at import time. If an object is moved to an included OU, it will be imported on the next delta import cycle. However, if the OU was previously excluded, the object may already exist in the connector space if it was synced before the exclusion. You need to run a full import to remove it.
Mistake
The cloudFiltered attribute is a property of the on-premises AD user object.
Correct
cloudFiltered is a metaverse attribute. It is not stored in on-premises AD. It is set via sync rule transformations and is only used during sync to prevent export to Azure AD.
Mistake
Custom sync rules always override default rules regardless of precedence.
Correct
Custom rules override defaults only if they have a lower precedence number (higher priority). If a custom rule has a higher precedence number (e.g., 300), default rules (100-200) will apply first and may already set values.
Mistake
Group-based filtering syncs all members of the group, including nested group members.
Correct
Group-based filtering only syncs direct members of the specified group. Nested group members are not included unless the nested group itself is also a member of the filtering group.
Mistake
You can create a sync rule that filters based on the object's Azure AD attributes.
Correct
Sync rules are evaluated on the connector space objects (on-premises AD attributes) for inbound rules and on metaverse attributes for outbound rules. You cannot directly filter on Azure AD attributes in inbound rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can create a custom inbound sync rule that sets the cloudFiltered attribute to True for those users. For example, create a rule with scoping filter department EQUALS Temp, and add a transformation that sets cloudFiltered = True. This rule must have a lower precedence than the default join rule (e.g., 50) so it applies first. The user will be imported but marked as cloudFiltered, and the outbound rule will skip exporting them to Azure AD.
Full import reads all objects from the connected directory (on-premises AD or Azure AD) into the connector space. Full synchronization evaluates all sync rules and updates the metaverse based on the connector space data. After changing sync rules or filtering, you need to run a full synchronization to apply the new logic. If you change OU filtering, you need a full import to reload objects from the newly included/excluded OUs.
Yes, you can specify multiple groups during Azure AD Connect installation or via PowerShell. You can also add groups later using the Set-ADSyncGroupFiltering cmdlet. Only direct members of these groups are synced. The groups themselves must be security groups and must be synced to Azure AD.
Open Synchronization Service Manager, select the on-premises AD connector, click 'Search Connector Space', find the user, right-click and select 'Properties'. Go to the 'Lineage' tab. It lists all sync rules that have processed this object, with their precedence and whether they contributed to the metaverse object.
The sync engine will apply the rule with the lowest GUID (globally unique identifier) first. However, this is not deterministic and is considered a configuration error. You should always ensure unique precedence values. The Synchronization Rules Editor warns you if you try to set a duplicate precedence.
You can modify default sync rules, but it is not recommended because Microsoft updates may overwrite them. Instead, create custom rules with lower precedence to override specific behaviors. The Synchronization Rules Editor allows editing default rules, but changes may be lost during an upgrade.
Enable staging mode on the Azure AD Connect server. In staging mode, the sync engine runs normally but does not export any changes to Azure AD. You can verify the results in the metaverse and connector spaces. To enable staging mode, use the Azure AD Connect wizard or run Set-ADSyncScheduler -StagingModeEnabled $true.
You've just covered Entra Connect Sync Rules and Filtering — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?