|
Sp1 for Mom has introduced a whole new mechanism for accessing, and
in some cases, manipulating data in the database. This mechanism is based
on WMI and will allow the simple development of private or ISV add-ons to
perform those essential but hitherto elusive tasks.
So What?
-
You don't have to write code to access the SQL Database
directly. Microsoft may (and almost certainly will) change the
database schema with versions and service packs. Like SMS the advantage
here is that if your applications use the WMI interface then changes to the
underlying database aren't your problem. The Mom provider will 'know' how
to fetch the data. If your apps talk directly to tables in SQL, then
changes in the design of those tables will break your app.
-
You can access Mom's functionality programmatically. Write
your own scripts, VB, and .Net apps to extend Mom functionality.
-
If you don't know about WMI yet and are serious about the business
of Windows Platform Desktop, Web and Server management then this is yet another
wake up call. Nothing moves in this arena but for WMI and it is
increasingly significant as each nw product version is released..
MomWmi.mof
First comes the Mof file which specifies the provider and classes to
be used with Mom. Beware of a legacy mof file called OM.MOF
which came with RTM Mom which is not installed and can be safely ignored as it
is dysfunctional and makes no contribution. MomWmi.mof is
automatically compiled on the DCAM at installation and adds the provider
registration and classes to the existing CIM Repository. It also adds
this file in the list of MOF's to be autorecovered if the CIM Repository is
deleted or damaged.
HKLM\Software\Microsoft\Wbem\Cimom\AutoRecoverMofs
The namespace used by Mom is Root\Mom and exists on each
DCAM where the Service Pack has been applied. You reach this using the
standard syntax '\\myServer\root\mom'.
Security is set on this namespace as inherited from the
root and for Win2k the default setting is to allow local administrators Full
access, while the Everyone group is only given Read and Execute access if they
are querying the CIM repository locally. In other words, by
default, only administrators can make a remote connection to root\mom.
MomSDKProvider
This provider is the software that acts as the 'broker 'or
'go-between' between the CIM repository and the OnePoint SQL Database.
(To this extent it has the same functionality as the SMS Provider in
SMS). When a script or application queries a class in the CIM Repository
for data, it's the MomSDKProvider that has to go and fetch it. It
supports the standard WQL query syntax such as 'Select * From class Where x =
y'. It is also a method provider - that is to say, some of the classes
(notably msft_Computer) not only define the data that can be fetched, they also
allow you to carry out some task.
Mom WMI Classes
Here is a list of the classes defined in the root\mom namespace:
| MSFT_Win32Provider
|
The class used to register the provider |
| MSFT_ParameterEvent
|
Used with the msft_Computer.InsertEventIntoWorkFlow method |
| MSFT_ParameterStatistic |
Used with the msft_Computer.InsertStatisticIntoWorkFlow
method |
| MSFT_Alert |
Returns data about Alerts |
| MSFT_AlertHistory |
Returns data tracking the changes made to an alert during its life
cycle |
| MSFT_AlertResolutionState |
Returns data on the default and admin configured Resolution States |
| MSFT_Computer
|
Returns data about Computers |
| MSFT_ComputerGroup |
Returns data about Computer Groups |
| MSFT_MicrosoftOperationsManager
|
There is only one instance of this class and it is used to
provide version and installation information about Mom itself. |
| MSFT_TodayStatistics
|
There is only one instance of this class and it is used to
return the latest version of exactly the same data found in the Today's
Statistics pane of the MMC. |
| MSFT_Script |
Returns data about Custom Scripts |
| MSFT_AlertHistoryToAlertResolutionState
|
Relates Alert History and Resolution State |
| MSFT_AlertToAlertResolutionState |
Relates Alert and Resolution State |
| MSFT_AlertToAlertHistory |
Relates Alert to Alert History |
| MSFT_AlertToComputer
|
Relates Alert to Computer |
| MSFT_ComputerToComputerGroup |
Relates Computer to Computer Group |
| MSFT_ScriptToComputerGroup |
Relates Custom Scripts to Computer Group |
Notice that some of these classes are 'Association' classes and exist
in order to help define the relationship between one class and another.
For example, if you wanted an easy way to find which alerts go with which
computer you would refer to the msft_AlertToComputer class.
Using these classes you will be able to do things like:
-
List all the alerts for a certain computer with a certain resolution
state and change the owner.
-
Reset the resolution state for a mass of alerts.
-
Automatically resolve alerts when a problem is fixed.
-
Create events on behalf of a computer
-
Force a computer to contact its DCAM
-
Create computer groups and add computers to it
-
Force the Agent Manager to Scan computers
-
Add non Agent computers (such as Unix machines)
-
Manage scripts
More examples will be posted here as time goes by......................
|