Section 3.4. Deploying and Managing Agents Across a Firewall and a Slow WAN Link


3.4. Deploying and Managing Agents Across a Firewall and a Slow WAN Link

The major considerations for deploying and managing servers in this type of environment are the presence of a firewall between the target computers and the management servers, and the limited bandwidth. Of the two, the limited bandwidth is more likely to cause problems. If the environment outside the firewall is not in the same AD domain, then there are additional considerations. All of the servers at the Leaky Faucet remote sites are members of the LKF domain, so they don't have to change the underlying security structure. Figure 3-25 shows the area of interest in the Leaky Faucet network.

For operational data, heartbeats, and management pack update communication, MOM agents communicate with their management server over TCP port 1270. It is easy to keep this port is open, so the presence of the firewall poses no problem. Agent-to-management-server communication resists being passed across a proxying firewall. If you try to, the management server will not recognize the agent, because the network traffic is coming from the proxying firewall, not the server on which the agent is installed. The workaround is to turn off proxying for port 1270 on the intervening firewall and pass the port 1270 traffic straight through using stateful inspection. However, agent installation is a different matter. For a management server to install an agent remotely and update the agent configuration, a variety of protocols and ports are used; for example, TCP 135 (RPC End Point Mapper) and the RPC port range must be open, as well as UDP 445, DCOM, and SMB. Because these ports are usually closed on a firewall, you cannot remotely install agents from the management servers. You must manually install and update the agents on the target machines.

Figure 3-25. In this environment the target computers are separated from the management servers by slow WAN links and a firewall


The volume of traffic over port 1270 can be estimated with the MOM 2005 Sizer.xls tool. This tool is available at http://www.microsoft.com/downloads/details.aspx?FamilyId=93930640-FA0F-48B3-8EB0-86836A1808DF&displaylang=en. You can also use this tool for estimating operations database sizes, but you may get mixed results. It is a very straightforward tool, consisting of a single-page spreadsheet on which the computer counts or other appropriate information is entered in the yellow highlighted cells. Leaky Faucet's servers are split about evenly between the 12 remote sites and headquarters. The amount of traffic that can be expected cumulatively from the 24 remote site servers is only about 3,000 bps or 2.5 percent of a 128-Kbps line (Figure 3-26).

Figure 3-26. Estimation of the network traffic for 24 servers


This number is a rough estimate, since the tool performs its calculations based on a network connection without intervening port restrictions, so it is including configuration update data as well. Even so, the number is useful because is gives an order-of-magnitude estimate for the traffic that can be expected. In Leaky Faucet's case, there are only one or two servers at the end of each 128-Kbps line, so the actual volume of traffic will be less than the estimate.

Certain steps can be taken to accommodate successful operations across the slow link. You can reduce the amount of data that is sent, increase the communications interval so that data transmission occurs less frequently, and increase the buffer size on the agents to hold the extra data between those communication sessions. See the "Accommodating Low Bandwidth" section later in this chapter.

3.4.1. Manual Agent Deployment

Before you manually install the agent, you have to identify the primary management server for the agents, then change the "Reject new manual agent installations" setting. Remember that once you override this at the management-server level, you must right-click the Management Packs node, select Commit Configuration Change, and restart the MOM service on each management server in the management group. For this example, homemomserver is the designated management server.

To start the manual agent installation, log on to the target machine locally with administrative rights and either launch setup.exe from the root of the MOM 2005 install media and select the Manual Agent Install tab, or locate the momagent.msi file in the i386 directory and launch that. Clicking through the Welcome panel brings you to the select install location page (Figure 3-27).

Accept the default location, as was planned for, and click Next. If you planned to install the agent to a different location, click on the Change button and enter the path to the desired directory. On the next page of the setup process, shown in Figure 3-28, you are prompted for all the necessary parameters required to install the agent.

Enter the appropriate information in the management Group Name, Management Server, and Management Server Port fields. I recommend that you accept the default

Figure 3-27. Manual agent install destination folder selection


Figure 3-28. Manual Agent Installation Configuration page


port (1270). If you decide to use another port, you will have to configure this on the management servers as well. This is addressed in Chapter 5, but briefly: navigate to the Administration node in the Administrator console Global Settings node Security object on the Communications tab and change the port setting there. You will have to make the change on the management server before a manually installed agent can communicate with it. To allow agent failover, you have to change the communication port on all of the management servers.

