The discovery process identifies systems to which you can install agents or systems you can configure for agentless monitoring. This discovery process queries the Active Directory directory service for computer information matching the requirements you defined for discovery.

The Microsoft MOM team provides an excellent graphical representation of how the discovery process works. It is available at http://blogs.technet.com/momteam/archive/2007/12/10/how-does-computer-discovery-work-in-opsmgr-2007.aspx/. Figure 9.1 is based on that graphic, with the specific steps for discovery listed next.

Figure 9.1. Computer discovery in OpsMgr 2007.

To follow along with the steps in Figure 9.1, the process for computer discovery is as follows:

The Discovery Wizard has been enhanced since MOM 2005, with capabilities for automatic discovery of all Windows-based computers, and can scan computers in a specific Organizational Unit (OU). You can discover machines residing in nontrusted domains and workgroups if you provide the computer name in the format DomainComputerName or WorkgroupComputerName.

MOM 2005 included the capability to schedule computer discovery. This functionality was replaced in OpsMgr 2007 with Active Directory Integration (discussed in the “Active Directory Integration” section of this chapter), which applies the OpsMgr settings to systems with the agent deployed.

Because not all environments use Active Directory Integration, how can you schedule computer discovery in OpsMgr? You can use PowerShell with a scheduled task; an example of which is provided by Tarek Ismail at http://tarek-online.blogspot.com/2007/07/how-to-schedule-discover-and-install.html:

param ($OpsMgrservername,$Domainname)
#Initialize the OpsMgr Provider
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
#Set the location to the root of the provider namespace
cd OperationsManagerMonitoring::
#create a connection to the Management Group
New-ManagementGroupConnection $OpsMgrservername
#change the path
cd $OpsMgrservername
#configure query setting
$ldap_query = new-ldapquerydiscoverycriteria -domain $Domainname -ldapquery "(sAMAccountType=805306369)(name=*ABC*)"
#configure discovery setting
$windows_discovery_cfg = new-windowsdiscoveryconfiguration -ldapquery $ldap_query #discoveryresults
$discovery_results = start-discovery -managementserver (get-managementserver) -windowsdiscoveryconfiguration $windows_discovery_cfg
#install Agent
install-agent -managementserver (get-managementserver) -agentmanagedcomputer $discovery_results.custommonitoringobjects

Save this script using a name such as Agentdiscoverinstall.ps1 and configure it to run periodically from the Windows scheduler on the RMS using the following syntax:

Powershell.exe Agentdiscoverinstall.ps1 -OpsMgrservername: localhost-Domainname:<domain>

When this script runs, it will discover the computers that match the Lightweight Directory Access Protocol (LDAP) query defined in the script.

OpsMgr’s default configuration rejects manually installed agents. You can change this configuration in the Administration node of the Operations console. Perform the following steps:

An agent-managed system runs a software component called the OpsMgr agent, which runs as a local service on each computer it is installed on. The agent monitors the computer using management pack objects, which apply to that agent. The management server will update these objects as changes are applied to the management packs used by that management group. Updates are received by the agents at the next configuration request interval (5 minutes by default) after changes are applied. Typically, OpsMgr configurations use agent-managed systems.

Installing OpsMgr 2007 and the Reporting capability automatically imports approximately 40 management packs, listed in Table 9.1. The majority of these management packs are libraries, which provide a foundation of object types and settings that other management packs depend on. The other installed management packs monitor the health and availability of Operations Manager and the OpsMgr agent.

As you integrate other management packs into OpsMgr 2007, additional items will be monitored depending on the functionthe server provides.

You can deploy OpsMgr 2007 agents to the following operating systems:

Figure 9.3. Windows XP and Vista systems in the Client State view.

Microsoft does not support Microsoft Windows NT 4.0 in an agent-managed configuration (or support any other operating systems that do not match the configurations listed previously). If there is a requirement to manage unsupported systems such as this, consider either agentless management or review third-party supplemental software for OpsMgr 2007.

