Data from two sources is combined when report hierarchy is displayed in the Operations Manager console. List of reports always comes from SSRS while additional metadata like report display name and knowledge come from management packs.
OpsMgr console always looks for everything under SSRS root folder and shows it under the Reporting node in the console. That’s right, everything that is visible even if this is not part of a management pack. That said you can simply create any directory in the SSRS, drop a report in it and it will be displayed inside the console. Is that the way to go with the custom reports? May be or maybe not. It all depends again on what you actually trying to accomplish.
Creating a report and just dropping it to the SSRS is definitely the easiest way to go. This will work just fine for certain cases where you need to quickly share some simple reports with others in your organization. This solution doesn’t scale however and also has some side effects. One of the things to look for is automatic report deployment.
SCOM 2007 assumes that all reports come in management packs. If management pack contains reports they are going to be automatically deployed to the SSRS when the time comes. That means that when all dependencies for these reports are ready (database objects are created all dependent management packs are deployed etc) deployment module creates a directory with management pack ID under SSRS root folder and puts all reports in this management pack in it. It also puts images, parameter block definitions and other resources if they are defined in the management pack. Names for all the objects are IDs again.
Why use IDs for names? The answer is simple: localization. Remember I said that SCOM combines information from SSRS and management packs when displays them in the console? That’s how it does it. When IDs match SCOM assumes that this is a management pack object and displays it metadata instead of SSRS name. Try to compare what you see in the SSRS Report Manager with the Console report view and you quickly understand what I am talking about.
Imagine now that you created a folder in SSRS and put some reports in it. If all your employees speak one language localization is not a problem for you, but you still need to watch for name collisions. If some time down the road you install a management pack that happens to have the same ID as your folder name your reports are going to be overwritten without notice. You would also need to care about dependencies yourself. If your custom report happened to depend on some management pack objects or reports from other management packs SCOM is not going to stop administrator from deleting this management pack from the system if your reports are not in a dependent management pack. The reports will just simply stop working for you.
Packaging report in a management pack is not that difficult and I encourage everybody to do so. It will save you time and effort in a long run.