Filtering objects before they are imported into the AD MA connector space

Forefront Identity Manager 2010 (FIM 2010) build 4.0.3594.2 (kb2520954) introduces several new features across the product.  The KB text defines feature 3 for the Synchronization Engine as follows:

Adds the ability to filter objects before they are imported into the AD MA connector space.

What does this actually mean?  And how do we configure this?  Here’s a screenshot:

image

Whereas in the past we had “None”, “Declared” and “Rules extension” the AD MA now has a fourth option – “Declared (Import Filter)”.  The purpose of this feature is for customers that have a large number of valid disconnectors.  When I say valid I mean there’s nothing wrong with their join rules –there’s just loads of objects in the containers selected but out of scope of FIM.  Having a large number of disconnectors obviously slows down delta synchronisation therefore this option filters during import so that they’re never re-evaluated during synchronisation.

When you implement a declared import filter any new objects that match the filter are not created in the CS.  If there are existing objects that match the filter they are deleted during the next Full Synchronization.  Yes, I said full synchronisation.  They’re not obsoleted during Full Import they are deleted during Full Synchronization.

Hopefully that’ll help someone.  And in case it’s not obvious I’ll state it.  This needs to be configured in the FIM Synchronization Service Manager, i.e. this is a property of an MA and is different from an external scoping filter on a Synchronization Rule (SR).

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, FIM 2010, News and tagged , , , , , , , , . Bookmark the permalink.

12 Responses to Filtering objects before they are imported into the AD MA connector space

  1. ali khawaja says:

    are you sure that your understanding is correct? from MIIS documentation:

    The connector filter rule determines whether a staging object is processed further during synchronization.

    its not to filter it from CS; its actually to filter it from synchronization.

    • Yes I am sure – this is a new feature in FIM and works differently to the classic connector filter that works as you describe. This is specifically aimed at the ADMA – not available on other MA types – and allows you to not have a whole bunch of filtered disconnectors in the CS.

  2. Deniz says:

    Hello, I would like to know if there is a way to filter an object before I export it. For example, the environment will import data from several source, but I don’t want all the data to be exported to all destinations. Some of the data I will export to some destination and go on. Is there a way to do it?

    • Yes, but through the overall system design. When you design your solution you will define what object types are in-scope and out-of-scope and will configure your scope through a variety of techniques, e.g. specific containers in a directory, or a view of a database; connector filters to remove certain types of unnecessary or incomplete data; provisioning logic so that you only provision clean and consistent objects in target systems; synchronisation rules so that you only synchronise the correct data from the authoritative sources, and potentially transform or perform additional filtering of source or target (or both) data.

      You configure what data flows to what source mainly using export attribute flow (EAF) in an MA/connector configuration. You have complete control over what objects are in-scope of your synchronisation.

  3. Deniz says:

    Hi Mr. Williams, thank you for your message.

    I am not sure if I understood you correctly, I will try to put this in another way.

    Imagine I have four forests: Forest A, B, C and D.

    Forest A has User1, User2, User3
    Forest B has User4, User5, User6
    Forest C has User7, User8, User9
    Forest D has User10, User11, User12

    I want to sync all the forest. To do so, I will use FIM Sync Service.

    For my understanding, the FIM will have all the 12 objects above, or whatever scope I will use. Lets assume all the 12 objects is alright.

    I want to sync all of them between the forests. I create Management Agents for each forest and do the Import. After that if I go to the Management Agent from Forest A, and select “Export”, that will add the objects from Forest B, C and D to Forest A. After that I will have 12 objects in Forest A (its own 3 objects + 9 objects from the other forests).

    I do the same to Forest B, C and D and after that all the forests will have 12 objects. That’s great !

    If for instance I want the Forest C (and only Forest C) to have objects only for Forests A and B and not have objects from forest D, how can I do it? Is there a way to do it? I want Forest C to have (after all) 9 objects (its 3 own objects + 6 objects from Forests A and B), and all the remain forests to have all the 12 objects.

    I looked at the graphical options from FIM (Connector Filter, Join and Projection Rules, Attribute Flow) but all of them will filter the object before it goes to the FIM database, and that’s not what I want.

    The conclusion that I got is after the data is inside the FIM database, you can not exclude it from the export command. Is there a way to do it using the graphic interface?

    Thank you very much for your time.

    My best regards,

    • In order to get objects from the metaverse into a connector space you must either write provisioning code or utilise the FIM Service and declarative provisioning. Either approach allows you to control what is and isn’t provisioned into downstream connector spaces. The answer is therefore to filter objects from the source connector space so that you only have those that you want (like you say) and then to utilise logic in your provisioning process to decide what is provisioned where (and when if you like).

      You currently describe import (from managed identity system into connector space) and export (from connector space to managed identity system) but not synchronisation (from connector space into metaverse and from metaverse into other connector spaces). This is the core of FIM, import and export are basic processes that require little to no involvement. Synchronisation is where almost all of the work is. What attributes of what objects flow to what and where, etc.

  4. Deniz says:

    When I wrote “you can not exclude it from the export command, I meant “you can not filter it from the export command”.

    Regards.

  5. Deniz says:

    Thank You vey much for your help Mr. Williams.

    Have a good day..

  6. Pingback: Windows Azure Active Directory Connector part 2: multi-forest directory synchronization | Yet another identity management blog

  7. Leo says:

    Import Connector Filter works for other types of agents aswell, e.g. the ECMA 2.x agent types.
    Very useful, and it makes Delta Sync run a lot faster if you have a lots of Disconnectors in your CS.

  8. Kazimierz says:

    Hallo Paul
    Thank You for this article. I have looking for something similar information since some time
    It is very helpful article for my actually situation with my FIM environment. I have depromoted few old Active Directory domains but I could not deleted object from connectors spaces. Now I know how to do that. I have only one question yet. When I used declared (import filter) filter for example with condition “All object with ends with name one of my old domain, example “dc=company,dc=com” some object are deleted from CS but some object stays as placeholders and are discontented state of curse. Why all object are not deleted from CS ?
    Thank You very much

    • There are two different things here. First things first – to disconect connectors that fall into the scope of an import filter type connector filter you need to synchronise the object. Typically, after introducing such a connector filter you will perform a full sync to disconnect connectors.

      Re. your specific problem – the placeholders exist because some other object is referencing that object. The most common examples are group membership and manager attribute values. If you have removed domains you should update the properties of the ADMA to no longer have those partitions selected, assuming they are still discoverable. You should not need the filter you have as you can effectively remove all objects from the decomissioned domains.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s