Upgrading MIIS/ILM to FIM

In this post I will offer general advice about migrating MIIS/ILM Sync to FIM Sync, supplementing the information in the Migration Guide on Technet. I’m looking at this purely as a Sync Service to Sync Service migration so there will be nothing about adding the FIM MA, replacing classic rules with declarative, or any of the other changes you may be planning to  take advantage of FIM Portal functionality.

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 separate 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 again with it turned 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.