Postings in the same series:
Part II – Tips & Tricks
Part III – Targeted Reports
Part IV – Examples for Disk Reports
Part V – Scheduling / Publishing Reports and some tricks
Before I start first some history about Reporting.
In MOM 2005 it was already present, also as an ‘extra’. However it worked much different compared to OpsMgr nowadays.
First of all, it wasn’t ‘real-time’. The database used for MOM 2005 Reporting got filled by an automated process which queried the MOM 2005 Operations database on a daily schedule (default at night). So when a report was run, it showed data which was at least a day old. And we all know that IT can change within a day, so sometimes these reports didn’t live up to the expectations.
Besides that, the nightly process could be problematic and was prone to errors. Many times it didn’t run and needed attention.
OpsMgr Reporting vs. MOM 2005 Reporting
In OpsMgr there is a separate Data Warehouse which gets filled with data, along side the OpsMgr database itself and on a 24/7 basis. So the OpsMgr database isn’t queried anymore to get the Data Warehouse filled. Therefore the Data Warehouse has been constructed in a different manner in order to accept huge loads of data in a short time frame.
Besides the obvious advantage that filling the Data Warehouse has become an automated process which doesn’t need that much attention (when setup properly), it also provides near real-time reports. So what get’s in now, is to be found back in a report a bit later. That’s nice!
Another advantage is that the Data Warehouse can collect totally different information compared to the OpsMgr database. Where as the OpsMgr database is filled with operational information (how are the monitored servers/services doing?) is the Data Warehouse filled with statistical information (How did the servers/services perform during a specific timeframe?). This also enables to tell what a server/service will do in the future.
MOM 2005 reporting also had another issue. The reports were a bit static and didn’t leave much room for adjustments. So many reports were displaying information which didn’t always met up to the requirements set out by the organization. Also referred to as Wallpaper For the IT Managers. (It hasn’t a real function but makes it looks like the IT Manager is really involved.)
Whenever people wanted to run other reports they needed to dive deep into reporting and hoping that the information needed was really present in the database. If not, no report. Simple but frustrating.
With OpsMgr Reporting became way much more flexible which made the reports more spot on. However with enabling the OpsMgr user to get their reports as needed, a new challenge was created.
The OpsMgr Data Warehouse contains much information. Only the challenge became how to get it out? What class does one have to select in order to get a filled report? This challenge can translate itself in reports ending up empty. And no, that is not nice.
So one of the most heard complaints about OpsMgr Reporting is that they end up empty. Since Microsoft isn’t deaf they picked this one up as well. So in OpsMgr R2 the Object Picker module for the Reports is to be found.
The idea is good: it allows to show only the relevant classes of objects which are needed for a certain report. However, there is a small downside to it at this moment:
The list of supported classes has to be defined in the MP in order to take full advantage of the Object Picker.
Yep. You already felt this one coming: today not all Microsoft’s MPs do have this feature yet. But it will certainly come.
But as stated before, at the moment many MPs do not fully support this feature yet. This support will certainly come however.
So upcoming postings about this topic will show some tips and tricks in order to get filled reports.