Unlike the remote agent installation from a management server process, during a manual install you can configure the failover server. To do this, click on the Advanced button and enter the desired management server name (Figure 3-29). If the agent is being multi-homed, this is where you can enter the management server name from a different management group.

Figure 3-29. Configuring the failover server for a manually installed agent


3.4.2. Agent Failover

In management groups with multiple management servers, you can configure which management servers agents will failover if communication is lost with an agent's primary management server. This is done in the properties of the management server, on the Failover tab . Here you can choose to allow or disallow the agents owned by this management server to failover to other management servers in the management group. The Failover tab also indicates how many agents are currently assigned to the other management server, as shown in Figure 3-30. If you don't want agents to failover to a specific management server, simply clear the checkbox. Remember that agent failover is configured automatically in multi-management server management groups; you do not need to take any additional steps to enable it, only to modify it.

Next, you must set the level of control that the management server will have on this agent. Agents that are fully controlled will have all updates, patches, and configuration changes pushed to them by the management server and can be uninstalled by the management server. Basically, with full control, all management functions can be performed remotely by the management server. Full control requires all remote procedure call (RPC) ports to be available, as well as a number of others. Typical firewall configurations do not permit RPC ports to be opened. Agents whose control level is set to None must have patches, upgrades, and configuration changes manually applied, and must also be uninstalled manually. In Leaky Faucet's case, because the firewall is blocking the ports used for these management tasks, the Agent Control Level is set to None, as shown in Figure 3-28.

Figure 3-30. Configuring agent Failover


Manual install prompts you for the agent action account and as before, you can choose to use the local system account or some other domain or local account. The next panel prompts you for the AD configuration (Figure 3-31). This is necessary so mutual authentication can be configured correctly on the agent. Leaky Faucet is running MOM 2005 in AD and mutual authentication is required between the agents and the management servers.

Figure 3-31. This setting tells the manually installed agent if it is in an AD domain or not


The installation wizard will next present you with the familiar Ready to Install summary page where you can review the configuration choices for accuracy and then start the installation.

After the installation is complete, MOM places the computer into the Pending Actions container in the Administrator console, with an "Approve manual agent installation" status in the Pending Actions column (see Figure 3-32).

Figure 3-32. Manually installed agents are placed into the Pending Actions container


To allow the management server to start managing this agent, right-click the computer and select to approve the install. The computer will then be placed into the Agent-managed Computers container and the process is complete.

If the agent does not appear in the Pending Actions container, after the manual agent installation process, you probably did not correctly configure the management server to accept new manually installed agents. Don't panicyou don't have to uninstall and reinstall the agent. Simply confirm your override settings on the management server, commit the configuration change in the Administrator console, and restart the MOMService on all management servers in the management group. The agent should then appear in the Pending Actions container. When you are done with manual agent installation, re-enable the Reject New Manually Installed Agents configuration.

3.4.3. Accommodating Low Bandwidth

One configuration step to minimize the bandwidth used by the agent/management server is to set the agent control level to None. By doing this, the traffic associated with automatic agent configuration updates (not processing rule updates) is eliminated. Other steps can include modifying the heartbeat interval and the request configuration interval on the Global Settings Agents Agent Heartbeat tab. This is practical only if you have a management group that is dedicated to agents across slow links. Otherwise, you are forcing all agents to behave as if they were across a slow link even if they are not. Even if you increase the request configuration interval, I dont recommend increasing the heartbeat interval. Heartbeat communications are very small, so you won't recover much bandwidth by reducing them but you will sacrifice a good deal of functionality.

On the Properties tab for individual agents (Agent-managed Computers) you can override the global settings and increase the Service Monitoring Status check interval so that it reports less frequently. When a service on the target computer changes state, say from started to stopped, it will take longer for the status change to be reflected in the State view in the Operator console. Also, in the agent properties, you can change the event, performance, and alert buffer settings so they report less frequently.

The most effective way to reduce agent-to-server operations traffic is to keep the applied management packs to a minimum. If it is possible, create separate versions of the required management packs for the low-bandwidth agents and only enable rules that are required. This is especially applicable to rules that collect performance- counter data. See the "Management Pack Tuning" section in Chapter 4.




Essential Microsoft Operations Manager
Essential Microsoft Operations Manager
ISBN: 0596009534
EAN: 2147483647
Year: N/A
Pages: 107
Authors: Chris Fox voc

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net