Funny, I'm doing the same thing here currently but with getting Thresholds and stuff using the SDK.

Chad,



It is very nice report. Thanks for sharing. in order to run the report do we have to set additional permission? When you launch the report it is trowing following error'



Note: The following information was gathered when the operation was attempted. The information may appear cryptic but provides context for the error. The application will continue to run.



Microsoft.Reporting.WinForms.ReportServerException: An error has occurred during report processing. (rsProcessingAborted) ---> Microsoft.Reporting.WinForms.ReportServerException: Query execution failed for dataset 'list_object'. (rsErrorExecutingCommand) ---> Microsoft.Reporting.WinForms.ReportServerException: The EXECUTE permission was denied on the object 'sp_syscentered_managedentity_fortypename', database 'OperationsManagerDW', schema 'dbo'.

--- End of inner exception stack trace ---

--- End of inner exception stack trace ---

at Microsoft.Reporting.WinForms.ServerReport.GetExecutionInfo()

at Microsoft.Reporting.WinForms.ServerReport.GetParameters()

at Microsoft.EnterpriseManagement.Mom.Internal.UI.Reporting.Parameters.ReportParameterBlock.Initialize(ServerReport serverReport)

at Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ReportForm.SetReportJob(Object sender, ConsoleJobEventArgs args)

Microsoft.Reporting.WinForms.ReportServerException: Query execution failed for dataset 'list_object'. (rsErrorExecutingCommand) ---> Microsoft.Reporting.WinForms.ReportServerException: The EXECUTE permission was denied on the object 'sp_syscentered_managedentity_fortypename', database 'OperationsManagerDW', schema 'dbo'.

--- End of inner exception stack trace ---

Microsoft.Reporting.WinForms.ReportServerException: The EXECUTE permission was denied on the object 'sp_syscentered_managedentity_fortypename', database 'OperationsManagerDW', schema 'dbo'.

Sorry about the security oversight. If you run the below against your datawarehouse DB, it should take care of it. All the SQL below does is grants execute rights to the stored procedures to the OpsMgrReader application role. I will update the Management Pack tonight to include this in the build script.





GRANT EXEC ON [dbo].[sp_syscentered_collectedperfmoncounters_formanagedentity] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_managedentity_fortype] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_managedentity_fortypename] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_managedentitytype] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perf] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perf_daily] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perf_hourly] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perf_raw] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perfcounters_counter_forobject] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perfcounters_instance_forcounter] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perfcounters_object_forobject] TO OpsMgrReader

GRANT EXEC ON [dbo].[sp_syscentered_perfruleinstance_getfromobjectcounterinstance] TO OpsMgrReader

The multiple computers reports will be a little bit slower, but should be livable.



What would you guys prefer, to have the computer parameters in the drop down or to use the SCOM parameter block?



The reason behind having the drop down is so that the reports can be ran from Reporting Services, not requiring SCOM and still allowing for parameters. The advantage to the SCOM parameter block is that the report will take the user's security context. I may just have two MP's, it shouldn't take too much more work.