3.2. Preparing to Deploy
3.3. Deploying and Managing
It is important to ensure that the Windows event logs are configured correctly. MOM 2005 gathers a great deal of information from the Windows event logs. If the server stops logging events because the event logs are full, MOM won't able to report on the state of the managed computer accurately.
All logs should be configured to "Overwrite events as needed" with a maximum logfile size of at least 25 MB. If you leave the event logs configured to "Overwrite events older than X days" or "Do not overwrite events (clear log manually)," then you will likely
One way to ensure the logfiles are configured correctly is by using AD group policy. AD group policy is a mechanism that enforces configuration settings on computers. Group policies can be applied at the AD site, domain, organizational unit, and local computer levels. Group policies are applied in a specific order, so a policy that is higher in the order can be overridden by one that is lower or inheritance can be
Maximum application log size
Maximum security log size
Maximum system log size
Retention method for application log
Retention method for security log
Retention method for system log
Shut down the computer when the security audit log is full
You should also be aware of the effective Security Options Audit Group Policy setting that specifies whether the system should be shut down immediately if it is unable to log audit events to the security log. It may be appropriate to have the machine shut down automatically if it can no longer write to the security event log, depending on the security nature of its role. However, if the machine is not in a role that demands a high level of auditing, make sure this setting is disabled.
Configuration and application of domain-wide group policy is beyond the scope of this book, so for a detailed treatment of AD group policy, see Learning Windows Server 2003 and Active Directory , both published by O'Reilly.
All management group configuration
You can access this Microsoft management console (MMC) tool on the management server and on any computer where the MOM 2005
Notice that the details pane shows an inventory and classification of the computers that MOM is aware of and a list of
Familiarizing yourself to the Administrator console, and for that matter the Operator console, can take a bit of time, so be patient. There are multiple entry points into almost every function in both consoles. For the sake of clarity, this book will avoid using hyperlinks and instead show you how to navigate to that point manually. I have found that knowing where an object is located in the hierarchy helps in understanding its function and scope relative to the rest of the objects in the hierarchy. Use the hyperlinks once you know how to navigate the hierarchy and know the purpose of each node.
MOM 2005 can automatically install agents to computers
Figure 3-6 shows the default Automatic Management tab of the Management Servers Properties dialog box.
If you allow automatic installation, MOM will attempt to execute whatever install, uninstall, or upgrade action specified on this tab using the management server action account. If the account does not have full administrative permissions on the target computer, these operations will fail. You would receive failure notifications in the Operator console.
The "Uninstall delay" setting is useful for allowing a period of time between the creation of a computer discovery rule that will cause the removal of an agent and the actual removal of the agent. This interval can be used to ensure that all critical functions are removed from the node before monitoring is
By leaving this setting at the default, which is "Do not automatically install" MOM 2005 will place the target computers into the Pending Actions node with an entry indicating what the desired action is after each computer discovery cycle. You can then approve the action and it will be carried out during the
Since Leaky Faucet's administrator, Max, does not want unknown computers using MOM to generate alerts and he doesn't want unexpected configuration changes, he elects to retain the default setting.
When you install MOM 2005 into an AD directory services environment, MOM can take advantage of the native Kerberos v5 authentication present in AD. Both
Mutual authentication can only be configured globally, so there is only one setting for the entire management group. To configure mutual authentication, navigate to the Administrator console Administration node Global Settings Security, as shown in Figure 3-7.
Leaky Faucet has implemented a single AD domain, so mutual authentication was enabled during installation. They choose to accept this configuration because it enhances the overall security of their monitoring solution.
MOM 2005 agents can be installed on a discovered computer remotely from the management server, or locally at the discovered computer either by manually running the setup from the MOM 2005 installation media, which calls
, or by copying the
file to the local computer and running it there. The critical difference here is that the remote installation is initiated at the management server and is, therefore, intentional on the part of a MOM administratormanual installation is not. Manual installation can be initiated by
This setting is configurable globally, but can be overridden at the management server level. To install agents manually, which is the only method of installing agents on computers that are separated from the management server by a firewall, you should override this setting on a single management server. When you change this setting, you must also right-click the Management Packs node, select Commit Configuration Change, and then restart the MOM service on all the management servers in the management group for it to take effect.
Opening a single management server to manually install agents, rather than all of the management servers in a management group, gives you a higher degree of control and
Because Leaky Faucet is first installing agents into a trusted network with no port restrictions between targeted computers and the management servers, Max will use the remote push-type installation of agents. Max
So, the servers that you want to manage are now prepared and you've configured the pertinent parameters in the management group to allow the deployment of agents in this environment. The remaining task to do before the agents are deployed and the machines are monitored is to make the management servers aware of the target machines. You do this by creating computer discovery rules , which are really just filters that look for matches to search specified criteria. When a match is found between the scanned computers and the search criteria, a mapping to the managed computer is created on the management server. This mapping makes the management server responsible for agent administration and monitoring on that machine.
MOM 2005 has three ways to create the mapping between the scanned computers and the search criteria. Each method has its advantages and drawbacks:
Create discovery rules in the Computer Discovery Rules node, and then either run an on-demand computer discovery cycle, or wait for the daily automated cycle to run. The default is every day at 2:05 a.m., but you can change this by going to the Administrator console, and in the Administration node choose
Discovery tab. This cycle will use all of the computer discovery rules that have been configured. Agents are automatically installed or
Use the install/uninstall agents wizard. This tool helps create a specific computer discovery rule,
Create a text file that contains the
Do your initial discovery by creating your rules in the Computer Discovery Rules node. This method gives you the greatest flexibility and describes the configurable parameters. Skip the wizard to start with, because it does other things at the same time and there are certain restrictions associated with it. The ManualMC.txt method is a holdover from the previous version of MOM. So, you either have to maintain it manually on each management server or develop scripts to do so; either way is prone to human error.
To start creating rules, navigate to the Computer Discovery Rules node in the Administrator console, then right-click and select Create Computer Discovery Rule. This
The computer discovery rule options are as
When you create a computer discovery rule, it is linked to a specific management server. When the discovery cycle runs, computers that match this filter become "owned" by that management server for the purposes of agent administration. If there are multiple management servers in a management group, this drop-down list will allow you to select which management server you want to bind this rule to. homemomserver has been selected for this example.
Use the "Rule type" field to specify whether the rule will be used to include computers for management by the management server or exclude them from being managed. Exclude rules always override include rules. Since the only two computers that are currently being managed by this management group are the management servers
In the "Domain name" field, enter the NetBIOS name of the domain that you want searched, the Fully Qualified Domain Name (FQDN), or no value at all. The more the search scope is narrowed by providing distinguishing criteria, the quicker the search will run. If the rule searches for computers that are not in the same domain as the management server you are configuring the rule on, use the FQDN, because it gives the rule a more exact focus. homesqlserver is located on homelab, so that is entered here.
The "Computer name" field is where you specify most of the distinguishing criteria. The first drop-down menu allows you to select from the following options:
Equals. Use this to match an exact string. When selected, wildcard
Contains substring. This is useful if your server naming convention includes characters that specify a server role and there are multiple servers in that role, such as EXCH for Exchange servers. In Figure 3-9, the string HOME is specified because all servers in the homelab domain have that substring in them, but workstations do not.
Matches wild card. This allows you to insert ? (any character), * (any number of characters), or # (any digit) values into the target text in the next field.
Matches regular expression and matches Boolean regular expression. To build more complex filters, select these options from the "Computer name" field. This will make the matching types of operators available for insertion into the search string.
This rule can discover all of the servers in the homelab domain. By specifying contains substring HOME, homesqlserver and all of the other servers in the domain will return as a result. You can then choose to install agents or start agentless management without having to configure another rule.
Unless you have very specific needs, such as a management server that will be dedicated to managing either servers or clients, leave this at the default setting of Servers and Clients. If you change it to one or the other, the discovery process must query each computer that has matched the filter for its role in the domain. It is left at the default setting here.
The default Initial Management Mode is Agent-managed, but you can also select Unmanaged or Agentless-managed. This field doesn't play a role in the filter, but labels the discovered computers with the type of management you want to be performed.
The Agent-managed option is self-explanatory.
The Agentless-managed mode provides some of the functionality as the full agent, but it cannot monitor across firewalls (it uses the RPC port range), and not all data providers are supported (
Unmanaged is a management mode that indicates that MOM is aware of the computer but is not currently monitoring it. Before you can delete a computer from MOM, the agent must be removed or agentless management must be stopped. This places the computer into the unmanaged category.
Finally, the two checkboxes, "Apply query criteria to domain controllers" and "During computer discovery, contact each computer to verify that it exists," change how the query runs. By default, queries are not applied to domain controllers, nor do they verify the existence of a server. So, if you have stale computer entries in AD, the "Verify existence" setting can help weed them out at the cost of increasing the overhead and time required to complete the search.
If a computer is
Now that the discovery rule has been configured, you can either initiate a full computer discovery cycle or wait overnight for MOM to kick discovery off automatically. To initiate discovery immediately, right-click the Computer Discovery Rules node or the Management Servers node and select Run Computer Discovery Now. A pop-up box will appear, confirming that a computer discovery task has been submitted to the management servers. The management server then queries the domain that was specified in the rule and applies the search criteria. If you have configured the rule to verify existence or to determine the computer role of the matches it finds, it will perform those actions now as well.
What happens next depends on how you configured automatic agent installation. If you allowed it, the management server will attempt to execute whatever action the rule specifies. For example, if you have created an Include rule that specifies the initial management mode as agent-managed, the management server will attempt to push an agent to the newly discovered computer using the management server action account credentials. If you have created an Exclude rule that has all the other settings configured identically, it will schedule an uninstall action for the targeted agents that will wait until the uninstall delay interval has passed and then uninstall the agent.
If you have disallowed automatic agent installation, then the management server will place an entry for the discovered computers in the Pending Actions container, as shown in Figure 3-11.
Figure 3-11 shows that four computers have been found that match the search criteria. The domain controller homesrv02 is listed because the search criteria were applied to domain controllers. homesqlserver has been discovered, its management mode is currently Unmanaged, and the desired Management Mode is Agent-Managed. MOM 2005 will hold the discovered computers in this state until an administrator approves or rejects the desired action, or initiates the action immediately. You make this choice by right-clicking the computer or group of computers and selecting the desired action. Again, if you choose to approve the action, MOM will attempt to execute it during the next discovery cycle using the management server action account credentials.
Using the Computer Discovery Rules node to create discovery rules, run discovery cycles, and install/uninstall agents gives you the most flexibility of the three methods. It also gives you access to all options and incorporates the best features of the other two
Because Leaky Faucet (and homelab) chose a management server action account that is a domain user account with no administrative rights on any computers except the management servers, approving the desired action for the discovered computers will always fail. The next step is to choose the Install Agent Now option, as shown in Figure 3-12.
This starts the Install Agent Wizard, which prompts you for a set of credentials to install the agent on the target computer, as shown in Figure 3-13. These credentials are stored securely during the install process and are then disposed of. Choosing to install agents in this manner does not impose any restrictions. This technique is used to build security into your procedures. For example, if the installation account is the domain administrator account or equivalent, or the target machine's local administrator account, then an administrator would enter the credentials at this time. If this person isn't the original MOM administrator, then an additional individual will have to be added to the agent deployment or removal process, which introduces a human checkpoint and bottlenecksecurity is always a trade-off.
Next, you are prompted to identify and provide the credentials for the Agent Action Account, as shown in Figure 3-14. The local system account is
The next prompt is for the agent installation directory. Remember this defaults to the %Program Files%\Microsoft Operations Manager 2005 folder, which is on the C: drive. Since this is the drive that was inventoried for space, accept the default.
This takes you to the Completing the Install Agent Wizard page shown in Figure 3-15, which provides you with a summary of the actions and allows you to choose to view the task progress. Click Finish to start the installation of the agent.
By selecting the "Show task progress" checkbox, the progress of the agent installation is tracked and displayed, as shown in Figure 3-16. Note that if you selected multiple machines, this single display window would have tracked all of the agent installations.
Once finished, the tracking window will display the final status of the action. If a successful status is returned, this is the first indicator that the agent installation has completed and the target server is now being monitored. If the installation process encounters an error and fails, the tracking window will return a failure status along with initial diagnostic information for the failure (see Figure 3-17). The failure was caused by not providing the correct agent installation credentials to the agent installation wizard.
At this point, the server
has been removed from the Pending Actions container and placed into the Agent-managed Computers container. The computer is being monitored and will now appear in the operator console as well. The computer that the installation failed on will
The last task in successful agent deployment is to confirm that the agent has installed successfully and is returning data to MOM. The first indication of a successful deployment is the success status returned at the end of the agent installation wizard. The second indication is that you can examine the computer data in the results pane of Agent-managed Computers container and access the properties of the agent on the target computer, in this case homesqlserver (Figure 3-18).
Figure 3-18 shows that the agent is returning data, the time the server was last contacted, the time and date that it was successfully added to MOM, and the primary management server. If you right-click the managed computer and bring up its properties, as shown in Figure 3-19, you can see additional information such as the time of the last good heartbeat and any alerts generated for this computer. These are all definitive indicators that the agent has installed successfully.
The last step is to confirm that end-to-end monitoring is occurring successfully. This is done in the Operator console. Navigate to the State view, select the target computer, and launch the Test End to End Monitoring task against it. This should produce a 9898 informational event that is viewable in the Public Views Task Status object indicating the following:
Type: Information Domain: HOMELAB Computer: HOMESQLSERVER Description: The task 'Microsoft Operations Manager\Test End to End Monitoring' has successfully executed against 'Computer:HOMELAB\HOMESQLSERVER'. Launched By: HOMELAB\user1 The following output has been generated: Source: Microsoft Operations Manager Event Number: 9898 Provider Type: Generic Provider Provider Name: Internally-generated Event Source Domain: HOMELAB Source Computer: HOMESQLSERVER
This shows that the agent was successfully deployed and is working. Chapter 4 discusses how processing rules are passed to the agent and what the agent does with them. As far as agent administration, there are only a few other tasks that you can perform: uninstalling the agent, forcing it into unmanaged mode, and updating the agent's settings.
One alternate method of installing agents combines the creation of the computer discovery rule with a limited discovery cycle and agent install/uninstall. This is probably the quickest method for installing or uninstalling agents, but you lose the ability to configure some of the deployment options. For example, you can only create Include computer discovery rules . But you can browse for target computers in addition to creating the search criteria.
To start the Install/Uninstall Agents Wizard, click on the hyperlink by that same name in the results pane, as previously shown in Figure 3-5. Or right-click on the Computers node, the All Computers node, or the Agent-managed Computers node in the navigation pane of the Administrator console.
After the welcome page, select the management server to apply the computer discovery rule (see Figure 3-20). In this case, homemomserver2 is selected.
Because homemomserver2 currently has no agents reporting to it, the wizard automatically proceeds through the steps to install or uninstall agents. If you selected a management server that was already managing agents, the wizard would prompt you to proceed with the install or uninstall process.
Next, you can browse for a computer or group of computers, or create the search criteria using the same process as the Computer Discovery Rules method (see Figure 3-21). This is described in the previous section, "Confirming Agent Functionality."
If you select the "Browse for or type in specific computer names" option here, you can enter the specific computer names in either FQDN or domain\NetBIOS name format, as shown in Figure 3-22.
The browse button
If you select the "Search criteria" option in the Method for Discovering Computers and Installing Agents page (see Figure 3-21), you are presented with the same Computer Discovery Rule dialog box as discussed in the previous section. However, your options for rule configuration are not available, namely the management server, the rule type, and the initial management mode. By default, the wizard also selects to verify the existence of the target computers (Figure 3-24). If you need to control the rule type or management mode options, you should not use the install/uninstall agents wizard.
Once you have identified the target computers through one of these methods, the install/uninstall agents wizard behaves identically to the agent install wizard. It prompts you for the credentials to install the agent, for the agent action account, and the directory to install the agent. When you finish the wizard, the same task progress feedback appears.
The install/uninstall agents wizard then performs a limited computer discovery cycle that only looks for computers according to the rule/filter that was created in the wizard and executes the install/uninstall action against it. This is unlike the daily full discovery cycle, which will search the network and apply all discovery rules that have been configured, execute the actions specified in those rules, execute any actions that have been approved for computers in the Pending Actions container, and place discovered computer names into the operations database.
The difference between the previous method and this one is that in this method, the action will be executed regardless of the automatic agent installation setting. The target computers are never placed into the Pending Actions container, so there is no opportunity to reconsider or to check your work once you click Finish in the wizard. Although this method of installing agents may seem easier, the functionality that is lost is not offset by the ease of use. I don't used this wizard because it adds little value in my eyes.
At this point, if you used the wizard to perform an agent install, you should go through the steps to confirm agent functionality.
To use this method of installing agents, simply create a text file named ManualMC.txt on the management server that will own the agents and populate it with the names of the desired target computers. You can use FQDN, NetBIOS name, or domain\NetBIOS format. Here is an example of the contents of a ManualMC.txt file using the FQDN format:
avalon.homelab.lab homesrv02.homelab.lab homee2k3server.homelab.lab homememberserver.homelab.lab
Note that there is only one entry per line and that there are no spaces between the lines. Also, for the sake of clarity, you should use a single format for the computer name for all entries. If you need to add computers that are not
When the next full discovery cycle runs, the management server will either place these computers into the Pending Actions container for further action or execute the installation based on the automatic agent installation settings. To uninstall an agent that was installed using this method, simply delete its entry from the ManualMC.txt file and either wait for the daily discovery cycle to run or initiate a full discovery cycle yourself. Remember, if you want the management server to perform the install/uninstall tasks automatically, then the management server action account must have full administrative rights on the target computers.
This text file method for discovering and installing agents is the easiest to configure but also gives you the fewest options and no immediate feedback except by monitoring the Administrator and Operator consoles for the expected changes. With this method, as with the wizard, you can only identify computers that will be agent managed, and you cannot use the
file to exclude a computer from being managed by a management server. Using this method overrides all other Include rules but not Exclude rules for that management server. This method is
Uninstalling the agent is a very simple task. Right-click the managed computer in the Agent-managed Computers container in the Administrator console, select Uninstall Agent, and provide the appropriate credentials. With this method there isn't a
You'll need to update an agent to change things like the storage space allocation on the agent, the communication port, the "Collect event binary data" settings, and the agent control level if it is set to None. Most significantly, if you need to change the agent action account or if the mutual authentication setting is changed, these modifications will need to be
Pushing agent updates to managed computers is a different process than pushing management pack updates to managed computers. For example, if you make a change to a threshold where a processing rule generates an alert, or if you disable a rule, these changes are pushed down automatically once a minute. Updating agent settings is a manual process and is only needed when reconfiguring the agent.