none
FIM PowerShell Extension

    General discussion

  • I just wanted to share this with the community as I have found it extremely powerful in implementing FIM. It is a FIM extension that runs PowerShell scripts for the IMVSynchronization and IMASynchronization interfaces. I have example scripts and what I think is enough documentation to get people started assuming they are familiar with the concepts of those two interfaces.

    I'm also looking for feedback. I have been using this (in many cases instead of code-less portal sync rules) in a pre-production environment for 2 months. I plan to roll it into a full production (40k user objects) environment in the next month.

    http://fim.codeplex.com 

    Friday, July 01, 2011 8:04 PM

All replies

  • Interesting...

    PowerShell vs C#/VB knowledge aside, what's the value prop here?


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com
    Saturday, July 02, 2011 12:49 AM
  • I just <3 powershell :)

    Really though, PowerShell was way easier teaching my team of windows sysadmins vs c#/vb fundamentals let alone the VS IDE. Getting development to own code in FIM would also be a struggle as we don't have an I.T. centric group of coders (they are divided by business unit mainly for all business units except I.T.!!). So, with this simple extension, now our sysadmins can understand some of the more complex provisioning processes within FIM without understanding a lot about .NET.

    Compiling code every time I want to tweak something just seems odd, plus usually having VS on a server that is running FIM, even a test server, is not something as a sysadmin i approve of; though I just copied the dll from the installer to use as a reference for the build of the extension on my workstation.

    I would imagine MS could integrate PowerShell or extensible code-less provisioning into the FIM portal and reduce the need for extensions all together, but until then, this is a way easier option at the moment, especially for deploys that don't require FIM portal.

    Tuesday, July 05, 2011 12:24 PM
  • This looks interesting, but, also opens the door too easily to do things to your connected directory that should be happening during export. I would be very careful with this.
    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM
    Tuesday, July 05, 2011 8:35 PM
  • Monday, January 16, 2012 2:04 PM
  • I like the idea of the PowerShell module a lot, because I do something similar, because there is already code like this on TechNet, and because there are probably a LOT of people doing the same thing.  The challenge is: how do we (or do we at all?) make one a community winner?  This is a good problem to have, since it means there are a lot of people doing cool things.


    CraigMartin – Edgile, Inc. – http://identitytrench.com
    Monday, January 16, 2012 4:04 PM
  • I really tried to use what was out there. The TechNet stuff was my source for how to do it, though it wasn't very PowerShell-ish, which is why I wrote what I did. I also liked the Quest PowerShell cmdlet, except that it was a snapin and required additional unsupported dlls/client. I added the stuff I found myself doing often with both FIMAutomation and the WMI classes. Honestly, I think what I have now should be baked into FIMAutomation ...

    I also love codeless sync rules, but as soon as I hit my first complex scenario it couldn't handle it wasn't long before I had two or three scenarios being handled by extensions. Then the whole mess of where is that being sync'd from was very problematic trying to explain the system to my team mates, so i opted for everything in the extension and ditch the sync rules. So far, I am happy, but we've only been sync'ing and growing for about 6 months now.

    There are so many areas in FIM where it could just be great if they'd let it be slightly more open for the community to provide the advanced components of the system, e.g. function evaluators, rcdc controls, sspr automation, xml/filter expressions.

    Monday, January 16, 2012 7:30 PM
  •  

    This one is very usable. We use it to create home folders, mailbox and custom tasks.

    There are some pre requisitions involved:

    1. The RUN-As question. Powershell use the FIM Service account or the requestor. We chose to use the FIM service account. So he had to become member of Domain Admins.

    2. The FIM service account must be present in the portal, otherwise the script execution fails. We placed it in the FIM OU's. Now we must be careful not to delete or disable it.

    3. The script must be triggerd only when users are already present in the AD. We chose to create a set, based on 'ObjectSID is present'. This way we are sure the user is present in the AD. Then we use 'Transition in' to trigger scripts.

    It;s a;st possible to use code to introduce all available attributes  into the script. It will be handy when a lot of variables are in use.  Here it is:

    # Simplifying the FIMAutomation snap-in: PsExportObject
    # The FIMAutomation PowerShell snap-in is a very useful tool to automate administrative tasks, as it allows you to perform queries and create, modify and delete objects in FIM. Check the FIM Scriptbox page on TechNet for many examples of what you can do with the snap-in.
    #
    # The only problem with the tool, however, is that it was conceived primarily to migrate the FIM configuration from one server to another, and the syntax for manipulating objects with it is not really straightforward. This example shows how to read the attributes of a user:
    #
    # $user=Export-FIMConfig -CustomConfig "/Person[AccountName='jdoe']" -OnlyBaseResources
    # foreach ($attribute in $user.ResourceManagementObject.ResourceManagementAttributes) {
    #     $name=$attribute.AttributeName
    #     if ($attribute.IsMultiValue) {
    #         $value=$attribute.Values
    #     } else {
    #         $value=$attribute.Value
    #     }
    #     "$name = $value"
    # }

    # This is not terrible either, but it's quite a lot of typing, especially if you are not running a script but just running commands in the prompt. This other example shows how to get a particular attribute, e.g. the DisplayName:

    # $user=Export-FIMConfig -CustomConfig "/Person[AccountName='jdoe']" -OnlyBaseResources
    # $displayName=$user.ResourceManagementObject.ResourceManagementAttributes | Where-Object {$_.AttributeName -eq "DisplayName"}
    # $displayName.Value
    # It would be nice to have a way to manipulate an ExportObject in a simpler way. This can be done using PowerShell's capability to extend objects. This filter will convert an ExportObject to a PSObject:

    #PsExportObject

    function PsExportObject() {
        process {
            $importObject = $_
            $psObject = New-Object PSObject
            foreach ($attribute in $importObject.ResourceManagementObject.ResourceManagementAttributes) {
                $name=$attribute.AttributeName
                if ($attribute.IsMultiValue) {
                    $value=$attribute.Values
                } else {
                    $value=$attribute.Value
                }
                Add-Member -InputObject $psObject -MemberType NoteProperty -Name $name -Value $value
            }
            $psObject
        }
    }

    # We can use the filter simply piping the results of Export-FIMConfig to it:

    # PS > Export-FIMConfig -CustomConfig "/Person[ObjectID='$TargetID']" -OnlyBaseResources | PsExportObject
    # ObjectID                   : urn:uuid:b8144b57-5bac-4a29-b6f1-b36914d194c0
    # AccountName                : jdoe
    # Company                    : FIMTEST
    # CreatedTime                : 6/10/2010 2:57:00 PM
    # Creator                    : urn:uuid:fb89aefa-5ea1-47f1-8890-abe7797d6497
    # DisplayName                : John Doe

    # And now, we can access the user's properties with a more intuitive syntax:

    $user=Export-FIMConfig -CustomConfig "/Person[ObjectID='$TargetID']" -OnlyBaseResources | PsExportObject

    # Now we can use all attributes

    $user.DisplayName > c:\log.txt
    $user.AccountName >> c:\log.txt

    # Etc.


    GH

    Tuesday, February 14, 2012 1:51 PM
  • Funny, we arrived at the same approach:

    Convert a FIM ExportObject to a PowerShell PSObject


    CraigMartin – Edgile, Inc. – http://identitytrench.com

    Tuesday, February 14, 2012 9:56 PM
  • Hi Guy,

    Since that is taken from my blog, a link to the original article would be nice: http://espace.cern.ch/idm/Lists/Posts/Post.aspx?ID=31

    Cheers,
    Paolo


    Paolo Tedesco - http://cern.ch/idm



    Wednesday, February 15, 2012 1:03 PM