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).
|
Note |
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!
|
Important |
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.
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.
Computers
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.
|
Note |
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.
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:
-
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.
-
The Install Agent Wizard begins. Click Next
to move to the next window.
-
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.
Figure
6-1
-
Choose the appropriate Agent Action Account
for the computer to use. Click Next.
-
Specify an Agent Installation Directory. If
the default is suitable, leave it as is and click Next to
continue.
-
In the last window, verify the actions that
you've selected. Click Finish to continue.
|
Note |
In order to see the progress of the
installation, leave the Show task progress check box selected.
|
-
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.
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.
|
Important |
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:
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.
|
Important |
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.
|
Note |
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.
|
Important |
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.
-
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.
-
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.
-
Type in a description and keep it relevant.
It'll suppress the urge to question its existence later.
-
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.
-
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.
-
Click Finish to end the wizard.
-
Launch the Computer Management MMC.
-
Navigate to Local Users and Groups, and
select Groups.
-
Double-click MOM Users and add in the
appropriate users as defined in Step 5.
|
Important |
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.
|
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.
|
Important |
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.
Agents
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).
|
Note |
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.
|
Note |
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.
Communications
The normal encrypted communication port is
1270. If this must be changed for any reason, the setting exists in
this tab.
Security
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.
|
Note |
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.
500 Internal Server Error
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator at
webmaster@systemmanager.forsenergy.ru to inform them of the time this error occurred,
and the actions you performed just before this error.
More information about this error may be available
in the server error log.
Additionally, a 500 Internal Server Error
error was encountered while trying to use an ErrorDocument to handle the request.
| |