locked
Conceptual information about Declarative Provisioning RRS feed

  • General discussion

  • Knowing how declarative provisioning works helps you to configure FIM according to your business requirements.
    In the Introduction to Outbound Synchronization, you find a first attempt to explain declarative provisioning from the conceptual point of view.

    The objective of this discussion post is to collect feedback in conjunction with conceptual information about declarative provisioning.
    If you have feedback in conjunction with conceptual information (e.g.: existing topics that need clarification or topics that are missing), use this post to share your feedback with us.

    We are in the process of updating the conceptual information and having a better understanding of what you are looking for helps to make sure that we are including the right information.


    Cheers,
    Markus   
     

     


    Markus Vilcinskas, Technical Content Developer, Microsoft Corporation
    Friday, October 16, 2009 3:38 PM

All replies

  • Hi Markus!
    I would really like to see a "Do's and don'ts" checklist based on your best practices and with a descriptive title and a more in depth description why and why not, I really think that could be a perfect way for everyone to be able to find out if their plan follow best practices and maybe how to do it in a better way.

    //Henrik

    Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)
    Saturday, October 17, 2009 8:37 AM
  • Makes sense, Henrik, thanks for your feedback!

    All
    , what else do we have?
    What would help to make declarative provisioning easier to digest?

    Cheers,
    Markus 
    Markus Vilcinskas, Technical Content Developer, Microsoft Corporation
    Tuesday, October 20, 2009 9:18 PM
  • Henrik,

    could you please also add some more details on what type of best practices you are after?
    Something like "how to filter objects" - the discussion we had - should probably be part of it - right?

    What else?

    Cheers,
    Markus
    Markus Vilcinskas, Technical Content Developer, Microsoft Corporation
    Tuesday, October 20, 2009 11:37 PM
  • Markus,

    Can you provide more detail as to why it is a best practice to include all person objects from the metaverse in the FIM portal? I was reading the prior thread and you mentioned an issue with evaluating disconnected object with a delta sync. A delta import and delta sync run would resolve that issue. Outside of evaluating disconnected objects are there any other reasons why it is favorable to manage all person objects in the portal. Thanks.

    Mark
     
    Wednesday, October 21, 2009 2:22 AM
  • Hi Markus!
    That was an evil question! You made me have to go through both of the sync introductions again but still I'm pretty much out of ideas (it's pretty early in the morning for me) except the "how to filter objects" we've discussed earlier but you know there's a bunch of pitfalls you could end up in. Maybe declarative provisioning have made it easier to avoid doing "bad things" but still I believe there's a couple of things you shouldn't do even thought it's possible just like avoiding filters as much as possible. The introductions to inbound and outbound sync describes a single scenario that works in most cases but when it doesn't suit your case it's easier to end up in a pitfall thats why I want a checklist for avoiding them or at least a description why it's a bad thing to do.

    I believe you have better knowledge of what pitfalls users ended up in , why it's bad , how to avoid them or maybe how to go around them .
    I think it would be a good idea to make this as a form of checklist since it's easier to digest and easier to go back to than the lengthy introduction documents.

    A good start would be if you made a more in-depth description around the blue boxes in the documents to give more understanding around these important notes even thought it is obvious for most of us it isn't for beginners and maybe those that have been away from the product for a while:
    • Why you should avoid using filters.
    • Why you should consider appstore a mirror of metaverse and what problems you might end up having if you ignore this.
    • To create the FIM management agent, you need a separate user account that is used to run it - Why?
    • To apply an inbound synchronization rule to connector space objects, the synchronization rule must exist in the metaverse! If you update an inbound synchronization rule, you must also bring the updated synchronization rule configuration into the metaverse. Why?
    • Each run of an export run profile requires a following import run to complete the export operation. You don’t have to run this import immediately after the last export. It is a common best practice to leave a delta (2 or 3 minutes) between an export run and a following import run. Why?
    • In most scenarios, you will have to at least configure import and export attribute flow rules for the FIMMA because what it is you need to replicate depends on your scenario requirements. Why?
    • After the creation of the sample account, you should wait one minute before starting the deployment cycle. Why?
    • It is a recommended best practice for newly staged connector space test objects to verify the actual attribute values in the connector space. Why?
    • An so on...
    I think a checklist with dos and don't s or at least don't s could be helpful not only for inbound/outbound sync and provisioning, recently I was about to create an export only XMA, it's possible but fortunately I realized it was strange and found a forum post with a description why it's considered a bad practice even thought it wasn't going under the hood of the product as much as I wanted it to.

    //Henrik

    Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)
    Wednesday, October 21, 2009 7:53 AM
  • My second first name is evil – didn’t you know :o)
    This is wonderful feedback – thanks a million!

    If you find more for "and so on", please add it to this thread.

    Cheers,
    Markus 


    Markus Vilcinskas, Technical Content Developer, Microsoft Corporation
    Wednesday, October 21, 2009 9:41 AM
  • Markus,

    Can you provide more detail as to why it is a best practice to include all person objects from the metaverse in the FIM portal? I was reading the prior thread and you mentioned an issue with evaluating disconnected object with a delta sync. A delta import and delta sync run would resolve that issue. Outside of evaluating disconnected objects are there any other reasons why it is favorable to manage all person objects in the portal. Thanks.

    Mark
     

    Yep, will do...

    Cheers,
    Markus
    Markus Vilcinskas, Technical Content Developer, Microsoft Corporation
    Wednesday, October 21, 2009 9:41 AM
  • Hi Markus,

    I think it would be useful to explain in more detail the "initial flow" concept, and especially to stress more that you must configure certain attributes as "initial flow only".
    Speaking out of experience, if you are new to FIM and forget to check the initial flow box for some attributes, it's not obvious why the export is failing.
     
    Cheers,
    Paolo

    Paolo Tedesco - http://espace.cern.ch/idm
    Friday, October 23, 2009 7:36 AM
  • I think it would be useful to explain in more detail the "initial flow" concept, and especially to stress more that you must configure certain attributes as "initial flow only".

    Paolo Tedesco - http://espace.cern.ch/idm

    Thanks, Paolo, this is also a good one!
    I guess, I should also add a link to a test script in the ScriptBox - if one exists.
    For the intitial flow configuration, we have one.

    Cheers,
    Markus 
    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Friday, October 23, 2009 9:52 AM
  • Hi Markus!
    In this thread I tried to answer the question how traditional attribute flow relates to "portal" attribute flow and all I can find in the documentation is that conventional attribute flow could be used for fine tuning... This could definitely need a better description.

    What if I declare both a conventional flow and a portal flow for the same attribute?
    What if I declare both a conventional flow and a portal flow for the same attribute and the conventional one has a legacy flow rule defined?

    //Henrik

    Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)
    Wednesday, October 28, 2009 9:55 AM
  • Hi Henrik, Hi Markus and hello everybody
    I have tried to map all what I have configured in the lab and what I understood from Henrik into 1 excel sheet that explaines specific configuration mapped to concepts and also mapping confusing architecture that is still new to some of us, please can you guys download the sheet from here: http://www.ipility.com/fimdata%20flow.xlsx

    the sheet lists HRMA, FIMMA and ADMA configs along with run profiles and syncrules configured and tried to map each step to a concept in FIM to understand specific configuration step and how it affects data flow, can you please read it and comment or modify it as it will make a great point for people starting understnading data flow in FIM, also it will be great for people to start creating their own sync rules and data flow for their custom environment since we will have a deep understnading for each step and its relation with the data flow.

    additionally I will appreciate from you Markus if you can answer henrik's questions regariding MA Attribute flow and Synch rules and how they are related and working together.

    Thanks
    Regards, Mahmoud Magdy
    Friday, October 30, 2009 10:55 AM
  • Hi Mahmoud!
    I think the Excel document describes the process pretty well.

    You had two questions in the document:

    Why did we have configured the manager as a Reference DN?

    The manager is stored in AD as a distinguished name (reference) and this helps us to for example find all persons that have a specific manager or let the manager approve memberships etc. for his own employees.

     

    But why did we made a string flow to the domain attribute?

    The domain is a string for example"Fabrikam" and by using it in combination with AccountName the AccountName alone doesn't have to be unique but together they must be.

     

    //Henrik



    Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)
    Friday, October 30, 2009 2:05 PM