Exchange provisioning for select users

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

April 7th, 2015 10:10am

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.

Free Windows Admin Tool Kit Click here and download it now
April 7th, 2015 11:21am

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

April 7th, 2015 1:23pm

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

Free Windows Admin Tool Kit Click here and download it now
April 9th, 2015 10:01am

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

April 9th, 2015 10:09am

I would use classical rules. Flexible to do anything you want.  What you want to do is very simple.
Free Windows Admin Tool Kit Click here and download it now
April 9th, 2015 10:11am

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.



April 23rd, 2015 3:12pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics