Searching is cumbersome and I’ll have to specify multiple possible MPR attributes. It’s also no good if I want to review a number of Sets or Workflows at once.

So what I decided to do was write a script which updates Set and Workflow objects with a list of the MPRs using them. I started out with the Description field but quickly ran up against the length limit, so instead I created a new unindexed string attribute called “ReferringMPRs”, which I bound to both the Set and WorkflowDefinition object types. I’ve added this attribute to the Search Scope definitions so it’s easy to see:

Next I wrote a script which I schedule to run once a week. It updates the ReferringMPRs attribute on each Set and WorkflowDefinition with the list of MPRs referencing it. Note I don’t differentiate on where the MPR is using the object – ie I don’t care which phase the Workflow runs in, or which role the Set is performing. When trying to figure out what a Set or Workflow is used for I often won’t need this level of detail – it’s enough to know that the MPR is using it somehow. You are of course welcome to take the script and modify it if you think it should do more.

On a suggestion from my colleague Pete Wass I added an extra function to the script. If you feed it a folder name it will create a datestamped report in that folder if it finds differences in the list of referring MPRs.

You can grab a copy of the script from the FIM Team Scripts site.

I created a new Search Scope, absolutely certain the usage keywords and permissions are all correct, and the thing just won’t appear, no errors, nuthin.

My problem was entering the “Attribute Searched” list of attributes in the same way as the “Attribute” list – ie semi-colon separated rather than on seperate lines. Am I the only one who finds it confusing that these two very similar fields must be filled in in a different way?

We’ll be putting various goodies on this site that we want to make publicly available and the other thing you’ll find there right now are the tools to set up your very own Replay MA, as presented by Bob Bradley at TEC. This clever idea of Bob’s allows the Import drop file from any other MA to be replayed into the FIM Sync service via a second, LDIF MA. The main use we put this to is replaying the FIM MA, thus giving us a way to apply advanced import flow rules and manual precedence to data coming from the FIM Portal. Very neat!

No In-Place Upgrade

The platform requirements are quite different for FIM as compared to MIIS/ILM, in particular we’re now on a 64-bit platform, so it shouldn’t be a surprise to anyone that this is a migration to a new server rather than an in-place upgrade. So the first thing you will need to do is prepare your new server as described in the Installation Guide.

Migrate or Re-Design?

The first question you need to consider is this: are you happy enough with the existing  MIIS/ILM configuration to want to migrate it to FIM, or is it time to start afresh with a new design? From a simplistic, high-level POV:

Re-Design if:

• Current system has too many problems to continue with,
• Requirements have changed drastically,
• Planning on using new features in a big way.

Migrate if:

• Main goal is to get on a supported platform with minimal change,
• Some changes needed (eg., replacing an MA) but it’s not a total overhaul,
• No budget for a re-design right now.

Migration Method 1: Database Transfer

There are essentially two methods to do the migration – and the first is the database transfer method, which transfers both configuration and data.

1. Start on MIIS SP2 or higher,
2. Backup the source database (it’s recommended to clear the run history first but that’s just to reduce DB size, there’s no other technical reason),
3. Restore it to the new DB server with the name “FIMSynchronizationService”,
4. Install FIM Sync, telling it to use the restored DB, and providing the encryption keys,
• Note if you don’t have a copy of the encryption keys just export them on the old server using miiskmu.exe,
5. Transfer any supporting scripts, scheduled tasks, staging databases, log folders, and whatever else you’ve got going on around the Sync Service and forming part of its ecosystem.

You should now have a FIM Sync Service that looks remarkably like your old Sync Service. It will also have all the contents of the Extensions directory already there as copies are stored in the database.

Migration Method 2: Config Export/Import

The second method transfers configuration only:

1. Export the Metaverse and MA configurations from the source server,
2. Build your new FIM server with a new, empty database,
3. Import your Metaverse and MA configurations,
4. Transfer Extension dlls,
5. Import connector spaces from the data sources,
6. Synchronise everything – making sure projections and joins  all happen properly,
7. Transfer scripts etc.

This method has the advantage of starting with a clean database, but you  may have a lot of work to do in re-instating all those joins. Particularly if there’s a legacy of manual joins, potential duplicates, and non-existant breadcrumbing.

Combination Method

In some cases it will make sense to do a combination of the above methods. Say you want to use the new Lotus Notes MA but the rest of your MAs are fine as they are. You can use the database transfer method, but then delete and recreate the Notes MA on the new server. In this way a good proportion of your data and joins stay in place, and you just need to worry about re-importing and re-joining where it’s really necessary.

Which Migration Method?

After having used both methods (actually, all 3 if you count “combination” as a seperate one) my advice is to go with the database transfer as the first option. You will save time on re-importing and, most importantly, retain your existing joins.

There may be times when a config migration is a better bet. Perhaps the data in the Metaverse is in such a state (orphaned objects, bad joins, duplicates) that a good clean out is called for. Or perhaps you’re migrating some MAs and retiring others. Clearly you’ll have to assess the situation before deciding which method suits best.

Recompiling Extensions

For a long time I thought you had to recompile the extensions. But I was wrong – you don’t have to recompile.

The doco says “recommended” but only for “performance reasons if you did not originally compile them to be platform independent”. By default the code should have been compiled to be platform independent so there is no problem running the 32-bit extensions. In addition, to debunk a couple of things I’ve read on the forum, you can recompile them using the Microsoft.MetadirectoryServices.dll on the new x64 server, and you can attach the debugger.

So my advice is try them and see. They may work just fine without any need to recompile to x64.

I will make one point about CSExtensions – I have a couple of XMAs on FIM that I now seem to have to run in process where they used to run fine out of process. So if you’re getting a stopped-extension-dll-load error it is worth making sure you have the “in process” option ticked.

Full Syncs

The official doc says full syncs following migration is a “good practise”. Personally I would say it is essential. How can you really verify that everything is working properly if you don’t do full syncs? Problems to look out for however:

• Environments where full syncs take days to run,
• MAs that are never full sync’d for various reasons – perhaps because they’re running external processes from MV or MA extensions, or because they’re doing some time-based logic which relies on only ever doing deltas. These are of course terrible design, but that doesn’t mean they don’t happen, and that some hapless sod won’t be called in to migrate them.

For my own peace of mind, I would want to run Full Syncs with the provisioning code turned off and then on before I declared “job done”.

Password Sync

There’s not a lot to say about migrating password sync because it should be pretty straight forward. It’s not essential to upgrade PCNS on your DCs. When you switch the PCNS target to the new Sync server there may be a delay while the change replicates around your AD sites, but in the meantime the old server can still be servicing password sync, even if you’ve stopped all the scheduled jobs.

Migration Plan

Sometimes customers ask about a progressive migration; migrating a couple of MAs at a time. They perhaps think this would reduce risk and complexity but I think just the opposite. It greatly increases risk as I now have to meddle with the old server and could inadvertently break something there. I have to gain a much deeper understanding of the configuration to work out how to safely extract a subset of MAs. I have essentially doubled my workload while taking on responsibility for two servers instead of one. Not a path I’d gladly take.

So the preferred path is to do a full migration to the new server, get everything working there, and then switch functionality in one go.

Helper Scripts

I’ve written a bunch of scripts to help with the pre-migration analysis, any CS reimporting that might happen during the migration, and then validating the job at the end. You can download a copy of them here.

Most fun helping out a fellow MVP

I arrived a couple of days early so was able to do a run through of Craig Martin’s half-day workshop on managing FIM with PowerShell. Craig claimed to be worried about the labs and the text and whether there was enough and whether it would work…. I don’t know why because he’d clearly put enourmous amounts of effort into it and the payoff was an incredibly useful, practical learning experience for the attendees. Great work Craig, and I hope you get to deliver it again!

Coolest FIM Ideas

FIM is not the most fashionable of products, but these sessions did really make everyone sit up and say “now that is cool!”

Eihab Isaac’s replacement for selected RCDC forms

When I’ve heard talk of designing a web form to replace the underwhelming user experience of the FIM Portal I imagined something completely seperate to the Portal. The genius of Eihab’s solution is that he is selectively replacing RCDC-based forms, while still using all the other functionality of the Portal. The forms are actually hosted on IIS outside the Portal, and communicate with the Portal via web services, but to the user they appear seamlessly integrated. So when you click the “New User” button you get what we all wish would pop up – a form with immediate data validation including helpful messages to the user, dynamic modification of controls and drop-down lists based on other options chosen, and a wider variety of controls than we get in the RCDC.

