SCSM managment pack deployment seems to hang

While installing reporting for FIM, I left the management packs deploying overnight. To my surprise, they weren’t finished this morning. (I know it takes a while, but not THAT long.)

Checking the Event Viewer “Operations Manager” log on the data warehouse server revealed that there was a problem starting the Health Service.

Starting the System Center Management service (which was, indeed, in a stopped state) seems to have cleared up the issue.


Setting FIM to run in single request mode

Microsoft Support had me set FIM into single request mode to get around an issue in the Beta version of R2. I had to ask for instructions, so thought I’d post them here for future reference:

“There is configuration file for sync service:

C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe.config

You will have to change default value for “aggregate” attribute of “resourceSynchronizationClient” section to “false”.

Basically, if you haven’t modified this file before and everything is default, then your “resourceSynchronizationClient” node will change from this:


to this:

<resourceSynchronizationClient aggregate=”false”/>

After you make this change you will have to close “Synchronization Service Manager” and restart the “Forefront Identity Manager Synchronization Service”. Once it is done you’re switched to single request mode for synchronization.”

Error when launching password registration portal from home page

When I tried to access the password registration site from the FIM portal home page, I received this error:

“Password reset registration cannot be completed because configuration data are missing from this computer.”

There was nothing in the Event Viewer.

I tried to search the 12-hive to find the “PwdRegister()” javascript function, but didn’t see anything.

Not sure if this is the correct approach, but I went to “Home Page Resources” under the “Administration” menu and selected “Register for password reset”. I changed the Navigation Url in the Behavior tab to:


That seemed to work.

SharePoint Admin can login on server but not from another location

So, I could login to my new SharePoint site with the Administrator account when I was logged into the server, but not when logged into another machine.

I was able to pull up Central Administration from the other machine.

After much puzzling, it looks like the SharePoint service account for my site isn’t correctly configured. When I switched the service account to the same one Central Administration is using, I could log in just fine.

Turns out the service account hadn’t had the SPNs set:

setspn -s HTTP/FIMServerName domain\SPService
setspn -s HTTP/ domain\SPService
setspn -s FIMService/FIMServerName domain\FIMService
setspn -s FIMService/ domain\FIMService

Some notes on installing FIM Reporting

I’m writing this as I go through the installation process to keep a note of what steps I’ve had to take and what troubleshooting issues I come across.

1. Install SQL Server on the SCSM DA and DW servers. The DW server also needs SSRS installed. See this ( for steps to configure SSRS.

2. Created AD groups for use during the installation of both the DA and DW.

3. Despite what’s written in a lot of documentation, the Authorization Manager hotfix isn’t required.

4. Installed SCSM DA, SCSM DW and ran Windows Update.

5. Installed the following hotfixes on the SCSM server: KB2542118, KB2561430, KB2561415. [Note: if you need the SCSM reporting portal, install it before applying these updates. If they’ve already been applied, there’s an unsupported workaround here…. One step not mentioned in the post is to re-apply the CU after you install the portal to make sure all applications receive the patch. That will also re-apply the registry key correctly.)

6. Installed the SCSM Service Manager Console on the same server that hosts the FIM Reporting Services.

7. In the FIM portal, enabled ReportLogging via All Resources–> System Configuration Settings.

8. In the SCSM DA application, registered the data warehouse.

9. Waiting, waiting, waiting for the MPSync job to complete. To verify, when the job has stopped, double click the job and verify everything has a status of Associated or Imported. I left this running overnight, so not sure how long it takes.

10. Installed FIM Reporting feature on the portal. Waited for the management packs to complete. (This took a decent amount of time.)

11. Installed Powershell on SCSM DW and ran set-executionpolicy unrestricted.

12. Backed up SQL databases and then, ran the ./FIMPostInstallScriptsForDatawarehouse.ps1 script found in the separate download on the connect site for tech notes. (Documentation says to be sure the MPSync process is done before doing this.)

13. On FIM portal, executed Start-FIMReportingInitialSync.ps1. Waited on the ETL jobs to complete in the Service Manager. [Note: in the FIM_R2_TestLabGuide_Reporting.aspx document there is a PowerShell script that can optionally be run after this completes to see the data immediately in the reports.]

14. Ran a report in the Service Manager. Now trying to figure out what use to make of them.

Note: On Step 13, I received the error described here:…

The solution (for me) was to roll back the FIM Reporting installation, the SCSM DA and SCSM DW application installations and to re-install SQL on both SCSM servers to start from scratch. I was then extra careful to be sure the MPSync had completed, checking in multiple places (the Management Packs and the MPSync job details).

The URL for the reporting service can be configured via the SQL Reporting Services Configuration Manager. (

I just saw on this page ( that there is a script that can be run in a loop to speed up the initial reporting load process. Will have to try it next time.

SERVICE ACCOUNTS: provides information on the service accounts:

SVC_SCSM_Install: SCSM Install Account

SVC_SCSM_Service: SCSM service Account. Must have rights on the SQL Server and must be local admin. Must also be local admin on the SQL server during installation

SVC_SCSM_Workflow: Workflow Account, must be mail enabled

SVC_SCSM_Report: Report Service Accounts, must have rights on the SCSM_DW databases

Next we must give the SVC_SCSM_Install Account local Admin rights on the SCSM01 Server, we must give the SVC_SCSM_Service Account local admin rights on the SQL Server and we must give the SVC_SCSM_Service Account Create DB rights on the SQL Server.

1. The documentation that comes in the download from the connect site.

NOTE: I was getting an error 1503 when trying to start the System Center Data Access Service. Although I followed the instructions here 9 I think the real fix was closing the Service Manager Console and then trying to start the service.

FK_ObjectValueReference_BindingInternal Conflict

I was receiving this error when exporting to FIM:

The INSERT statement conflicted with the FOREIGN KEY constraint “FK_ObjectValueReference_BindingInternal”. The conflict occurred in database “FIMService”, table “fim.BindingInternal”.

I also noticed I could not write to one of the new multivalued string attributes I had created via the portal. That would fail with a notice that the reason for failure was “Other”.

Eventually, removing the binding and the attribute and recreating those seemed to fix it. I’m not sure if the deletion of just the binding would have worked, but it may have.

UPDATE: This happened again and I just removed the binding and that didn’t solve the problem. I did notice that it was just one particular value that I couldn’t set in the MVA. Strange. Still working on figuring this out.

EXECUTE permission was denied on the object ‘ReadSynchronizationError’

I received messages about the Export on the FIM MA taking too long and my previous trick of restarting the FIM Service didn’t help.

Looking in the event viewer, I saw this error reported:

Unhandled exception, the CLR will not terminate: System.Data.SqlClient.SqlException (0x80131904): The EXECUTE permission was denied on the object ‘ReadSynchronizationError’, database ‘FIMService’, schema ‘sync’.

I know better than to change anything in the FIMService database, but I did compare permissions from a working instance for the service accounts and everything seemed to be in order.

After some pondering on the error message, I cleared out the connector spaces and re-initiated the environment. Seems to have worked. Glad this was on a dev server.

Didn’t see anything else posted online about this error, so maybe it’s a one off and it’ll never happen to anyone else again…

Exporting to FIM “export session has timed out”

While exporting a very tiny number of objects to FIM, the export operation gave a stopped-server error and the Event Viewer for FIM reported the “export session has timed out”. It rambled on a bit about connection times taking too long, resetting the timeout value, etc.

After failed attempts to fix this by rebooting the FIM Sync Server, clearing out the metaverse, etc. the solution turned out to be blindingly obvious–restart the FIM Service.

Email Address as Login for AD

This is a simple thing I get asked about from time to time. Frequently, there is a requirement for users to be able to login to the Forefront Identity Manager (FIM) portal with an email address that does not have the same domain as the AD domain the portal is authenticating to.

The implementation of this is so simple, just create an attribute flow from the EmailAddress to the userPrincipalName. That should do it.