Monday, November 23, 2009

Darryl Russi's Blog : Service Partitions - Multiple Middle Tiers, Request & Workflow Processing

This was already picked up elsewhere whilst I was out on vacation but I still had to add my "way cool" for the extra detail. Thanks Darryl!

With RC1 Update 1 we can start to see some of the dedication the product group has been talking about over the past year to ensure greater scalability in large environments. With the new service partitions it allows you to rollout portals focused at specific user segments which addresses portal response issues that were rampant before. Addressing the performance perception from end users is critical and should not be undervalued as there is nothing that will sink a project quicker than poor reception from your user community. Terms like "sluggish", "slow", or phrases like "it timed out when I tried to do x" makes it quickly through management and all of the sudden your big investment is cast aside.

Mark my words, features like this will drive better long term adoption and uptake in enterprises.

The next bottleneck to address then becomes the single SQL Server instance which all of the service partitions run against; however, I doubt this will be addressed in this version of the product. Perhaps the ILM "3" candidate (still in early planning stages) will seek to address this by adding capabilities to partition the FIM Service Database as well. Until then, you need to scale UP your SQL Server investment for FIM 2010 Service Database.

Darryl Russi's Blog : Service Partitions - Multiple Middle Tiers, Request & Workflow Processing

Thursday, November 12, 2009

FIM 2010 RC1.1 – Adjusting the Request Object Retention Policy

Thanks to Henrik Nilsson for this little gem – this is the first thing on your list of things to do after installing FIM 2010 in your test environment. Follow these instructions to adjust how long Request objects will be retained in the system.

System Resource Retention Configuration

This is a special resource type in the portal that allows you to adjust how long request objects linger in the portal. Nothing will clog up your database and fill your drives like millions of request objects sitting around for 30 days (the default). And make no mistake, you will end up with millions of objects in a few short days or weeks depending on the item count you're working with. You find your way here by navigating to Administration/All Resources/System Resource Retention Configuration. Once there you'll see the object we're after:

As you can see from my example, I've already adjusted this to two days from the default of thirty. What you will notice if you click on this object is that you are not allowed to change the value yet! We first have to create a policy that allows members of the Administrators set to modify the value we need.

Creating the Management Policy Rule

Ok, you're going to create a new Management Policy Rule with the following specifications:

  • Display Name: Administration: Administrators can update system resource retention service objects
  • Description: Allows members of the Administrators set to adjust the policy for request object retention
  • Permissions: Grants Permission
  • Requestors: (Specific Set of Requestors) Administrators
  • Operation: Modify a single-valued attribute
  • Target Resource Definition Before/After Request (same): All System Resource Retention Configurations
  • Resource Attributes: (Select specific attributes) Retention Period in Days

Once you're done, go back and click on the configuration object, now you should be able to adjust the value:

Once you submit the change, all new requests will have a 2-day expiration, whereas any previous requests will have the 30-day default. Observe:


Notice that even the request to update the policy is stamped with the new policy. I am on a quest to understand exactly how they expire and if there is anything you can do to speed along old requests. There are a few promising looking stored procedures, but those could be very dangerous to an active system.

Wednesday, November 11, 2009

FIM 2010 RC1.1 – Customizing the Request Object RCDC

One of my frustrations is tracing down the target of a request and in some cases, the parent request that caused this request to be generated. The default RCDC doesn't expose these values except within the Advanced View/Extended Attributes tab. Having the Applied Policy tab is great to see what policies this request triggered, but being able to see the target and parent request is essential – so here's how to add it yourself. At the end we'll have two new controls:

Here we see the Target revealed on the Detailed Content tab, we now know we had a Modify operation to a Person object type and the target was Smith, John; we can even click the hyperlink here and go look at the current status of John's object.

Here we see on the Applied Policy tab we've added the link to the Parent Request, also hyperlinked. In this example a Workflow configured for "Run On Policy Update" triggered a series of System Event Requests which we can examine in more detail.

After clicking the link we see the policy that was updated which caused this sequence of events – nifty right?
This should all be by default right? Vote here if you're signed up for the FIM Connect site.
Ok, so how do you do this yourself – it's pretty easy. I would strongly recommend applying the Update 1 packages prior to doing this as any updates has the chance of overwriting any of your customizations. So, I'll show you how to add the sections manually and provide the entire file for your consumption as well.


When editing RCDC configurations, it's always recommended to Export the current configuration and save it as an Original copy. If you get into trouble you should restore the original version, edit a copy and use the copy to upload.

Adding the Target control to the Detailed Content tab

