One of the possible topologies for the FIM 2010 solution is having your FIM Portal and FIM Service load-balanced across two (or more) servers. In the backend the FIM Service uses the same database for both nodes. However since FIM 2010 Update 1 (KB978864) has been released, installing such a topology got a bit trickier. I will explain the scenario were one node is damaged, no backup exists (woopsie), so we have to re-install the server. In fact this can al be done without data loss as the  data resides on the SQL server in the back. For this scenario I will use a single SQL server as it doesn’t matter. It could be a clustered SQL server as well. The topology to start from is the following:

We got two nodes with the FIM Service/Portal at version RTM + Update 1. This means the database is configured for RTM + Update 1. The version of the FIM Service DB can be found in the table called fim.version in the version column. Now suppose we want to reinstall the second node from scratch.

So we got the server team deploy a shiny new 2008 R2 VM and we take our FIM Service setup, go next, next, use existing database and start installing. And then the setup fails. Oh bloody hell. The error shown is not that obvious but if you dig deeper you’ll see it querying the aforementioned FIM.version table before stopping the install.

So what to do? One of the tips I got over at the TechNet forums, was to install the additional node using a temporary database and afterwards re-run the MSI but choosing the change option and pointing to the original DB. I assume this is the only supported way to change the DB. You could also start editing registry keys, but this is probably not supported. So you start the FIM Service setup and in stead of “using the existing database” you provide a name like “FIM Service TEMP”… Oi, Stop!

The FIM Service install for the initial setup added some jobs to the SQL Agent configuration which are run on a scheduled base. We wouldn’t want anything happen to them! Two of the four jobs are disabled, but these seem to be called from the other two jobs. In the screenshot below you can see them. Make sure to temporary rename them. I appended “REN”. As the jobs call each other by name (I think), this might temporary break those jobs. And then proceed with the installation to the FIM Service TEMP DB.

Now your good to go:

This is how the SQL jobs look like after installing a second FIM Service to the same SQL SERVER. You can can see that the same jobs are added again. I can tell you for sure if you don’t rename those jobs, the only remaining jobs will be those for the FIM Service TEMP DB we installed.

As these jobs have references to the actual database, this would break things for sure.

But we got it all covered and RTM is installed so we can continue updating the TEMP DB to the RTM + U1.

Almost there, just relaunch the FIM Service MSI and choose the change option. It’s now possible to point it to the original shared database and finish the setup without problems.

All we have to do now is deleted the temporary database, deleted the jobs added by installing the temporary FIM Service and rename the old jobs back to normal.

In fact the above scenario is almost identical to installing an additional node. As for installation from the ground up there’s an additional possibility: you can install both servers at RTM level with the same database, and then you’ll be able to upgrade them both to Update 1 without issues. The real issue is that you can’t install an RTM Service to a RTM + U1 database.

I can imagine someone having two FIM Service instances point to the same SQL for a lab and production FIM Service instance. When you want to have 2 FIM Service instances use the same SQL Server you’ll have to do some trickery. First you’ll have to rename the jobs, and afterwards you’ll have to make sure the renamed job reference each other with the new name. Upgrading this to newer versions might even be trickier. So the second issue is that you must pay attention to your SQL jobs when installing an additional FIM Service DB on a SQL Server which already hosts a FIM Service DB.

Note: as for the FIM Synchronization server I was able to install an active/standby (2 node) setup using the same database without the above problems. The FIM Synchronization Service seems to be capable of installing a RTM Sync Service to a RTM + U1 database.