This blog post will assist you in upgrading a FIM 2010 environment to MIM 2016. To be clear: FIM 2010, not FIM 2010 R2. Disclaimer: if you “play” around like I do below, make sure you use one, or more, of the following.

• A test environment
• SQL Backups
• VM Snapshots
• …

Trust me sooner or later they’ll save your life or at least your day. After each attempt I did an SQL restore to be absolutely sure my upgrade path was OK. The installer “touches” the databases pretty quickly even if it fails in the beginning of the process.

The upgrade process is explained on TechNet: Upgrading Forefront Identity Manager 2010 R2 to Microsoft Identity Manager 2016 as well, but the guide is only partially applicable for the scenario I’ve foreseen.

• No information on upgrading from FIM 2010, only FIM 2010 R2 is mentioned
• No information on transitioning to a more recent Operating System
• No information on transitioning to a more recent database platform

In order to clarify I’ll show a topology diagram of our current setup:

Current versions:

• Operating System: Windows 2008 R2
• SQL: SQL Server 2008
• FIM: FIM 2010 (build 4.0.3576.2)

Target versions:

• Operating System: Windows 2012 R2
• SQL: SQL Server 2012 SP1
• FIM: MIM 2016 (RTM)

I won’t post a target diagram as in our case we decided not to change anything. We intend to upgrade FIM 2010 to MIM2016. However, we also would like to upgrade the various supporting components such as the underlying operating system and the SQL server edition. The TechNet guide shows you what has to be done to perform an in place upgrade of FIM 2010 R2 to MIM 2016. If I were to do an in place upgrade I would end up with MIM 2016 on server 2008 R2. I’d rather not do an in place upgrade of 2008 R2 to 2012 R2. That means I would have to migrate MIM 2016 to another box. Another disadvantage of upgrading in place is that you’ll have downtime during the upgrade. Well eventually you’ll have some downtime, but if you can leave the current environment intact, you can avoid the lengthy restore process if something goes wrong. And what about the database upgrade processes? Depending on your environment that can take quite some time. If you want plan your window for the upgrade, you could follow my approach as a “dry run” with the production data without impacting your current (running) environment! If you’re curious how, read on!

I wanted to determine the required steps to get from current to target with the least amount of hassle. I’ll describe the steps I followed and the issues I encountered:

Upgrading/Transitioning the FIM Synchronization Service: Attempt #1

1. Stop and disable all scheduled tasks that execute run profiles
2. Stop and disable all FIM 2010 services (both Sync and Service)
3. Backup the FIMSynchronization database on the SQL 2008 platform (see note at bottom)
4. Restore the FIMSynchronization database on the SQL 2012 platform
5. Enable SQL Server Service Broker for the FIMSynchronization database (see note at bottom)
6. Transfer the logins used by the database from SQL 2008 to SQL 2012
7. Copy the FIM Synchronization service encryption keys  to the Windows 2012 R2 Server
8. Ran the MIM 2016 Synchronization Service MSI on the Windows 2012 R2 server

However that resulted in the following events and concluded with an MSI installation failure:

In words: Error 25009.The Microsoft Identity Manager Synchronization Service setup wizard cannot configure the specified database. Invalid object name 'mms_management_agent'. <hr=0x80230406>

And in the Application Event log:

In words:Conversion of reference attributes started.

In words: Conversion of reference attributes failed.

In words: Product: Microsoft Identity Manager Synchronization Service -- Error 25009.The Microsoft Identity Manager Synchronization Service setup wizard cannot configure the specified database. Invalid object name 'mms_management_agent'. <hr=0x80230406>

The same information was also found in the MSI verbose log. Some googling led me to some fixes regarding SQL access rights or SQL compatibility level. None of which worked for me.

Upgrading/Transitioning the FIM Synchronization Service: Attempt #2

This attempt is mostly the same as the previous. However now I’ll be running the MIM 2016 installer directly on the FIM 2010 Synchronization Server. I’ll save you the trouble: it fails with the exact same error. As a bonus the setup rolls back and leaves you with a server with NO FIM installed.

Upgrading/Transitioning the FIM Synchronization Service: Attempt #3

I’ll provide an overview of the steps again:

