Querying for Pending or Finished FIM Requests

Just a follow-up to a previous post.  Here are two sample FIM XPath filters based on the RequestStatus values.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031

### ### Find pending requests ### $xpathFilter = @" /Request     [             RequestStatus != 'Denied'         and RequestStatus != 'Failed'         and RequestStatus != 'Canceled'         and RequestStatus != 'CanceledPostProcessing'         and RequestStatus != 'PostProcessingError'         and RequestStatus != 'Completed'     ] "@ $requests = Export-FIMConfig -CustomConfig $xpathFilter ### ### Find finished requests ### $xpathFilter = @" /Request     [            RequestStatus = 'Denied'         or RequestStatus = 'Failed'         or RequestStatus = 'Canceled'         or RequestStatus = 'CanceledPostProcessing'         or RequestStatus = 'PostProcessingError'         or RequestStatus = 'Completed'     ] "@ $requests = Export-FIMConfig -CustomConfig $xpathFilter

News on FIM Plans for Cloud Integration

At its core, FIM is just an integration tool, and identity management has always been about the applications.  This is an exciting time for FIM and identity management because ‘to the cloud’ seems to be great motivation to drive change into applications that are normally really hard to change.

My overall take is:

1. Federate where you can
2. Synchronize where you must

But it is never this simple, and tools like FIM will always be required so it is good to hear that Microsoft has plans for FIM to make cloud integration easier.

To me this is analogous to FIM’s early days when Active Directory was the big push, and FIM (then called MMS) was used to accelerate the adoption of Active Directory by getting application data into the DS thereby making it a reasonable target for other applications (remember directory-enabled applications?).  If I ruled the world (or at least a significant amount of Microsoft) then I’d again position FIM in this way, only this time using it to accelerate adoption of Azure/Office365 by easing eliminating the pain of the hybrid enterprise.

Anyhow, maybe the new article above is an indication of Microsoft moving FIM in this direction.  Time will tell, at least until I rule the world.

FIM Service RequestStatus – What Are All the Possible Values?

I’m writing a small function to tell me when a FIM Request has completed, so need to know the possible status values of a FIM Request.  Some digging around in Visual Studio using Class View unearthed an Enum for this in the FIM DLL.

The PowerShell one-liner below will display all the possible Request status values (called RequestStatusType).

 

001	[Enum]::GetNames([Microsoft.ResourceManagement.WebServices.WSResourceManagement.RequestStatusType])

Below are the results of the one-liner, showing all the possible FIM Request status values.  HINT: the highlighted ones represent a FIM Request is that is done (can’t reach any other status).

• Denied
• Validating
• Canceling
• Validated
• Authenticating
• Authenticated
• Authorizing
• Authorized
• Failed
• Canceled
• Committed
• CanceledPostProcessing
• PostProcessing
• PostProcessingError
• Completed
• NotFound

Convert a FIM ExportObject to a PowerShell PSObject

Working with the output from Export-FimConfig is not always fun because you have to dig hard to get attributes off an object.

This function I just whipped up will convert a FIM ExportObject to a PowerShell PSObject.  The advantage here is that you can then use dot-notation <sp?> to dig out the attributes.

For example the Export-FimConfig used like this produces the output below.

001	Export-FIMConfig -CustomConfig "/Person[AccountName='hi']"

Source : http://localhost:5725/ResourceManagementService
ResourceManagementObject : Microsoft.ResourceManagement.Automation.ObjectModel.ResourceManagementObject

Source : http://localhost:5725/ResourceManagementService
ResourceManagementObject : Microsoft.ResourceManagement.Automation.ObjectModel.ResourceManagementObject

Now using the fancy new function we get:

001	Export-FIMConfig -CustomConfig "/Person[AccountName='hi']" | Convert-FimExportToPSObject

ObjectID            : urn:uuid:caf0178b-b8c1-41b2-bd71-f2f48b1fdf3b
AccountName         : HI
CreatedTime         : 7/8/2011 6:02:50 AM
Creator             : urn:uuid:7fb2b853-24f0-4498-9534-4e10589723c4
DisplayName         : HoofHearted IceMelted
Domain              : africa
FirstName           : HoofHearted
IsRASEnabled        : True
JobTitle            : Sheller
LastName            : IceMelted
MailNickname        : HI
ObjectType          : Person

In addition, it is easier to get at the attributes for each object:

001 002 003 004

$person = Export-FIMConfig -CustomConfig "/Person[AccountName='hi']" |      Convert-FimExportToPSObject $person.DisplayName $person.AccountName

HoofHearted IceMelted

HI

Finally, here is the function:

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029

Function Convert-FimExportToPSObject {     Param     (         [parameter(Mandatory=$true, ValueFromPipeline = $true)]         [Microsoft.ResourceManagement.Automation.ObjectModel.ExportObject]         $ExportObject     )     Process     {                $psObject = New-Object PSObject         $ExportObject.ResourceManagementObject.ResourceManagementAttributes | ForEach-Object{             if ($_.Value -ne $null)             {                 $value = $_.Value             }             elseif($_.Values -ne $null)             {                 $value = $_.Values             }             else             {                 $value = $null             }             $psObject | Add-Member -MemberType NoteProperty -Name $_.AttributeName -Value $value         }         Write-Output $psObject     } }