FIM 2010 R2 Reporting Troubleshooting

FIM 2010 R2 Reporting Troubleshooting

The following section will provide troubleshooting guidance for FIM 2010 R2 Reporting. Use the table below to give you an indication of the areas to check when you encounter an issue with FIM 2010 R2 Reporting.

Troubleshooting Area Look In…

FIM Reporting Synchronization Jobs

•Reporting Job Status in FIM Portal

•FIM Service Event Log

•Operations Manager Event Log on Mgmt. Server

Management Packs

•MPSyncJob Status in SCSM Console

•MP Deployment Status in SCSM Console

Data Warehouse ETL

•ETL Job Statuses in SCSM Console

•Operations Manager Event Log on Mgmt. Server

•Operations Manager Event Log on DW

Performance

•Hardware (especially RAM and storage speed) behind Data Warehouse Data Base

•Report filtering parameters

•Contention as a result of recurring maintenance jobs.

Known Issues and Solutions

The following is a list of known issues and resolutions that have been observed with FIM 2010 R2 Reporting.

After deploying reports to Data Warehouse, Initial sync fails with: System.Data.SqlClient.SqlException: Could not find stored procedure 'etl.GetDWSourceInfo'

Cause Solution Additional Notes

Forgetting to deploy the Data Warehouse Support Scripts

Install the Support Scripts before attempting to run initial synchronization.

After deploying reports to Data Warehouse, Initial sync fails with: “System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary”

Cause Solution Additional Notes

Most often caused by failing to deploy, or mis-deploying, the Data Warehouse Support Scripts.

Can also be caused by attempting to run initial sync before FIM MP deployment is finished.

Ensure that all FIM MPs are properly synchronized, then re-run Support Scripts deployment.

In extreme cases, you may need to re-install the Data Warehouse.

After deploying reports to Data Warehouse, Initial sync fails with SystemConstraint error.

Cause Solution Additional Notes

Reporting logging is not properly enabled on the FIM Service.

Navigate to Administration -> All Resources -> System Configuration Settings, and ensure “Reporting Logging Enabled” is set to “true”.

Reporting Logging

In RC, this can happen when you run a change install to install the reporting feature.

Event log will contain: System.InvalidOperationException: This service instance could not create a reporting job because ReportingLoggingEnabled setting is false.

Incremental sync job shows an error state* after installing FIM Reporting

Cause Solution Additional Notes

Initial synchronization has not yet been completed successfully

Start initial synchronization soon after installing reporting

In most cases, the error status on the job object has a detailed error message.

Data Warehouse Support Scripts have not been installed

Install Data Warehouse Support Scripts

In most cases, the error status on the job object has a detailed error message.

An incremental job was scheduled while another job was already running

Change incremental job schedule via FIMService DB SQL agent job editor

In most cases, the error status on the job object has a detailed error message.

Incremental / Initial sync job shows a timeout exception error.

Cause Solution Additional Notes

Contention on the Management Server database caused by pruning and grooming jobs running at the same time as the sync job. Most often caused by failing to deploy, or mis-deploying, the Data Warehouse Support Scripts.

Re-run incremental or initial synchronization.

To ensure this does not happen in the future, you may also wish to suggest that users ensure that no synchronization jobs are running at the same time as the SCSM Management Server pruning and grooming jobs

These pruning and grooming jobs run every day starting at 0:00.

You can change the reporting job schedule by going to the FIM SQL Agent Job scheduler and modifying the FIM_ScheduleReportingIncrementalSync job schedule.

Reports do not appear in SCSM console immediately after running Import-Report.

Cause Solution Additional Notes

Not waiting for MPSync to finish after importing new reports into SCSM.

Before checking the SCSM console or SSRS web browser interface, ensure that MPSync completes successfully so that your reports are loaded into the SCSM Data Warehouse.

“Data access service not running” error when running ImportSchema or ImportReport PowerShell cmdlets.

Cause Solution Additional Notes

Specifying an incorrect server name for the Service Manager Management Server.

Specify the correct server name for the Service Manager Server.

Can also be caused by the data access service being disabled on the Management Server.

Additionally, ensure that the Service Manager Data Access service is running on the Service Manager Management Server.

“XSD verification failed for the management pack. [Line: xx, Position: yy]” error when importing a new management pack using Import-FIMReportingSchemaDefinition

Cause Solution Additional Notes

Unexpected XML element type or value specified in SCSM Management Pack.

Inspect element on line xx. Position yy will tell you exactly where the error is in that line.

Example:

<Property ID=”ContosoShoeSize” Type=”integer” …>

Integer isn’t a proper data type for a property in the DW, therefore……this should be

<Property ID=”ContosoShoeSize” Type=”decimal”…>

Management pack fails to import into Data Warehouse, even after MPSync completes without error.

Cause Solution Additional Notes

Management pack was not sealed when it was imported into the Management Server.

Seal the Management Pack and attempt import again.

Inspect MPSync by going to DW –> DW Jobs -> MPSyncJob -> Details.

Look at Data Warehouse event log and Service Manager event log for detailed deployment errors.

To see real-time deployment status, you may also run the following: SELECT * FROM [dbo].[DeploySequenceView] on DWStagingAndConfig

Data does not seem appear in reports after a long period of time (several days).

Cause Solution Additional Notes

Data Warehouse ETL jobs may not be running frequently enough to move data.

Increase the frequency at which the Data Warehouse ETL jobs run.

Alternatively, FIM Reporting jobs may not be sending data appropriately to the Management Server.

Ensure that FIM service has the appropriate permissions on the SCSM Management Server.

Ensure that you have successfully deployed the Data Warehouse Support Scripts.

Data does not seem appear in reports after a long period of time (several days).

Cause Solution Additional Notes

Reports run slowly.

Increase RAM and / or storage speed of Data Warehouse SQL Database.

Additionally, choosing the “Show All MPRs / Approvers” option may also decrease report performance.

Alternatively, you can also filter the reports over a smaller date range, or more selective parameter set, to allow the reports to operate over a smaller set of data.

Group Membership Change report may run slowly on very large data sets.

When running incremental synchronization, you encounter the message "Data Warehouse Watermark Mismatch"

Cause Solution Additional Notes

This issue can be caused by data loss on either the FIM database or Data Warehouse databases. For example, if you recently restored your FIM database or Data Warehouse databases from a backup, and then attempted to run incremental synchronization, you may see this error. This is the result of the tracking mechanism between the FIM and DW databases (called a watermark) getting out of alignment due to data loss on one of the two databases.

This problem can be easily rectified by re-running initial synchronization. Re-running initial synchronization will NOT cause any data loss in this case, but will ensure that your watermarks are properly updated so that you can continue your incremental synchronization jobs. Do note, however, that if you have restored the Data Warehouse to an earlier point in time than the FIM database, then certain operations (such as group membership or set membership changes) that occured during the outage will not appear in your reports. Subsequent changes to these objects will, however, appear as expected after you re-run initial synchronization.

Duplicate deletion requests appear in the request history report

Cause Solution Additional Notes

In rare cases, when running initial synchronization a second time after one or more incremental synchronizations have been run, the request history report appears to have duplicate entries for deletion requests. Only requests which have not yet expired in the FIM Database will show this phenomenon.

Prune requests from the FIM database before running the second initial synchronization job. Do note that these duplicate deletion requests do not affect data integrity in any way, and can be safely ignored if they do occur.