1. Stop and disable all scheduled tasks that execute run profiles
2. Stop and disable all FIM 2010 services (both Sync and Service)
3. Backup the FIMSynchronization database on the SQL 2008 platform (see note at bottom)
4. Restore the FIMSynchronization database on the SQL 2012 platform
5. Enable SQL Server Service Broker for the FIMSynchronization database (see note at bottom)
6. Transfer the logins used by the database from SQL 2008 to SQL 2012
7. Install a new (temporary) Windows 2012 Server
8. Copy the FIM Synchronization service encryption keys to the Windows 2012 Server
9. Run the FIM 2010 R2 (4.1.2273.0) Synchronization Service MSI on the Windows 2012 server–> Success
10. Stop and disable the FIM Synchronization Service on the Windows 2012 server
11. Copy the FIM Synchronization service encryption keys to the Windows 2012 R2 Server
12. Run the MIM 2016 Synchronization Service MSI on the Windows 2012 R2 server

Again that resulted in several events and concluded with the an MSI installation failure:

In words: Product: Microsoft Identity Manager Synchronization Service -- Error 25009.The Microsoft Identity Manager Synchronization Service setup wizard cannot configure the specified database. Incorrect syntax near 'MERGE'. You may need to set the compatibility level of the current database to a higher value to enable this feature. See help for the SET COMPATIBILITY_LEVEL option of ALTER DATABASE.

Now that’s an error that doesn’t seem to scary. It’s clearly suggesting to raise the database compatibility level so that the MERGE feature is available.

Upgrading/Transitioning the FIM Synchronization Service: Attempt #4 –> Success!

I’ll provide an overview of the steps again:

1. Stop and disable all scheduled tasks that execute run profiles
2. Stop and disable all FIM 2010 services (both Sync and Service)
3. Backup the FIMSynchronization database on the SQL 2008 platform (see note at bottom)
4. Restore the FIMSynchronization database on the SQL 2012 platform
5. Enable SQL Server Service Broker for the FIMSynchronization database (see note at bottom)
6. Transfer the logins used by the database from SQL 2008 to SQL 2012
7. Don’t worry about the SQL Agent Jobs, the MIM Service setup will recreate those
8. Install a new (temporary) Windows 2012 Server
9. Copy the FIM Synchronization service encryption keys to the Windows 2012 Server
10. Run the FIM 2010 R2  (4.1.2273.0) Synchronization Service MSI on the Windows 2012 server
11. Stop and disable the FIM Synchronization Service on the Windows 2012 server
12. Changed the SQL Compatibility Level to 2008 (100) on the database
13. Copy the FIM Synchronization service encryption keys to the Windows 2012 R2 Server
14. Run the MIM 2016 Synchronization Service MSI on the Windows 2012 R2 server –> Success!

Changing the compatibility level can easily be done using the using the SQL Management Studio:

In my case it was on SQL Server 2005 (90) and I changed it to SQL Server 2008 (100). If you prefer doing this through an SQL query:

USE [master]

GO

ALTER DATABASE [FIMSynchronization] SET COMPATIBILITY_LEVEL = 100

GO

Bonus information:

This is the command I ran to install both the FIM 2010 R2 and MIM 2016 Synchronization Instance:

Msiexec /i "Synchronization Service.msi" /qb! STORESERVER=sqlcluster.contoso.com SQLINSTANCE=fimsql SQLDB=FIMSynchronization SERVICEACCOUNT=svcsync SERVICEDOMAIN=CONTOSO SERVICEPASSWORD=PASSWORD GROUPADMINS=CONTOSO\GGFIMSyncSvcAdmins GROUPOPERATORS=CONTOSO\GGFIMSyncSvcOps GROUPACCOUNTJOINERS=CONTOSO\GGFIMSyncSvcJoiners GROUPBROWSE=CONTOSO\GGFIMSyncSvcBrowse GROUPPASSWORDSET=CONTOSO\GGFIMSyncSvcPWReset FIREWALL_CONF=1 ACCEPT_EULA="1" SQMOPTINSETTING="0" /l*v C:\MIM\LOGS\FIMSynchronizationServiceInstallUpgrade.log

No real rocket science here. However, make sure not to run /q but use /qb! as the latter allows popups to be thrown and answered by you. For instance when prompted to provide the encryption keys.

Upgrading/Transitioning the FIM Service: Attempt #1 –> Success!

Now to be honest, the upgrade I feared the most proved to be the easiest. From past FIM experiences I know the FIM Service comes with a DB upgrade utility. The setup runs this for you. I figured: why on earth would they throw away the information to upgrade from FIM 2010 to FIM 2010 R2 and cripple the tool so that it can only upgrade FIM 2010 R2 to MIM 2016?! And indeed, they did not! Here’s the steps I took to upgrade my FIM Portal & Service:

1. Stop and disable all scheduled tasks that execute run profiles => this was already the case
2. Stop and disable all FIM 2010 services (both Sync and Service) => this was already the case
3. Backup the FIMService database on the SQL 2008 platform (see note at bottom)
4. Restore the FIMService database on the SQL 2012 platform
5. Enable SQL Server Service Broker for the FIMService database (see note at bottom)
6. Transfer the logins used by the database from SQL 2008 to SQL 2012
7. Installed a Standalone Sharepoint 2013 Foundation SP2
8. Run the MIM 2016 Service and Portal MSI on the Windows 2012 R2 server –> Success!
9. Note: the compatibility level was raised to 2008 (100) by the setup

One thing that assured me the FIM Service database was upgrade successfully was the database upgrade log. The following event indicates where you can find it:

The path: c:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.IdentityManagement.DatabaseUpgrade_tracelog.txt An extract:

Database upgrade : Started.
Database upgrade : Starting command line parsing.
Database upgrade : Completed commandline parsing.
Database upgrade : Connection string is : Data Source=sqlcluster.contoso.com\fimsql;Initial Catalog=FIMService;Integrated Security=SSPI;Pooling=true;Connection Timeout=225.
Database upgrade : Trying to connect to database server.
Database upgrade : Succesfully connected to database server.
Database upgrade : Setting the database version to -1.
Database upgrade : Starting database schema upgrade.
Schema upgrade: Starting schema upgrade
Schema upgrade : Upgrading FIM database from version: 20 to the latest version.
Schema upgrade : Starting schema upgrade from version 20 to 21.
...
Database upgrade : Out-of-box object upgrade completed.
Database ugrade : Completed successfully.
Database upgrade : Database version upgraded from: 20 to: 2004
The AppDomain's parent process is exiting.

You can clearly see that the datbase upgrade utility intelligently detects the current (FIM 2010) schema and upgrades all the way to the MIM 2016 database schema.

Bonus information

This is the command I ran to install the MIM 2016 Portal and Service. Password reset/registration portals are not deployed, no reporting and no PIM components. If you just want to test your FIM Service database upgrade, you can even get away with only installing the CommonServices component.

Msiexec /i "Service and Portal.msi" /qb! ADDLOCAL=CommonServices,WebPortals SQLSERVER_SERVER=sqlcluster.contoso.com\fimsql SQLSERVER_DATABASE=FIMService EXISTINGDATABASE=1 SERVICE_ACCOUNT_NAME=svcfim SERVICE_ACCOUNT_DOMAIN=CONTOSO SERVICE_ACCOUNT_PASSWORD=PASSWORD SERVICE_ACCOUNT_EMAIL=svcfim@contoso.com MAIL_SERVER=mail.contoso.com MAIL_SERVER_USE_SSL=1 MAIL_SERVER_IS_EXCHANGE=1 POLL_EXCHANGE_ENABLED=1 SYNCHRONIZATION_SERVER=fimsync.contoso.com SYNCHRONIZATION_SERVER_ACCOUNT=CONTOSO\svcfimma SERVICEADDRESS=fimsvc.contoso.com FIREWALL_CONF=1 SHAREPOINT_URL=http://idm.contoso.com SHAREPOINTUSERS_CONF=1 ACCEPT_EULA=1 FIREWALL_CONF=1 SQMOPTINSETTING=0 /l*v c:\MIM\LOGS\FIMServiceAndPortalsInstall.log

Note: SQL Management Studio Database Backup

Something I learned in the past year or so: whenever taking an “ad hoc” SQL backup, make sure to check the “Copy-only backup” box. That way you won’t interfere with the regular backups that have been configured by your DBA/Backup Admin.

Note: SQL Server Service Broker

Lately I’ve seen cases where applications are unhappy due to the fact that the SQL Server Broker Service is disabled for their database. In my case it was an ADFS setup. But here’s an (older) example for FIM: http://justanothertechguy.blogspot.be/2012/11/fim-2010-unable-to-start-fim-service.html Typically a database that is restored from an SQL backup has this feature disabled. I checked the SQL Server Broker Service for the FIM databases on the SQL 2008 platform and it was enabled. I checked on my SQL 2012 where I did the restore and I could see it was off. Here’s some relevant commands:

Checking whether it’s on for your database:

SELECT is_broker_enabled FROM sys.databases WHERE name = 'FIMSYnchronization';

Enable:

ALTER DATABASE FIMSYnchronization SET ENABLE_BROKER WITH NO_WAIT

If issues arise you can try this one: I’m not an SQL guy. All I can guess it handles the thing less gracefully:

ALTER DATABASE FIMSYnchronization SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE;

And now it’s on:

Remark

I didn’t went all to deep on certain details, if you feel something is unclear, post a comment and I’ll see if I can add information where needed. The above doesn’t describe how to install the second FIM Portal/Service server or the standby MIM Synchronization Server. I expect the instructions to be fairly simple as the database is already on the correct level. If I encounter issues you can expect a post on that well. To conclude: there’s more to do than just running the MIM installers and be done with this. You’ll have to transfer your customizations (like custom workflow DLLs) as well. FIM/MIM Synchronization extensions are transferred for you, but be sure to test everything! Don’t assume! Happy upgrading!

Conclusion

The FIM 2010 Portal and Service can be upgraded to MIM 2016 without the need for a FIM 2010 R2 intermediate upgrade. The FIM 2010 Synchronization Service could not be upgraded directly to MIM 2016. This could be tied to something specific in our environment, or it could be common…

Update #1 (12/08/2015)

Someone prompted me if the FIM can be upgraded without providing the FIM/MIM Synchronization service encryption keys. Obviously it can not. That part has not changed. Whenever you install FIM/MIM on a new box and you point it to an existing database, it will prompt for the key file. I’ve added some “copy keys” steps in my process so that you have them ready when prompted for by the MSI.

Recently I came across the following error when trying to import a FIM Synchronization Server configuration:

In words: Failed to connect to the specified database. The extension operation aborted due to an internal error in FIM Synchronization Service.

Not only was I seeing this when importing the configuration, but also when manually trying to create a FIM MA. Whilst it says it has problems trying to connect, it has nothing to do with either the database or FIM Service base address. Even filling in random stuff results in this error immediately. So something had to be wrong with the Synchronization Service or the management console.

The odd thing was that I didn’t had this error when migrating from Development to Test or Test to Acceptance. So what was off with the Production server?! After a bit of googling I stumbled upon this post:

TechNet Forums: FIM 2010 R2 Error when creating FIM MA

Well I can tell you, I wasn’t going to install .NET 4.0 on the Dev, Test, Acc environment just because a fresh installed FIM server was behaving odd. After looking around on the server and verifying all installed updates I couldn’t find anything specific until I verified the installed software. Seems that somewhere in the staging process of the server the “Microsoft .NET Framework 4 Client Profile” got installed. I didn’t saw it on the other servers, so I went forward, uninstalled, rebooted and voila!

I’m not sure whether a lot of people will stumble on this, but for those that do, I hope this post helps!

Currently I’m involved in a project where we are setting up a lot of Windows technologies, just to name a few: Dynamics Ax 2012, BizTalk, SharePoint 2010, FIM 2010 and thus SharePoint Foundation 2010. It seems some legacy thingy in the Active Directory is biting us in the ass, so for both SharePoint (Full blown and Foundation) and Dynamics Ax we’ve had to modify the permissions on the service accounts used by those products.

So here’s the first occurrence I came across. It happened when I was running the initial configuration wizard of SharePoint Foundation 2010. This SharePoint instance will host the FIM 2010 R2 Portal in the near future. This wizard is to be executed after installing the bits & bytes of SharePoint 2010.

What it says in words: Failed to create the configuration database. An exception of type System.Collections.Generic.KeyNotFoundException was thrown. Additional exception information: The given key was not present in the dictionary.

One thing to look into would be the permissions on the SQL server instance. All in vain. In the end I fired up google and came across numerous posts like these:

• “The given key was not present in the dictionary” issue in Sharepoint 2010 RTM
• The given key was not present in the dictionary Error When Validating User Accounts

The solution is pretty simple to implement, but I’m still struggling whether there’s a “nicer” way which does not involve touchy every service account or the OU in which they reside. Using Active Directory and Computers, or the new Active Directory Administrative Center, we can modify the permissions on the involved service accounts. The ones involved or the ones which are being used by SharePoint: to run various service, application pools or the farm admin. In order to view the security tab on a given user you might have to enable the advanced features in the view option of the ADUC MMC.

Once you got your service account open, just check “Allow Read” for “Authenticated users”.

This exact same error also popped up when registering a new Managed Service Account within the Central Administration site:

If you’re interested in a more definite solution which does not involve modifying the security of all your service accounts, make sure to read Service Accounts: Active Directory Permissions Issues: Part #4 Conclusion.

Using FIM it’s easy to provision mailboxes for users. In my current project we also needed to provision mail enabled users. The difference between a mailbox enabled and mail enabled is that the latter only has an email address associated with it’s account. The mailbox is typically located at an external organization.

Here’s a table from Exchange Provisioning using ILM 2007 and FIM 2010

It shows which attributes to flow for each recipient type. As we are going to provision mail enabled users we only need to flow

• mailNickname
• targetAddress

I like to use the sAMAccountName for the mailNickname. The reason why we wanted to mail enable some users is that we’d want external users (like consultants) to appear in the GAL. The customer itself was using a (fictive) domain like @internalAD.local.

At first I had my rules configured as:

• sAMAccountName –> mailNickname
• TargetAddress –> targetAddress

Where TargetAddress has values like “thomas@setspn.com”.

The result:

While it looks ok at first sight, when you look for the user in the GAL, it will appear with an e-mail address of the customer his address space...  Not exactly what we were looking for.

I did some testing using the Exchange Management Console, and the what I wanted to achieve seemed to be possible using the GUI, I must have done something wrong! It seems the targetAddress attribute in AD is supposed to contain “SMTP:emailaddress” and not merely “emailaddress”. So I changed the rules:

• sAMAccountName –> mailNickname
• TargetAddress –> “SMTP:”+targetAddress

And now my user looks like:

You can clearly see that the “primary” address is now the external address. And below you can see the difference in the GAL lookup. The first entry is bad, the second entry is OK.

After updating our FIM Servers to the latest build, we also started upgrading the Password Reset Client software on the clients. After some tests we seemed to receive the following error in certain cases:

In words:

A service proxy exception was encountered while running the Password Reset application. Error Text: An unexpected error has occurred. Please contact helpdesk or your administrator. Error Code 40007.

In the trace log:

Microsoft.ResourceManagement: Microsoft.ResourceManagement.WebServices.Client.UnwillingToPerformException: The endpoint could not dispatch the request. ---&gt; Microsoft.ResourceManagement.WebServices.Faults.ServiceFaultException: The endpoint could not dispatch the request.

We quickly saw that we only had this error when users logged on to a workstation where the user didn’t exist in the Portal. IF these people visit the Portal they should get the generic FIM Service unavailable error. However before updating to the last build, the Password Reset Client software just closed quietly when it couldn’t match a user. As it should. I discussed this with someone at Microsoft and it seems to be a known bug which is fixed in FIM 2010 R2 but which will not be fixed in 2010.

Luckily for us all our users are managed from within FIM, except in test where some managed to slip by the FIM processing...

Wow! I had no idea it was the time of the year MVP’s were being (re)awarded. Somewhere in the past year I heard I was nominated for MVP and to support my candidature I filled in some docs but the mail I received yesterday came as a complete surprise.

Dear Thomas Vuylsteke,

Congratulations! We are pleased to present you with the 2011 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Identity Lifecycle Manager technical communities during the past year.

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say "Thank you for your technical leadership."

Toby Richards
General Manager
Community & Online Support

Special thanks to Markus for coaching and supporting me on the FIM TechNet Forum & Wiki. Thanks to Glenn Zuckerman & Anthony Ho for helping me out every once and while.

Thanks to the people of MCS Belgium for giving me opportunity to get to know FIM and be part of a great project/team. Thanks to my company RealDolmen for providing me with interesting projects again and again.

Thanks to everyone in the FIM community for all the knowledge sharing and troubleshooting help.

And of course, most of all thanks to my wife Stefanie for just letting me do what I do.

Let’s keep up the good work for another year!

One of the typical things of a webapp deployed on IIS is that everyday the first visitor has a very slow loading page. This is due to the application pool recycling. Every night, somewhere between 2 and 4 (for default installs) the application pools are recycled. After this when the first visitor arrives certain code is loaded again which takes some time. Consequent visitors don’t suffer this phenomena.

In the IIS world there’s a known solution for this: "IIS Warm Up scripts”. There even was  a built-in module for this in IIS 7.5, however it was in beta state and currently has been removed from the web. With some PowerShell and Scheduled Task magic we can warm up IIS just as good. In my example the first user was experiencing a 15-20 seconds delay before the FIM Portal showed up. After applying the following solution that was more like 2 seconds.

Our script which will warm up the site will do this every time the application pool is recycled. The trigger for the scheduled task will be an event in the Application event log. Therefor we have to modify the default settings of the application pool so that it logs these events.

Open the IIS management console and locate the application pool responsible for the SharePoint site hosting your FIM portal

Righ-click and choose advanced settings, make sure to set “Specific Time” to True.

Every time the application pool is recycled by the schedule defined in the “Specific Times” array the following even will be logged:

A worker process with process id of '4420' serving application pool 'SharePoint - 80' has requested a recycle because it reached its scheduled recycle time.

Now the following script can be executed to warm up IIS. It will do this by visiting the page and performing a get. It’s very basic and probably can be improved or rewritten.

function get-webpageWithAuthN([string]$url,[System.Net.NetworkCredential]$cred=$null){
    write-host -foregroundcolor green "Warming up $url";
    $wc = new-object net.webclient;
    $wc.credentials = $cred;
    #$wc.Headers.Add("user-agent", "PowerShell");
    $html = $wc.DownloadString($url);
    #$html
}

#FIM
$website = http://FIM.setspn.blogspot.com/IdentityManagement
$credentials = [System.Net.CredentialCache]::DefaultCredentials;
get-webpageWithAuthN -url $website -cred $credentials

Now we can create the Scheduled Task. I choose to run it as “local system”. This seems enough to warm up the portal. I think because this way the FIM Service is queried to see if “Local System” (my FIM server itself) is known in the portal. Obviously this is not the case and I will probably see a “Service not available” error. But the point is that the Portal is warmed up!

We will add some triggers:

• Type: On an event
• Log: System
• Source: WAS
• Resource ID: 5076

Then we will specify an action:

• Action: Start a program
• Program/Script: PowerShell.exe
• Add arguments: c:\yourfolder\script.ps1
• Start in: c:\yourfolder

If we also want to trigger the script when we an administrator recycles an Application Pool we have to add a trigger for event 5079 (System –> WAS: 5079)

If we also want to trigger the script when we perform an IISreset we can add a trigger for the following event 3201 (System > IIS-IISREeset: 3201)

Obviously this way of working could be applied for other websites too.

Performing a configuration migration is pretty straight forward. You just have to pay attention to some things. Besides the excellent guide (Configuration Migration Deployment Guide ) I also pay attention to the following points:

1. FIM MA health

This is a rather nasty one. However if you fail to detect it, and you happen to migrate your configuration to a FIM MA in this situation you’ll be doomed to a do a rollback using SQL backup-restore. The good news it’s easy to detect. Every time you perform modifications to your MA’s or MV configuration, this info get’s replicated to the FIM Service. You can see this info below administration > all resources:

Every time such an update occurs, requests are logged in the FIM requests log:

That’s also one of the reason why running a Full Synchronization profile on your FIM MA very often is a bad idea. This data gets replicated to the FIM Service every time you do a full sync on your FIM MA. This is the easiest way to make your FIM Service DB explode in size. But, back on track now. Using the following WMI trickery (discovered by Craig Martin): MSDN: MIIS_ManagementAgent Class

You can force this replication to occur by executing the following statements:

### Get the FIM MA
$fimMa = Get-WmiObject -Class MIIS_ManagementAgent -Namespace root/MicrosoftIdentityIntegrationServer -Filter ("Type='Forefront Identity Management (FIM)'")
### Call the WMI method to ReSync the Config Objects from miiserver.exe to microsoft.resourcemanagement.service.exe$fimMa.ResyncSyncConfigObjects()
$fimMa.ResyncSyncConfigObjects()

Now what should the outcome look like?

The ReturnValue Success is a good start. You also should see the requests being logged. However, if you see the following entry in your application log you got some work to do:

In words:

A update on the configuration of a MA or MV failed to replicate to a target connector directory that is capable  of storing MA/MV configurations.  As a result, the MA/MV configuration data in this connector directory is not up to date.  Please correct the condition that causes the error, and triggers a resync by updating the password information of the target MA.
Additional information:
Error Code: 0x80230709
Error Message: (The extension operation aborted due to an internal error in FIM Synchronization Service.)
Operation: Clean up MAs
Name of the MA to replicate: 
Guid of the MA to replicate: 
Name of the target MA: FIM MA
Guid of the target MA: {35F6A1E2-CCF6-4C8A-91FF-2114625B144D}

I haven’t found a nice workaround just yet… What I’ve done successfully in the past:

1. delete the FIM MA (CS and MA itself)
2. wipe the MV
3. Reconfigure the FIM MA from scratch or by importing an earlier (healthy?) FIM MA xml.
4. Import, join and sync in the proper order

This might seem like a lot of pain, and it sure it. But I prefer avoiding even worse: having a setup which refuses to recognize it’s declarative SR’s.

2. MA Schema Up-to-dateness

Very short tip: before you start exporting/importing, make sure your schema’s of your MA’s are up to date. Doing an update schema on each MA is a quick & easy test. This way you can avoid some additional trickery. It shouldn’t break anything, but it might give you all sorts of weird issues.

3. Attribute Precedence

Make sure to double check your attribute precedence. If you have declarative rules and classic rules (which the FIM MA always does), you might have to toy around with the attribute precedence. As this might get scrambled due to the order the MV gets the contribution info.

This is in fact a double post. I posted this article to the TechNet Wiki for which I originally wrote this article. Link: TechNet Wiki: FIM 2010: Understanding Kerberos Authentication Setup

The goal of this article is to provide some background information regarding the Kerberos related configuration steps of the FIM Portal and FIM Service. The article has been written in such a way so that most of the points can in fact be used for any application requiring Kerberos.

This article will not discuss the various possible FIM Topologies. All information should be valid regardless whether all roles are combined on a single server or split across multiple servers.

Throughout the article a demo domain will be used. The domain which will be referenced as an example is contoso.com (NetBIOS name: CONTOSO).

Table of Content:

1. Identify Services
2. Identify Service Identities
3. Name Services
4. Configure DNS
5. Configure Service Principal Names (SPN's)
6. Configure IIS for Kerberos
7. Identify Delegation Requirements
8. Configure Delegation
9. Enforce Kerberos (FIM Specific)

1. Identify Services top

Before we can start configuring SPN’s (Service Principal Names) we have to determine what services we want to enable for Kerberos authentication. A typical FIM Portal deployment has the following services:

• Database for the FIM Service (SQL Service)
• FIM Service
• FIM Portal (Windows Sharepoint Services (WSS))

Note
In the above overview we’re leaving the FIM Synchronization Service and the databases for the WSS aside. They don’t bring any added value to this article.

The following picture provides an overview of these services.

2. Identify Service Identities top

Kerberos is all about authenticating principals to a service. Each principal is represented by an account in AD. This can either be a computer or a user account. Before Kerberos can take place, each service should be represented by an account in AD. Again this can either be a computer or a user account. Therefore it’s important to determine which account represents a given service.

Note
A typical Windows Service has its identity configured in the Services MMC. A website however has its identity configured in the IIS Management Console (below the Application Pools section)

The list below provides an overview of our services and their associated identities.

• Database for the FIM Service: the user account running the sqlservr.exe process of the SQL Instance hosting that database
• FIM Service: the user account running the FIM Service service
• FIM Portal: Application Pool identity in IIS for the FIM Portal site

This information is displayed in the following picture.

3. Name Services top

Besides the principal representing a service, we also need to determine a name to access the service. Choosing names can be rather important when actual people are involved. Check the following examples:

1. The FIM Service is configured to access its database on SPRDL2FIMSQL01B.contoso.com
2. Users visit the FIM Portal by browsing to SPRDL3FIMPOR01.contoso.com

The first one is in fact not a problem at all. Nobody will mind that a name, for which IT probably has an explanation, is configured for a service to use. In the second example your users will by no means be able to remember the URL. Something like fimportal.contoso.com is way more feasible.

Important
Choose your service names carefully and always keep in mind whether end-users will use them.

In the picture above several client-server communication arrows have been pictured. In our example we will go with the following names to access the services:

1. Database for the FIM Service: fimsql.contoso.com
2. FIM Service: fimsvc.contoso.com
3. FIM Portal: fimportal.contoso.com

Note
There’s nothing wrong with choosing the actual server name of the SQL server to associate with your SQL service.

4. Configure DNS top

Clients have to be able to resolve the names for these services. We can register these records in DNS. It might seem convenient to use an alias (CNAME) record for some of the services. However this is a bad idea as explained in the following paragraph.

Using a CNAME record would ensure that updating the server its IP has no influence on the service name record. However CNAME records resolve in another way than A records. A client requesting a Kerberos ticket for a given service will ask AD a ticket for whatever the name resolves to. This is how a client will resolve those names:

• fimsvc.contoso.com (CNAME) -> server01.contoso.com -> IP_of_FIM_Server
• fimsvc.contoso.com (A) -> IP_of_FIM_Server

In bold the names are shown for which a Kerberos authentication attempt will be performed. In the first example you can clearly see that our client will request a Kerberos ticket for the wrong service as our service is coupled to fimsvc.contoso.com. So things will go wrong. For more information check Kerberos Basic Troubleshooting: Tip 3: SPNS and CNAME Records

Important
Register A records to ensure the correct service name is used in the Kerberos authentication attempt

5. Configure Service Principal Names (SPN's) top

So we got a name and an identity for our service. How do we tell AD that these belong together? Ahah! Now we get to the Service Principal Names (SPN's). Whenever someone wants to use Kerberos to authenticate to a given service, they contact the Key Distribution Centre (KDC) and ask for a service ticket. The KDC is running on each domain controller. It knows which ticket to hand out because the client specified the service it wants a ticket for. The service was in fact specified by its name. More particularly by using the Service Principal Name (SPN).

An SPN is based upon the following format <service>/<fqdn>:<port>

In our example we will execute the following commands:

• Setspn –S MSSQLsvc/fimsql.contoso.com:1433 sa_sqlsvc
• Setspn –S MSSQLsvc/fimsql:1433 sa_sqlsvc
• Setspn –S FIMService/fimsvc.contoso.com sa_fimsvc
• Setspn –S FIMService/fimsvc sa_fimsvc
• Setspn –S HTTP/fimportal.contoso.com sa_wss
• Setspn –S HTTP/fimportal sa_wss

Important
Never register a given service (<service>/<fqdn>:<port>) on multiple accounts. Whenever multiple accounts are responsible for the same service, AD cannot determine which account to use to hand out the Kerberos service ticket. As such Kerberos authentication breaks. This issue is called Duplicate SPNs. You can do a quick check in your domain for duplicate SPN's by executing Setspn -X.

Important
Always register both short and long (domain fqdn) for a service. This will ensure Kerberos is available at all times.

Important
SQL always requires an SPN of the format MSSQLsvc/<fqdn>:<port>, even when using the default (1433) port. If your port is dynamic you have to configure it to be static or give the SQL Server service account permissions to update its own SPN's.

Note
A lot of guides will tell you to use Setspn –A instead of setspn –S. The advantage of using the –S option is that it will check the domain prior to adding the SPN. This will avoid setting duplicate SPNs.

6. Configure IIS for Kerberos top

When the above steps have been implemented, both the FIM Service and SQL will start accepting Kerberos. However IIS is slightly different. In fact skipping this particular step will often break your configuration all together. One of the symptoms when having a bad Kerberos implementation is the following: you type the URL of your website, you get presented with an authentication prompt, and no matter how many times you correctly enter your credentials, you keep getting prompted over and over again.

This issue occurs because by default IIS uses the account of the server to validate service tickets instead of the Application Pool identity. We can force IIS to use the identity of the application pool by configuring this in the applicationHost.config configuration file.

Important
The applicationHost.config is typically located in c:\windows\system32\inetsrv\config\ Remember to take a backup when modifying this file.

The following steps are required to configure Kerberos Authentication to work with a custom Application Pool Identity.

7. Identify Delegation Requirements top

Now that we got Kerberos authentication working for all of the involved services we have to determine whether additional configuration is required. Sometimes it’s obvious that Kerberos delegation has to be configured, sometimes it’s less obvious. Either way, it’s advised to check the product specific documentation to be sure. Kerberos delegation will allow a service to impersonate a visiting user and authenticate to another service as if it were the user himself who visits that service.

From the FIM Installation Guide we know that the following delegation scenarios are required:

1. FIM Portal to FIM Service
2. FIM Service to FIM Service

This is explained in the "Establish SPNs for FIM 2010" section of the installation guide.

8. Configure Delegation top

To allow a given service to delegate to an other service, we have to configure delegation on the service its service account to the delegated service its SPN. Delegation can be configured using Active Directory Users & Computers (ADUC). As explained in the previous section we have to configure the following delegation scenario's:

For the Portal to be able to delegate to the FIM Service we would have to:

1. Open ADUC and locate the service account for the Portal (sa_wss)
2. Open the properties of sa_wss and choose the delegation tab
3. Check Trust this user for delegation to the specified services only
4. Check Use Kerberos only
5. Click Add...
6. Click users or Computers...
7. Type the name of your FIM Service service account: sa_fimsvc
8. Click Check Names and Click Ok
9. Select the FIMService entry and Click Ok
10. Click Ok to close the account properties

Some screenshots to aid in the process: FIMService selection screen

And the resulting Delegation tab for the sa_wss acocunt:

For the FIM Service to be able to delegate to the FIM Service we would have to:

1. Open ADUC and locate the service account for the Portal (sa_fimsvc)
2. Open the properties of sa_fimsvc and choose the delegation tab
3. Check Trust this user for delegation to the specified services only
4. Check Use Kerberos only
5. Click Add...
6. Click users or Computers...
7. Type the name of your FIM Service service account: sa_fimsvc
8. Click Check Names and Click Ok
9. Select the FIMService entry and Click Ok
10. Click Ok to close the account properties

Note
The delegation tab on a user is only visible when an SPN has been registered for that account.

Note
The above procedure assumes your domain is in 2003 DFL or higher. Windows 2000 DFL only has unconstrained delegation available.

9. Enforce Kerberos (FIM Specific) top

Optionally you can configure the FIM Portal to only accept Kerberos. This is explained in the FIM Installation Guide  > Installing The FIM 2010 Server Components > Activating The Kerberos Protocol Only (link)

The following steps are required to force Kerberos Authentication for the FIM Portal.

Happy Kerberizing