Insert the new TargetID control between the TargetObjectType and SummaryControl controls like so:
<my:Control my:Name="TargetObjectType" my:TypeName="UocLabel" my:Caption="{Binding Source=schema, Path=TargetObjectType.DisplayName}" my:RightsLevel="{Binding Source=rights, Path=TargetObjectType}">
<my:Property my:Name="Text" my:Value="{Binding Source=object, Path=TargetObjectType, Mode=OneWay}"/>
<my:Control my:Name="TargetID" my:TypeName="UocHyperLink" my:Caption="{Binding Source=schema, Path=Target.DisplayName}" my:Description="{Binding Source=schema, Path=Target.Description}" my:RightsLevel="{Binding Source=rights, Path=Target}">
<my:Property my:Name="ObjectReference" my:Value="{Binding Source=object, Path=Target, Mode=OneWay}"/>
<my:Control my:Name="SummaryControl" my:TypeName="UocHtmlSummary" my:Caption="%SYMBOL_RequestContentCaption_END%" my:Description="%SYMBOL_RequestContentDescription_END%" my:ExpandArea="true">
<my:Property my:Name="ModificationsXml" my:Value="{Binding Source=requestDetails, Path=DeltaXml , Mode=OneWay}"/>
<my:Property my:Name="TransformXsl" my:Value="{Binding Source=RequestDetailTransformXsl, Path=/, Mode=OneWay}"/>

Adding the Parent Request control to the Applied Content tab

Insert the new ParentRequestObj control between the Policy grouping and the PolicyList control like so:
<my:Grouping my:Name="Policy" my:Caption="%SYMBOL_PolicyTabCaption_END%">
<my:Help my:HelpText="%SYMBOL_PolicyTabHelpText_END%" my:Link="cb9dbf88-0045-4e1e-ae3a-a2449ea7095a.htm#bkmk_grouping_Policy"/>

<my:Control my:Name="ParentRequestObj" my:TypeName="UocHyperLink" my:Caption="{Binding Source=schema, Path=ParentRequest.DisplayName}" my:Description="{Binding Source=schema, Path=ParentRequest.Description}" my:RightsLevel="{Binding Source=rights, Path=ParentRequest}">
<my:Property my:Name="ObjectReference" my:Value="{Binding Source=object, Path=ParentRequest, Mode=OneWay}"/>

<my:Control my:Name="PolicyList" my:TypeName="UocListView" my:Caption="%SYMBOL_PolicyListCaption_END%" my:Description="%SYMBOL_PolicyListHint_END%" my:ExpandArea="true" my:RightsLevel="{Binding Source=rights, Path=ManagementPolicy}">
<my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName,GrantRight,AuthenticationWorkflowDefinition,AuthorizationWorkflowDefinition,ActionWorkflowDefinition"/>
<my:Property my:Name="UsageKeywords" my:Value="ManagementPolicyRule"/>
<my:Property my:Name="ResultObjectType" my:Value="ManagementPolicyRule"/>
<my:Property my:Name="TargetAttribute" my:Value="ManagementPolicy"/>
<my:Property my:Name="SelectedValue" my:Value="{Binding Source=object, Path=ManagementPolicy, Mode=OneWay}"/>
<my:Property my:Name="EmptyResultText" my:Value=""/>
<my:Property my:Name="PageSize" my:Value="10"/>
<my:Property my:Name="ShowActionBar" my:Value="false"/>
<my:Property my:Name="ShowPreview" my:Value="false"/>
<my:Property my:Name="ShowSearchControl" my:Value="false"/>
<my:Property my:Name="ShowTitleBar" my:Value="true"/>
<my:Property my:Name="EnableSelection" my:Value="false"/>
<my:Property my:Name="SingleSelection" my:Value="false"/>
<my:Property my:Name="ItemClickBehavior" my:Value="ModelessDialog"/>
<my:Property my:Name="ReadOnly" my:Value="true"/>
<my:Property my:Name="ListViewItemHandler" my:Value="PolicyItemHandler"/>

Build 2570 (Update 1) Files

Remember to iisreset if you can't wait for the cache to refresh.

Monday, November 02, 2009

FIM 2010 RC1 – Resolving the Duplicate SynchronizationRule RCDC

In the FIM release notes it advises you to adjust the "Applies to Create" setting for one of two Resource Control Display Configuration (aka OVC) objects that share the same Display Name; however, it doesn't tell you how to determine which one to change. You need to do this IF you are exporting and importing your configuration between systems (the source of yet another topic).

RC1 looks like this by default:

We need it to look like this:

…but how do you know which one to change? Both are set to apply to Create, Edit and View, but only one should be Create while the other should be only Edit and View.

  1. Click the first entry hyperlink and then Export Configuration, when prompted, just click Open, we're not going to change anything
  2. On the definition for the Panel/Grouping control you will see one of two entries:

For this object, uncheck Applies to Create.


For this object, uncheck Applies to Edit and Applies to View.

That's it!

Newer Posts Older Posts Home