Microsoft IT’s OpsMgr 2007 Deployment: MS and GW

Management Servers

The management server (MS) role has not changed significantly from previous versions of Operations Manager (OpsMgr). An MS is still responsible for receiving data from agents, and forwarding that data along to the relevant locations.  For more information on the management server role, refer to the OpsMgr 2007 deployment and design guides.   There are a few relevant points that are worth making, which might not be readily apparent from the documentation:

1.       Management servers write their data directly to the OpsDB, as well as directly to the data warehouse if it has been installed in the management group.  They do this via direct SQL connections (1433/tcp by default) for both DBs.

2.       Management servers communicate with the root management server over the standard agent communication channel (5723/tcp by default).

3.       It used to be that in some larger MOM 2005 infrastructures multiple management servers were deployed due to the need to use diverse action accounts.  With OpsMgr 2007 the association with action accounts is no longer strictly at a server level, and therefore the number of management servers deployed can be based strictly on scale, and redundancy requirements.

Gateways

The gateway server role is something that is completely new with OpsMgr 2007.  In effect a gateway server acts as a proxy for agent communication between a group of agents and one or more management servers which do not have a full trust between them.  Again I’ll defer to the OpsMgr 2007 deployment and design guides for the details of this role, but simply stated gateway serves should be used to bridge a gap where a two way trust doesn’t exist between a group of agents and one or more management servers.  A few additional points to make on the gateway server role:

·         Gateway servers communicate with management servers over the standard agent communication channel (5723/tcp) by default.

·         It is sometimes helpful to think of gateway servers as being an agent in the eyes of the management server(s) it communicates with while at the same time appearing to be a management server in the eyes of the agent(s) that communicate with it.

·         Since gateway servers are most commonly used where there is an absence of a full Active Directory trust, this role is usually deployed using certificate based authentication.  More to come on this point in the “deployment considerations” section below.

The Platform

For the gateway servers and the management servers Microsoft IT uses a trimmed down version of the same basic platform as the OpsDB and RMS systems.

·         Server Model: A mix of HP ProLiant DL385 G1 and ProLiant DL380 G5

·         Processors: 1 x dual core (shown as 2 processors by the OS).  The brand and speed of the processors vary, but are at least 2.2 Ghz and are 64bit capable.

·         RAM: 2GB for a stand-alone MS or GW.  More RAM may be installed if the server is hosting another role (i.e. ACS collector).

·         Drives: The Operations Manager bits are installed on a separate 18GB logical drive from the OS installation.

·         OS: Windows Server 2003 Enterprise x64 Edition with SP1

Generally speaking Microsoft IT has found that for both of these roles they could’ve used lesser hardware.  The average CPU utilization on a management server is around 19% and a little over 5% for a gateway server.  Likewise memory use has been very low at less than 0.3 pages/sec on average, for both roles.  behavior at the disk level is the reverse that of CPU utilization in that management servers are about a quarter as active as gateway servers are.  The OpsMgr installation drive on an average MS is doing 34 transfers/sec with an average size of .21 MB/sec.  The gateway servers on the other hand perform an average of 211 transfers/sec and .56 MB/sec.

Deployment Considerations for These Roles

As the management server and gateways server roles are both fairly straight forward, there are not a tremendous number of considerations to be made when it comes to their deployment.  With that said, following are a couple significant points that the Microsoft IT team focused on when deciding on their deployment for the MS and GW roles.

·         Deploy for redundancy:  Every agent must have at least two “management servers” that it can report to (management server is in quotes because it could be an MS or a GW – as was previously mentioned the agent thinks of it as a management server regardless).  Likewise every gateway server needs to be capable of failing over between at least two management servers.  Steps on how to configure gateway failover are mentioned below.

·         Run dedicated: In each management group there should be management servers, and where necessary gateway servers, that are dedicated to the bulk of the agent management.  If the management group will contain management servers that will perform other roles (most notably an MS which is also acting as an ACS collector) those servers should not be the primary server for agents to report to.

Gateway Setup “Footnotes”

Given that the role is relatively new, and can be somewhat complicated as it’s typically paired with certificate based authentication, the rest of this post is a few dumps from Microsoft IT’s experiences of deploying gateways.

Gateway Deployment Process

1.       Generate the certificate request for the management server and the gateway server
The process here differs depending on the type of CA you are working with and the tools used to request the certificates but the following points were relevant for the way IT gets issued certificates internally. 

a.       The request file must be generated on the system that the certificate will ultimately be installed on.

b.      The “name” and “Certificate Friendly Name” of the certificate must be the FQDN of the system that the cert will be installed on.

c.       The certificate must include the usage OID’s of “1.3.6.1.5.5.7.3.1” and “1.3.6.1.5.5.7.3.2”.

d.      The “Key Generation Options” must include the “Mark keys as exportable” and “User local machine store” flags.

e.      The request file that is generated is then used to request a certificate from the CA services, and the resulting certificate is saved as a CER file with a “Base 64” encoding method.

2.       Install the certificates on the management server and the gateway server
The same tool used to generate the certificate request file is used to install the certificate and the following steps can be used to confirm the certificate is correctly installed:

a.       Open a blank MMC console

b.      Load the “Certificate” snap-in managing the “Computer account” on the “Local Computer”.

c.       Once the MMC snap-in comes up navigate to “Certificates” -> “Personal” -> “Certificates”

d.      In the details pane there should be a certificate listed that is issued to the FQDN of the server being setup.  Likewise the “Intended Purposes” column should contain “Client Authentication, Server Authentication”.

e.      Open the properties of that certificate and confirm there are no warnings.  If there is a warning indicating “Windows does not have enough information to verify the certificate” then the certificate chain needs to be setup as well.

3.       Run the gateway approval tool to setup the gateway server in the MG’s OpsDB

a.       Connect to the management server via terminal services.

b.      Copy the approval tool (SupportToolsMicrosoft.EnterpriseManagement.GatewayApprovalTool.exe) from the OpsMgr 2007 installation media to the installation directory on the management server.