Having a play with Craig Martin’s FIM PowerShell Activity

I’ve been wanting to explore the possibilities of Craig Martin’s FIM PowerShell Workflow Activity for a while, and now my lab is out of it’s TechEd bubble-wrap I can get back to play.

In this post a couple of extra steps I had to take to get it working on R2. I’ll post sample scripts later.

Recompiling

I downloaded the pre-compiled R2 version from codeplex but it didn’t work for me straight away. I got this error:

System.InvalidOperationException: Could not load file or assembly 'Microsoft.ResourceManagement, Version=4.1.1906.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at FimExtensions.FimActivityLibrary.PowerShellActivity.Execute(ActivityExecutionContext context)
   at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)
   at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity, ActivityExecutionContext executionContext)
   at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
   at System.Workflow.Runtime.Scheduler.Run()

Craig suggested I recompile which did the trick. I downloaded the source from codeplex, opened in VS2010 on my FIM2010 R2 server, and ran a Build. I did not change any references. The new DLL works fine.

Installing in the GAC

Craig includes a nice script to install the activity for you – however I’m pretty used to the FIMPowershell.ps1 helper script from TechNet so I modified the “Create AIC” part of Craig’s script to use those functions instead of the ones from his module.

###
### Create the Activity Information Configuration
### (requires FIMPowershell.ps1 from http://technet.microsoft.com/en-us/library/ff720152(v=ws.10).aspx)
###

. .\FIMPowerShell.ps1

$importObj = CreateImportObject -ObjectType ActivityInformationConfiguration
SetSingleValue $importObj  DisplayName  'PowerShell Activity'
SetSingleValue $importObj Description 'PowerShell Activity from CodePlex (fimpowershellwf.codeplex.com)'
SetSingleValue $importObj ActivityName 'FimExtensions.FimActivityLibrary.PowerShellActivity'  
SetSingleValue $importObj TypeName  'FimExtensions.FimActivityLibrary.PowerShellActivitySettingsPart'
SetSingleValue $importObj  AssemblyName  $wfAssembly.FullName
SetSingleValue $importObj IsActionActivity $true
SetSingleValue $importObj IsAuthenticationActivity $false
SetSingleValue $importObj IsAuthorizationActivity  $true
SetSingleValue $importObj IsConfigurationType $true
import-fimconfig -importObject $importObj

Allow the Activity to run FIM PowerShell cmdlets

It turns out there is a config file modification to make if you want your activity to run a PowerShell script that uses the FIM cmdlets, such as Export-FIMConfig and Import-FIMConfig. The details of the change are in this forum thread: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/295fc491-ffc8-4e02-b923-43af1c3aef1d

Using a FIM-enabled Account

If you want the script to run FIM cmdlets you’ll also have to think about the account being used.

When you run the script from the FIMPowersell activity it will run as the FIM Service service account. This account does not exist in the FIM Portal by default. You could add the service account as a Portal user. I preferred to take the approach of (securely) hard-coding the credentials of another account in the script:

1. As the FIM Service user encrypt and store the password of the account you want to use to run FIM cmdlets:

   read-host -assecurestring | convertfrom-securestring | out-file encrypted.txt
   <type the password>

2. Create a credential object as part of your script:

   $AdminAccount = accountname
   $password = get-content encrypted.txt | convertto-securestring
   $UserCredential = New-Object -Typename System.Management.Automation.PSCredential -Argumentlist $AdminAccount,$password

3. Then just use the credential object whenever calling a FIM cmdlet in your script:

   $importObject | Import-FIMConfig -Credential $UserCredential

Testing

I made a simple MPR/WF combo to run a script every time a particular attribute is changed. Then it’s a simple matter to modify the attribute and trigger the WF.

For errors you need to check both the Request object and the Forefront Identity Manager application event log. I also found it useful to write every variable out to a log file so I could see what was going on. Have a look at the FIMRequestLogger.ps1 script included in the source code download for ideas.

In Conclusion

I’m really very interested in this activity as an alternative to developing custom WF, at least in the Action phase. The fact that I can access the Request object and WorkflowData from the PowerShell script is nothing short of brilliant. I can then do all the querying, updating and creating of objects from a PowerShell script as I can do in a custom WF.

Thanks Craig!

Coming soon – I re-write my GenerateUnique activity as a PowerShell script.