Today I had some time to look through some forum threads at System Center Central. One of discussions which captured my attention was about the bug in the discovery of SSRS Instances with underscore (_) in the instance name.
I will not write anything about the bug itself, by the end of the day it was an ugly bug. Bugs happen, some sit there for years. Believe me or not, good developers and testers blame themselves and fill unhappy when they step into the situation like this, when they failed to catch that in advance.
In this post I want to discuss another thing – a couple of sentences caught my eye. Here they are:
At least with the VB script, you could run it manually and see where it was failing. The dll process is impossible to do anything with (as far as I know) and leaves us having to call MS every time we get one of those cryptic errors.
Indeed, many modern System Center Operations Manager Management Packs are been implemented using so called SCOM managed modules. I know that many SCOM Admins like to unseal management packs and read the source code to gain an understanding of how exactly they work, how do they suit their needs. Many people think that managed modules do limit their ability to research the logics. In my opinion, that is absolutely incorrect and here is the walk-through for reverse engineering of MPs based on managed modules.
SCOM Managed modules are in fact .NET classes. Nothing more than that. Those .NET classes are stored in assemblies (.dll files) which are bundled together with the management pack definition into .mpb file. Luckily, a) .NET assembly has tons of metadata inside and b) .NET Framework has a feature called Reflection. There are some tools, which leverage this capabilities and can convert the assembly back to human-readable C# code. This approach is widely used by .NET developers for research and reverse engineering, which is an integral part of the profession.
1. Get the MSI for the management pack you want to explore.
2. Unpack the MSI:
msiexec /a <FullPathToMsi> /qb TARGETDIR="<FullPathToSomeDirectory>"
3. Unseal the .mpb (this can be done with various tools, MPViewer is one of them)
4. Locate the module you want to research (drill down from the discovery, through data sources, until you find the probe with “managed” implementation)
5. Find the appropriate .dll
6. Get the reflection tool (for example – dotPeek from JetBrains – it is free)
7. Open the .dll with the reflection/decompile tool
Now you can browse the code, compare versions, find what and how was changed, and so on. Personally I prefer not to rely on others, especially on the huge software shop located in Redmond. Yeap, we pay money for the software, but other guys pay us money – most probably for getting things done, not for waiting.