Retreiving information from Person in Powershell Workflow Activity.

Apr 17, 2013 at 8:19 AM
Edited Apr 17, 2013 at 8:19 AM
Hello, I am trying to use the latest version of this FIM PowerShell Workflow Activity. The version is: Fri Mar 22, 2013 at 9:00 AM. I am using FIM2010R2 SP1.

I need to run a workflow activity to run a powershell script. In that script I need the 'accountname/sAMaccountname of the user/person.

When I use the examples found on: https://fimpowershellwf.codeplex.com/wikipage?title=Using%20the%20FIM%20Workflow%20Details%20in%20your%20PowerShell%20Script&referringTitle=Documentation

The only result I get is the GUID of the request. When I try to extract the account name of that GUID manually in a Powershell and input that GUID in the commands I can extract the accountname. When I put the same powershell code in the workflow activity I get nothing back.
[CODE TO RETREIVE REQUEST GUID]
add-pssnapin FIMAutomation -Verbose:$false
Import-Module "C:\Codeplex\FIMPowerShellModule\FimPowerShellModule.psm1" -Verbose:$false

$fn=get-date -uformat %Y-%m-%d-%H-%M-%S

$fimwf.requestid.guid | Out-File c:\codeplex\task\todo\$fn.txt
[CODE TO RETREIVE REQUEST GUID]
[CODE TO RETREIVE ACCOUNT NAME WITH STATIC GUID]
add-pssnapin FIMAutomation -Verbose:$false
Import-Module "C:\Codeplex\FIMPowerShellModule\FimPowerShellModule.psm1" -Verbose:$false

$getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F "{0266ebfb-e084-4105-a2fe-23f327ab1661}")

$request= $getfimx | Convert-FimExportToPSObject
$request | out-file c:\codeplex\test1.txt
$getfimx | out-file c:\codeplex\test2.txt

$t1=$request | where {$_.accountname}
$t1.accountname  | Out-File c:\codeplex\test4.txt
[CODE TO RETREIVE ACCOUNT NAME WITH STATIC GUID]
When I run second script manually the accountname is displayed in test4.txt, but when I add this code in the workflow activity the accountname stays empty.

Can anyone help me on this?
Thanks
Stefan Peters
Apr 17, 2013 at 8:23 AM

This line looks incorrect:

$getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F "{0266ebfb-e084-4105-a2fe-23f327ab1661}")

Try something more like this:

$getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.requestid.guid)

-Craig

Apr 17, 2013 at 8:46 AM
Edited Apr 17, 2013 at 8:48 AM
I know that look incorrect. When I put in the $fimwf.requestid.guid it also fails. But when I retrieve the GUID with the first, and manually run the second powershell on the Powershell console with the GUID retrieved from the first script I get the accountname.

When I merge the scripts and run it from the Workflow activity it fails and I get nothing back from the line: $getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.requestid.guid). The $getfimx var is empty.

When I run it from the commandline/powershell I get nothing back in $fimwf (obvious) so I changed the part: $fimwf.requestid.guid with the actual GUID retrieved in the workflow activity. Then the $getfimx is not empty and command below that work perfectly.

Thx.
Stefan
Apr 17, 2013 at 9:19 AM

Keep in mind the workflows run in the security context of the FIM Service service account. You might want to try the query from the command line as the FIM Service’s account. You can do this with RunAs, or by supplying the Credential parameter to Export-FimConfig as shown below.

###

### Query FIM as the 'administrator' account

### NOTE: the FIMAutomation Snap-in caches this credential

###

$adminCredential = New-Object System.Management.Automation.PSCredential 'administrator', (ConvertTo-SecureString 'HoofHearted' -AsPlainText -Force)

Export-FIMConfig -only -custom "/Person[AccountName='administrator']" -Credential $adminCredential

Apr 17, 2013 at 10:16 AM
Craig, I changed the code to this:
But the test1 - 3 files remain empty.

When opening a powershell console with "RunAs" as the FIMService account is nice to try but at that point the $fimwf is not available.
add-pssnapin FIMAutomation -Verbose:$false
Import-Module "C:\Codeplex\FIMPowerShellModule\FimPowerShellModule.psm1" -Verbose:$false

$adminCredential = New-Object System.Management.Automation.PSCredential 'administrator', (ConvertTo-SecureString '*******' -AsPlainText -Force)

Export-FIMConfig -only -custom "/Person[AccountName='administrator']" -Credential $adminCredential 

#$getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F "{59233211-56da-4184-9a7b-b48a50e2e520}")
$getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F "$fimwf.requestid.guid") -Credential $adminCredential 
$getfimx2 = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.requestid.guid) -Credential $adminCredential 


$request= $getfimx   | Convert-FimExportToPSObject
$request2= $getfimx2 | Convert-FimExportToPSObject
$request  | out-file c:\codeplex\test1.txt
$request2 | out-file c:\codeplex\test2.txt


$Target= Export-FimConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.TargetId.Guid) | Convert-FimExportToPSObject 
$Target | out-file c:\codeplex\test3.txt
Apr 17, 2013 at 10:20 AM

You can fake the $fimwf variable for testing your scripts in an editor like PowerShell_ISE, just do this at the top of your script:

### Mock objects for testing

$RequestId = New-Object PSObject -Property @{Guid='00000000-0000-0000-0000-000000000000'}

$TargetId = New-Object PSObject -Property @{Guid='00000000-0000-0000-0000-000000000000'}

$fimwf = New-Object PSObject -Property @{TargetId=$TargetId;RequestID=$RequestId}

You’ll need to replace the empty GUIDs with actual GUIDs from FIM.

-Craig

Apr 17, 2013 at 12:19 PM
Craig,

Well I have got a little further. The first time I tried using the FIMService account it failed. Then I added the FIMService account to the FIMPortal and to the Administrators set. After that I get the results from below.

Unfortunately the results when the Powershell is fired from the Workflow activity are still empty.

Hope you can help!
thx.
Stefan
PS C:\Windows\system32> whoami
fim\fimservice
PS C:\Windows\system32> add-pssnapin FIMAutomation -Verbose:$false
PS C:\Windows\system32> Import-Module "C:\Codeplex\FIMPowerShellModule\FimPowerShellModule.psm1" -Verbose:$false
PS C:\Windows\system32> $getfimx = Export-FIMConfig -Custom ("/*[ObjectID='{0}']" -F "{65da6b5e-9a24-4f20-923a-9459a00683b3}")
PS C:\Windows\system32> $getfimx

Source                                                      ResourceManagementObject
------                                                      ------------------------
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
http://localhost:5725/ResourceManagementService             Microsoft.ResourceManagement.Automation.ObjectModel.Reso...
PS C:\Windows\system32>
Apr 19, 2013 at 4:52 AM

Might be helpful to review what these two scripts do:

· Create-FimServiceAccountAsFimPerson.ps1

· Update-FimServiceConfigFile.ps1

It sounds like the FimAutomation snap-in may not be working in the workflow activity. Is there evidence of this? Do the requests in FIM complete with errors?

Apr 23, 2013 at 11:51 AM
Craig,

Thanks for this last reply. I finally got it working.
Installation steps should be like this:
  1. Install wf activity.
  2. Add FIMService user to FIMportal
  3. Add FIMService user to default SET: Administrators
  4. Run the Update-FIMServiceConfigFile.ps1 from the examples ZIP.
  5. Run the scripts and get results.
These steps seem to be the correct steps.

Thanks again.
Stefan
Apr 25, 2013 at 4:52 AM

That’s about right ;-) and most of it should be automated in the checked-in scripts too.

The FIMService user does not strictly need to be in the Adminstrators Set (that’s a bit over-privileged) but it does need permission to do whatever you try to perform in your workflow scripts.

Glad you got it working Stefan!

Nov 7, 2013 at 7:32 AM
Edited Nov 7, 2013 at 7:34 AM
Hello, Craig. Wanted to ask you about this activity.
I've done every step outlined in codeplex_anykey's post.
1.Install wf activity.
2.Add FIMService user to FIMportal
3.Add FIMService user to default SET: Administrators
4.Run the Update-FIMServiceConfigFile.ps1 from the examples ZIP.
5.Run the scripts and get results.

Is "fim service" account the account that is used to run "fim service" service?
I use this wf activity:
Import-Module C:\CodePlex\FimPowerShellModule\FimPowerShellModule.psm1 -Verbose:$false
$Target= Export-FimConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.TargetId.Guid) | 
    Convert-FimExportToPSObject 
and get the following error.
System.InvalidOperationException: Exception of type 'Microsoft.ResourceManagement.Workflow.WorkflowExtensionException' was thrown.
   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()
any ideas?
when I run powershell script from the account identity using
$TargetId = New-Object  PSObject -Property @{Guid='00000000-0000-0000-0000-000000000000'}
$fimwf = New-Object  PSObject -Property @{TargetId=$TargetId} 
everything works great.
btw, why do I have to use "$fimwf.TargetId.Guid" if documentations says use "$fimwf.targetid" (tried both, doesn't work) same error.
Nov 8, 2013 at 7:39 AM
4c74356b41 wrote:
Hello, Craig. Wanted to ask you about this activity.
I've done every step outlined in codeplex_anykey's post.
1.Install wf activity.
2.Add FIMService user to FIMportal
3.Add FIMService user to default SET: Administrators
4.Run the Update-FIMServiceConfigFile.ps1 from the examples ZIP.
5.Run the scripts and get results.

Is "fim service" account the account that is used to run "fim service" service?
I use this wf activity:
Import-Module C:\CodePlex\FimPowerShellModule\FimPowerShellModule.psm1 -Verbose:$false
$Target= Export-FimConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.TargetId.Guid) | 
    Convert-FimExportToPSObject 
and get the following error.
System.InvalidOperationException: Exception of type 'Microsoft.ResourceManagement.Workflow.WorkflowExtensionException' was thrown.
   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()
any ideas?
when I run powershell script from the account identity using
$TargetId = New-Object  PSObject -Property @{Guid='00000000-0000-0000-0000-000000000000'}
$fimwf = New-Object  PSObject -Property @{TargetId=$TargetId} 
everything works great.
btw, why do I have to use "$fimwf.TargetId.Guid" if documentations says use "$fimwf.targetid" (tried both, doesn't work) same error.
Hello, I don't know exactly what went wrong. You might need an IISReset after you step 4 on this. I have wrote a full step by step manual to get this powershell wf working including test scripts. You can check them out on my blog: http://www.anykeyonline.nl
Hope that will help you get it right.

Good luck
Stefan
Nov 8, 2013 at 8:40 AM
Hello, Stefan, first of all, I'd like to thank you for the response. I do have powershellWF activity in my fim portal already, so I guess no need for IIS reset, but I did reboot the server quite a few times since and nothing changed.
Other powershellWF activities I "wrote" are working like a charm. But to pass them parameters I have to do really crazy stuff like this:
Call a WF Dictionary Function, export it as a text file (doh!), read the text file, cut the contents and then I finally get the variable I could just get with $fimwf.TargetId.Guid...
I noticed that everytime I fire a powershellWF activity I get a warning (same as the error posted above) in event log. The only reason is: if its warning or error. If it's a warning - activity worked just fine, if its an error - activity failed completely.
Nov 8, 2013 at 9:15 AM
4c74356b41 wrote:
Hello, Stefan, first of all, I'd like to thank you for the response. I do have powershellWF activity in my fim portal already, so I guess no need for IIS reset, but I did reboot the server quite a few times since and nothing changed.
Other powershellWF activities I "wrote" are working like a charm. But to pass them parameters I have to do really crazy stuff like this:
Call a WF Dictionary Function, export it as a text file (doh!), read the text file, cut the contents and then I finally get the variable I could just get with $fimwf.TargetId.Guid...
I noticed that everytime I fire a powershellWF activity I get a warning (same as the error posted above) in event log. The only reason is: if its warning or error. If it's a warning - activity worked just fine, if its an error - activity failed completely.
What are you trying to pass thru? Do you have other Powershells that correctly pass information?
Nov 9, 2013 at 3:03 PM
Edited Nov 9, 2013 at 4:03 PM
Well...
Import-Module C:\CodePlex\FimPowerShellModule\FimPowerShellModule.psm1 -Verbose:$false
$Target= Export-FimConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.TargetId.Guid) | 
    Convert-FimExportToPSObject 
this.

And yes, I do have working powershell activities, but not those using wfpowershell activity commandlets
Nov 9, 2013 at 5:15 PM
4c74356b41 wrote:
Well...
Import-Module C:\CodePlex\FimPowerShellModule\FimPowerShellModule.psm1 -Verbose:$false
$Target= Export-FimConfig -Custom ("/*[ObjectID='{0}']" -F $fimwf.TargetId.Guid) | 
    Convert-FimExportToPSObject 
this.

And yes, I do have working powershell activities, but not those using wfpowershell activity commandlets
Do you have this line also in the powershell? Don't know for sure if it is mandatory but you could try. In my example script it is placed before the import-module part.
add-pssnapin FIMAutomation -Verbose:$false

My example file:
http://www.anykeyonline.nl/blogdownloads/powershellwftest.zip

You can test my example file also, it will extract user info (at least if you are firing the powershell for a user). It will save it in a txt file to have visual confirmation.
Also the fim_service account must have permissions. You can always test and make it member of the Administrator SET. When changing this you have to restart the fimservice.
Nov 12, 2013 at 7:03 AM
If you are not able to query the FIM Service using Export-FimConfig then it points to a couple of causes:
  1. the FimAutomation PS Snap-In is not loaded (as suggested by Stefan - thanks!)
  2. the FIM Service config file did not get updated properly
First rule out Stefan's suggestion, then share your config file so we can validate it.
Nov 12, 2013 at 8:26 AM
Edited Nov 12, 2013 at 8:28 AM
I am getting desperate guys, I don't think you even read what I type ;)
Let me clarify this and quote myself.
"when I run powershell script from the account identity (that is service account) using powershell (not PowershellActivity) everything works great."
FIM Service account is administrator, in fact I used it to install fim. I mean it is the only admin account in FIM.
ps. I tried with "add-pssnapin fimautomation" and without it.
pps. http://pastebin.com/GURFjvay - config file.
Nov 12, 2013 at 9:04 AM
Mkay, so the test script worked just fine, now the thing I don't get is, why do you use requestID.guid and not targetID.guid?
Can you tell me whats the difference between requestID.guid and targetID.guid, because that the obvious reason why my activities were not working. I was quering for TargetID instead of RequestID, but what's the difference?
ps. when I was using powershell instead of powershell activity I passed user guid as TargetID, that's why it worked fine.
Nov 14, 2013 at 7:01 AM
So you're now able to call Export-FimConfig from the PowerShell WF Activity?

$fimWF.RequestID.Guid is the objectID of the current request being processed.
$fimWF.TargetID.Guid is the objectID of the object being acted on.

Both properties should have a value. You can test this by doing something like this in your WF script:
Write-Verbose "Processing FIM WF with RequestId: $fimwf"
Nov 22, 2013 at 9:54 AM
Thanks Craig and codeplex_anykey. I was thinking I need to use TargetId instead of RequestId. Thank you.
Dec 13, 2013 at 8:19 AM
Hello, friends. I have this question, I cant invoke ADDS commandlets from FIM PowerShell WF, do I really have to use dsquery like codeplex_anykey or am I missing something?
I have tried "Import-Module ActiveDirectory" and "Start-ScheduledTask" and both do not work. Is there a way to figure what kind of powershell commands are available in PowerShell WF or not? (I saw Craig's post (might be not Craig's actually) saying Start-Transcript wont work and indeed it doesn't)
Dec 13, 2013 at 10:41 AM
The fim_service accounts needs to have permissions to run the Import-Module commands, and the ActiveDirectory module should be installed on the FIM server. I used the dsquery commands because the customer I created these scripts for had Win2003 AD controllers. Also the account needs permissions to invoke the AD commandlets that you want to use.

Hope this helps!
Dec 13, 2013 at 11:27 AM
I'm running a test lab... so fim service account is administrator on the server and enterprise administrator of the test domain, ADDS module is installed on the server.
I can run same commands from powershell from that user, but cant from PowerShell WF Activity
Dec 14, 2013 at 3:24 PM
Edited Dec 14, 2013 at 3:24 PM
So after poking around a bit I figured weird stuff... when I do something like this:
try {
Import-Module ActiveDirectory
} catch {
 $_ | Format-List -Property * | Out-String | Out-File C:\FIM\PowerShell\error.txt -Append
}
Everything looks cool, but when I do this:
try {
Import-Module ActiveDirectory
ADD-ADGroupMember Group -Members User
} catch {
 $_ | Format-List -Property * | Out-String | Out-File C:\FIM\PowerShell\error.txt -Append
}
I get:
The term ADD-ADGroupMember is not recognized as the name of a cmdlet, function, script file, 
or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try 
again.
And at this point I'm completely out of ideas.
Dec 17, 2013 at 8:19 PM
Edited Dec 17, 2013 at 8:20 PM
Codeplex_anykey, do those commandlets work in your environment?
Craig, can you, maybe, help me in this issue? ;)
ps. I'm using WS 2012, does that affect anything?
Dec 18, 2013 at 7:51 PM
Edited Dec 18, 2013 at 7:55 PM
I'm not giving up ;)
So, using WS 2012 does affect things =(
This is what I was able to get (I have no idea why it didn't work when I tried it before)
Import-Module : The 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ActiveDi
rectory\ActiveDirectory.psd1' module cannot be imported because its manifest con
tains one or more members that are not valid. The valid manifest members are ('M
oduleToProcess', 'NestedModules', 'GUID', 'Author', 'CompanyName', 'Copyright', 
'ModuleVersion', 'Description', 'PowerShellVersion', 'PowerShellHostName', 'Powe
rShellHostVersion', 'CLRVersion', 'DotNetFrameworkVersion', 'ProcessorArchitectu
re', 'RequiredModules', 'TypesToProcess', 'FormatsToProcess', 'ScriptsToProcess'
, 'PrivateData', 'RequiredAssemblies', 'ModuleList', 'FileList', 'FunctionsToExp
ort', 'VariablesToExport', 'AliasesToExport', 'CmdletsToExport'). Remove the mem
bers that are not valid ('HelpInfoUri'), then try to import the module again.
So... the answer to this lies here $psversiontable I got from within the WF
Name                           Value                                            
----                           -----                                            
CLRVersion                     2.0.50727.6387                                   
BuildVersion                   6.1.7600.16385                                   
PSVersion                      2.0                                              
WSManStackVersion              2.0                                              
PSCompatibleVersions           {1.0, 2.0}                                       
SerializationVersion           1.1.0.1                                          
PSRemotingProtocolVersion      2.1                                              
I bet calling powershell 3.0 from within WF is possible with altering the code, but I have absolutely zero knowledge on how to do that, so I'm totally stuck in here. I tried exporting PSSessions and stuff like that to no avail. I would love to hear from Craig confirming this and possibly helping me out with a patch or a workaround. ;)
ps. Sorry to be such a hassle, Craig, I really like what you've done and I use it a lot, but I just can't get over this problem without assistance.
Feb 6, 2014 at 9:17 AM
Hi, I can confirm same problem with loading ActiveDirecotry module (FIM on Win 2012). Did anybody found how to sove it?
Feb 11, 2014 at 9:43 AM
I finally found workaround for that

You can just call from your powershell script PowerShell 3.0 (with the script doing rest of the job)

powershell version 3.0 -command your_command_file.ps1
Feb 11, 2014 at 11:46 AM
Edited Feb 11, 2014 at 12:00 PM
Hello, borysm, but how do we pass variables to that powershell? I mean I'm pretty sure that's new instance of powershell so no variables will be available in that session, right?
ps. I tested your workaround and it works perfect, thank you.
Feb 11, 2014 at 11:57 AM
You can add parameters after command and read them in the inner script using arg[0] ...

Or you can do it nicely - add in the your_command_file.ps1 script at the begining:
param([guid]$TargetGuid)

then anywhere in the script you can use $TargetGuid

and then call it nice way:
powershell version 3.0 -command your_command_file.ps1 -TargetGuid $fimwf.TargetId.Guid