Hello Readers and Viewers! It has been a while since I added to the “8 Minute Demo” Video Series, but today, along with some CodePlex content, I submit to you… drum roll…
My 40th YouTube Video!
Nah, though that is a true statement, it is not the intent of this post //obvious (besides, one of those videos was just for fun).
drum roll again…
A very special use case for Opalis! – Data Extraction and Reporting
Starring in this video is the “SCDEMO Usage Report”. SCDEMO stands for “Server and Cloud Demo and Learning Environment”, if you have seen a System Center or Private Cloud demonstration from a local Microsoft Datacenter TSP/SSP team, there is a good chance it was hosted in this environment. Simply put, it is one of the most powerful demo and learning environments on the planet! – I am a fan. :)
The video takes you through the various extracted datasets and their respective tables/charts for the report.
The CodePlex content is a sanitized* and packaged “kit” of examples you can use as a guide for your own Opalis powered Reporting use case based on the above video.
Opalis Data Extraction and Reporting Kit (http://opalis.codeplex.com/releases/view/57671)
Included in the CodePlex content:
*SCDEMO has been changed to RPTDB, all production names and references have been removed, all non-reporting workflows have been removed, etc.
Some of you will wonder why I didn’t take advantage of other Microsoft System Center tools to perform these actions (thank you randorfer for pointing this out!). I will try to explain “why” with the following background…
Believe me, I would leverage VMM, SCCM, or SCOM in an instant…
The issue is, the environment that I am pulling this information from is completely disparate. Each physical host is on one corporate domain, but each of the VMs on those hosts are on their own internal domain (or domains in some cases). You can think of each of the 125+ different physical machines as separate “Private Clouds”; each with their own architecture and infrastructure configuration, based on the decisions of the admin on the box. The only things we have control over are the rules and the physical machine specifications.
First, being on one corporate domain means that the physical host machines are already “homed” to a corporate SCCM deployment that I do not have access to.
Second, there is also no “overarching” VMM deployment for all physical hosts and their VMs; so PowerShell interrogation to each of the machines from a centralized Opalis install was necessary.
Finally, as far as SCOM is concerned, I could get physical host info, but what we really wanted was the VM specific information. Since each one of the VMs on the hosts has the potential to be in a different domain (or workgroup), there is no “overarching” SCOM deployment either.
I hope this helps with “why” I did what I did. If you have the ability to leverage the System Center tools to gather this kind of information, all rolling up through Opalis, I recommend doing so. If you have a mixed infrastructure (System Center and non-System Center), this illustrates Opalis’ disparate data source extraction and reporting capabilities.