An agentless managed system does not run the OpsMgr agent. The Agent Component on the management server (or Root Management Server) collects data from the agentless managed computer through remote calls to that system. OpsMgr 2007 does not have a documented limit on the number of agentless managed systems that can report to a management server, but in MOM 2005 Microsoft limited support for agentless systems to 10. This limit was a supportability limit, not a physical limit (that is, 11 or more agentless systems would still function). The limit was rather a recommendation, based on the impact on the performance of the management server providing the agentless monitoring functionality.

There are restrictions to using agentless monitoring. It is not supported on several management packs and provides a reduced set of functionality for others. We discuss these topics in more detail in the “Integrating Agentless Managed Systems into OpsMgr 2007” section of this chapter.

Application owners are sometimes concerned about installing agent software onto their application servers and the potential impact on the operations of that computer. The resource load on an agent-managed computer is low and does not generally pose a problem.???

For some environments, any change to the configuration or installed software base may lead to complications. A good example of this is a validated system where specific testing processes must occur for any changes to the configuration, including deploying agents. (A validated system is one that has a strict process to validate the functionality of the system anytime software is installed on it.) In these cases, the Information Technology (IT) group responsible for server management wants to avoid even the appearance of affecting an application server, thus avoiding potential liability. If you are in this situation, you can use the agentless management mode to manage servers that might otherwise be unmanaged. As discussed earlier (in the “Agent-Managed State” section), legacy systems such as NT 4.0 or operating systems that are not current on patching are also common reasons for at least temporarily using an agentless configuration.

Agentless managed computers have a more limited set of features than do agent-based managed computers. Similar to agent-based managed computers, agentless managed computers include the following capabilities:

However, there are some significant limitations to agentless managed systems. The primary limitation is the management packs that will not run agentless. This list includes the following:

Agentless monitoring also increases the resource load on the management server that is monitoring the system.

Unknown systems are unmanaged systems, either identified for potential management in the future (the systems are discovered but they are not managed) or that have had the agent removed from them. OpsMgr does not collect information from unmanaged systems. Computers in an unknown state display in the right-side pane in the Operations console at the root of the Monitoring node. (In Figure 9.4, see the empty circle on the right side of the screen.)

Figure 9.4. Devices currently in an Unknown state.

Operations Manager 2007 has additional functionality to provide a seamless integration for monitoring network devices. Microsoft designed the network device functionality in OpsMgr to monitor devices by providing information from the Simple Network Management Protocol (SNMP) to OpsMgr. You can view network devices through the Operations console in the Administration node, as shown in Figure 9.5. To add a network device, on the left side of the screen, right-click Device Management and start the Discovery Wizard, selecting the option for an Advanced Discovery.

Figure 9.5. Network Devices.

Chapter 17, “Monitoring Network Devices,” includes information on how to discover and use network devices with OpsMgr.

Operations Manager 2007 adds new functionality that provides the ability to configure agents through Active Directory (AD). This takes place by publishing the OpsMgr agent configuration details to Active Directory. An OpsMgr agent performs an LDAP query to the authenticating domain controller at startup, determining the management group it belongs to and the management server with which it will communicate. Note that Active Directory Integration does not actually deploy the agent.

Configuring Active Directory Integration

Although the AD Integration approach simplifies deploying OpsMgr 2007 agents, it increases the complexity of your OpsMgr configuration. We do not recommend AD Integration except for organizations with a very large number of agents deployed.

Three steps are involved in configuring Active Directory Integration with OpsMgr:

1. Creating Active Directory objects

2. Configuring the Operations console

3. Modifying the AD Integration Registry key

The first step is to run the MomADAdmin utility on a domain controller with an account that is a member of the Domain Admin security group. This utility is located under the SupportTools folder in the OpsMgr installation media and creates the required Active Directory objects. The syntax to run this command is as follows:

<LINELENGTH>90</LINELENGTH>

MomADAdmin.exe <management group name> <OpsMgr Admins Security Group> <RMS name> <AD Domain>

We can look at our Odyssey environment as an example. We have a single management group named GROUP1. The RMS is Hydra, and we are monitoring systems in the Odyssey.com domain.

We created a computer group named OpsMgr Admins as a global security group on the domain. This step is important because the MomADAdmin utility tool does not create the specified group; it assumes that the group already exists. To configure Active Directory Integration in our domain, we logged in to the domain controller (Pantheon) as a domain administrator and ran the following command:

<LINELENGTH>90</LINELENGTH>

MomADAdmin.exe GROUP1 "OpsMgr Admins" Hydra Odyssey.com

The MomADAdmin utility creates the Operations Manager -> (Management Group name) -> HealthServiceSCP container and contents in Active Directory, as shown in Figure 9.6. This container includes a security group <Management Group Name>_HSvcSCP_SG (for our example, this is GROUP1_HSvcSCP_SG) that is used to determine who can read the HealthServiceSCP container. In addition, the utility adds the RMS computer account to the security group the utility creates. The container also stores special objects called service connection points, used to publish information about desired agent settings that the agent queries at initial system startup.

Figure 9.6. Operations Manager container for Active Directory Integration.

Tip: How to Tell If an Agent Is Using Settings from the SCP

The Registry key HKLMSYSTEMCurrentControlSetServicesHealthServiceParametersmanagement groups<Management Group name>IsSourcedFromAD has a value of “1” on agent-managed machines. This indicates the agent will gather settings from the SCP (service connection point). The key is only on AD-integrated systems.

The Windows NT Operations Manager Event log on the agent-managed machine records successful access to the SCP information from the agent, with event IDs 20062 and 20013 of type Information from the event source OpsMgr Connector.

After we finish creating objects, the next step is configuring the Operations console for AD Integration. In the Operations console, navigate to Administration -> Device Management -> Management Servers.

Select the management server you will configure AD integration for, right-click the management server, and choose Properties. (You can also initiate this from the Administration screen by clicking the Configure Active Directory (AD) Integration optional configuration and choosing the management server to configure.) Click Add on the Auto Agent Assignment tab. This starts the Agent Assignment and Failover Wizard. To configure agent assignment with this wizard, perform the following steps:

1. Click Next to continue on the Introduction page.

2. On the Domain screen, choose the domain to configure AD Integration on (this defaults to the domain the management server is within) and choose the account to perform the issue (which defaults to the Active Directory Based Agent Assignment account). Click Next to continue.

3. On the Inclusion Criteria screen, click Configure to define an LDAP query to target the computer accounts.

4. On the Find Computer screen, we define how to create the LDAP query. As an example, choosing the wildcard “*” will define an LDAP query that chooses all computers in the domain. Click OK to leave the Find Computers screen. You can create LDAP queries that are more complicated by selecting the Advanced tab and defining the criteria. The fields available include Computer name, Description, Managed By, Name, Operating System, and Operating System Version. Conditions available consist of Starts with, Ends with, Is, Is Not, Present, and Not present. Figure 9.7 shows a LDAP query defined to apply to computers that start with DAL.

   

   Figure 9.7. LDAP query to include systems that start with DAL.

5. Click Next to continue to the Exclusion Criteria screen.

6. On the Exclusion Criteria screen, specify any systems to exclude from auto-assignment. Add the Fully Qualified Domain Names (FQDNs) on this screen, delineating using a semicolon, comma, or newline. You can cut and paste text into this screen, providing a method to add large numbers of systems for exclusion. Click Next to continue.

7. The Agent Failover screen specifies how to handle agent failover. Here are the options available:

   • Automatically manage failover—. Agents will report to the other management servers in the management group.

   • Manually configure failover—. Allows you to define which management server(s) the agents should fail over to.

   We recommend using automatic failover, unless you have a requirement to fail to a specific management server in your environment. This might be when you have management servers in different physical locations and do not wish to fail over the agents to the management server in the remote location.

8. Click Create to finish the Agent Assignment and Failover Wizard.

To complete the process of activating OpsMgr integration with AD, the final step is to make a Registry change on each management server. Use the Registry editor to edit the Registry (select Start -> Run and then type regedit). Follow these steps:

1. Open HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHealthServiceParametersConnectorManager.

2. Right-click the EnableADIntegration key and set the value to 1, as we show in Figure 9.8.

   

   Figure 9.8. Registry key change to enable AD Integration.

