My goal was to restrict available roles based on a user’s EmployeeType. My “Role” objects have an attribute called “SubType” which matches the EmployeeType.  All I have to do is filter with an xpath query that references ‘%Attribute_EmployeeType%’. The same filter works for a UocListView too.

<my:Control my:Name="Role" my:TypeName="UocIdentityPicker" my:Caption="{Binding Source=schema, Path=Role.DisplayName}" my:Description="{Binding Source=schema, Path=Role.Description}">
	<my:Properties>
		<my:Property my:Name="Required" my:Value="false"/>
		<my:Property my:Name="Mode" my:Value="SingleResult"/>
		<my:Property my:Name="ObjectTypes" my:Value="Role"/>
		<my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName"/>
		<my:Property my:Name="AttributesToSearch" my:Value="DisplayName"/>
		<my:Property my:Name="Filter" my:Value="/Role[SubType = '%Attribute_EmployeeType%']"/>
		<my:Property my:Name="ResultObjectType" my:Value="Role"/>
		<my:Property my:Name="Value" my:Value="{Binding Source=object, Path=Role, Mode=TwoWay}"/>
		<my:Property my:Name="ListViewTitle" my:Value="Available Roles"/>
		<my:Property my:Name="PreviewTitle" my:Value="Selected Roles"/>
		<my:Property my:Name="MainSearchScreenText" my:Value="Search"/>
	</my:Properties>
</my:Control>

The other thing I figured out is that it is possible to pass an attribute value in the UsageKeywords property. This is an alternative method to the for UocIdentityPicker and displays the Search Scopes that have the specifed Usage Keyword.

               <my:Property my:Name="UsageKeywords" my:Value="%Attribute_EmployeeType%"/>

Note: as pointed out by Eugene below this an Edit-RCDC function only as it uses the attribute value already committed to the object. We still wait in hope for a way to dynamically scope choices based on other values chosen in the current form…

The gereral consensus on the forum has been that you need to start a new request from outside the Portal – perhaps by using a powershell script. This new request can then follow the full AuthN -> AuthZ -> Action progression. But how to trigger it?

I have now worked through this idea and it’s working, though did need quite a few policy objects in the Portal as well as the script.

The problem I needed to solve

Users need to be able to request access to a system and the access must be approved.

To simplify the user creation process in the Portal I want to include the option to request access on the user create form, but I don’t want an approval holding up creation of the person object. The person should be created and then the approval should kick off.

In fact it’s not just for convenience - the administrators of the target system need forewarning that an approved access request is coming. So they should receive info about the new person via the Sync Service, and they should also receive info about the access request. Later on when the request is approved they will of course get to see that as well.

Here’s what it looks like

So here’s what the end result is looking like in my lab. Notice I’ve pasted over some of the text as this is a customer lab with some real names in it (not Elvis obv).

I should also add I was aiming to solve this using out of the box functionality only. I could perhaps do something more elegant with custom workflows – but I’m sure my client is not the only one who prefers to avoid that.

I added an extra tab to the User Create form where the access request is made. The tab also appears on the User Edit form so you can equally request access for an already existing user.
The user is created straight away and without any approval. If I go check the Access Requests tab now I can see the access was requested, and who did it.
I then have a bit of powershell magic going on in the background. This script: detects the request, sets another attribute (“AccessApproved”) that has an Approval AuthZ workflow associated with it, and changes the request status to “Manager approval requested”.
The user’s manager receives the Approval request, which they can approve in the FIM Portal or using the Outlook client, if installed.
Now when the person’s details are checked we see their Approved status. The Sync Service does whatever needs to be done with this information.

FIM Policy Objects

I had to create quite a few policy objects to support all of this.

Powershell User

I created a dedicated user account to run the powershell script. I explicitly blocked this user from the “All People” set so it wouldn’t accidentally trigger other workflows.

Schema

I now have three attributes to handle the request:

• AccessRequested (boolean)
• AccessRequestStatus (indexed string)
• AccessApproved (boolean)

Sets

I created the following Sets:

• “Access Requested”: users where “AccessRequested” is true.
• “Access Approved”: users where “AccessApproved” is true.
• “Access Requested and Not Approved”: user in “Access Requested” and not in “Access Approved”. I use this to display the request status at this point.
• “Access Request Ready”: the state the user should be in for an access request to make sense. In my case the user is not a member of the Approved or Requested sets, but they are a member of the “All People with a Manager” set.

Workflows

I have one AuthZ workflow:

• “Request Approval”: triggers an Approval process when the “AccessApproved” flag is set by the powershell script.

And two Action workflows:

• “Set Access Status”: uses the Function Evaluator to write “Requested by [//Requestor/DisplayName]” into the “AccessRequestStatus” attribute.
• “Clear Access Request”: uses the Function Evaluator to set “AccessRequested” to “false”, and clear the “AccessReqeustStatus”. This is run after the approval and clears the request, whether it was approved or rejected.

Additionally I changed the workflow I run whenever a new user transitions in to the All People set, that sets a few default values. When working with booleans in the Portal it is always better if they have a value – null booleans have a habit of setting themselves to ‘false’ when an object is edited – sometimes resulting in “Access Denied” messages. So to this workflow I add:

• AccessRequested = IIF(IsPresent(AccessRequested),AccessRequested,’false’)
• AccessApproved = ‘false’

MPRs

“All People may request access”:

• Modify, Create and Read to attributes “AccessRequested” and “AccessRequestStatus”,
• Set before “Access Request Ready”; set after “Access Requested”,
• Action WF “Set Access Status”.

“All People may read pending access request status”:

• Read attributes “AccessRequested” and “AccessRequestStatus”,
• Target set “Access Requested and Not Approved”.

“All People may read approved request status”:

• Read attribute “AccessApproved”,
• Target set “Access Approved”.

“Powershell user can trigger Access Approval”:

• Read and Modify attribute “AccessApproved”,
• Set before “Access Requested”, set after “All People”,
• AuthZ WF “Request Approval”,
• Action WF “Clear Access Request”.

“Powershell user may set Access Request details”:

• Read and Modify attributes “AccessRequested”, “AccessApproved” and “AccessRequestStatus”,
• Target set “All People”.

RCDC

I modified the User Create and User Edit RCDCs to include the new fields. It is important to include the “my:Rights” parameter to allow the MPRs to display and hide the fields appropriately.

Email Templates

I also created some specific email templates for the Approval workflow. It is quite handy to include the AccessRequestStatus attribute in the template as it includes the name of the person who made the original request. This is something you would have with a direct approval, but is lost by having the powershell user trigger the approval.

Powershell Script

The powershell script is run under the special user account I created for it and sync’d to the Portal. It should run on a regular schedule in the background.

if(@(get-pssnapin | where-object {$_.Name -eq "FIMAutomation"} ).count -eq 0) {add-pssnapin FIMAutomation}
$DefaultUri = "http://localhost:5725"

function ModifyImportObject
{
    PARAM([string]$TargetIdentifier, $ObjectType = "Resource")
    END
    {
        $importObject = New-Object Microsoft.ResourceManagement.Automation.ObjectModel.ImportObject
        $importObject.ObjectType = $ObjectType
        $importObject.TargetObjectIdentifier = $TargetIdentifier
        $importObject.SourceObjectIdentifier = $TargetIdentifier
        $importObject.State = 1 # Put
        $importObject
    }
}

function AddImportChangeToImportObject
{
    PARAM($ImportChange, $ImportObject)
    END
    {
        if ($ImportObject.Changes -eq $null)
        {
            $ImportObject.Changes = (,$ImportChange)
        }
        else
        {
            $ImportObject.Changes += $ImportChange
        }
    }
}

function CreateImportChange
{
    PARAM($AttributeName, $AttributeValue, $Operation)
    END
    {
        $importChange = New-Object Microsoft.ResourceManagement.Automation.ObjectModel.ImportChange
        $importChange.Operation = $Operation
        $importChange.AttributeName = $AttributeName
        $importChange.AttributeValue = $AttributeValue
        $importChange.FullyResolved = 1
        $importChange.Locale = "Invariant"
        $importChange
    }
}

function SetSingleValue
{
    PARAM($ImportObject, $AttributeName, $NewAttributeValue, $FullyResolved=1)
    END
    {
        $ImportChange = CreateImportChange -AttributeName $AttributeName -AttributeValue $NewAttributeValue -Operation 1
        $ImportChange.FullyResolved = $FullyResolved
        AddImportChangeToImportObject $ImportChange $ImportObject
    }
}

function ConvertResourceToHashtable
{
    PARAM([Microsoft.ResourceManagement.Automation.ObjectModel.ExportObject]$ExportObject)
    END
    {
        $hashtable = @{"ObjectID" = "Not found"}
        foreach($attribute in $exportObject.ResourceManagementObject.ResourceManagementAttributes)
        {
            if ($attribute.IsMultiValue -eq 1)
            {
                $hashtable[$attribute.AttributeName] = $attribute.Values
            }
            else
            {
                $hashtable[$attribute.AttributeName] = $attribute.Value
            }
        }
        $hashtable
    }
}

# Find users with the trigger attribute set
$objects = export-fimconfig -customconfig ("/Person[AccessRequestStatus != 'Manager approval requested']")

# Referenced objects also returned so make sure we get one with the attribute set
foreach ($object in $objects)
{
  $hash = ConvertResourceToHashtable -exportobject $object
  if ($hash.Contains('AccessRequestStatus'))
  {
    $hash

    $importObject = ModifyImportObject -TargetIdentifier $hash.Item('ObjectID') -objecttype $hash.Item('ObjectType')
    $importChanges = SetSingleValue -importobject $importObject -attributename 'AccessApproved' -newattributevalue $true
    import-fimconfig -importObject $importObject

    $importObject = ModifyImportObject -TargetIdentifier $hash.Item('ObjectID') -objecttype $hash.Item('ObjectType')
    $importChanges = SetSingleValue -importobject $importObject -attributename 'AccessRequestStatus' -newattributevalue 'Manager approval requested'
    import-fimconfig -importObject $importObject

  }
}

And if you want to do this more than once?

I’ve shown you how to triger an authorization following a completed action, using a powershell script and a whole bunch of policy objects. In my case I actually have two types of access to request and there may be more in the future. However I couldn’t find a suitable way to roll them all into the one set of policy objects. Using a multi-value attribute to send messages to the powershell script was briefly appealing, but I had to forget it due to limitations with FIM xpath and the Function Evaluator. So for this approach, the answer for multiple request requirements is to replicate the whole system of policy objects for each case.

You should also refer to the following documents from the FIM R2 media:

• Test Lab Guide: Demonstrating Forefront Identity Manager 2010 R2 Beta Reporting
• Test Lab Guide: Installing Forefront Identity Manager 2010 R2 Release Candidate

Servers

Here’s what I’ve installed into my lab:

PreReqs

I’ll assume you already have SQL installed. I created seperate instances for FIM and System Center.

• The instance for SC needs Database, Full Text Indexing and Reporting Services.
• If you use the default collation you get a warning during installation about multi-lingual environments, so if this is an issue you will need to install with a suitable collation.

The FIM Service and Portal may already be installed, but you should not yet have installed the Reporting component.

I also disabled all the Windows Firewalls just to get it working. I’ll look into what ports I need to open up when I switch them back on later.

Install SCSM

Install System Center Service Manager on the FIM server. (Note: I don’t know that it needs to be on the FIM server – that’s just how it is in my lab).

Configure the Service Manager database
Configure the management group: Pick a suitable name for the management group  – this is some kind of system center thing and I used the name of the company (changed in the picture here to something generic). For the administrators group I added FIMSyncAdmins because it’s a lab and I was feeling lazy and it’s just being installed for FIM. Obviously IRL you would create a dedicated group.
The following two screens ask you to select accounts for service and for the workflow account. I left both on the default of Local System.There was something about the workflow account needing to be an email-enabled domain account if you want to send reports by email later on, but that’s a nicety I can come back to later.

After completing these options you should be able to proceed with the installation.

Install SCDW

Install System Center Data Warehouse Management Server onto its dedicated (or at least, seperate) server.

Straight off you may see a couple of warnings. The 8GB seems excessive for a lab. My server has 4GB configured and I’ve not seen it go above 2GB usage. The message about the hotfix may be ignored for Win2008r2. I downloaded and tried to install the patch several times and was always told that the hotfix was not applicable to my system. So eventually I googled it and, sure enough, you don’t need it on R2, even though it warns you about it!
Configure the databases – Click “Staging and Configuration” and “Data Mart” in turn and point it at the SQL server and instance – in my case hosted on the FIM server.
Here for the name I just added “FIM” after the “DW_” that was already there. And as above I was lazy and reused the FIMSyncAdmins group.
Set the details of the SQL Reporting Server to be used by SCDW. I’ve ticked the box saying I’ve taken certain manual steps  but actually I haven’t done it yet so we’ll go do that now.(Incidentally if you forget these manual steps all the DW Management Packs deploy except for the ones named “* Report Library”.)
Here’s the link where the manual steps are described: http://technet.microsoft.com/en-us/library/ff461215.aspx First you copy the file Microsoft.EnterpriseManagement.Reporting.Code.dll from the Prerequisites folder on the System Centre DVD to the ../ReportServer/bin folder relevant to your named instance of SQL (more details about how to find this folder in the technote).
Then there’s a piece of XML to be pasted into the ../ReportServer/rssrvpolicy.config file. You don’t need to modify the XML, but you do need to copy it at the same level as the other CodeGroup nodes. While it doesn’t say in the technote, there is a comment at the bottom saying you should restart Reporting Services, which sounds pretty sensible.
Now back to the SCDW installation – specify a domain account to run the service. This account needs to be a local Administator on the SCDW server.
I just used the same account for the reporting account. Again not sure if this is a good or bad idea, but it’ll do for now.

Now you should be able to click Install and let the installation run.

Register the DW server with SCSM

Next you have to register the SC Data Warehouse Management Server with SC System Manager.

Run the System Center Service Manager Console and, on the Administration page, click on “Register with Service Manager Data Warehouse”.
Enter the name of the SCDW server.
Here I just accepted the default, even though the accountname doesn’t look familiar - I guess it maps to the service account because it seems to work.

The last step is just to click Create and the registration should complete.

Wait for the Management Packs to finish deploying

The first time I installed I had a lot of trouble with DW jobs seemingly never finishing and no data appearing in the reports. So the second time through I made sure each step completed without errors before continuing on.

In the System Center console, if you open Data Warehouse -> Management Packs, you should see a list of Management Packs. Wait until all of them have “Completed” as their Deployment Status.

If any come up as “Failed” then troubleshoot that before proceeding. Note that when looking for error messages you have to go into the Operations Manager event log on the Data Warehouse Management Server - and not the server where you’re running the console.

Install the Reporting component of FIM R2

If you don’t yet have the FIM Service and Portal installed, install it now, selecting the FIM Reporting option.If it is already installed, go to Control Panel / Uninstall a Program. Select “Forefront Identity Manager Service and Portal” and choose “Change”.
Enter the name of the server where you installed SCSM (the FIM server in my lab). If you get a warning about a hotfix go and install it.

Otherwise just configure as appropriate for your environment and complete your Portal re/installation.

Run the DW Configuration Script

There’s a script in the FIM R2 installation media you need to run to set things up correctly. It’s called FIMPostInstallScriptsForDataWarehouse.ps1 and you’ll find it in the “Data Warehouse Support Scripts” folder which ius located in FIM_R2_RC_TechNet_Docs.zip (a seperate download to the installtion files).You have to enter the DataWarehouseServerInstance which is actually asking for the SQL instance where the DW databases are - so here I’ve entered localhost\SCDW. The FIMServiceAccountName is simple enough – the account running the FIM Service.

Run the FIM powershell cmdlets to create Report objects

The reporting data is exported by a workflow that is triggered by the creation of Reporting Job objects in the FIM Portal. There are a couple of powershell cmdlets that do this for you.

First run the Start-FIMReportingInitialSync script. If you haven’t already done so you’ll need to add the FIMAutomation pssnapin.
Now go into the FIM Portal and check the Reporting Job object was created. In Adminstration -> All Resources locate the object class msidmReportingJob. Click on “Reporting Job” to view all objects of this type.
You should see a job of type “Initial”. Open it and check it’s properties to see the status of the job. First it will be “Running” and then “Completed”. If the job fails then you will have some troubleshooting to do.
Next run the cmdlet Start-FIMReportingIncrementalSync script. This does the same sort of thing - creates a Reporting Job object in the Portal.It is this cmdlet that you will need to schedule to run periodically.

Wait for DW Jobs to complete

You won’t see any data in the reports until the following Data Warehouse Jobs have completed:

• Extract_MyName
• Transform.Common
• Load.Common

In the FIM doco there’s a section showing you how to create a script called ETLScript.ps1 that forces these jobs to run straight away. However in my environment the first two scripts are set, by default, to run every 5 minutes, and the last one runs once an hour. So you can either run the script, or wait an hour or so and then find data in the reports.

I found the following powershell cmdlets useful while I was waiting for the pot to boil. They have to be run on the SCDW Server.

• Get-SCDWJob
• Get-SCDWJobModule
• Get-SCDWJobSchedule

You have to add the pssnapin SMCmdletSnapIn first.

View Reports

All going well you should eventually see some data in the reports, which can be viewed in the SC Service Manager Console under Reports.

However Alex’s script uses Excel which I don’t have installed in my lab and don’t really want. So I’ve taken his source lists and his concept and written a little powershell script to do much the same thing.

You can download it from here.

When creating an Outbound Sync Rule now you are offered the enticing option to use an “Outbound System Scoping Filter”:

And now, instead of mucking around with Sets and MPRs, I can set a simple rule which says which objects I want this to apply to.

And it works!

The other thing that hasn’t appeared to clutter up my Metaverse is any EREs, though the DREs are still generated.

All up a definite improvement!

I guess this shows I haven’t used the migration scripts all that much, because I didn’t realise they would start deleting all the new schema attributes to do with reporting!

So now I know: don’t use the FIM migration scripts between versions.

At first I was just killing these tasks and then the Sync Service Manager would run properly, but then I started working with the Portal as well – and I noticed that, increasingly, I was getting 503 Service Not Available errors when I tried to access the Portal.

The first couple of times it happened I reinstalled the Portal by using the “Change” option in Add/Remove Programs. This got it working again -  but before long I’d have to restart the Sync Service Manager, I’d get that whole thing with Microsoft.IdentityManagement.SolutionPackUtility.exe again, and immediately after an inaccessible Portal with 503 errors. Clearly the two problems were linked!

Eventually I solved the problem by reinstalling Sharepoint. I had to completely uninstall WSS and the Windows Internal Database. I then reinstalled WSS and the FIM Service and Portal. I used my original FIMService database so I didn’t lose any of my work.

I did see Tim’s post on the technet wiki with a similar sounding problem but I didn’t see the job definition in Sharepoint that he mentions, so it wasn’t exactly the same root cause.

I made this recording as an emergency backup for a session I gave at TEC, in case of laptop implosion or other unforseen disaster. So it’s not particularly professional and in fact a bit rubbish in places (there must have been some “zoom to mouse” setting so I’m afraid there’s a couple of nice long shots of the corner of the screen), however I’ve decided to share it as an example of some of the useful things you can do with the FIM Portal.

Note also that the demo shows my lab environment, but much the same configuration is currently running in a production environment with over 20,000 user objects being managed, and from what I hear, still going strong several months after I left that part of the world.

(Video: Watch this video on the post page)

My first post was on the 18^th of May 2007. I’d been working with MIIS for about two years and found it both heavy going and completely absorbing – in fact I was obsessed! I was also on the verge of a big move: London to Geneva via 3 months in Australia. I started the blog as a memory-aid for myself, as something that might help my employment prospects in Geneva, and of course with the thought that it might help out others, just as I have always found great tips and explanations on other people’s blogs.

So, 4½ years in, what can I say about missmiis?

Content

• I’ve stuck to my original intention of posting only what I’ve actually done myself – with any theorising or speculation noted clearly,
• I also try to post only what can’t easily be found elsewhere – at least, I couldn’t find it.
• If someone else’s blog post or forum entry has helped me I acknowledge and link it.

Reader Stats

My stats don’t go back to the very beginning, but I definitely can say readership has climbed steadily, except for the year following the Great ILM2 Delay. You can see pretty clearly when that was from looking at my stats!

Posts of Note

• A GALSync powershell script because it is far and above my most popular posting ever.
• Powershell Activity because, while no great piece of code, it represents when I finally understood how to develop a custom activity – the usual minimalist MS documentation having left me mostly in the dark.
• ILM 2 release date put back – A WHOLE YEAR! This was the post where, without realising it, I “broke” the news on the internet. This was actually my most-read post for quite some time, especially considering the readership dive that followed.
• Exchange 2007 Cross-Forest Migration Up until about 18 months ago I was still working as an Exchange, as well as FIM, consultant. There just wasn’t enough FIM work to keep me fully occupied (there is now!) This is my most-read Exchange post.

What this blog has given me

• A convenient place to put stuff so I know where to find it,
• Speaking opportunites, starting with TechDays Geneva 2008 where I presented ILM 2007,
• Three MVP awards,
• The chance to meet some great people, and
• A job!

And why is the blog still named after an eight year old product?

No reason I should rename my blog every time Microsoft rename their product.

However, even if I don’t use it, I have permanent dibs on FIM fatale.