At the same time he also solved the problem of allowing an Approver to go in and modify some details before approving – now that is cool!

For more info talk to the lovely people at Zeva.

Rob Allen’s FIM phone app

Rob demonstrated a pair of impressively snazzy looking apps, for iPhone and Windows mobile, that allow FIM tasks such as approving a request, resetting your password, and adding a user to a group. Both apps are available on their respective app stores (look for “FIM Mobile”) if you want to take a look. Unfortunately I have Android so will have to wait until Rob and the other clever boys at ActiveIDM write one of those too.

Bob Bradley’s Replay MA

Bob is my colleague at Unify, and I even had a hand in this presentation, so including this does seem a little self-congratulatory – but it is a really cool idea! Essentially Bob takes the import drop file from FIM MA import jobs (full and delta), converts them to LDIF using an XSLT stylesheet, and feeds them back into the Sync Service via a second MA (the “Replay MA”). This is a completely normal (albeit import-only) MA to which you can apply advanced import flow rules and manual precedence rules to data generated in the FIM Portal. The number of people sitting there saying “now why didn’t I think of that?!” made me laugh – the simplest ideas are often not self-evident at all.

There will be more details on this coming soon, including the scripts and stylesheets.

Most fun dissing a fellow MVP

You have to hand it to David Lundell for being a great sport. His “Declarative vs Classic” FIM showdown was always going to be controversial, but then to try and claim that declarative was the winner??? Clearly he was just trying to wind us all up   I think everyone had a lot of fun in that session.

Weirdest 1am conversation

Those Powershell dudes can talk PowerShell any time of the day or night. This is the second year running I’ve ended up in some kind of intense PowerShell related conversation, including whipped-out laptops and kamikaze demos, at well past the time I should have been in bed. This year I was hearing all about James Brundage‘s mad-scientist type plans to take over the entire world using his PowerShell super-powers… at least the websites for starters. Gotta love all that crazy passion and inspiration!

R2 Snippet of the week

It was all a little light-on for R2, and in particular I think a lot of us would have appreciated a session from Microsoft on the BHold aquisition and integration… but there was one excellent little snippet in Eric Huebner’s talk. Apparently R2 will include “Request Splitting”.

My understanding, and I really do hope I got this right, is that this will overcome the current problem of all changes being bundled into a single request object and, if any approvals are needed, FIM sends all changes to all approvers, any one of which being able to approve or reject the entire list.

What we really want of course is for changes that don’t need approval to go through unobstructed. And where changes do need approval they should go to the correct approver for that particular change – which may mean a couple of different people getting to approve seperate attribute changes.

This made me super happy as the single request architecture has been a big thorn in my side lately!

Most Interesting Sponsor Solution

I really like OptimalIDM‘s solution for multi-forest/multi-environment and Office 365. Regular readers of this blog will know I did a big, messy, multi-forest BPOS project in 2010-2011, and if I were doing that same project now I would be looking seriously at this product. At a high level, they solve some of the key problems faced by any complex organisation trying to move to Office 365:

• Their Virtual Directory presents a unified source directory to DirSync, taking objects from whatever directories you have about the place, not just AD – so if you have a Lotus Notes LDAP directory they can DirSync your users up to Office 365 without needing to also create them in a local AD!
• You can control which objects from your source directories make it into the Virtual Directory, overcoming the vacuum cleaner tendencies of DirSync.
• They solve the “public UPN” problem of federating with Office 365 by allowing you to map the UPN in the Virtual Directory. So if your local AD is myorg.local but the public domain is myorg.com you won’t have to rename all your user UPN’s – just let the Virtual Directory simulate it. Also for non-AD users it can provide a virtual UPN in the correct format.
• Following on from the last point, non-AD users can in fact use the federated login to Office 365. By acting as an account store for ADFS, OptimalIDM’s product can proxy the authentication request to any other directory. Again really great if you’re migrating from non-Exchange to Office 365.

For more info see http://www.optimalidm.com/Products/VIS/VirtualIdentityServerforOffice365/