3. Click OK and close the Registry editor.

   Tip: Active Directory Integration and Domain Controllers

   You cannot configure domain controllers to use Active Directory Integration. To understand why, you need to understand how AD Integration works in more detail. To control which agents go to which management groups, an Access Control List (ACL) is used on the object. This ACL, created in Active Directory, represents the management group.

   The computers allowed to join the management group have rights to read the SCP object created for the management group. When an agent using AD Integration starts up, the OpsMgr Health service (running as Local System) goes to AD, does a lookup to find what SCPs it has access to, and from that determines which management groups it should be a member of.

   For a domain controller, the built-in Local System account has full access to read each of these folders for the SCP, so it would attempt to join every management group. To work around this issue, OpsMgr disables AD Integration for domain controllers.

MomADAdmin.exe -d GROUP1 Odyssey.com

Group Policy can deploy software, both through software deployment and running the installation using a startup script. Group Policy software deployment cannot run setup switches with an MSI package as part of a GPO, so using this method requires creating a transform (MST) file for the Operations Manager 2007 agent. Currently no transform files exist, so we will instead focus on how to deploy the agent through using a startup script, which requires the following steps:

You can use SMS or ConfigMgr to deploy the OpsMgr 2007 agent. For the purposes of this section, we will refer to both products as SMS—this being the most familiar name to most IT professionals. The primary benefits to using these products to deploy the OpsMgr 2007 agent include the following:

The negatives to using SMS to deploy the OpsMgr 2007 agent include

SMS uses packages that you create. These packages are deployed to collections of systems by creating an advertisement. Creating the package for OpsMgr is simple and requires only a few steps.

You can use various imaging technologies to install or deploy operating systems, including Norton Ghost and Systems Management Server Operating System Deployment (OSD). Imaging can deploy preconfigured operating systems that may already have applications deployed on them. Imaging provides a rapid way to install identical operating systems and software configurations on multiple systems very quickly and efficiently.

Imaged systems can integrate the OpsMgr agent as part of the image. When the system starts, it looks up its configuration in Active Directory (see the “Active Directory Integration” section earlier in this chapter), and the agent is able to report to the specified Operations Manager management server.

Integrating the OpsMgr agent into the image and using the Active Directory Integration technologies provides a deployment method that is easy to maintain after implementation. For smaller organizations that do not frequently add systems for monitoring by OpsMgr, this approach is most likely overkill.

The Operations Manager 2007 Discovery Wizard provides an easy-to-use process to discover and deploy agents for OpsMgr. The Discovery Wizard can easily scan an entire Active Directory domain for Windows-based systems, limit its scan to specific OU structures, browse for computers, or even deploy to specific systems you enter that you can cut and paste into the wizard. You have several things to consider when using the Discovery Wizard to deploy agents, including the following:

The Discovery Wizard first discovers the system(s); after discovery, you can choose the specific system(s) to receive the OpsMgr agent. You can see deployment successes and failures displayed within both the Deployment Wizard results and the Tasks section (Monitoring -> Tasks). We recommend using the Discovery Wizard to discover and deploy agents in all but the largest of OpsMgr environments.

MOM 2005 had a process to create discovery rules that identified what agents would report to what management server. These were auto-created with the Install/Uninstall Agents Wizard, or created manually and viewable within a Computer Discovery Rules folder in the Administrator console.

With Operations Manager 2007, the discovery process occurs as part of the Discovery Wizard, and there is no direct interaction with the discovery rules. This simplifies the process for deploying agents because the discovery rules often became complex to manage over time.

Using the wizard is the easiest method to deploy OpsMgr agents. To launch the Discovery Wizard, perform the following steps:

In general, manual agent installation should be the method of last resort for deploying OpsMgr agents. This deployment requires you to log in to the system that you will be installing, make configuration changes to OpsMgr, and approve the agent installation. Typically, you will use manual agent installations when specific servers are not installing the agent using the more automated methods. Take the following steps to perform a manual installation:

