Here are the various ways to approach creation of management packs in SCOM. Each one has it's merits and disadvantages, so probe well before accepting that this might be a fit for your situation.

1. Create a WMI class and target it in your management pack

2. Create a management pack based on pure VB script

3. Create a management pack based on pure WMI

4. Create a management pack based on VB script plus WMI

5. Create a management pack based on attributes

6. Create a management pack based on registry entries

7. Create management packs using existing management packs

From a manageability perspective, if you are creating complex management packs, stay away from using a lot of attributes as readability will be an issue. Also, while taking the attribute based approach, attributes cannot be deleted, the management pack associated with the attribute has to be deleted for the attribute to be deleted. Now that is a pain.

Scripts are a hit on the performance. Imaging the script pushed to several agents and the amount of time it can take for data to be transmitted over the network to the actual SCOM central. So, pure script should be used only where all other options are absolutely impossible.

In places where you can use script in combination with WMI, take this route as many SCOM developers around the world take this approach. Data is with windows and you just query the WMI to get hold of it, not wasting precious time writing script to do all that has already been done.

If the data to be managed in SCOM is a nightmare to retrieve using existing discovery techniques, create a specialized WMI class or registry handler module that will dump the data needed by SCOM, either into the CIM or the registry, this will be easier for SCOM to handle as it has to query a single class only. In this approach, a assembly will need to be installed on all clients. For large projects it makes sense to have this class packaged as a part of the project itself

Most of the data that normal SCOM MP target are fit to be retrieved from default management packs, but this will take ages for one to figure out, or paying Microsoft professional support thousands of dollars to get to know your way around. Tools are minimal and documentation is limited. So, many people do not trudge down here.