Overview:
In Operations Manager, the Gateway server role is primary used for monitoring servers outside the Root Management Servers trusted Domain boundary. Another popular use of the Gateway role is for performance improvements by placing gateways in sites with poor network connectivity. Sometimes it is necessary to “chain” multiple gateways together to get monitor across multiple untrusted boundaries.
For Example, say you have a scenario that looks like the following:
Here we have a management group installed in the “My Company” network. The Admin has the requirement to monitoring the machines in the “DMZ” network. There is no direct connection between the “My Company” network and the “DMZ” network without first going through the “ExtraNet” network.
How to setup chained Gateways?
To minimize the chance of configuring things wrong, install 1 gateway at a time starting with the one reporting directly to an existing MS or the RMS, and moving “out.” Verify newly installed gateways are properly communicating, downloading MPs, etc before attempting to install the next one in the chain.
The actual install steps are identical for any gateway, whether reporting to an MS/RMS or chained to another gateway.
1. On the RMS, run the GatewayApprovalTool
a. /ManagementServerName:<FQDN of existing server (RMS, MS, or gateway) which the new gateway will report to>
b. /GatewayName:<FQDN of the new gateway>
2. Install the gateway bits on the new machine
3. If needed, configure certificates to establish trust between the new gateway and the server it reports to
Here is the tricky part:
Configuring certificates between two gateways is no different than configuring certificates between an agent and a gateway, or a gateway and a MS or RMS. The same certificate settings are required, the same tools are used to request, install, and import the certs. A healthservice can only load and use a single auth certificate, so in the chained scenario the same certificate will be used by the gateway to authenticate to its parent and to any children. The parent and child(ren) must both trust the Certificate Authority which issued the gateway’s cert.
Supported Configurations:
Simple:
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and trusts CA1. GW2 loads a cert issued from CA1 and trusts CA1.
Complex:
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and trusts CA1 and CA2. GW2 loads a cert issued from CA2 and trusts CA1.
Unsupported Configuration:
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and CA2 and trusts CA1 and CA2. GW2 loads a cert issued from CA2 and trusts CA2. This is not possible because GW1 cannot load more than one certificate in it’s health service communication channel.
FAQs:
Q1.
In the supported complex configuration, doesn’t GW2 also need to trust CA2?
A1.
No, since GW1 presents a cert from CA1, and this is the only cert GW2 needs to trust. GW2 never needs to verify the trust of a CA2 certificate (HealthService only check settings of the cert it loads, not that it comes from a trusted CA) so it doesn’t NEED to have that CA trust cert. A machine only needs to trust the incoming certificate from parent or child, it does not need to trust the one it has loaded.
Hope this helps! I will update FAQs as I get more questions.
Technical content was provided and tested by Lincoln Atkinson . Thanks Lincoln!!
Rob Kuehfus | System Center Operations Manager | Setup and Deployment Program Manager
This is supplied "as -is" with no support. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions.