Customized Reports in SCOM R2: Save them to a MP or Publish them?

First some background information. When one creates a customized Report and would like to use that same Report another time as well, this Report could only be Published in SCOM RTM/SP1. With SCOM R2 a new option has been added: now one can save that Report to a MP as well.

However, both approaches do have their pro’s and cons. This blog posting will about these, enabling you to make the right decision.

Publishing Reports

• Con: When Published these Reports are not generally available to every other SCOM Report Operator / Administrator.
  The Published Reports are placed in the Authored Report node of the Reporting Tree. However, this node is like a personal profile so other SCOM Report Operators / Administrators cannot access that Report by default. Additional steps are needed for that. (This blog posting of mine describes it in detail, Step 6 ‘Using a special folder in the Report Tree’.)
  
  
• Con: Disaster Recovery
  Suppose the SQL Server hosting the SSRS instance for SCOM dies. When that server is rebuilt and there is NO valid backup available for the Report Server DB, all the customized Reports are gone. So when Publishing Reports and moving them to another folder in order to make them available for other users as well, make sure to have a valid backup mechanism for the Report Server DB in place as well.
  
  
• Con: More labor intensive
  When Reports are published, these Reports need to be moved in order to make them available to others as well. For this additional actions are needed.
  
  
• Con: Reports cannot be shared to other sources
  In advanced distributed SCOM environments where multiple SCOM MGs are in place and connected to the same DW, the Reports cannot be shared across the multiple MGs. For this extended knowledge of SQL and SSRS is required.
  
  
• Pro: Less Authorizations are needed
  In companies which are reasonable sized, there are also people present who have a position in departments like Capacity Management. And boy, do they LOVE the SCOM Reports! So many times they need some training and off they go, creating their own Reports as needed. When they only need to Publish their Reports, not too many authorizations are needed. Report Operator will do. With this User Role they are less likely to harm the SCOM environment, compared to have the Administrator User Role in SCOM.
  
  
• Pro: More detailed sorting is possible
  Because the Reports have to be moved to another folder, a new folder structure can be created, for instance: _Cap Man > Performance Reports where all Performance Reports are move to and _Cap Man > Availability Reports where all availability Reports are moved to. This creates a better to navigate View.
  

Saving Reports to one or more MPs

• Pro: Report is available for everyone with the required permissions
  When the Report is saved to a MP this Report becomes automatically available to all other SCOM R2 Users.
  
  
• Pro: Disaster Recovery
  The Reports are stored in one or more MPs. When the Unsealed MPs are exported and back upped on a regular interval, these Reports are easily restored when the SQL server which hosts the SSRS instance dies. No restore of the Reporting Server DB is required.
  
  
• Pro: Easily shared among different SSRS instances
  In advanced distributed SCOM environments where multiple SCOM MGs are in place and connected to the same DW, the Reports are easily shared across the multiple MGs. Only an export of the related MPs and import into the other MG will do the trick. The Reports are automatically uploaded to the related SSRS instance.
  
  (I have heard that this trick also works with MGs which run separate DWs as well. In order to work around this the MP has to be exported and imported in to the other MG. After that the Report has to be opened and saved again in order to get it working. However, I have never tried this so I cannot say whether this really works.)
  
  
• Con: More Authorizations are needed
  In companies which are reasonable sized, there are also people present who have a position in departments like Capacity Management. And boy, do they LOVE the SCOM Reports! So many times they need some training and off they go, creating their own Reports as needed. When they need to save their Reports to one or more MPs, SCOM Admin permissions are required. For people without too much knowledge of SCOM R2 this is a potential recipe for disaster…
  
  
• Con: Less detailed sorting is possible without taking additional steps
  Even though the customized Reports can be saved to different MPs, nested Views (like _Cap Man > Performance Reports) aren’t possible by default. So only flat Views are available. An approach to circumvent it is to open the MP in the MP Authoring Console and add the nested folders as required.
  
  
• Con: In order to save Reports to a MP certain requirements have to be met
  There are some conditions which have to be met before a Report can be saved to a MP. Taken from this webpage:
  So when a customized Report has been created and Published, it can not be saved to a MP any more. For this the customized Report has to be created again and now it can be saved to a MP.

With these lists one is able to understand what both options available for keeping customized Reports have to offer and what potential pitfalls to reckon with. Whenever you have some good advice to share, do not hesitate and let me know. (I might even add it to this blog posting where I will refer to the source as well.)