The Last FIM Workflow You Will Ever Need, Part 2

A year ago I introduced the idea of a FIM Workflow that would allow you to use the UI to write the code that you wanted executed at run time. Since then I have updated the workflow to allow you to also specify additional references and using/import statements. 

I also got approval to upload the project to CodePlex so that you can have access to it.  Check it out at http://fimwf.codeplex.com and let me know what you think!

Be on the lookout for the next item in Last FIM series,the Last FIM Management Agent Rules Extension You Will Ever Need.

The Last FIM Workflow You Will Ever Need

Okay, probably not, but its still pretty cool.  I recently built a Workflow in FIM that will allow a user to define the code they want executed at run time.  The Workflow will compile the code and run it in a separate app domain when its initiated (http://www.west-wind.com/presentations/dynamicCode/DynamicCode.htm).  The UI will allow you to specify the input parameters and where the result of the code execution will go.  Here is a simple example, I am passing in the first and last name from the target of the request, I am also passing the the mail host that I have calculated in a previous step and saved to WorkflowData.  I am then using the code to calculate the user’s email address and save it to the email parameter on the target:

You can add and remove input parameters as needed during design time and then refer to them in the code using their specified index. I expect in future releases to be allow the user to specify additional namespaces and code references to import. It currently won’t do any syntax checking or formatting at design time, but otherwise its extremely versatile and flexible! 

UPDATE: Check out Part 2 of this article for the latest information and download instructions!

Exchange Room Resources

Recently while trying to provision Room Resource Mailboxes via FIM, or more specifically I was setting their Access Booking Policies via the Set-CalendarProcessing command in a PowerShell Workflow, I received the following error:

The values for ResourceMake, ResourceModel, and ResourceType must be included in the ResourceProperties collection.

You may also see this error if you try to open the object in the Exchange Management Console and try to save it. 

Upon further inspection, the issue appeared because the msExchResourceSearchProperties attribute didn’t contain the resource type, in this case “Room”, anywhere in the multi-valued list.  After manually adding this value to the existing list, this issue was resolved.  Since we are getting this list from user input in the portal, a more permanent solution will involve adding a Workflow to ensure that “Room” appears in this list when we add/update it in the portal.