Administrator Console

MOM 2000 Administrators will recognize the Administrator Console immediately. (It wasn't that long ago!) Short of the monitoring section of the MOM 2000 console (under the Operations node in 2005), it's nearly functionally identical.

The Administrator Console is where the MOM Administrator will spend a good deal of his or her time. Things such as deploying agents, changing agent settings, importing/exporting management packs, importing reporting packs, adjusting rules, and creating discoveries all take place here. The Administrator Console is composed of two main sections: management packs and Administration.

Clicking the subsections of the navigation pane will display a list of useful options on the right-hand side of the Administrator Console. The right-hand pane uses two columns to display actions. The left column is generally a wizard-driven action, while the right column provides links to the sections listed next.

Management packs section:

  • Computer Groups: Contains collections that group computers together (or excludes them) either by static mapping or by formula based on Computer Attributes.

  • Discovered Groups: Groups created by imported management packs and managed by service discovery.

  • Rule Groups: Contains all Alert, Event, Performance Measuring, and Performance Threshold rules as well as child Rule Groups.

  • Override Criteria: Provides modifications (known as overrides) to rules in order to change the behavior of a rule to ignore or use a different criterion.

  • Tasks: Performs a defined action in the context of the agent or from the Operator Console.

  • Notification: Contains Operators and Notification Groups (defined in more detail in the Mail and Paging section).

  • Scripts: Contains VBScript, JScript, or Managed Code.

  • Computer Attributes: For use in creating Computer Group formulas.

  • Providers: A variety of providers exist to gather data from the Event Log, Performance Counters, WMI Events, Script-generated Data, and log files, or to run as timed executions.

Administration section:

  • Computers: The area of the console to manage your agents (install, uninstall, change settings, and create discovery rules).

  • Console Scopes: Manage defined scopes that allow administrators to see information only from Computer Groups they are interested in.

  • Global Settings: Manage settings for the Management Group.

  • Product Connectors: Manage MOM-to-MOM connectors or third-party connectors that utilize the MOM Connector Framework.

The other sections not mentioned include Information Center and Operations. Information Center provides links to various web sites that contain useful information on Microsoft Operations Manager, management pack downloads, documentation, and so on. The Operations section contains links to launch the operations-centric consoles (Operator, Reporting, and Web).


We cover management packs further in Chapter 8, which details the components of the management pack (Computer Groups, Rules, Scripts, and so on) as well as building your own rule set.

Installing the MOM Consoles

Installation of the MOM Administrator and Operator Consoles was covered in Chapter 3. However, there are a few things to note. First, like other products covered in this book, the MOM consoles do not have to run from the server. In the case of MOM, the MOM consoles don't even need to be installed on the server. (The Reporting and Web Consoles are an exception; they must be installed on the server to be functional for Web-based access.)

The second thing to understand is that neither the Administrator nor the Operator Console can be installed alone. Giving a user the Operator Console means they also get the Administrator Console. During the installation of the Administrator Console, please keep in mind that the Operator Console is also getting installed!


Any user that uses the consoles must be in at least the MOM Users local group. Refer to the table in the section "Administration: Agents, Consoles, and Settings" to determine the right level of access to grant users.


The maximum number of consoles recommended per Management Server is 15. Each console adds additional load to the Management Server. Make sure to plan accordingly to accommodate all the console connection requirements in your organization.

Administration: Agents, Consoles, and Settings

Everything discussed so far in this chapter has pertained to the elements that make up the management pack. This probably comprises 75 percent of the daily administration required to keep MOM tuned and happy. However, you may encounter a lot of headaches if you don't have MOM agents that are configured properly. In fact, a lot of the rules created may never reach the agent otherwise.

MOM Local Groups

Before we continue, one console hasn't been discussed yet: Computer Management. There are some local groups on each of the Management Servers that act as the foundation of all the security in the MOM Administrator and Operator Consoles. The table that follows illustrates the permissions each group has.




MOM Administrators

Administrator, Operator

Modify on Management Packs
Modify on Administration
Modify/Create Views
Modify Alerts
Modify Company Knowledge

MOM Authors

Administrator, Operator

Modify on Management Packs
Read on Administration
Modify/Create Views
Modify Alerts
Modify Company Knowledge

MOM Users

Administrator, Operator

Read on Management Packs
Read on Administration
Create Views only in My Views
Modify Alerts

At a minimum, the user must belong to the MOM Users group in order to utilize the Administrator or Operator Console.

The Administration section of the MOM Administrator Console is composed of the following areas:

  • Computers: All agent management is handled in this section.

  • Console Scopes: For any MOM User who uses the Operator Console, this helps "scope," or limit, the data that they can view. This is necessary not only for showing the proper data to the correct user, but also to weed out unnecessary noise. For example, an Exchange MOM User may not necessarily wish to see alerts for file servers.

  • Global Settings: MOM has both global and agent-specific settings. This area contains all the settings that apply to all agents, including configuration settings for database grooming, e-mail server, and agent security requirements.

  • Product Connectors: This section displays details for any connectors used to join data to MOM through the MOM to MOM product connector or the MOM Connector Framework.


This node of the Administrator Console is used to manage the various states of the MOM agent as well as all accessible settings. MOM agents can have two states: Agent-managed and Agentless. The Agent-managed computer should always be the first option of agent state because an agent on the computer can provide a much more robust experience than Agentless, which is generally limited to status monitoring. This means that the information that the Management Server can retrieve from these Agentless machines is highly confined. However, because the MOM agent is not supported on Windows NT 4.0, Agentless may work as an interim solution until the computer can be upgraded to Windows 2000 or later.


In order to use Agentless managed mode, the computer must be accessible via WMI. Windows NT 4.0 may not have the necessary components and will require an installation of the WMI Redistributable files.

The limit for Agentless managed computers is 60 per Management Server.

Sometimes the views can become quite confusing in relation to where functions or settings reside, particularly the All Computers, Management Servers, Unmanaged Computers, Agentless-managed Computers, and the Agent-managed Computers area. The following table should help clear up any confusion and also provide quick reference when searching for that particular function that seems to have disappeared.


Available Functions

All Computers

Unfiltered view of all computers discovered in MOM
Properties for unmanaged computers
Agent-specific settings for Agent-managed computers
(override Global)
Management Server–specific settings (override Global)

Management Servers

Filtered view displaying only Management Servers of the Management Group.
Management Server–specific settings (override Global)
Run Computer Discovery Now
Run Attribute Discovery Now

Unmanaged Computers

Filtered view of all unmanaged computers
Install Agent
Start Agentless Management
Delete unmanaged computer
Properties for unmanaged computers

Agentless Managed Computers

Filtered view of all Agentless managed computers
Stop Agentless Management
Run Attribute Discovery Now

Agent-Managed Computers

Filtered view of all Agent-managed computers
Install Agents
Uninstall Agents
Update Agent Settings
Run Attribute Discovery Now
Ignore Missing Heartbeats
Force to Unmanaged Management Mode
Agent-specific settings (override Global)

Installing/Uninstalling Agents

There are three methods of installing or uninstalling agents. The manual method requires the use of the MOMAgent.msi file. Any agents that are installed this way can be uninstalled through Add/Remove Programs. Manual agent installations are useful whenever the agent isn't accessible for installation by the normal means. For instance, DMZ computers are often installed manually. This way only port 1270 needs to be opened from the agent to the Management Server.

Agent installations can be initiated manually for any discovered computer (that is, the computer must match a Computer Discovery Rule). Discovered computers that are not managed will fall under the Unmanaged Computers view. These computers can have the agent installed by following these directions:

  1. From any section in the previous table that states "Install Agents" as an action, right-click the computer on which to install the agent. Choose Install Agent.

  2. The Install Agent Wizard begins. Click Next to move to the next window.

  3. If the Management Server Action Account has enough permission to install the agent, leave the default as it is (see Figure 6-1). Otherwise, choose Other and specify an account. Click Next.

    image from book
    Figure 6-1

  4. Choose the appropriate Agent Action Account for the computer to use. Click Next.

  5. Specify an Agent Installation Directory. If the default is suitable, leave it as is and click Next to continue.

  6. In the last window, verify the actions that you've selected. Click Finish to continue.


    In order to see the progress of the installation, leave the Show task progress check box selected.

  7. The next window shows the current progress of the agent installation (see Figure 6-2). Use the Details button to view additional information on the progress of each agent.

    image from book
    Figure 6-2

The last method is the general method used for installing MOM agents. If the Automatic computer management settings (located under the Management Servers properties) are not set to automatic, the discovered computers are moved into Pending Actions with a status of "Install agent." Right-click the pending action and choose Approve for Processing by Computer Discovery. The next time Computer Discovery runs, the agent installation will take place.

Start Agentless Management

If there are computers that fall under the scenario for requiring monitoring without the MOM agent installed, a minimal set of monitoring can be done from the Management Server. In order to initiate an Agentless Management mode, right-click the computer and choose Start Agentless Management.

Update Agent Settings

The only time this option comes in handy is when the Agent Action Account needs to be synchronized. An account with enough permission (either manually entered or the Management Server Action Account) can switch the agent from running under Local System to a domain account or back to Local System.


Agents that have a control level of "None" (available only with Manual Agent installations) cannot have their settings updated by this method.

Deleting Computers

Two things must be satisfied before a computer can be removed from the Administrator Console (thus ultimately removing it from the Operator Console). First, the agent must be in an Unmanaged state. Second, all Alerts, Events, and Performance data associated to the computer must be groomed out of the database. Once the criteria are met, the computer can be deleted from the Unmanaged Computers node.

Agent-Specific Settings

As defined in the previous table, any section marked as "Agent-specific settings (override Global)" allows the modification of properties that are specific to the agent.

Management Server–Specific Settings

As defined in the previous table, any section marked as "Management Server–specific settings (override Global)" allows the modification of the properties that are specific to the Management Server in the Management Group.

Windows Server Cluster Computers

When the agent is deployed to the physical nodes of a cluster, the virtual node(s) will display in this area. Management of the virtual nodes can be initiated by selecting the node to manage and then right-click and choose Start Managing.

Pending Actions

This view lists the varying states that exist for computers managed (or not) by MOM. A right-click on any computer displays the following actions:

  • Approve for Processing by Computer Discovery

  • Install Agent Now

  • Reject Pending Installation

The action "Approve for Processing by Computer Discovery" places the computer object in a state that, upon the next Computer Discovery cycle, the computer will either have the MOM agent installed or begin Agentless monitoring (defined by the Computer Discovery Rule, discussed next). The action "Install Agent Now" starts the Install Agent Wizard while "Reject Pending Installation" will move the discovered item out of the Pending Actions area.


Multiple computers can be selected and approved or rejected. If the discovered computers are not destined to be assigned to the same Primary Management Server, multiple machines cannot be selected and deployed using "Install Agent Now."

Computer Discovery Rules

Computer Discovery Rules are used as definitions to find computers to manage. Rules can be specified to be inclusive or exclusive. Rules can set the discovered objects for a preferred management mode such as "Agent-managed" or "Agentless managed." Agentless managed may sound self-defeating but as you may recall, Agentless managed state means to monitor the computer remotely.

Unfortunately the Computer Discovery Rules can't use things such as Organizational Units to perform the searches. All the searches are based strictly on computer name. This makes it difficult to follow the convention of making rules as explicit as possible unless all of your computers are named similarly. However, a combination of inclusive and exclusive rule types can help achieve this goal. For example, if all of your servers are named SERVER001 through SERVER009, an inclusion rule could be created with a computer name of "SERVER*." This would pick up all the computer objects that match the criteria and wildcard. If, say, SERVER020 through SERVER029 are to be monitored through some other means, an exclusion rule could be created to match names that start with "SERVER02*."

Although these Computer Discovery Rules are limited to computer name matching, wildcards, substring matches, regular expressions, or Boolean expressions can be used to build criteria matches. The following table is from the Microsoft Operations Manager 2000 Help file.

Menu Item



Any Character


Matches any single character.

Character in Range


Matches any single character from within the bracketed list. Within square brackets, most characters are interpreted literally.

Character Not in Range


Specifies a set of characters not to be matched.

Beginning of Line

Matches the beginning of a line.

End of Line


Matches the end of a line.



Matches either the regular expression preceding it or the regular expression following it.


( )

Groups one or more regular expressions to establish a logical regular expression consisting of sub-regular expressions. Used to override the standard precedence of certain operators.

0 or 1 Matches


Specifies that the preceding regular expression is matched 0 or 1 times.

0 or More Matches


Specifies that the preceding regular expression is matched 0 or more times.

1 or More Matches


Specifies that the preceding regular expression is matched 1 or more times.

Exactly n Matches


Specifies that the preceding regular expression is matched exactly n number of times.

At Least n Matches


Specifies that the preceding regular expression is matched n or more times.

At Most n Matches


Specifies that the preceding regular expression is matched n or fewer times.

n to m Matches

{n, m}

Specifies that the preceding regular expression is matched a maximum of n times and a minimum of m times. If not specified, m defaults to 0.

If n is not specified, the default depends on whether the comma is present. If no comma is present, n defaults to m. If a comma is present, n defaults to a very large number.

New Line Character


Matches a new line.

Tab Character


Matches a tab character.


This table defining some uses of Regular Expressions in MOM 2005 is not available in the MOM 2005 Help file. It's available in the MOM 2000 Help file only. Also keep in mind this helpful example. When the search criterion contains a space such as "Domain Admins" the Regular Expression needs to include a space. A space is expressed as the following: Domain[]Admins.

Initial Management Mode can define the agent mode a set of discovered computers should default to. If there were a set of computers that could not run the MOM agent for whatever reason, they could have their Initial Management Mode set to Agentless Managed.


Consider using the Computer Discovery Rules to load-balance your Management Servers. For example, to work with two Management Servers (MOMMS1 and MOMMS2), create the first rule pointing to MOMMS1 with the name criteria as a regular expression SERVER00[02468]. The second rule would look like this regular expression SERVER00[13579] pointed to MOMMS2.

Now all computers starting with SERVER00 and ending in an even number would report to MOMMS1. The computers ending with an odd number would report to MOMMS2.

Console Scopes

Any user who does not have a console defined may be immediately inundated by alerts the moment they open the Operator Console. Console scopes are helpful in focusing the user to their specific area of concentration. As is quite often the case, when alerts are overwhelming to sift through, white flags may go up — as well as hands.

  1. Launch the Create Console Scope Wizard by right-clicking the Console Scopes node in the navigation pane and choosing Create Console Scopes. Click Next to begin.

  2. Type in a name that makes sense. This doesn't have to be an exact representation because a scope description can be defined on the next window. Click Next.

  3. Type in a description and keep it relevant. It'll suppress the urge to question its existence later.

  4. Add in the appropriate Computer Groups by using the Add button. Additionally, the Has All Computer Groups option can be used to grant the user the ability to view everything. For example, if the user is an SMS 2003 Administrator, select all the subgroups that begin with "Microsoft SMS 2003." Click Next.

  5. Add in the users that will have this scope applied. There is no searching or checking on the user defined in this window. Make sure the name and domain are typed in correctly. Click Next.

  6. Click Finish to end the wizard.

  7. Launch the Computer Management MMC.

  8. Navigate to Local Users and Groups, and select Groups.

  9. Double-click MOM Users and add in the appropriate users as defined in Step 5.


Console scopes cannot use group membership for the defined user. It must be user name only. The MOM Users group in Local Users and Groups, however, can accept group names. It does not have to be defined per user.


Remember that any user wishing to use MOM must be included in one of the MOM local groups defined in the table at the beginning of the section "Administration: Agents, Consoles, and Settings."

Global Settings

Global Settings affect all of the Management Servers in a Management Group as well as all the agents that belong to the Management Servers. Choosing any one of the Global Setting types (aside from Management Server or Agent) will bring up the Global Settings dialog box with that type in focus. The Agents type brings up a different dialog box specific to Global Agent Settings, while the Management Servers type brings up a Global Management Servers Settings dialog box.


It's important to understand that only the settings for the Management Server or the Agents settings can be overwritten per Management Server or per agent-specific settings, respectively. The other settings cannot be overwritten.

Management Servers

The following global settings apply to Management Servers:

  • Discovery: Only schedule runtimes and intervals can be specified.

    • Attribute: Refers to the discovery of computer attributes as defined in the Computer Attributes section of the Administrator Console.

    • Computer: Specified runtime for when computer discovery takes place (defined in Computer Discovery Rules). This setting cannot be lowered less than one day nor can it be turned off.

  • Agent Install: Specify location of directory path to install the MOM agent. Also, specify whether to allow or reject new manual agents. This refers to agent installations that are done manually by using MOMAgent.msi.

  • Responses: Specify the number of simultaneous responses (either script or notification) that can be performed at the same time. Ordinarily, this setting should remain at the default. However, if the agent on the Management Server tends to draw more resources running intensive scripts, consider lowering this value.

  • Temporary Storage: This is essentially a cache during times when the database is unavailable. The Management Server will retain this amount of data and write the information to the database once it's available again.

  • Rule Change Polling: Any time a rule change is committed, an agent will check back to determine if any updates have been added.

  • Heartbeat Checking:

    • Interval to scan for agent heartbeats

    • Scan agentless computers (specified interval)

    • Number of ping attempts

    • Time between pings

    • Ping time out

    • Number of scans before generating

  • Automatic Management: This setting specifies whether or not agent installs/uninstalls should occur automatically as changes in availability are detected. If your company uses any kind of change control, this setting is not recommended because you will not be able to control the agent deployments with any level of granularity. Often the Computer Discovery Rules used are not specific enough to risk the changes that setting may introduce.


The following global settings apply to Agents:

  • Agent Heartbeat:

    • Configuration Requests specifies the interval at which the agent will check for rule updates or settings changes. Raising this value will reduce the performance requirements of the MS but not significantly. Note that agent-side task requests follow this interval as well.

    • The heartbeat interval is coupled with the Management Servers setting. The option will not allow a value less than the scan interval; otherwise heartbeat scans would constantly indicate that agents weren't sending up heartbeats.

  • Responses: Specify the number of simultaneous responses (either script or notification) that can be performed at the same time. Ordinarily, this setting should remain at the default. However, if the agent tends to draw more resources running intensive scripts, consider lowering this value.

  • Temporary Storage: In the event that a Management Server is unavailable (e.g., the link is down between agent and MS), the agent will store the data until it can reestablish the link again, at which point it will send the data up. If there's a potential for unstable links in your organization, consider raising the value to accommodate for any data points that may be lost (assuming you need to save them all).


This setting can also be adjusted to compensate for situations in which the outgoing queue is full.

  • Service Monitoring: Instructs the agent to check the availability of a service every x number of seconds and record the availability information. The agent is also instructed to send this data to the Management Server every x number of seconds, as well.

  • Security: Refers to agent proxying whereby an agent can send data on behalf of a different computer.


This setting must be disabled for physical nodes of clustered servers. It's not necessary to disable this function in the Global Settings because it can be turned off per agent. Also, agents requested to handle proxying that are prevented from doing so will send an alert to the Management Server. This is useful if you want to keep this function turned on and don't know which agents require proxying capability.

  • Buffering: Allows a buffer to be set on things such as performance and event data which do not carry the priority of alert data. Alert data should always have a lower buffering threshold so that alerts can be sent quickly, while events and performance should lag behind because that data is mostly used for reporting or tracking. Altering the buffering settings to higher values may require temporary storage to be increased.

  • Communications: Controls the rate of data transfer. The default settings are the recommended settings and should be used wherever possible. However, if the value of Maximum amount of data per second is too low, you may experience issues with the agent cache filling up. The Packet size can be altered as well, raising the value to increase network utilization, but may result in additional latency.

  • Event Collection: Instructs the agent to collect binary information in any events that may have it. We recommend you leave this off because of potential database bloat. Not to mention, most administrators won't be able to use it for any useful purpose.

Custom Alert Fields

If the standard names of CustomField1 through CustomField5 don't work, you can change them to something more suitable. It can make it more presentable and understandable when these fields are in use.

Alert Resolution States

Additional alert resolution states can be added in this field to accommodate for the alert management in your organization. Optionally, they can be removed if it doesn't make sense. The Service Level of each escalation can be modified here as well.

Operational Data Reports

Enabling this setting allows the Management Servers to send operational reports to Microsoft.

E-mail Server

Specify an SMTP server to send e-mails for e-mail notification alerts. The Transport type cannot be changed. Only SMTP is supported.


The normal encrypted communication port is 1270. If this must be changed for any reason, the setting exists in this tab.


Three settings make up the contents of this tab. They do not necessarily relate so it's important to understand the function that this provides.

  • Mutual authentication required: As it implies, both agent and Management Server must authenticate (using Kerberos) before communicating. This model does not work for any domains that are not trusted. Because this cannot be disabled per Management Server, this generally must remain off for situations such as a DMZ domain computer.

  • Block MOM 2000 and MOM 2000 SP1 agents from connecting to the Management Server: This blocks any down-level clients from communicating with the Management Server. If mutual authentication is enabled, this setting is also enabled.


You may find from time to time that Security Issue alerts may come in erroneously from a MOM 2005 agent, specifying that it's a down-level agent attempting to connect.

Web Addresses

These settings specify various URL locations for information purposes. Only the FTP Address is an actual setting that changes agent behavior.

  • Web Console Address: Specify the Web Console Address as it should appear in e-mail notifications. It's important to emphasize that the Web Console port or URL cannot be changed. This is strictly for informational purposes.

  • File Transfer Server Address: Specifies the default location that file transfer responses should use to move files back and forth.

Database Grooming

This is one of the most important settings of your Management Server. This area specifies the behavior of auto-resolution of Alerts as well as grooming data from the database. The "Groom data older than the following number of days" setting tells the Management Server to remove data from the database for alerts, events, and performance data that are older than this value. (If there's a Reporting Server established, then the data is moved by DTS package.)

The "Specify when alerts are automatically resolved" setting instructs the Management Server to resolve alerts of a specific type (e.g., critical, error, inactive) to resolve. This is important for two reasons. First, the alerts will not resolve unless they are no longer active. If an alert has a repeat count that continues to climb and an activity date that's earlier than the specified auto-resolution cycle, it will not automatically resolve. Second, the groom setting will not touch alerts that are not resolved.

Notification Command Format

Specify the application details for the default external command when calling the Command options in a Notification response.

Product Connectors

This section remains unavailable for use until the following components are installed: MOM Connector Framework and MOM to MOM product connector on all Management Servers in the Management Group.

Professional MOM 2005, SMS 2003, and WSUS
Professional MOM 2005, SMS 2003, and WSUS
ISBN: 0764589636
EAN: 2147483647
Year: 2006
Pages: 132 © 2008-2017.
If you may any questions please contact us: