Before we discuss backing up reports, let's talk about how reports work. Similar to MOM
2005, Operations Manager 2007 uses SQL Reporting Services as its report engine, although
the Operations console now front-ends and displays the reports. You can also access the
OpsMgr reports from the SQL Reporting console, but that is not the recommended
approach, as the report names display with their GUIDs (Globally Unique Identifiers) and
the information (metadata) about the report is only displayed in the Operations console.
When you display the report hierarchy in the Operations console, you actually are seeing
information from two places:
- SQL Reporting Services provides the list of reports.
- The management pack provides metadata such as the report display name and
knowledge about the report.
The reports displayed in the Reporting node of the Operations console are actually those
found in the SRS root folder. This means that any report is visible, whether or not it is part
of a management pack—and is one reason why you want a dedicated SRS for Operations
Manager Reporting (a second reason is the Reporting Component installation changes security
such that any existing reports are no longer accessible).
This model also means that you can create a directory in SRS, store a report under it, and
have it appear in the OpsMgr console. That makes it easy to add reports, but it doesn't
help if you want to deploy a new report to a new management group, deal with localization
or dependencies, or easily back up any new reports you have created for Operations
Manager. Out-of-the-box, reports are included with management packs, and OpsMgr
expects that and deploys them to SQL Reporting Services for you.
There are two steps to backing up custom reports you develop. You can export the report
as an RDL file, save it in XML format, and then optionally package it in a management
pack. To keep things simple from an administrative standpoint, we recommend that you
package your reports in management packs.
Backing Up OpsMgr Reports
To export the custom report as a RDL file, open it in Report Builder and choose File →
Save As File.... This creates the RDL file, which is in XML format. To package the RDL in a
management pack, edit it in a text browser and paste its content in an unsealed MP under
the Reporting/Report/Definition node in the management pack. As an example:
<Reporting>
<Reports>
<Report ID="Sample.Report1" Accessibility="Public" Visible="true">
<Definition>
[RDL XML file content here...]
</Definition>
</Report>
</Reports>
</Reporting>
Where:
- ID is the name of your report in SRS. It must be a unique name within the management
pack.
- Accessibility="Public" allows other management packs to reference this report. If the
report is Public, the ID must be unique in your OpsMgr reporting environent.
- Visible="true" makes your report visible within the catalog.
Many other parameters can be specified within the node. See Chapter 23, "Developing
Management Packs and Reports," for more information.
For purposes of backup, we will assume you have saved your RDL files and included them
in unsealed management pack .XML files. These should be placed in a folder with your
other customized and unsealed management packs to be backed up.
Backing Up ACS Reports
Microsoft does not support including ACS custom reports in management packs, as by
default an OpsMgr administrator does not have access to ACS Reporting. Customized ACS
reports should be extracted using the Report Builder and stored in a separate directory. By
default, the Report Builder saves to your My Documents folder; we suggest establishing a
common location to save all customized ACS RDL files. You would later use the Report
Builder to import RDL files back into the SRS environment.
The ReportingConfig.exe utility, found in the installation media under the SupportTools
folder, is used to reload Microsoft-supplied ACS reports. Chapter 15 provides additional
information.
Home: 
