We're receiving almost daily alerts for blocking within the FIM SQL Server instances in production. Alert description: The session/s 97,95 in SQL instance "FIM" on computer "Server" is/are blocked. See "alert context" tab for more details. The blocking has been seen in the databases for the FIM Sync Serice and the FIM Service. FIM Synchronisation Service Database: update mms_metaverse statements block insert into mms_csmv_link statements. FIM Service Database: Execute UpdateRequestStatusForCompletedActionWorkflows statements block xp_userlock statements We have contacted Microsoft with this issue, and they advised us that theyd expect to see blocking on the FIM Sync DB if multiple management agents were running at the same time. We went through the logs and have determined that the last two times this has happened, only one Run Profile was running at the time. As we use a script to run the profiles continuingly, it can be assumed that this has been the case throughout most of the cases. The only way more than one profile would be running simultaneously would be if one was kicked off manually. We run full database backups nightly and transaction log backups every 15 minutes. However all these backups are fully online operations and they shouldnt cause blocking like this. The only database maintenance processes that could cause blocking are the weekly reindexing jobs, which start at midnight each Sunday, and for these databases are typically finished before 1am Sunday morning. It is apparent that none of these blocking incidents seem to fall into this database maintenance window. Below is an extract from SDM with some analysis from our DB team from two of the FIM blocking incidents. Incident One SQL Session 58 was blocked (waiting for locks held) by SQL Session 79. It had been waiting for these locks for more than 5 minutes.SQL Session 79 was not blocked at allBoth SQL sessions originated from program Microsoft Forefront Identity Manager 2010, running as service account Domain\ServiceAccount on server ServerThe blocked session (58): Was waiting on locks held by Session 79 on the table mms_connectorspace in the FIM Synchronization Service databaseWas running stored procedure dbo.mms_getcsobjectwithguid_holdlock This stored procedure is a read-only transaction, although it include the holdlock table hint, which can contribute to blocking issues The blocking session (79): Had a status of sleeping within SQL Server, yet has a transaction open. This could imply it is doing work on the application server even though it still has an open transaction within the database.Was running stored procedure dbo.mms_getprojected_csrefguids_noorder This stored procedure is a read-only routine, however it was called from within an active transactionThis stored procedure also uses the holdlock table hint, however this is on table mms_csmv_link (see below) Incident Two SQL Session 76 was blocked (waiting for locks held) by SQL Session 88. It had been waiting for these locks for more than 5 minutes.SQL Session 88 was not blocked at allBoth SQL sessions originated from program Microsoft ForefrontT Identity Manager 2010, running as service account Domain\ServiceAccount on server ServerThe blocking session (88) appears exactly the same as for incident 195508 (same status, same stored procedure name etc)The blocked session (76): Was running SQL statement delete [mms_csmv_link] where ( [cs_object_id] = @0 and [mv_object_id] = @1 )Was waiting on locks held by Session 88 on the table mms_csmv_link in the FIM Synchronization Service database. This is the table that is referenced with a holdlock table hint in the stored procedure. Has anybody else seen something like this before?