Friday, April 22, 2011

File Based Management Agents In MIIS/ILM/FIM

I had a recent need to really compare the capabilities of each of the file based Management Agents in FIM.  Can you name all five? Don't worry, I won't leave you hanging, they are:

  • Attribute-value pair text file
  • Delimited text file
  • Directory Services Markup Language (DSML) 2.0
  • Fixed-width text file
  • LDAP Data Interchange Format (LDIF)

Here are some of the things that they can and can't do (this is for you Joe) and just for kicks, I also added in the SQL MA. If you are using one of these file types in an Extensible Management Agent (XMA), the following still applies: 

 

Multi-valued Attributes

Attribute Level Updates 1

Multi-valued Level Attribute Updates 2

Attribute-value pair

YES

NO

NO

Delimited

YES 3

NO

NO

DSML

YES

NO 4

NO

Fixed-width

YES 3

NO

NO

LDIF

YES

YES

ON IMPORT ONLY 5

SQL MA

YES

YES

NO 6



Okay, now for the caveats (can’t get away without some of those):

  1. An Attribute Level Update implies that a delta import can contain only the attribute that has changed (along with the other required columns, like the type of change and the anchor)

    So, here’s what that might look like.  Suppose I have a user with the following attributes:
      ID: 12345
      Name: Sarah
      Status: Active
      Phone: 555-123-4567
                                         
    If Sarah’s phone number changes to 555-987-6543, I can simply tell FIM something like: 
      ID: 12345 
      Type Of Change: Update
      Phone: 555-987-6543

    This has the advantage of giving FIM less work to do to determine what has changed on the records being imported and greatly speeds up delta imports. 
     
  2. A Multi-valued Level Attribute Update supports adding and deleting specific values from a multi-valued attribute
     
    Let’s take another look at Sara’s record:
      ID: 12345 
      Name: Sarah 
      Status: Active 
      Phone: 555-123-4567
      Phone: 555-456-7890
                                          
    Now, Sarah has two Phone numbers, or a single attribute with multiple values. With multi-value level attribute update support, we can do things like add a new phone number to the list, delete a phone number from the list or update a phone number (in essence by doing an add of the new value and then a delete of the old one):
      ID: 12345 
      Type Of Change: Add
      Phone: 555-987-6543

    Without this support, the source system would be required to do a “replace” action and provide FIM with all of the current values at the time of import which FIM will use to override all the values that it has for that attribute.  So if we start with Sarah’s record as listed just above and add the phone number 555-987-6543 and remove the phone number 555-123-4567, we would have to pass:
      ID: 12345 
      Type Of Change: Replace
      Phone: 555-987-6543
      Phone: 555-4567-7890

    As with attribute level updates, multi-valued level attribute update can greatly reduce the amount of work that FIM needs to accomplish.  To illustrate, just imagine applying this scenario to attributes like member on an AD group that can have thousands of values.
     
  3. Using a multi-valued attribute in a delimited or fixed-width file requires the use of a header on the import file

    So for a comma delimited file this would look like: 
                                           ID, NAME, PHONE, PHONE, PHONE
                                           12345, Sarah, 555-123-4567, 555-987-6543, 555-456-7890

    This would import a record for Sarah with three attributes - ID, NAME and PHONE, the last of which will have three values. A fixed width file would work the same way.
     
  4. While the DSML specifications themselves can actually handle attribute level updates using the addRequest, delRequest and modifyRequest operations, FIM only implements the ability to import a SearchResultEntry element which must contain all of the attributes on the object

    Just a side note for those that might be curious, you can actually place the addRequest, delRequest and modifyRequest nodes in the DSML file.  FIM will be able to parse the file and it wont cause any errors, however these elements are completely ignored and aren’t processed by FIM.  I also tried sending a DSML delta to FIM with just the attribute that changed and a change type of “modify”, and I suppose not surprisingly, the object in the connector space was updated so that it only had the one attribute I specified,  all the other attributes originally on the object were removed. Had any of these attributes been defined as required, this update would have failed.
     
  5. While you can import an update to a specific value in a multi-valued attribute, if you were to export this same change to an LDIF file, it will come through as a replace operation containing all values now present on the attribute
     
  6. While the SQL MA does not support updates to a specific value on a multi-valued attribute out of the box, I hear rumor that some customizations can be done to make this happen

2 comments:

Bob Bradley said...

Excellent article!!! I can't believe there isn't some form of DTD for all of the variations of DSML files used within FIM :(.
This post has been very helpful - I had always presumed DSML import file templates were far more featured than they appear to be.

Question - have you got a difinitive answer as to whether or not it's possible (and how) to do specify the following for a DSML import file (template):
. specify the anchor attribute, including whether or not you want to use the dn as an anchor
. specify the type for each attribute
... so far my attempts to do any of the above have been fruitless and I can't find any documentation as to why ... other than http://technet.microsoft.com/en-us/library/cc720660(WS.10).aspx

Rebecca Croft said...

Thanks Bob! You can specify any attribute as the anchor, but that doenst occur in the DSML import file or template. You are given this option from within the MA itself. You can use the Configure Attributes page to set the anchor for all objects or the Define Object Types page to do it at the type level.

To answer your other question, try adding a type attribute to the value element for the attribute. So it would look something like... <attr name="givenName"><value xsi:type="string">Bob</value></attr>. Where the namespaces are defined on the root as <xmlns:xsd="http://www.w3.org/2001/XMLSchema"> and <xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">. Take a look at those schema documents, they should give you a good idea of what types are allowed as well as how to indicate maximum and minimum lengths, etc. Let me know how it works out!