General best thing about going to TEC

Seeing people who feel like old friends now even though I only see them once a year, and making new friends!

This script updates the ConfigurationData attribute of the named RCDC with the contents of a file. It then recycles the Sharepoint – 80 app pool.

PARAM($RCDCName, $FilePath)

# Get FIMPowershell.ps1 from http://technet.microsoft.com/en-us/library/ff720152(v=ws.10).aspx
. ./FIMPowershell.ps1

# Update Configuration

$content = Get-Content $FilePath

$filter = "/ObjectVisualizationConfiguration[DisplayName = '" + $RCDCName + "']"
$RCDC = export-fimconfig -customconfig ($filter)

$ModifyImportObject = ModifyImportObject -TargetIdentifier $RCDC.ResourceManagementObject.ObjectIdentifier -ObjectType "ObjectVisualizationConfiguration"
SetSingleValue $ModifyImportObject "ConfigurationData" $content
import-fimconfig -importObject $ModifyImportObject

# Recycle App Pool

$AppPool = "W3SVC/APPPOOLS/SharePoint - 80"
$Path = "IISApplicationPool.Name='$AppPool'"

Invoke-WMIMethod Recycle -Path $Path  -Namespace root\MicrosoftIISv2 -Authentication PacketPrivacy

The one thing this won’t do is stop that first connection error when you go to test. I tried Thomas’ warm up FIM approach but it didn’t work for me – possibly because I was testing using a different account to the one that had “touched” the Portal.

In case you’re wondering whether I’m so random in my RCDC changes that I couldn’t just back out the last change – it was a transfer of configuration between environments that triggered the error, and actually permissions were at fault, but I didn’t know which permissions until I’d identified the faulty RCDC controls. Somehow two attributes appeared to be in the MPR, but the rights weren’t assigned. I removed and re-added the attributes and then the RCDC worked properly. Some kind of issue with the config migration I guess.

The session should be particularly of interest to consultants who may have to estimate and conduct migrations, sometimes with no prior experience of the customer’s environment.

If you’re going to be at TEC, do come and say hi! If you’re still thinking of registering, what are you waiting for? http://www.theexpertsconference.com/us/2012/

This struck me as a good idea for a number of reasons.

Mostly you want to trigger Workflow based on something changing but you don’t much care how the change happened. The Set transition MPR is ideally suited here – we don’t care how the object got into the set, but it did, so now we’re going to do something else.

However it’s often better to use a Request MPR so that the resulting changes are still tied to the original (“parent”) request and you can, for example, send a notification back to the original Requestor.

In a typical FIM Portal environment you will have a number of MPRs granting access to the same resource type – for example:

• Self can change some attributes,
• Manager can change some attributes,
• Particular people may be designated elevated access – eg., Helpdesk, IT Support, department assistants.

All of this can stack up to a number of permission-granting MPRs which overlap on their attribute inclusion lists.

Now let us say you also want to launch workflows when certain attributes change. The only way to do this is to target the MPR at the specifc attribute/s where a change should trigger the particular workflow. If these MPRs also grant permissions you run the risk of one requestor triggering the same workflow multiple times – perhaps because they’re a department assistant but changing their own profile. When two workflows try to change the same attribute in the one request the result is “Cannot insert duplicate key row” errors and a failure of both workflows.

When you separate the MPRs into those that grant permissions and those that run workflows, things become a lot simpler. Now all your request-type workflow MPRs can generically have “All People” as the Requestor Set, because your permission granting MPRs will be restricting who can actually make this change anyway. Ideally you will also have each Workflow being called by only one MPR.

I now have a bunch of “Access Control” MPRs and a bunch of “Workflow” MPRs and I’ll be keeping it that way!

When I mentioned to Bob Bradley that I’d done this his response was “oh yes I always do it that way” – so that, to me, is a Best Practise!

Certainly I don’t want my customer to have to go through this every time someone complains that it should be “Family Name” instead of “Surname’, or whatever the flavour of the month happens to be. Sure you can set it up so that each field title and description comes from the schema, but you can also go a step further with String Resources.

You don’t have to look at an RCDC very long to notice a lot of variables that look like this: %SYMBOL_AFCaption_END%.

