Microsoft IT's OpsMgr 2007 Deployment: MS and GW

Microsoft IT's OpsMgr 2007 Deployment: MS and GW

  • Comments 2
  • Likes

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.


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 “” and “”.

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 (\SupportTools\Microsoft.EnterpriseManagement.GatewayApprovalTool.exe) from the OpsMgr 2007 installation media to the installation directory on the management server.

c.       Open a command prompt on the management server and change directories to the installation directory where the approval tool was just copied.

d.      Run the tool to create the entry in the OpsDB for the gateway server

D:\Program Files\System Center Operations Manager 2007>Microsoft.EnterpriseManagement.GatewayApprovalTool.exe / /

4.       Install the OpsMgr 2007 software onto the gateway server system

a.       Connect to the gateway server via terminal services.

b.      Run MOMGateway.msi from the platform appropriate directory off of the installation media (\SelectCDImage\gateway\<Platform>\).

c.       Provide the relevant details in the installation wizard, being sure to give the FQDN for any server names.

5.       Run the MOMCertImport.exe to associate the certificates with the Health Service

a.       Connect to the server via terminal services.

                                                               i.      Export the certificate to a DER encoded CER file via the following steps:

1.       Open a blank MMC console

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

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

4.        Right click on the cert that was issued for this server and select “All Tasks” -> “Export”

5.       Click “Next>”

6.       Select “No, do not export the private key” and click “Next>”

7.       Select “DER encoded binary X.509 (.CER)” and click “Next>”

8.       Select a location to save the file to and click “Next>”.

9.       Confirm the details and click “Finish>”

                                                             ii.      Run MOMCertImport.exe from the platform appropriate directory off of the installation media (\SelectCDImage\SupportTools\<Platform>\).

MOMCertImport.exe c:\temp\GW1Cert_X.509.cer

b.      If no output is provided then the command succeeded.

c.       Bounce the HealthService.

d.      You can confirm that the certificate was correctly imported by checking the following two things:

                                                               i.       An “OpsMgr Connect” 20053 event should be generated after the health service is started indicating the certificate was loaded successfully.

Event Type:     Information
Event Source:   OpsMgr Connector
Event Category: None
Event ID:  20053
User:      N/A
Computer:  GW1
The OpsMgr Connector has loaded the specified authentication certificate successfully.

Using PowerShell for Gateway Failover

Just like an agent can failover between multiple management servers, gateway servers can be configured to failover as well.  Assuming the necessary steps have been taken to setup communication channels and certificate based authentication between a given GW and all relevant management servers, the following PowerShell commands can be used to setup these failover relationships.

#Get a variable loaded with the object for my GW
$GW = Get-ManagementServer | where {$_.DisplayName -eq "<GW FQDN>"}

#Do the same thing for the management servers you will use as primary and failover
$MS01 = Get-ManagementServer | where {$_.DisplayName -eq "<MS1 FQDN>"}
$MS02 = Get-ManagementServer | where {$_.DisplayName -eq "<MS2 FQDN>"}

#Run the set command for partners
#Set-ManagementServer -ManagementServer $MS01 -FailoverServer $MS02 -GatewayManagementServer $GW

Likewise the following commands can be used to view the failover configuration for all gateway servers in a given management group:

# Get all gateway management servers so we can see what is setup
$GWs = Get-ManagementServer | where {$_.IsGateway -eq $true}

$GWs | sort | foreach {
       Write-Host "";
       "Gateway MS    :: " + $_.Name;
       "--Primary MS  :: " + ($_.GetPrimaryManagementServer()).ComputerName;
       $failoverServers = $_.getFailoverManagementServers();
       foreach ($managementServer in $failoverServers) {
              "--Failover MS :: " + ($managementServer.ComputerName);
Write-Host "";

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment