I’m sure you get it that tasks can be accomplished asynchronously via one mechanism or another, but you may be wondering how MIIS can be notified when the task has completed.  There are two different solutions.  The home directory example still applies for the following reason… if the user’s home directory has not been created, you most likely would not want the user to be able to login.  Since MIIS will likely manage the userAccountControl for user accounts (enabling or disabling), MIIS will need to know that the home directory is online before enabling the account.  Or, you may want to go ahead and enable the account, but not specify a home directory for the user until it is available.

Solution A) Use a synchronization field...

1. Make the Active Directory MA (ADMA) the authoritative contributor of the homeDirectory attribute.
2. Create a new string attribute 'homeDirectorySync' in the MetaVerse and add it to person.
3. Upon projection & modification of the MetaVerse person, the value of homeDirectorySync is set (leaving homeDirectory in tact).
4. In the ADMA export flow for userAccountControl, if the value of homeDirectory does not match the value of homeDirectorySync, ensure the account is disabled.  The AD account is created/modified as disabled and the value for homeDirectory will be blank on creation.
5. A new record is written in the monitored table for the Home Directory Service using the homeDirectorySync attribute.
6. The Service creates/moves/archives the Home Directory, and when complete it writes the value of the AD User homeDirectory attribute using ADSI (DirectoryServices).
7. The next ADMA import into MIIS will now flow the value of homeDirectory into the MetaVerse and the values of homeDirectory and homeDirectorySync are the same.
8. In the ADMA export flow, enable the account because the values are in sync.

Solution B) Use a Provisioned Actions MA...

1. Create a new SQL Server MA called 'Provisioned Actions' that is based on a table with four fields (UniqueID, objectClass, objectId, actionId).
2. Upon projection & modification of the MV person, the value for homeDirectory is NOT set.
3. During the ADMA export, a null/unchanged homeDirectory is specified with the account enabled (this is how the customer may want it).
4. A new record is written in the monitored table for the Home Directory Service with an export flow that sets the appropriate value for the homeDirectory.
5. The Service creates/moves/archives the Home Directory, and when complete it writes a record to the Provisioned Actions table.  For example, a SQL record may have the values of (UniqueID=GUID, objectClass=person, objectId=UID, actionId=HomeDirCreated). 
6. A join rule would be made to match the 'Provisioned Actions' objectId field to the MV UID attribute according to the objectClass specified in the record (ex: person). 
7. Create authoritative flows for the 'Provisioned Actions' MA that drive the value of MetaVerse attributes of the specified objectClass.   When the authoritative attribute flow occurs, it will see that the actionId indicates that the Home Directory has been created and it sets the value of the MV homeDirectory attribute.
8. During the next MIIS Provisioning, any  'Provisioned Actions' csentries are Deprovisioned while not revoking it's contributing MV values.
9. On the next export to AD, the homeDirectory is set to the appropriate value.
10. On the next export to  'Provisioned Actions', the record is deleted.

Both solutions are equally effective.  I have put both to use in other scenarios effectively.  For example, the Provisioned Actions can be quite useful for "tickling" an MVEntry to fire off the provisioning rules to re-evaluate such events as a user being added to a security group in AD through nested group membership.