Operations Manager Report subscription wizard asks you to specify a File Name when you choose Windows File Share delivery method. In most cases where you just need to have a most recent report delivered to the share you would just type a desired name in the field and look for the result then the time comes. If you would like to keep the history though, you would probably want to include something like a time stamp in the file name to keep the names unique and prevent reporting server overriding the results every time a new report is generated. To do the trick you can add @timestamp variable to the File name. For example: Report@timestamp. The resulted file name will look something like Report2009_10_05_000000 which would not only allow you to keep the names unique but would also give everyone an immediate idea on when the file was generated.
Read more about File Share Delivery in SQL Reporting Services documentation.
SCOM 2007 reporting infrastructure has an ability to invoke a view or execute a task defined in a Management Pack from a report. This functionally helps bringing context from the report "back" to the operation console. Most of the out-of-the-box SCOM 2007 reports leverage this feature to open various typed of monitoring or in certain cases even authoring views.
Reference to a view or a task is a regular RDL Hyperlink that points to a specially formatted URI. This formatting lets SCOM console to treat it as an execute a view or a task command rather than a report drill-down. There is a ConsoleIntegration class that helps in formatting console links correctly. This class is defined in the SCOM reporting code extension library (Microsoft.EnterpriseManagement.Reporting.Code.dll) that is shipped with the product and installed into Report Server Bin directory during setup. You need to reference this library to make it available for the report code to call.
<CodeModules>
<CodeModule>Microsoft.EnterpriseManagement.Reporting.Code, Version=6.0.0.0, Culture=neutral</CodeModule>
</CodeModules>
After the library is referenced you can start using it. Here is an example that references State view from a report:
<Textbox Name="textbox">
...
<Action>
<Hyperlink>= Microsoft.EnterpriseManagement.Reporting.ConsoleIntegration.CreateConsoleViewLink(
Fields!ManagementGroupGuid.Value,
"Microsoft.SystemCenter.StateView",
Fields!ManagedEntityGuid.Value)
</Hyperlink>
</Action>
...
</Textbox>
ConsoleIntegration class defines a set of overloads for links. Here is the list:
string CreateConsoleViewLink(
Guid managementGroupId,
string viewName,
Guid viewTarget)
string CreateConsoleViewLink(
string managementGroupId,
string viewName,
string viewTarget)
string CreateConsoleTaskLink(
Guid managementGroupId,
string taskName,
Guid taskTarget)
string CreateConsoleTaskLink(
string managementGroupId,
string taskName,
string taskTarget)
Since data warehouse can collect data for multiple management groups "managementGroupId" is a required parameter for all calls.
The important thing to remember is that these links make sense only in a context of SCOM console. They will fail to execute in case you try to clink on them in default SQL Report Manager interface. To avoid these failures you need to make sure you declare Interactive parameter in your report. SCOM console always sets this parameter to True when the report is executed in the console.
<ReportParameter Name="Interactive">
<DataType>Boolean</DataType>
<Nullable>true</Nullable>
<DefaultValue>
<Values>
<Value>=False</Value>
</Values>
</DefaultValue>
<Prompt>Interactive</Prompt>
<Hidden>true</Hidden>
</ReportParameter>
The last step is to make sure you use the parameter to hide hyperlinks in the report.
<Visibility>
<Hidden>=Parameters!Interactive.Value <> True</Hidden>
</Visibility>
Operations Manager 2007 R2 adds a set of valuable and long awaited features targeted to reporting users and report authors. Here is the list:
- Service Level Tracking reporting.
First step towards solving a problem of service level monitoring. Service Level Tracking "contract" along with tracking objectives needs to be created before the report could be run but they can use existing state and performance data that is already collected by the system.
- Saving reports to a Management Pack.
Now in addition to saving reports to Favorites and Publishing reports you can also save reports to a management pack. This solves a problem of sharing published reports with all reporting users in the organization. Reports get deployed to SSRS automatically after the management pack is imported in the system. Delete saved reports functionality is obviously also there.
- Class filtering for report object picker.
The feature allows filtering down search results to only certain classes of objects. Filter settings are available under "Options" button for both "Add Objects" and "Add group" functions.
This feature has most value when the list of supported classes is defined in a management pack. Not all the management packs take advantage of this feature though yet.
- Reporting support in Authoring console.
Authoring console now has a new "Reporting" space and exposes all available reporting elements including Reports, linked reports, scripts and resources. This feature for sure should simplify custom repot authoring a lot. There is no integrated editor for RDL and RPDL but existing files could be easily uploaded there.
- Improved search interface for performance rules.
Additional fields had been added to the search dialogs to help distinguish rules with the same name.
- Multi-selection parameters for Most Common Events report.
A set of SCOM 2007 SP1 specific training videos are now published on TechNet at http://technet.microsoft.com/en-us/opsmgr/bb986763.aspx. There are two videos out there I am doing on new reporting features in SCOM 2007 SP1. Here are the links:
Using the Microsoft Generic Report Library
This video demonstrates generic overrides report.
Running Time (minutes): 6:16
Using favorite reports and the report publishing feature
This video demonstrates favorite reports and report publishing features.
Running Time (minutes): 6:44
If you try editing some generic reports like Performance in Visual Studio you will get an error saying that EnterpriseManagementChartControl is not installed. The reason is that SCOM 2007 does not configure EnterpriseManagementChartControl development environment during normal install. If you like to use chart control designer in Visual Studio you would need to configure it manually. Here are the steps:
- Make sure SCOM 2007 Reporting is installed.
- Copy MicrosoftRSChart.dll and MicrosoftRSChartDesigner.dll from SSRS bin directory to Visual Studio private assemblies directory on your development machine.
Location of SSRS bin directory depends on the way you install SQL Sever but usually the path looks like this: \Program Files\Microsoft SQL Server\MSSQL.N\Reporting Services\ReportServer\bin
Visual Studio private assemblies directory usually could be found under \Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
- Find RSReportDesigner.config file in the Visual Studio private assemblies directory and add the following records to it:
<Configuration
>
<Extensions>
...
...
<ReportItemDesigner>
<ReportItem Name="EnterpriseManagementChartControl"
Type="Dundas.ReportingServices.DundasChartDesigner,
MicrosoftRSChartDesigner" />
</ReportItemDesigner>
<ReportItems>
<ReportItem Name="EnterpriseManagementChartControl"
Type="Dundas.ReportingServices.DundasChart,
MicrosoftRSChart" />
</ReportItems>
<ReportItemConverter>
<Converter Source="Chart" Target="EnterpriseManagementChartControl"
Type="Dundas.ReportingServices.RSChartConverter,
MicrosoftDundasRSChartDesigner" />
</ReportItemConverter>
</Extensions>
</Configuration>
- Restart Visual Studio.
Please note that these steps will only work with SCOM 2007 SP1 RC or later releases. The files mentioned here were not a part of SCOM 2007 RTM.
The Release Candidate of Service Pack 1 for Operations Manager 2007 is released and ready for download from http://connect.microsoft.com/systemcenter. This release is fully supported and it will be an upgrade form it to SP1 RTM.
SP1 RC is adding several interesting reporting features to the product. Here are some of them:
- Ability to view favorite reports in the Web Console.
- Report publishing functionality.
- Brand new Overrides report.
- Basic data warehouse capacity planning using data warehouse properties report.
- Improved availability reporting by introducing new "Monitoring Available" state.
Generic performance reports are ones of the most powerful generic reports in SCOM 2007. I like to start from "Performance Top Objects" and "Performance Top Instances" reports. They are the easiest and creating linked reports for them could be quite useful in case where you like to simplify customer experience in searching for objects or instances that are "on top" for a specific performance rule. In most cases the way to simplify the experience is to hard-code the rule in the linked report so the customers won't need to search for it.
If you haven't done this already I highly recommend reading "Linked availability reports" and "Linked reports" posts before continue. They cover some theory behind linked reports authoring. Reading "Report parameters block" and "Report parameter controls" could also be useful in understanding RPDL part of the story.
RuleId, SortOrder and TopCount are parameters that are customizable for "Performance Top" reports. "Performance Top Objects" report also has an additional RuleInstance parameter. This parameter is not valid for "Performance Top Instance" report since the rule instance is the result of the report rather then a filter.
RuleId
This parameter defines the rule report operates on. If you look at the actual report code (RDL file) you find that this parameter is in fact GUID of a performance rule in SCOM management group installation. You may ask me how could I know a GUID of the rule in a particular management group at the time of management pack authoring? The answer is you can't. Instead you should use a special $MPElement syntax which allows referencing of management pack elements by a system name at authoring time. $MPElement reference is resolved and converted to GUID automatically at the time of report deployment. Here is an example:
<Parameter Name="RuleId">
<Value>$MPElement[Name="SQL!Microsoft.SQLServer.2005.NumberDeadlocksPerSecond"]$</Value>
</Parameter>
SortOrder
This parameter switches report algorithm. Here is the list of possible values:
TopCount
This is "N" value for the SortOrder parameter. Specify any positive number here but be reasonable. Setting the value too high can make the report chart unreadable.
RuleInstance
As I said before this parameter only valid for "Performance Top Objects report". It is used in cases where you know an instance or a set of rule instances you like to include in the report filter criteria.
<Parameter Name="RuleInstance">
<Value>A</Value>
<Value>B</Value>
<Value>C</Value>
</Parameter>
Now when we know all these parameters it is a snap to define the lined report. As usually you should not forget about parameter definition for the new report. To simplify the process just copy and paste context of the Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTop.rpdl or Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTopInstance.rpdl. In most cases however you can choose to remove some parameter controls from the block to disallow users changing the parameters you specified. The most common control to disable is the rule picker, but you can choose to remove TopCount and/or SortOrder as well. Here is the complete example:
<LinkedReport ID="Demo.Bottom10DeadlockedDatabases"
Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTop">
<ParameterBlock columns="2" xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">
<Controls>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker">
<ReportParameters>
<ReportParameter name="TimeZone" binding="TimeZone">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone
</Prompt>
</ReportParameter>
<ReportParameter name="TimeZoneName" binding="TimeZoneName" />
<ReportParameter name="StartDate_BaseType"
binding="StartDate_BaseType" />
<ReportParameter name="StartDate_BaseValue"
binding="StartDate_BaseValue">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime
</Prompt>
</ReportParameter>
<ReportParameter name="StartDate_OffsetType"
binding="StartDate_OffsetType" />
<ReportParameter name="StartDate_OffsetValue"
binding="StartDate_OffsetValue" />
<ReportParameter name="EndDate_BaseType"
binding="EndDate_BaseType" />
<ReportParameter name="EndDate_BaseValue"
binding="EndDate_BaseValue">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime
</Prompt>
</ReportParameter>
<ReportParameter name="EndDate_OffsetType"
binding="EndDate_OffsetType" />
<ReportParameter name="EndDate_OffsetValue"
binding="EndDate_OffsetValue" />
</ReportParameters>
</Control>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">
<ReportParameters>
<ReportParameter name="ManagementGroupId">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementGroup
</Prompt>
</ReportParameter>
</ReportParameters>
</Control>
</Controls>
</ParameterBlock>
<Parameters>
<Parameter Name="RuleId">
<Value>$MPElement[Name="SQL!Microsoft.SQLServer.2005.NumberDeadlocksPerSecond"]$</Value>
</Parameter>
<Parameter Name="SortOrder">
<Value>1</Value>
</Parameter>
<Parameter Name="TopCount">
<Value>10</Value>
</Parameter>
</Parameters>
</LinkedReport>
The question keeps popping up so I decided to put this on my blog. SCOM 2007 console does not have an ability to create a new Report Operator user role. Part of the reason is that there is no UI to grant permissions to individual reports from SCOM console either. You can however grant permissions to reports using standard SSRS Report Manager interface as it described in the SCOM documentation (How to Set Permissions on a Report Using Command Shell in Operations Manager 2007). The one thing which is left unspecified is how to create a new Report Operator role so you can put users you like to grant or restrict access to into it.
So here is a script to create a new Report Operator user role using Command Shell:
$mg = (get-item .).ManagementGroup
$reportOperator = $mg.GetMonitoringProfiles() | where {$_.Name -eq "ReportOperator"}
$obj = new-object Microsoft.EnterpriseManagement.Monitoring.Security.MonitoringUserRole
$obj.Name = "TestReportOperatorRole"
$obj.DisplayName = "Test Report Operator Role"
$obj.Description = "Test Report Operator Role"
$obj.MonitoringProfile = $reportOperator
$mg.InsertMonitoringUserRole($obj)
After you execute this script “Test Report Operator Role” appears in UI and you would be able to add users to it using User Role Properties dialog.
Several customers asked us lately if there is a way of getting actual values the performance report charts are generated on in a tabular form. Even thought this is not possible in the Performance report it is in fact possible with the Performance Detail report.
Performance Detail report could be either run directly or as a drill down from the Performance report. The report shows detailed performance chart along with a summary table below. If you choose to display histogram in the parameter block a “Detail Table” link appears inside the summary table. The link allows you to see a value table the chart is based on.
Unfortunately in RTM version of SCOM the “Detail Table” link is disabled for non-histogram reports. However if you export this non-histogram report to Excel or XML format the value table will be exported as well and could be easily viewed or used in your custom application.
Availability report is one of the easiest reports to create links to. The report is based on the monitor state changes. There are not that many parameters to control besides list of monitoring objects, monitor states considered to be downtime and essentially the monitor.
One important thing to understand in linked report authoring is that objects should never be used as a hard-coded parameters to your reports. Monitoring objects are specific to a particular SCOM management group installation and could not be known at the time the management pack is created.
Monitor and downtime states on the other hand are things that are well known at the authoring time. Hard-coding them could be quite useful in cases where you either want to look at the particular monitor or when your organization has some specific rules around downtime definition.
Let's say we like to create an availability report based on ping status assuming that device is not available when the monitor is in down or warning states. Here is a definition of such report:
<LinkedReport ID="Demo.ComputerPingHealth"
Accessibility="Public" Visible="true" Base="Reporting! Microsoft.SystemCenter.DataWarehouse.Report.Availability">
<Parameters>
<Parameter Name="MonitorName">
<Value>Microsoft.SystemCenter.Ping</Value>
</Parameter>
<Parameter Name="DownTime">
<Value>2</Value>
</Parameter>
</Parameters>
</LinkedReport>
Notice that we put only value 2 for DownTime parameter even though I said we will consider both monitor down (red) and warning (yellow) states as downtime. This is because "monitor down" state is always considered as downtime regardless of what we specified it in the DownTime parameter.
Here is the list of all possible values for the DownTime parameter:
| Warning |
2 |
| Planned Maintenance |
6 |
| Unplanned Maintenance |
5 |
| Monitor disabled |
4 |
| Unmonitored |
3 |
The last thing to do is to create parameter definition for the new report. To simplify the process just copy context of the Microsoft.SystemCenter.DataWarehouse.Report.Availability.rpdl there. Here is the result:
<LinkedReport ID="Demo.ComputerPingHealth"
Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.Availability">
<ParameterBlock columns="4" xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">
<Controls>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">
<ReportParameters>
<ReportParameter name="DataAggregation">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation
</Prompt>
</ReportParameter>
</ReportParameters>
</Control>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" columnSpan="2" rowSpan="2">
<ReportParameters>
<ReportParameter name="ObjectList">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ObjectList
</Prompt>
</ReportParameter>
<ReportParameter name="ManagementGroupId" binding="GroupList"/>
</ReportParameters>
</Control>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="2">
<ReportParameters>
<ReportParameter name="DownTime">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime
</Prompt>
</ReportParameter>
</ReportParameters>
</Control>
<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker">
<ReportParameters>
<ReportParameter name="TimeZone" binding="TimeZone">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone
</Prompt>
</ReportParameter>
<ReportParameter name="TimeZoneName" binding="TimeZoneName" />
<ReportParameter name="StartDate_BaseType"
binding="StartDate_BaseType" />
<ReportParameter name="StartDate_BaseValue"
binding="StartDate_BaseValue">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime
</Prompt>
</ReportParameter>
<ReportParameter name="StartDate_OffsetType"
binding="StartDate_OffsetType" />
<ReportParameter name="StartDate_OffsetValue"
binding="StartDate_OffsetValue" />
<ReportParameter name="EndDate_BaseType"
binding="EndDate_BaseType" />
<ReportParameter name="EndDate_BaseValue"
binding="EndDate_BaseValue">
<Prompt>
Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime
</Prompt>
</ReportParameter>
<ReportParameter name="EndDate_OffsetType"
binding="EndDate_OffsetType" />
<ReportParameter name="EndDate_OffsetValue"
binding="EndDate_OffsetValue" />
<ReportParameter name="TimeType" binding="TimeType" />
<ReportParameter name="TimeWeekMap"
binding="TimeWeekMap" />
</ReportParameters>
</Control>
</Controls>
</ParameterBlock>
<Parameters>
<Parameter Name="MonitorName">
<Value>Microsoft.SystemCenter.Ping</Value>
</Parameter>
<Parameter Name="DownTime">
<Value>2</Value>
</Parameter>
</Parameters>
</LinkedReport>
Nearly any report requires you to fill some parameters before you run it. Most commonly you are asked to provide a date range, objects you are interested in and maybe some other parameters that drive report content.
"Report parameters block" is the place where all these parameters are entered. Report parameters block consist of a set of report parameter controls. Each parameter control defines a visual representation for one or more underlying report parameters.
Report parameter controls used for a particular report are defined in the RPDL file.
Here is the schema for them:
<xs:element name="Control" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="ReportParameters" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="ReportParameter"
minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="Prompt" type="xs:string"
minOccurs="0" maxOccurs="1" />
</xs:sequence>
<xs:attribute name="name" type="xs:token" use="required" />
<xs:attribute name="binding" type="xs:token" use="optional" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Properties" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="Property"
minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="Value" type="xs:string"
minOccurs="1" maxOccurs="1" />
</xs:sequence>
<xs:attribute name="name" type="xs:token" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="type" type="xs:token" use="optional" />
<xs:attribute name="columnSpan" type="xs:unsignedByte" use="optional" />
<xs:attribute name="rowSpan" type="xs:unsignedByte" use="optional" />
</xs:complexType>
</xs:element>
As you can see from the schema parameter control has a list of underlying report parameters it uses. The way it uses them is defined by "binding" attribute. Binding are defined by specific control code. You cannot change the way it is handled but you can set which report parameter is used for it. "Empty" or default binding is usually used for a report parameter the control sets value for but this is not a strict rule.
Next section is parameter control properties. It's a name multi-value collection. These properties changes control behavior or visual appearance. An example of a property could be control maximum width or background color.
All "out of the box" report parameter controls are defined in Microsoft.SystemCenter.DataWarehouse.Report.Library management pack. Here are some most commonly used ones:
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
TextBox
A way to enter string parameter value. Replaces standard SSRS text box control.
Bindings
Default
Parameters
Multiline (True/False)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
BooleanPicker
A way to enter parameter value of Boolean type. Replaces standard SSRS Boolean picker
Bindings
Default (report parameter has to be Boolean type)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
ComboBox
A way to select a value from a set. Replaces standard SSRS value picker control.
Bindings
Default (report parameter has to have a list of valid values)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
CheckedListBox
A way to select multiple values from a list of valid ones. Replaces standard SSRS multi-value value picker control.
Bindings
Default (report parameter has to be a multi-value parameter with a list of valid values)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
DatePicker
A way to select date value. Replaces standard SSRS date picker control.
Bindings
Default (report parameter has to be DateTime type)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
DateTimePicker
A way to select date and time value.
Bindings
Default (report parameter has to be DateTime type)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
NumericUpDown
A way to select an integer value.
Bindings
Default (report parameter has to be Integer type)
Parameters
Minimum (minimum possible integer value)
Maximum (maximum possible integer value)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
RelativeDateTimePicker
A way to select relative date time range. Microsoft.EnterpriseManagement.Reporting.ParameterProcessor class is used on the report side to process values entered by this control.
Bindings
TimeZone (time zone reference)
TimeZoneName (name of the time zone displayed in the report)
StartDate_BaseType (start date base type)
StartDate_BaseValue (start date base value)
StartDate_OffsetType (type of start date offset)
StartDate_OffsetValue (start date offset value)
EndDate_BaseType (end date base type)
EndDate_BaseValue (end date base value)
EndDate_OffsetType (type of end date offset)
EndDate_OffsetValue (end date offset value)
Parameters
MaxWidth (control maximum width in pixels)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
BusinessRelativeDateTimePicker
A way to select relative date time range with business hours. Microsoft.EnterpriseManagement.Reporting.ParameterProcessor class is used on the report side to process values entered by this control.
Bindings
TimeZone (time zone reference)
TimeZoneName (name of the time zone displayed in the report)
StartDate_BaseType (start date base type)
StartDate_BaseValue (start date base value)
StartDate_OffsetType (type of start date offset)
StartDate_OffsetValue (start date offset value)
EndDate_BaseType (end date base type)
EndDate_BaseValue (end date base value)
EndDate_OffsetType (type of end date offset)
EndDate_OffsetValue (end date offset value)
TimeType (type of time entered (business or regular))
TimeWeekMap (days of week selected for business time)
Parameters
MaxWidth (control maximum width in pixels)
Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.
MonitoringObjectPicker
A way to select monitoring object for report. List of Monitoring Object IDs are passed to the report as a result value (default binding).
Bindings
Default (report parameter has to be multi-value Integer type)
GroupList (list of management groups objects are allowed to be selected from)
It is not a secret that standard way of presenting report parameters in SQL Server Reporting Services does not give you much flexibility. Designing reporting solution for SCOM 2007 we wanted to change that and enable a way reach controls could be used for report parameter selection. Imagine yourself scrolling though a list of all computers in your organization trying to pick a particular one. We didn’t want that to happen…
As you know report parameters are traditionally defined in the RDL file. The RDL file parameter definition contains name, type, list of valid values, default value etc. It also contains parameter presentation attributes like display name and hidden flag. Standard SSRS parameter block layout logic is very simple: visible parameters are rendered in two columns (from left to right then from top to bottom) based on the order of parameters in the RDL file.
In SCOM 2007 we introduced report parameter definition block which provides additional layout and parameter presentation logic. The parameter block definition is stored in the RPDL (Report Parameter Definition Language) file. This file has to be stored in the same folder with the repot and have report name with ".rpdl" extension.
RPDL file is optional. SCOM 2007 will render parameters similarly to standard SSRS parameter block if you do not specify one.
What is inside RPDL file? Let’s take a look. Here is an example:
<ParameterBlock
columns="3"
xmlns="http://schemas.microsoft.com/mom/reporting/2007/
ReportParameterSettings">
<Controls>
<Control rowSpan="2" columnSpan="2"
type="Microsoft.SystemCenter.DataWarehouse.Report.
ParameterControl.MonitoringObjectXmlPicker">
<ReportParameters>
<ReportParameter name="ObjectList" />
<ReportParameter name="ManagementGroupId"
binding="GroupList" />
</ReportParameters>
</Control>
<Control
type="Microsoft.SystemCenter.DataWarehouse.Report.
ParameterControl.ComboBox">
<ReportParameters>
<ReportParameter name="Threshold" />
</ReportParameters>
</Control>
<Control
type="Microsoft.SystemCenter.DataWarehouse.Report.
ParameterControl.ComboBox">
<ReportParameters>
<ReportParameter name="AggregationType" />
</ReportParameters>
</Control>
</Controls>
</ParameterBlock>
As you can see the parameter block XML has a list of parameter controls. This is similar to parameters definition in RDL file. The difference however is that RDL defines parameters while RPDL defines controls to edit the parameter values. Control can manage or use one or more parameters in the underlying report. Controls are defined in a management pack and can have different implementation depending on what platform they are running.
RPDL still uses left to right / top to bottom layout model but you can control how many columns you have and define if you like controls to span several rows or columns to achieve desired parameters layout.
It’s unfortunate but SCOM 2007 RTM does not have an ability to publish favorite reports back to the reporting server. It can however be done manually. The best way to do this is to create a linked report. Console will show the report even if it is not part of the MP. The recommend way obviously would be to put such reports in a separate folder so they wouldn't be accidently removed by the auto-deployment module (read more about reporting catalog organization at my previous post "SCOM 2007 Report Catalog").
Linked reports are shortcuts to reports with different parameters. Favorite reports are pretty much the same thing. The difference is that linked reports are published to reporting server and could be potentially shared among all SCOM users while favorite reports are very personal things created by the user and used by that user only. Favorite reports are not stored on the reporting server. They are stored in the user settings collection in SCOM operational database instead.
SCOM Command Shell could be used to get a list of favorite reports along with their definitions from the database. Running the following command in the will give you your list of all favorite reports:
$userSettings = (get-item .).ManagementGroup.GetUserSettings()
$userSettings.GetFavoriteMonitoringReports()
To get specific report by name use the following command:
$userSettings = (get-item .).ManagementGroup.GetUserSettings()
$userSettings.GetFavoriteMonitoringReport("<report name>")
Looking at the result you will find that every report contains bunch of fields. The important ones we are looking for are: Name (the one see in the console), list of parameters (ReportParameters) in XML format and MonitoringReportPath which is full part to the original report in the SSRS. The last two pieces are actually all you need to know to create a linked report. All you need to do now is go to SSRS Report Manager, find a report corresponding to MonitoringReportPath, go it its properties, click "Create Linked Report" and carefully paste parameter values for from the ReportParameters XML to the report Parameter section. Easy huh? Actually not. I know. I hope we can do UI for it soon...
After you created a linked report don’t forget to copy the corresponding RPDL file to the same location you put linked report at and five it the same name as the linked report has with .rpdl extension. This will ensure you have nice parameter block for your linked report in the console.
In SCOM 2007 we tried to make out of the box reports as generic and as configurable as possible. The result of these efforts is more possibilities with actually much less work from your side to customize reports to needs of your organization or your custom application. The customization is done though linked reports. Linked reports are widely used in management packs for specific products like SQL Server or Windows Server. If you look at most management packs besides “Microsoft Generic Report Library” they mostly contain linked reports or in a lot of cases only linked reports.
What is the linked report anyway? In short, it is a shortcut to a report. You can read more about SQL Server Reporting Services linked reports concept here. The best part of the linked report concept that makes linked reports so useful in SCOM 2007 is that you can specify different default report parameter values and define a different way parameters are presented to the user. For instance you can create a linked performance report with a set of hardcoded performance rules. If you’ve done that you would never need to think about which rules to pick to check your application performance.
So, how do I create a linked report? The best way to do that is again in a management pack. Here is an example:
<Reporting>
<LinkedReports>
<LinkedReport ID="Demo.MyApplicationHealth"
Accessibility="Public" Visible="true" Base="Reporting!Microsoft.SystemCenter.DataWarehouse.Report.Availability">
<Parameters>
<Parameter Name="DataAggregation">
<Value>1</Value>
</Parameter>
<Parameter Name="DownTime">
<Value>2</Value>
<Value>3</Value>
</Parameter>
<Parameter Name="MonitorName">
<Value>System.Health.EntityState</Value>
</Parameter>
</Parameters>
</LinkedReport>
</LinkedReports>
</Reporting>
Linked report ID, Accessibility and Visible attributes have the same meaning as with regular report (see "Reports in Management Packs" post). The new attribute here is Base. Base tells which report this is a shortcut to. In our case it is a generic availability report. You can use any publicly defined report here from any MP. Just don’t forget to include a reference to that MP if this is not the same one you are putting the linked report into. In our case the required reference would be:
<Reference Alias="Reporting">
<ID>Microsoft.SystemCenter.DataWarehouse.Report.Library</ID>
<Version>MANAGEMENTPACK_VERSION</Version>
<PublicKeyToken>MANAGEMENTPACK_PUBLIC_KEY_TOKEN</PublicKeyToken>
</Reference>
Parameters section is the next thing that defines linked report. This is the section where we specify which parameter values we like to override in the original report. In our case we are saying that health of you application is defined by System.State.EntityHealth monitor and we consider Warning (2) and Unmonitored (3) states as downtime. We also say that we like to use “Houtly” (1) aggregations for our report to speed up report query execution.
As in case with custom report we probably want to provide a display name for this linked report so it is displayed nicely in the console.
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
<DisplayString ElementID="Demo.MyReport">
<Name>My Report</Name>
<Description>My First SCOM 2007 Report</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
That is pretty much all you need to do to define a new linked report. One thing I didn’t tell you about is report parameters presentation. If base report defines custom parameter presentation settings (all SCOM 2007 generic reports do by the way) you most likely would need to define it for the linked report as well. If you would, for example, create a linked report using exact XML I provided in this example you would see that your report has some odd parameters when you open it in the console. That would happen exactly because we didn’t defined any parameter block settings and SCOM generated a default ones for us.
Parameter block definition is a subject for a separate discussion I am planning to shed some light on next. Stay tuned...
In my previous post “Authoring reports for SCOM 2007” I said that there are basically tree ways to author new reports for SCOM 2007. Create a linked report, use Report Builder or create a custom report using Visual Studio. The best way to introduce a new report in the system is to include it in a Management Pack (read “SCOM 2007 Report Catalog” post for details).
Any Management Pack (MP) can contain reports. If you have RDL file you can simply paste it content under Reporting/Report/Definition node in the MP.
Here is an example:
<Reporting>
<Reports>
<Report ID="Demo.MyReport" Accessibility="Public" Visible="true">
<Definition>
[Paste content of the RDL file here...]
</Definition>
</Report>
</Reports>
</Reporting>
ID is the name your report is deployed under to the SSRS. ID is also a reference for your report inside the Operations Manager. It has to be unique inside the MP and if you specify Accessibility="Public" other management packs could reference your report if they like to use it as a drill-down or as a sub-report.
Your report is going to be visible inside the catalog if you set Visible to "true". Specify "false" if you author a sub-report or a drill down report that you don’t like to be a part of the list of reports users can run directly.
That’s it! Your report is ready to go. To complete the picture however you probably want to give you report a friendly name. That name is displayed in the console when user clicks on your management pack inside the Reporting navigation tree.
To give your report a friendly name you need to define a display string inside the management pack and target it to your report ID.
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
<DisplayString ElementID="Demo.MyReport">
<Name>My Report</Name>
<Description>My First SCOM 2007 Report</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
