You deploy a Forefront Identity Manager (FIM) 2010 server in your company network. You create bidirectional synchronization rules for an Active Directory Domain Services (AD DS) data source and a…

Adding the department attribute to an inbound attribute flow affects how the attribute is read into the FIM metaverse, not how it flows out to the SQL Server data source, so it would not prevent the attribute from being written to SQL Server.

Adding the department attribute to the outbound attribute flow of the new high-precedence SQL Server synchronization rule explicitly defines how (or whether) that attribute is handled in the output, allowing you to block or override the existing flow by defining a rule with no mapping or a null value for that attribute.

Creating a highest-precedence outbound synchronization rule for the AD DS data source controls what flows out to AD DS, not what flows into SQL Server from AD DS; this would not block the department attribute from reaching SQL Server.

Creating a new outbound synchronization rule targeting the SQL Server data source with the highest precedence ensures that this rule takes priority over the existing equal-precedence bidirectional rule, allowing you to control exactly which attributes flow into SQL Server and effectively suppress the department attribute from AD DS.

Creating both inbound and outbound synchronization rules for the AD DS data source addresses flows related to AD DS itself, but does not directly control the outbound flow to the SQL Server data source where the department attribute needs to be suppressed.