But where are they defined? The answer is the String Resources field which you can get at through the Localization tab of the RCDC configuration. The String Resources are actually there to allow you to customise the Portal for different languages. But even in a single-language environment it can be good to use them.

Like the RCDC configuration itself you can export the String Resources as an XML file, edit them, and load them back in. Just use the file control underneath the String Resources field. You will need to recycle the Sharepoint:80 app pool after uploading if you want to see an immediate effect.

And the great thing is that you can replace every bit of hard-coded text in the RCDC with a String Resource.

The text on the tab captions can be controlled by a string resource, as is already the case for the default RCDC tabs:

<my:Grouping my:Name="Identification" my:Caption="%SYMBOL_IdentificationCaption_END%" my:Enabled="true" my:Visible="true">

Something that I’ve just gone through and done in the RCDCs on my current project is to add a Hint parameter to every single control:

<my:Control my:Name="PreferredFirstName" my:TypeName="UocTextBox" my:Caption="{Binding Source=schema, Path=PreferredFirstName.DisplayName}" my:Description="{Binding Source=schema, Path=PreferredFirstName.Description}"
my:RightsLevel="{Binding Source=rights, Path=PreferredFirstName}"  my:Hint="%SYMBOL_PreferredFirstNameHint_END%" >
	<my:Properties>
		<my:Property my:Name="Required" my:Value="{Binding Source=schema, Path=PreferredFirstName.Required}"/>
		<my:Property my:Name="Columns" my:Value="34"/>
		<my:Property my:Name="MaxLength" my:Value="128"/>
		<my:Property my:Name="Text" my:Value="{Binding Source=object, Path=PreferredFirstName, Mode=TwoWay}"/>
	</my:Properties>
</my:Control>

Most of them are just set to empty strings in the String Resources setting, but the customer should now find it far more straight-forward to set a hint if one is needed:

 <SymbolResourcePair Symbol="PreferredFirstNameHint" ResourceString=""/>

Here’s another example: using String Resources so set the search box text in a UocIdentityPicker:

<my:Control my:Name="Manager" my:TypeName="UocIdentityPicker" my:Caption="{Binding Source=schema, Path=Manager.DisplayName}" my:Description="{Binding Source=schema, Path=Manager.Description}"
my:RightsLevel="{Binding Source=rights, Path=Manager}"  my:Hint="%SYMBOL_ManagerHint_END%">
	<my:Properties>
		<my:Property my:Name="Required" my:Value="true"/>
		<my:Property my:Name="Mode" my:Value="SingleResult"/>
		<my:Property my:Name="ObjectTypes" my:Value="Person"/>
		<my:Property my:Name="UsageKeywords" my:Value="ActiveAD"/>
		<my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName, Department"/>
		<my:Property my:Name="AttributesToSearch" my:Value="FirstName, LastName, PreferredFirstName, AccountName"/>
		<my:Property my:Name="Value" my:Value="{Binding Source=object, Path=Manager, Mode=TwoWay}"/>
		<my:Property my:Name="ListViewTitle" my:Value="%SYMBOL_ManagerListViewTitle_END%"/>
		<my:Property my:Name="PreviewTitle" my:Value="%SYMBOL_ManagerPreviewTitle_END%"/>
		<my:Property my:Name="MainSearchScreenText" my:Value="%SYMBOL_ManagerSearchText_END%"/>
	</my:Properties>
</my:Control>

And the variables defined in String Resources:

 <SymbolResourcePair Symbol="ManagerHint" ResourceString=""/>
 <SymbolResourcePair Symbol="ManagerListViewTitle" ResourceString="All People"/>
 <SymbolResourcePair Symbol="ManagerPreviewTitle" ResourceString="Selected Person"/>
 <SymbolResourcePair Symbol="ManagerSearchText" ResourceString="Search People"/>

You can also use them to replace the Text on check boxes, and the Captions on radio control options… Basicaly anywhere you find yourself hard-coding text in an RCDC have a think: would a String Resource work better here?

And one final plus point – if you mess up the XML in String Resources by forgetting a quote or something it doesn’t break your whole form - you just get some missing text and a note in red at the bottom of the form about which variables are missing. Both less risky and easier to troubleshoot than editing the RCDC configuration XML!