Section 8.2. Administering MOM 2005 Reporting

8.2. Administering MOM 2005 Reporting

If you skipped to this section from the beginning of Chapter 4 to install MOM 2005 Reporting before importing your management packs and reports at the same time, congratulations! You have saved yourself some re-work. Now that MOM 2005 Reporting has been installed and is functioning correctly, import the management packs with the processing rules and reports.

The report import process brings the report definition into the ReportServer database and creates the correct fields in the SystemCenterReporting database so the operational data is received when it comes over from OnePoint. It also creates a folder hierarchy that is seen in Report Manager in the Home folder as a peer-level folder to the Microsoft Operations Manager Reporting folder in Figure 8-10.

SRS is a product in its own right. Fortunately, just as in the case of SQL 2000, you do not need to be fully versed in SRS as a MOM administrator. In fact, the number and complexity of administrative tasks that must be performed to provide basic functionality are few and are really quite simple. There are a number of additional tasks that you will probably need to do, so this next section covers those as well. Once you get beyond enabling rudimentary functionality, how much more you provide depends on your business needs.

8.2.1. Required Administrative Tasks

By default, at the end of a successful installation and DTS transfer of data, the only group that can access the available reports is the Local Administrators group, which is secure but not very functional. To permit your users to access reports, each user's AD account must be associated with an SRS item-level role. Item-level roles are used to control what actions can be performed by a designee on SRS folders and their contents. The association can be created directly between the account and the role or between an AD security group in which the account has membership and a role. In SRS, a role is defined by the tasks it can perform in the context of the web site. Roles do not exist outside of the Report Manager web site.

If you are familiar with Windows Sharepoint Services, an SRS role is identical to a site group. In fact, much of the functionality in the Report Manager site and the security model is based on functionality in Windows Sharepoint Services.

In SRS, two groups of tasks are used to define roles to which user accounts are assigned. Some of the roles include System Administrator, System User, Content Manager, My Reports, and Publisher. There are item-level tasks and system-level tasks. Tables 8-1 and 8-2 provide the details of the different tasks and the roles that they have been used to define. This is viewable in Report Manager under Site Settings Configure System - Role definitions.

Table 8-1. System-level role definitions
Role	Task	Description
This role is not assigned by default	Generate events	Provide an application with the ability to generate events within the report server namespace
System Administrator	Manage jobs	View and cancel running jobs
System Administrator	Manage report server properties	View and modify properties that apply to the report server and to items managed by the report server
System Administrator	Manage report server security	View and modify system-wide role assignments
System Administrator	Manage roles	Create, view, modify, and delete role definitions
System Administrator	Manage shared schedules	Create, view, modify, and delete shared schedules used to run or refresh a report
System User	View report server properties	View properties that apply to the report server
System User	View shared schedules	View a predefined schedule that has been made available for general use

Table 8-2. Item-level role definitions
Role	Task	Description
Content Manager, My Reports, Publisher	Create linked reports	Create linked reports and publish them to a report server folder
Content Manager	Manage all subscriptions	View, modify, and delete any subscriptions regardless of who owns the subscription
Content Manager, My Reports, Publisher	Manager data sources	Create and delete shared data source items; modify data source properties
Content Manager, My Reports, Publisher	Manage folders	Create, view, and delete folders; view and modify folder properties
Browser, Content Manager, My Reports	Manage individual subscriptions	Each user can create, view, modify, and delete subscriptions that he owns
Content Manager, My Reports	Manage report history	Create, view, and delete report history snapshots; modify report history properties
Content Manager, My Reports, Publisher	Manage reports	Create, view, and delete reports; modify report properties
Content Manager, My Reports, Publisher	Manage resources	Create, modify, and delete resources; view and modify resource properties
Content Manager	Set security for individual items	View and modify security settings for reports, folders, resources, and shared data sources
Content Manager, My Reports	View data sources	View shared data source items in the folder hierarchy; view data source properties
Browser, Content Manager, My Reports	View folders	View folder items in the folder hierarchy; view folder properties
Browser, Content Manager, My Reports	View reports	View reports and linked reports in the folder hierarchy; view report history snapshots and report properties
Brower, Content Manager, My Reports	View resources	View resources in the folder hierarchy; view resource properties

The best way to grant users permission to reports is to add their AD accounts to the domain-level SCDW readers group that you created in Chapter 2. Then, add that domain group to the local SCDW readers group on the reporting server. This grants those users the necessary SQL permissions to use SRS. The last step is to assign the local SCDW readers group to an item-level role. To do this, log onto Report Manager as a local administrator, select the Properties tab of the Home folder (point 1 in Figure 8-11) and then select the New Role Assignment link (point 2 in Figure 8-11).

