none
Exchange provisioning for select users RRS feed

  • Question

  • Scenario:

    Users in Set 123 need AD accounts only

    Users in Set B need Ex mbxs (& AD accounts obviously)

    Users can move from Set 123 to Set B, or go directly into Set B

    We cannot simply create a 'base' AD sync rule, and then a dependent Ex sync rule with homemdb,mail,msexchhomeserver &mailnickname - we cannot use 'initial flow only' in a dependent sync rule.  We don't want FIM to continue to set the msexchhomeserver and other attributes - we want to transfer authority to Exchange to manage those attributes.

    If we create two separate sync rules, not dependent, we can't control which tries to execute first.  If we have the ex sync rule with just homemdb,mail,msexchhomeserver &mailnickname attributes set for initialflowonly, it will fail if it tries to run before the sync rule that creates the AD account.

    Separately, does initial flow only run when the user is added to the scope of the sync rule for the first time, or when the object is actually provisioned in AD?  In other words, if a user object exists in AD and FIM is aware of this, will FIM flow out attributes in a sync rule set for initial flow only?


    Ben Pahl

    Tuesday, April 7, 2015 2:08 PM

Answers

  • We solved this by:

    Flowing in AD Base sync rule inbound mail, msexchhomeservername,homemdb,msexchrbacpolicylink,msexchmailboguid, mdbusedefaults & mailnickname

    Creating equal precedence for all of those attributes with FIM Service *being careful to never run a full import/sync from FIM Service and then immediately exporting to AD, without doing a full import/sync from AD first* 

    Creating a set that says: *you are supposed to get an exch mbx based on job codes X-XX, *you don't have a value in your msexchmailboxguid currently, *your hrstatus is active

    Creating transition in MPR to the above set that fires workflows.  some workflows stamp static values (homemdb value, msexchhomeservername, etc) to the user object in FIM service.  some generate unique values for things like mail and mailnickname, and stamp them on the user object in fim service

    The MPR above also adds the user to the scope of a dependent sync rule that does not use initialflowonly for the referenced ex values above.  they flow out from fim service to metaverse, then the ex extension provisions the mbx.  when the user transitions out of the set above (they now HAVE a mbx, so they move out) they are removed from the scope of the exchange sync rule.




    Ben Pahl

    • Marked as answer by beneb Thursday, April 23, 2015 7:12 PM
    Thursday, April 23, 2015 7:12 PM

All replies

  • Use classical rules provisioning and provision the users you want - and you can solve the problem.

    Or you can simply use the mapping of the exchange attributes in classical MV.  Write code to do what you want and you are all set.


    Nosh Mernacaj, Identity Management Specialist


    Tuesday, April 7, 2015 3:20 PM
  • Hello.

    I would use 2 seperate SyncRules for this (if I want to do it in portal), but code provisioning like nosh told is still an option.

    Both sync rules should be nearly identical, beside that one of them has the exchange attributes as inital flow.

    Rule1: All normal AD attributes (incl. initals)

    Rule2: Same as Rule1 + exchange attribute.

    Which one of them applies can be controlled by EREs, so with either of your above Sets bring the objects to the approp. scope of the sync rule

    Inital flows are only evaluated on provisioning to the connector space, so if the objetcs already exists in AD and there is a connector to MV there will be no provisioning.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, April 7, 2015 5:22 PM
  • peter - but what about when someone moves job codes from:

    Already has an AD account

    to

    needs ex mbx, in addition to AD account?

    does the ex extension try to create the mbx only when provisioning the user, or if the AD account exists, does it try to do so as soon as it has all required attributes?  and if the latter, how do i provide those attributes without constantly overriding them in AD from FIM Svc/metaverse?

    BP


    Ben Pahl

    Thursday, April 9, 2015 2:00 PM
  • Hello,

    ok understood.

    in that case I think I would preferr using Sorens PowerShell MA to create and handle exchange mailboxes.

    and only users in Set B will get an ERE for outbound sync (and provisioning) to that MA.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Thursday, April 9, 2015 2:08 PM
  • I would use classical rules. Flexible to do anything you want.  What you want to do is very simple.

    Nosh Mernacaj, Identity Management Specialist

    Thursday, April 9, 2015 2:10 PM
  • We solved this by:

    Flowing in AD Base sync rule inbound mail, msexchhomeservername,homemdb,msexchrbacpolicylink,msexchmailboguid, mdbusedefaults & mailnickname

    Creating equal precedence for all of those attributes with FIM Service *being careful to never run a full import/sync from FIM Service and then immediately exporting to AD, without doing a full import/sync from AD first* 

    Creating a set that says: *you are supposed to get an exch mbx based on job codes X-XX, *you don't have a value in your msexchmailboxguid currently, *your hrstatus is active

    Creating transition in MPR to the above set that fires workflows.  some workflows stamp static values (homemdb value, msexchhomeservername, etc) to the user object in FIM service.  some generate unique values for things like mail and mailnickname, and stamp them on the user object in fim service

    The MPR above also adds the user to the scope of a dependent sync rule that does not use initialflowonly for the referenced ex values above.  they flow out from fim service to metaverse, then the ex extension provisions the mbx.  when the user transitions out of the set above (they now HAVE a mbx, so they move out) they are removed from the scope of the exchange sync rule.




    Ben Pahl

    • Marked as answer by beneb Thursday, April 23, 2015 7:12 PM
    Thursday, April 23, 2015 7:12 PM