Tuesday, September 03, 2013

The FIM Service msidmCompositeType Object Type

FIM 2010 R2 introduced some great features in the FIM MA for performance improvements.  The management agent is now able to batch changes from the FIM Sync Engine into the FIM Service.  The key challenges here were:
  • Arbitrating between a state-based system (FIM Sync) and a request-based system (FIM Service)
  • Optimizing for the synchronous nature of the FIM Sync Engine
In a nutshell what the FIM MA does is fill up a queue in the FIM Service.  Once the items are queued, the FIM MA is satisfied that the export is done, even though the actual FIM Service request is not yet complete.  This separation allows the FIM Service to process the queue asynchronously (fast, or at least pushing the bottleneck back to SQL) while also allowing the FIM MA to complete its export without waiting for every FIM Service request to finish.
With all this goodness, what could possible go wrong?  Well I’m not super happy about the introduction of a new naming convention (msidm*) after the product is already shipping.  Maybe I’m just partial to miiserver.exe setting the standard for naming conventions in FIM, but I was enjoying some consistency until R2.
So what is msidmCompositeType and why do you care?  The batching mode of the FIM MA is on by default. This is very well documented in the FIM Sync Service configuration file.  Very nice touch by the product group by providing the meaning of every configuration item by including comments in the actual file.  Here is the comment for the batching feature, showing us that it is on by default:
FIM Sync Config File Snippet
Additional properties that can be specified for the <resourceSynchronizationClient /> configuration section. This configuration is used to configure the FIM MA settings.    
PROPERTY NAME:  aggregate 
DESCRIPTION:    This property controls whether FIM MA can send data to FIM Service in batches.
PROPERTY NAME:  aggregationThreshold                           
DESCRIPTION:    This property controls the number of attributes per aggregated batch.
PROPERTY NAME:  delayUpdateAcknowledgements                    
DESCRIPTION:    This property controls whether the FIM Management Agent sends acknowledgements to FIM Synchronization Service immediately upon Request completion, or withholds them until the end for Update operations. Setting this to true may reduce the overall time to export data, but the FIM Synchronization Service UI statistics are not updated as frequently.
PROPERTY NAME:  exportRequestsInProcessMaximum                 
DESCRIPTION:    This property controls the maximum number of export requests that can be in process.                            
Anyhow, how do these things impact your FIM Service objects?  Normally a FIM Service request targets one and only one object, so it is pretty easy to determine which requests have applied to any object.  Like this:
What Request Changed My Object?
Export-FimConfig –Only –Custom @"
            DisplayName='Hoof, Hearted'
"@ |
Convert-FimExportToPSObject |
Mode   Operation Value                                  PropertyName    
----   --------- -----                                  ------------    
       Create    Hoof, Hearted                          DisplayName     
       Create    Person                                 ObjectType      
       Create    Issasquah                              City            
       Create    HoofHearted@there.ca                   Email           
       Create    ddddaaaa-c232-4d36-b6d1-98674bf248bf   ObjectID        
       Create    qqqqqqqq-0000-rrrr-ssss-tttttttttttt   Creator         
Modify Create    {aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa}  MVObjectID       
With the new object type and batching, the request parameters are not as easy to follow, or at least we have to get at them differently.  Here is how:
What Batch Changed My Object?
Export-FimConfig –Only –Custom @"
            DisplayName='Hoof, Hearted'
"@ -Attributes * |
Convert-FimExportToPSObject |
Mode   Operation Value                                    PropertyName      
----   --------- -----                                    ------------      
Modify Create    ICEMELTED                                Domain            
Modify Create    AQUAAAAAAAUVAAAAA+GUUUUUUUUU+WvusiEAAA== ObjectSID         
Modify Create    HOOFHEARTED?                             AccountName    
Modify Create    {aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaa}   MVObjectID         
<Truncated for the easily bored>


Anonymous said...

Thanks for this Craig, because all batched FIM Portal exports are now hiding behind this objecttype, searching requests in Portal became useless in that part.
If was wondering what that requests are until i read your post

Anonymous said...

Hello Craig, just one question on your example and using the -Attributes * parameter on Export-FIMConfig, as mine does not have such a parameter.

Is that a mistake or is there something wrong on my side ?

Craig Martin said...

Good catch on the Attributes parameter ;-) That parameter doesn't exist on the Export-FimConfig cmdlet (there is no way to tell Export-FimConfig to only give you a subset of attributes, which can be a real pain if you have a lot of results and/or objects with large attributes (such as ma-data objects).
I use an internal cmdlet that does have that parameter, loosely based on the CodePlex project here: http://fimpscmdlets.codeplex.com/

When I post samples I usually replace that cmdlet with Export-FimConfig and Convert-FimExportToPSObject.