This chapter emphasizes using the SCDW readers local group for assigning users to roles, but you can create associations between any domain, local user, or group and any role. In addition, you can create new roles simply by creating a grouping of items or system-level tasks into a named role in the site settings page under the configure item-level or system-level role definitions links. What you can't do is create new item- and system-level tasks.

Figure 8-11. Creating a new role assignment

Out of the item-level roles defined in Table 8-2, you must pick one to assign the bulk of your users to. I strongly recommend that you don't assign the average MOM report consumer to either the Content Manager role or the Publisher role. There is simply no need for this group of users to have that much power in your MOM 2005 reporting solution. That leaves the Browser and My Reports roles, and there are significant differences between the two.

Browser: Users that are assigned this role will be able to execute all reports and manipulate the parameters of those reports. They can also create a subscription to that report for themselves.
My Reports: Think of this role as the power user role for SRS. It allows the user to do everything the Browser role can, plus create and maintain persistent customized reports in their own My Reports folder.

As shown in Figure 8-12:

Enter the <machine>/sc dw, in this case homemomserver3/sc dw reader (point 1).
Select the My Reports role (point 2).
Click OK (point 3).

All user accounts can now perform the tasks of the My Reports role across all folders in the hierarchy. Just as with a filesystem folder hierarchy, all permissions flow down from the top level unless you specifically configure a child folder not to inherit the permissions from its parent folder. This also holds true for items within a folder.

Remember that a report consists of a data source definition, a query, and a layout or report definition. When a user clicks on a report to view it, depending on the report, certain selections will have to be made to fill out the query's value fields. For example, Figure 8-13 shows the Agent Configuration report. To navigate to this from the Home folder, select Microsoft Operations Manager Reporting Microsoft Operations Manager Agent Configuration.

Figure 8-12. Completing the initial role assignment for your users

Figure 8-13. Selecting the report parameters

Before the query behind this report can run (execute) against the SystemsCenterReporting database, values (parameters) must be supplied for the management group, agent, and primary server fields. Defaults have been supplied for the Sort Order and Sort By fields, but as you can see by the drop-down boxes for those parameters, they can be changed. For the report in Figure 8-13:

Select LKFProdMG Management Group for the Management Group field (point 1).
Leave <ALL> for the agent field.
Select homemomserver for the primary server field and then click View Report (point 2).

This will then execute the report and display the results in the pane beneath the parameters pane.

Users will have their own preferences for report parameters based on their needs. Once a user in the Browser role finds those preferences, she may subscribe to that report (point 3 in Figure 8-13). A report subscription requires the definition of all the same report parameters, as well as the definition of the desired format of the report, the delivery mechanism, schedule, and credentials if necessary. SRS will then render the report, using the defined parameters, in the defined format, and deliver it via the selected mechanism (to a mailbox or a file share). You cannot manipulate the parameters of the delivered report.

The Browser role is good for users who don't want to navigate the Report Manager interface on a daily basis and set report parameters. Typically, this type of user just wants the report to appear in his email inbox or in the same filesystem folder on a regular basis with no questions asked. If this description fits the bulk of your user population, then assign the Browser role to the SCDW readers group.

If your reporting business requirements are met by assigning your users the Browser role, then you have completed all of the MOM 2005 Reporting administrative tasks that must be done. However, this is unlikely to be the case. Additional business requirements, as demonstrated in the Leaky Faucet environment, include ensuring that certain reports are not publicly accessible and that the executives can get access to reports with minimal interaction with IT. To design a solution to meet these needs, your users must be assigned to other roles.

8.2.2. Additional Administrative Tasks

You may want to assign the My Reports role to the bulk of your users. What distinguishes this role from the Browser role is its ability to create folders and linked reports. These two abilities, along with enabling the My Reports feature, can be used together to deliver a good deal of customization in your reporting solution.

8.2.2.1. Enabling the My Reports feature

When the My Reports feature is enabled, a new folder (titled My Reports) will appear in the Home folder for every user that has access to MOM 2005 reporting. The idea behind the My Reports folder is to give users a private place to store reports that they are working with. This folder is not viewable by other users, but administrators will have a Users folder created on their home page that will allow them full access to all users' My Reports folders and their contents. To enable the My Reports feature:

Open Report Manager as an administrator of the Reporting Services machine.
Select the Site Settings link in the top right-hand corner of the page. This takes you to the Site Settings page (see Figure 8-14).
Select the checkbox to enable My Reports, leave the default role setting, and click Apply at the bottom of the page.

Figure 8-14. Enabling the My Reports feature

To take advantage of the My Reports folder, your users must be assigned to the My Reports role as shown in Figure 8-12. Again, you don't have to use the SCDW readers group for this role assignment if you have already created an association between it and another role. Simply create another group, add your users, and create the association.

Each user's My Reports folder can be used similarly to the My Views container in the Operator console. In the My Views container, you create and store customized versions of view objects; in the My Reports folder, you store customized versions of existing reports, called linked reports . However, with the My Reports folder you can also upload supporting files, also called resources . This is another feature taken directly from Windows SharePoint Services document libraries.

8.2.2.2. Creating a linked report in a My Reports folder

A linked report is a personal version of a public report. In the linked version, which is best stored in the My Reports folder, you can define the parameters for the report. This specific report configuration is then retained in the linked report so it becomes the default configuration for that linked report. The advantage of this over the subscription report version is that you can still interact with the report because it has not been rendered into a static format.

Linked reports are created from the Properties tab of an existing report. In Figure 8-15, browse to the Home Microsoft Operations Manager Reporting Microsoft Windows Base OS folder Operating System configuration report and select the Properties tab. Additional entries (point 1 in Figure 8-15) are available here that would not be available via the Browser role. The security link is missing because the Content Manager role is required to access that. Security for this individual report is configured at that point. Click the Create Linked Report link to start the creation process (point 2 in Figure 8-15).

Figure 8-15. Creating a linked report from a report's Properties tab, General page

On the next page, you enter a new name for the linked report, prepending the user name to the report name (point 1 in Figure 8-16). In the description field, it is a good idea to record what distinguishes this report from the default report. Select the Change Location button (point 2 in Figure 8-16) so that the newly created linked report can be placed into the My Reports folder.

Figure 8-16. Naming a linked report and changing its location

On the change location page, the entire folder hierarchy is displayed (see Figure 8-17). A user that is in the My Reports role can place this report in any of the existing folders, just as a custom view can be moved from the My Views container to a publicly available view folder. Navigate to the My Reports folder for LKFRemoteSiteAdmin1 and click OK.

Figure 8-17. Placing the linked report in the My Reports folder

In Figure 8-17, the page has changed slightly. The Location string now points to /Users Folders/Homelab LKFRemoteSiteAdmin1/My Reports. Click OK and navigate to the My Reports folder. Here, select the report, the Properties tab, and then the Parameters page.

On this page (Figure 8-18), change the value for the CompGroup and the SortBy values. The default settings for these fields are:

CompGroup: Blank, and the Null checkbox is selected
SortBy: Server name
Direction: Ascending

Figure 8-18. Configuring custom default parameters for a report

To set the CompGroup value to be Microsoft Windows Servers by default, clear the Null checkbox (point 1 in Figure 8-18) and enter the desired value. The report is also to be sorted by Operating System Version (point 2 in Figure 8-18), so that value is changed. Notice the Prompt User checkboxes to the right of points 1 and 2. By leaving these checked, the report will still allow the values in these fields to be changed from the defaults on the View page. If these checkboxes are cleared, the report will automatically execute using the defined default values when the View page is opened and there is no prompting for values. Figure 8-19 shows the rendered report using the new default values.

The report icon in the upper left-hand corner has changed and now includes a chain, symbolizing the linked nature of the report. So, why go through all that trouble when you can select the desired values for CompGroup and SortBy on the public version of the report? The answer is that the linked report will always start with the desired default values, whereas the public version of the report will not. Basically, you are always presented with the version of the report that you want right from the start.

Figure 8-19. The LKFRemoteSiteAdmin1 OS Configuration report with the new default values

Linked reports are entirely dependent on the base report that they are linked to. If the base report is deleted or otherwise becomes unavailable, the linked report will cease to function.

8.2.2.3. Controlling report execution

On-demand execution is when reports execute each time that they are opened and viewed. Since the SQL DTS job transfers data from the OnePoint database to the SystemCenterReporting database once a day at 1:00 a.m. (which is the default), there will be no change in the reports throughout the workday. Therefore, it is unnecessary to have the reports hit the SystemCenterReporting database each time they are viewed.

To reduce the load on the reporting server and the SystemCenterReporting database, reports can be configured to be cached for a certain period of time in the ReportServerTempDB after they are opened. Subsequent viewings of the report (within the configured time limit) access the cached version and do not generate another database hit. Once the cache time limit has expired, the report will be executed in an on-demand fashion, which then refreshes the cached version and restarts the cache report Time-To-Live countdown.

Figure 8-20 shows the execution page for the public Operating System Configuration report with the cache expiration set for 2:00 a.m. daily, according to a shared schedule. The report will be executed in on-demand mode the first time it is executed every day after 2:00 a.m.

Figure 8-20. Configuring a report to refresh at 2:00 a.m. daily

8.2.2.4. Shared schedules

Shared schedules are exactly what their name states. They are created by an administrator on the Site Settings page Managed Shared Schedules link (see Figure 8-21). These schedules can be used for report caching, generating report subscriptions, or report snapshots.

A shared schedule consists of a schedule name, start and end dates (which can be left open-ended), and the schedule details. For each shared schedule created, all reports that make use of it are listed on the Reports page. Execution of a shared schedule can be paused, thereby pausing all jobs that are dependent on them. This is done on the Shared Schedule Summary page, Site Settings Manage Shared Schedules.

Figure 8-21. Configuring a shared schedule

8.2.2.5. Snapshot execution

On-demand reports query the SystemCenterReporting database, returning the current values of whatever data was queried. When the daily DTS transfer runs, all data that is more than five minutes old and that has not copied in the previous transfer cycle (basically the past 24 hours of data) is added to the SystemCenterReporting database and made available to the report queries. Because the queried data is changing, the reports by their very nature must change as well. If on-demand reports were the only way to extract data from the SystemCenterReporting database, it would be very difficult to keep a historical record of reports as they existed at any given point in time.

To enable historical tracking of reports, you can take snapshots of reports and keep them in the report's history on the reporting server, or deposit them to a file share or email mailbox via a subscription. Snapshot reports can be generated and stored on a scheduled basis or (ironically) on demand. Reports that are executed on a scheduled basis do so without human interaction, which means that all report parameters must be predefined and a set of credentials that can access the data source must be provided. Snapshot reports, like rendered subscription reports, are non-interactive. Scheduled snapshot execution can be done according to a report-specific schedule or a shared schedule. If you want your users to make use of a shared schedule for generating snapshots (or subscriptions for that matter), make sure they have been assigned a My Reports item role and System User system-level role. System-level roles are assigned on the Site Settings Configure Site Wide Security page. Create the association between the domain/local user or group and the System User role. Otherwise, you (as the administrator) will need to configure a snapshot report to use a shared schedule.

To take and save a snapshot of a report to that report's history folder, first navigate to the report of interest, then to the Properties tab (see Figure 8-22):

Select the History link along the left side of the page (point 1). This opens the report history configuration page.
Select the "Allow history to be created manually" checkbox (point 2). This enables the New Snapshot button on the History tab.
Select the "Store all report execution snapshots in history" checkbox (point 3) to keep all of the snapshots in the reports history.
Select "Shared Schedule" since this snapshot will be collected at 2:10 a.m. every day. It has already been configured in the previous section (point 4).
Select to keep an unlimited amount of reports in the history (point 5).
Click Apply (point 6).

Figure 8-22. Configuring report snapshots on the history configuration page

At this point, the scheduled time for snapshot creation has not passed, so there will be no entries on the History tab. To generate an on-demand snapshot, click the History tab, then click the New Snapshot button (point 1 in Figure 8-23).

Figure 8-23. Creating a report snapshot on demand

Snapshot reports that are run according to a schedule must have a set of credentials stored in the data source. For MOM 2005 reports, this is not something you really need to worry about because they will all use a shared data source, which is the SCDW object that you see in most report folders, including the Home folder (see Figure 8-24).

Figure 8-24. SRS data source definition

There are a few things that you need to be aware of in this shared data source. In point 1 in Figure 8-25 the "Enable this data source" checkbox is the single control point that you can use to stop the execution of all reports. If you disable this data source, all of the reports listed on the Reports tab will cease to function until the data source is re-enabled. This shared data source already has a stored set of credentials that are used to access the SystemCenterReporting database, the homelab/dasaccount (point 2 in Figure 8-25).

Figure 8-25. Properties of a shared data source

8.2.2.6. Managing subscriptions

You will probably be asked to create a subscription to certain reports that are configured with certain parameters for a user or group of users. As a MOM administrator, you can configure two types of subscriptions: a standard subscription, in which every recipient of the report receives it in the same format and at the same location (their inbox or a filesystem folder), or a data-driven subscription.

Data-driven subscriptions for reports are probably the most useful because they allow you to mix report configurations (e.g., parameters, recipients, and delivery type) in a single SQL table, which is read from when the subscription runs. Each recipient then receives the report within her parameters (the report she wants), rendered in the format she wants (e.g., .PDF, .XLS, .HTM, and .CSV) and delivered where she wants it (e.g., inbox or file share).

To create a standard subscription for a user as an administrator, navigate to the desired report, then click the Subscriptions tab, and select the New Subscriptions button.

This brings up the Report Delivery Options page (see Figure 8-26), which is configured as follows:

Delivered by: Report email server
To: SMTP addresses, LKFRemoteSiteAdmin1@homelab.lab, LKFCFO@homelab.lab, and LKFMOMAdministrators@homelab.lab
Reply to: reportmaster@homelab.lab
Rendered: As a PDF file and included in the email as an attachment
Run: According to a shared schedule called "Create and send subscriptions"

Figure 8-26. Configuring standard subscription options

This report will be rendered as a PDF file and emailed to the recipients every morning at 6:00 a.m.

Creating a data-driven subscription requires more work up front, but saves you from creating and maintaining a standard subscription for every user who wants a report delivered to him in a different format or with different fields. In a nutshell, you create a database that has a table that houses all the fields required for generating the report, such as To, Reply-To, IncludeReport, IncludeLink, RenderFormat, and any other required parameter fields. These values can all be recorded in a single table with each row in the table representing a different recipient. Then, in the subscription creation process, you access this table and map the table fields to the report fields and set a delivery trigger. Whenever the subscription triggers, each recipient receives the report he wants, in the format that he wants it. For every report that you want to create a data-driven subscription for, you must gather the parameters in the subscriber's database along with the recipient's information, and any other applicable options. These will be used to create columns in the subscriber's information table.

Here's how to create a data-driven subscription for the operating system configuration report:

Log on as an administrator on the reporting server, open SQL Enterprise Manager, and navigate to the Databases folder.
Right-click and select New Database.
Enter a name, for example ReportSubscriptions. Click OK.
Right-click on the ReportSubscriptions database. Select New Table.
Click Save (the icon of the floppy disk in the upper lefthand corner). Name the table SubscribersInfo.
Select the SubscribersInfo table, right-click, and select Open Table Return All Rows. This opens the table so you can enter the values in each of the columns. For this example, the data entered is:
- Reply-To: reportmaster@homelab.lab
- IncludeReport: 1
- RenderFormat: PDF, Excel, MHTML
- CompGroup: Microsoft Windows Servers, Microsoft Windows 2003 Servers, Microsoft Windows Servers
- SortBy: Server Name, Server Name, Operating System
When you're done entering data, the SubscribersTable looks like Figure 8-28. Close the table and the values are automatically saved.

Figure 8-28. Enter the desired values in the SubscribersInfo table
Open SQL Query Analyzer, make sure the ReportSubscriptions database has the focus, and type SELECT * FROM SubscribersInfo. The query should return the table and all the data that has been entered.
Open Report Manager and navigate to Microsoft Operations Manager Reporting Microsoft Base Operating System Operating System Configuration report Subscriptions tab and select "New data-driven subscription."
Access the ReportSubscriptions database by using the connecting string on the Step 2 page (see Figure 8-30). It is in the format of data source=<databaseservername>; initial catalog=<databasename>.

Figure 8-29. Step 1 of a data-driven subscription

In this case, the data source is homemomserver3 and the initial catalog is ReportSubscriptions, as shown in Figure 8-30. Provide credentials to connect to the database; use the same login credentials you used when you created the database. Select the "Use as Windows credentials" checkbox and click Next.
Enter a query to return the list of recipients, in this case SELECT * FROM SubscribersInfo. Click the Validate button on the bottom of the Step 3 page. When the query successfully validates, click the Next button.
Map the report values to values in the table on the Step 4 page (see Figure 8-31). Select the value in the drop-down box that matches the report field on the left-hand side of the page as shown in Figure 8-31. Here, the report field is Reply-To and the mapped value from the table is set to Reply-To. Do this for all appropriate values on the page and click Next.
Apply the same report parameter to the table value mapping in Step 5 as you did on the Step 4 page. This will map the CompGroup, SortBy, and SortOrder fields (see Figure 8-32). Click Next.
Select the "On a shared schedule" option on the Step 6 page and choose the "Create and send subscriptions" shared schedule that was previously created.