PowerShell also provides a method to deploy agents for Operations Manager 2007. Installations through PowerShell are considered manual installations and need to be approved (or your OpsMgr environment must be configured to auto-approve new manually installed agents through the Operations console -> Administration -> Settings -> Security). The following is a sample script (provided by the “PowerShell guy” and is available at http://blogs.msdn.com/scshell/archive/2007/02/09/discovering-windows-computers.aspx).

# ScriptName: InstallAgents.ps1
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true
# Create the discovery configuration for computer2 and computer3. $discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: Computer1, Computer2
# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig
# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer-AgentManagedComputer: $discoResult.CustomMonitoringObjects

Save this script as InstallAgents.ps1. For the following example, we stored it in the D:Scripts folder. To run the script, select Start -> Run and type the following:

%windir%system32windowsPowerShellv1.0PowerShell.exe -noexit D:ScriptsInstallAgents.ps1

Note that the command assumes you saved the script to the D:scripts folder. The -noexit parameter stops the window from closing, which makes it possible to debug the script.

You can also run this script by opening the Command Shell (Start -> All Programs -> System Center Operations Manager 2007 -> Command Shell). To run the script from the Command Shell, change to the folder where the script is (d:, cd , cd scripts) and then run the script by typing .InstallAgents.ps1.

You can deploy agentless systems using the Discovery Wizard, similar to the way you deploy agent-managed systems. The wizard screens discussed in the “Using the Discovery Wizard” section of this chapter work in a similar fashion as when deploying an agent-managed system. The differences occur after the Discovery Wizard has run when choosing the devices to manage and the management mode they will use. The default on the screen is agent-managed mode, but the agentless mode is also available in the Management Mode dropdown box, as shown in Figure 9.16.

Figure 9.16. Discovery Wizard when deploying agentless managed systems.

When you select the agentless management mode, the screen also changes the Management Server field to Proxy Agent. This changes the available servers from the management servers in the environment to agent-deployed systems, allowing non-management servers to provide the agent proxy functionality to monitor your agentless systems. We will explain agent proxying in more detail in the next section of this chapter. Agentless managed systems display in the Administration -> Device Management -> Agentless Managed section of the Operations console, as shown in Figure 9.17.

Figure 9.17. Agentless managed systems displayed in the Operations console.

You can remove agentless systems in the Administration -> Device Management -> Agentless Managed section of the Operations console by right-clicking the computer name, selecting Delete, and choosing Yes to stop agentless monitoring of the system.

Operations Manager 2007 supports agent proxying. When you manage an agentless managed computer, it must be assigned to a management server or agent-managed computer to provide remote (proxy) agent functionality. As we previously discussed in the “Agentless Managed State” section of this chapter, computers are managed as agentless when you either cannot or do not want to install an agent on them.

Not all management packs work in agentless mode, and agentless management itself will not work if the agentless computer and its proxy are communicating through a firewall. Proxying is the capability for an agent to relay or forward information from other computers or network devices to the management server. Disabling agent proxying prevents spoofing by an attacker pretending to an agent, because the management server matches information sent from the agent to a known agent name before accepting the data. Agent proxying is disabled by default.

The proxy agent can be any agent-managed computer in the management group configured to be a proxy, including a management server.

Perform the following steps to configure agent proxying on an agent-managed computer:

If you want to configure a management server as a proxy for agentless managed computers, perform the following steps:

You will need to perform this procedure for each agent or management server for which you want to allow agent proxying. Enabling agent proxying allows the system to provide information for objects that do not have an agent installed on them. One of the most common examples for proxy agent configurations is monitoring network devices.

A number of management packs use agent proxying. For example, the Active Directory management pack requires that you configure all agents on a domain controller to allow proxying. For the Active Directory management pack, this setting allows the domain controller to discover its connection object between other domain controllers from information hosted by the forest, not the domain controller itself. Other examples of management packs using agent proxying include the Exchange management pack and the SharePoint management pack.

To change an agentless system to an agent-managed system, the process is to first delete the agentless managed system and then deploy the agent to the system. To delete an agentless managed system, follow these steps:

After deleting the agentless managed system, you can deploy an agent to the system using one of the standard methods of deploying agents discussed in the “Discovering and Deploying Agents” sections of this chapter.

In Chapter 7, “Migrating to Operations Manager 2007,” we discuss different methods available to migrate from MOM 2005 to Operations Manager 2007. This is actually very easy to accomplish due to how the OpsMgr agent differs from the MOM 2005 agent. The MOM 2005 agent service is called “MOM,” whereas the Operations Manager 2007 service is the “OpsMgr Health service.” The two agents run different programs under different service names, which separates them from each other when they are on the same machine.

However, the agents perform similar tasks. Each agent collects information such as performance counters and events and runs scripts. There is potential for crosstalk between the two agents, where actions performed by the MOM 2005 agent create an event interpreted by OpsMgr 2007, and vice versa.

In some situations, the two agents may collide, but the only restriction identified at this time concerns monitoring domain controllers in a 64-bit environment. Both the MOM 2005 Active Directory management pack and the OpsMgr Active Directory management pack depend on the Active Directory Helper object, but MOM 2005 requires the 32-bit version and OpsMgr 2007 requires the 64-bit version! The Active Directory management pack guide discusses this in more detail (available for download from the OpsMgr documentation link available at http://technet.microsoft.com/en-us/opsmgr/bb498235.aspx).

Although there are some potential challenges with coexisting MOM 2005 and OpsMgr 2007 agents, with the new OpsMgr agent these should be minimal.

Agents in Operations Manager 2007 can report to multiple management groups. These types of agents are multihomed agents. Multihomed agents typically are used for the following:

For more information on planning a multihomed environment, see Chapter 5, “Planning Complex Configurations.”

In MOM 2005, there was a limit restricting a multihomed agent to a maximum of four management groups. This restriction does not exist in OpsMgr 2007 because the agent software was almost completely rewritten.

We would, however, suggest limiting the management groups to four or less, and definitely less than 30. Also, be aware that there is an increase in the memory requirements of the agent when an OpsMgr 2007 agent reports to multiple management servers.

You can deploy multihomed agents using the Discovery Wizard for each management group, or you can do so manually by running the OpsMgr Agent Setup Wizard on the managed computer.

Event logs of a monitored system are one of Operations Manager’s major data sources. If the Event log on a managed computer fills completely, event logging either stops or events are overwritten, depending on the configuration of the Windows NT Event log. A full Security log can even stop the computer from functioning! If the Event log is not able to gather information, OpsMgr cannot provide information effectively about the status of the monitored system.

The recommended log file configuration for managed systems is to increase the size to a minimum of 25 megabytes (MB) and to configure the logs to overwrite events as needed for all Event logs. The logs include the Windows NT Event logs (application, security, and system) and other Event logs (such as the Directory Service, File Replication, DNS, and Operations Manager logs).

Other Configuration Techniques

A couple other techniques are available for changing the settings for the Event logs:

• Using the ConfigureEventLogs utility

• Using a Group Policy Object (GPO)

The ConfigureEventLogs utility from the MOM 2000 Resource Kit enables you to automate the process of setting the Event log configurations based on an input file listing the server names. Microsoft does not support this tool, which is available only as part of the MOM 2000 Resource Kit, and is no longer available on the Microsoft website.

Tip: On the CD

As a convenience, we include the package to install the ConfigureEventLogs utility (configurelogs.exe) on the CD accompanying this book.

If you have integrated the majority of your systems with Active Directory, a more effective approach to changing these configurations might be by creating a GPO that maintains these settings. The recommended approach is to move all servers (do not move the domain controllers) into an Organizational Unit (OU) and apply the GPO to that OU. See Figure 9.18 for an example.

Figure 9.18. Sample GPO to maintain log sizes for the application, security, and system event logs.

Using a Group Policy Object can save you work by automating the configuration of the application, security, and system log settings for all servers in that OU. You can apply a similar GPO to the Domain Controllers OU to change domain controller settings. Note that these GPO examples configure only the application, security, and system logs settings. You must manually modify any additional logs.

To gather disk performance information, ensure that each system with an installed OpsMgr agent has its disk performance counters activated. Activate the performance counters as necessary by using the command diskperf -YV; this takes effect after a reboot. In Windows 2000, the physical disk counters are on by default, but the logical disk counters are off by default. For Windows Server 2003, both the physical and logical counters are permanently enabled.

By default, the global setting for Operations Manager 2007 does not accept manual agent installations. You can change this configuration by performing the following steps:

You can also configure this on a per–management server basis. Perform the following steps:

With both of these configurations, a check box is available when you select the Review new manual agent installations in pending management view setting. This check box is labeled Auto-approve new manually installed agents. If this is not checked, manually installed agents are placed into a pending actions folder for approval.

You can navigate to the Pending Management folder at Administration -> Device Management -> Pending Management. Agents that fail installation are also added to this folder, where you can re-run the agent installation process. Figure 9.19 shows an example where agents have failed installation.

Figure 9.19. The pending management folder with failed installs.

Configure agent settings in the Operations console, under Administration -> Device Management -> Agent Managed. Right-click an agent and choose Properties. The Heartbeat tab provides a method to override the global settings for the agent’s heartbeat frequency (which is 60 seconds by default).

The Security tab has a check box labeled Allow this agent to act as a proxy and discover managed objects on other computers. This is an important setting if your environment will use either the Exchange management pack or the Active Directory management pack. You will need to enable this option for all domain controllers in your environment if you are using the Active Directory management pack. You will also need to check the Agent Proxy option for all Exchange servers in your environment if you are using the Exchange management pack.

You define agent failover using the Agent Assignment and Failover Wizard (Administration -> Device Management -> Management Servers). Select a management server and right-click Properties. At the Auto Agent Assignment tab, click Add to specify agent assignment settings. The Agent Assignment and Failover Wizard provides a way to define inclusion and exclusion criteria for the management servers in the management group. Figure 9.20 shows an example of how to configure failover as either automatic or manual.

Figure 9.20. Agent Assignment and Failover Wizard.

$comp = get-agent | where { $_.ComputerName -eq "<Computer Name>"}
$comp.PrimaryManagementServerName |Format-List name

$comp = get-agent | where { $_.ComputerName -eq"<fully qualified agent name>"}
$comp.GetFailoverManagementServers() |Format-List name

$comp = get-agent | where { $_.ComputerName -eq Ascension}
$comp.PrimaryManagementServerName |Format-List name
$comp.GetFailoverManagementServers() |Format-List name

$primaryMS = get-managementserver | where{$_.ComputerName -eq "RootManagementServer"}
$secondaryMS = get-managementserver | where{$_.ComputerName -eq "SecondaryManagementServer"}
$agent = get-agent | where {$_.ComputerName -eq "membersvr"}
set-managementserver -managementserver $primaryMS -agentManagedComputer
$agent -failoverServer $secondaryMS

An Operations Manager agent uses a queue file to store data that needs to be sent to the management server. These queue files prevent the loss of data when a management server is not available (such as when it is rebooted to apply patches and other maintenance). If multiple management servers are configured for failover, the agent fails over to another management server.

The agent queue file is used as part of the normal communication between an agent and a management server, but it only becomes important from a sizing perspective if the agent is unable to communicate with any available management servers.

These queue files default to 15MB in size (15360KB). For most systems, this queue file size should be sufficient to hold the OpsMgr data for several hours. There may be times, however, when the size of this queue may be insufficient, such as for servers that send a large amount of data to the management server (very intensive applications such as Active Directory or Exchange), or if there will be longer periods of time when the management server will be unavailable. The size of this queue is changed on a per-agent basis from the Registry within HKLMSYSTEMCurrentControlSetServicesHealthServiceParametersManagement Groups<Management Group Name>MaximumQueueSizeKb.

HKEY_CURRENT_USER = &H80000001
strComputer = "."
Set objReg = GetObject("winmgmts:\" & strComputer &
"
ootdefault:StdRegProv")
strKeyPath =
"SYSTEMCurrentControlSetServicesHealthServiceParametersManagement
Groups<Management Group Name>"
ValueName = "MaximumQueueSizeKb"
dwValue = 51200
objReg.SetDWORDValue HKEY_CURRENT_USER, strKeyPath, ValueName, dwValue
Set objShell = CreateObject("WScript.Shell")
objShell.Run "%COMSPEC% /c net stop healthservice",,1
objShell.Run "%COMSPEC% /c net start healthservice",,1

The recommended method to remove agents involves using the Operations console. Perform the following steps:

You can also manually uninstall the agent on the system and then delete the agent from the Operations console.

Systems monitored by Operations Manager that have their name changed will need to have their agent removed and reinstalled. If the renamed system does not have its agent uninstalled and reinstalled, the original system name will still appear in the console, but it no longer reports information back correctly to OpsMgr.