Archive for the ‘Forefront Identity Manager 2010’ Category

HOWTO: Access the User Profile Synchronization Client in SharePoint Server 2013

April 19, 2018

This post is one of those “I used to know how to do this – where is that app again?!?” kind of posts…

User Profile Synchronization in SharePoint 2013 was great when it worked, and diabolical when it didn’t. The User Profile sync used the “RTM” version of the Forefront Identity Manager (FIM) profile synchronization engine, which is great but also a pain because it Never Got Updated – you got all the issues that the RTM version had, with none of the great fixes released later on.

Under the hood, you can access the FIM admin utility via the following default path:

C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe

If you can’t find the application there, open up the Local Services app and look for “Forefront Identity Manager Service”, and the “Path to executable” value is where the FIM application is installed.

WARNING: don’t make changes in this application! User Profile Synchronization is configured by SharePoint Server 2013 automatically, and making changes here will cause issues! Think of the MIISClient as a handy window into the workings of profile synchronisation…



Using the Synchronization Service in SharePoint 2010 – Forefront Identity Manager 2010

June 25, 2012

If you use the User Profile Synchronization Service in SharePoint 2010, you may not realise that you are also getting an identity management product included – Forefront Identity Manager 2010 (or FIM 2010). FIM 2010 is a full-featured identity management system, and included with SharePoint 2010 is the basic version that does not have a lot of the “extras” (like Certificate Management, the FIM portal, etc) but is used to import and export data between identity systems. Typically this is SharePoint 2010 User Profiles and Active Directory (other systems are also supported).

To view the FIM 2010 interface you can open the Synchronization Service Manager, which is by default located at:

C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

Note that this is only installed when you configure the User profile Sychronization Service on SharePoint 2010, so if you have a multi-server deployment you need to be on the server that has the User Profile Synchronization Service running.

I’ve implemented a full FIM 2010 deployment previously so was quite interested to note that it is indeed the same product, with some reduced functionality. This has been helpful a couple of times when the synchronization has failed from SharePoint 2010 and I have needed to troubleshoot the issue by opening the Sync Service Manager.

Synchronization Service for SharePoint 2010

Synchronization Service Manager for SharePoint 2010

I was getting the following error in the Application event log after a Full Sync was being performed:

Event ID 6298 (Timer)
The Execute method of job definition Microsoft.Office.Server.UserProfiles.UserProfileImportJob (ID 719df063-5757-4542-8ed1-a2c1622f6603) threw an exception. More information is included below.
Generic failure

I also noted that the FIM Sync Service was stopping on the server, but the SharePoint 2010 Central Admin reported the service still running. 10-20 minutes later, the FIM Sync Service would start again.  I opened up the Sync Service Manager and checked the Management Agent Operations under the “Operations” tab. This tells you which Management Agents (responsible for synchronising data between systems) had been run recently and the result. My sync runs had not started at all.

I decided to run a full sync on all Management Agents in the following order:

1. On the Active Directory Domain Services management agent, I ran the profiles: DS_FULLIMPORT and DS_FULLSYNC

2. On the Extensible Connectivity type management agent (which is the customised SharePoint management agent), I ran the profiles: DS_FULLIMPORT, DS_FULLSYNC, DS_EXPORT, DS_DELTAIMPORT

(for FIM-people, this is the export and confirming import required to ensure data is full synchronised)

The imports completed successfully and further “normal” syncs via the SharePoint interface worked too.

FIM Sync Results

FIM Synchronization Results

It is possible to adjust the synchronization settings via the Sync Service Manager, but I wouldn’t recommend it – there is no documentation about the connection between SharePoint and the FIM Sync Engine, so it is possible you could break the interface by making changes.

FIM 2010 Self-Service Password Reset Minimum Account Permissions

June 17, 2012

We are just implementing FIM Password Reset at a client’s site and needed to set the minimum permissions required to enable password reset. We used the following steps:

  1. Open Active Directory Users and Computers snap-in
  2. In “View”, click “Advanced Features”
  3. Right-click on the parent OU that you want to enable self service password reset for and select “Properties” (child OUs will inherit these permissions)
  4. Click the “Security” tab
  5. Click the “Advanced” button
  6. Click the “Add” button
  7. Enter the FIM account that is being used for password reset (the FIM service account)

From this point you need to select the following options:

  • In the “Object” tab set “Apply to:” to “Descendant user objects”, then tick “Change password” and “Reset password”
  • In the “Properties” tab set “Apply to:” to “Descendant user objects”, then tick “Change password” and “Reset password” then tick “Read lockoutTime”, “Write lockoutTime”, “Read userAccountControl”, “Write userAccountControl”

NOTE: When selecting the “Properties” tab it does keep the previously selected “Apply to” setting – so you won’t be able to see the properties.


HOWTO Move Forefront Identity Manager 2010 Databases to a Different SQL Server

October 3, 2011

I had installed FIM 2010 using an SQL Server alias, which worked fine – I use the same process when installing SharePoint and it has helped before, so I thought “why not with FIM?”. Famous last words.

I tried to deploy FIM 2010 Cumulate Update 1 and it failed, citing “Cannot connect to SQL Server”. I had the nasty suspicion that while FIM 2010 seemed to support SQL Server aliases, the Cumulate Update process did not.

FIM 2010 maintains information on SQL Server connections in the Registry under the hives:


The FIM services use these keys to establish database connections. Likewise, the Cumulative Update process accesses these locations to perform database updates.

A final note – after changing to a SQL Server instance instead of an alias, I got some errors when trying to upgrade the database via the Cumulative Update 1:

25070 Invalid class string

Installing the latest SQL Server Native Client from the Microsoft SQL Server 2008 R2 SP1 Feature Pack fixed these errors.