In the first part of this blog post series I introduced the concept behind the Azure Monitoring Gateway (AMGW). In the second part of this blog post series I discussed the architecture and the pricing for AMGW's in a variety of configurations.
This blog post will focus on installation and configuration of the AMGW servers focusing on certificates, networking and name resolution requirements.
AMGW Installation & Configuration
Gateway servers installed in Azure follow the same processes as an on premise Gateway server for most steps so the focus of this blog post will be on what is different when installing an AMGW. For details on installation of a Gateway server see the System Center 2012 Operations Manager Unleashed book
or Microsoft's TechNet documentation on this topic.
For an AMGW the differences are related to installing in a workgroup, enabling an inbound port on the AMGW, configuring certificates, and name resolution for the management servers.
The following are the high level steps required for Gateway installation in this configuration:
- Download the Operations Manager installation media and extract the files
- Add the root certificate
- Create a certificate request (unique to the Gateway)
- Approve the certificate request
- Install the certificate, and use MOMCertImport on the AMGW
- Install the Operations Manager Gateway
Workgroup vs. Domain:
In most cases an AMGW will not have other agents which will communicate with it from the same domain/forest as its function is to provide monitoring for agents which exist in a variety of domains and forests. As a result, a certificate will be required on the AMGW's or the domain which includes the management servers will need to be extended into Azure. For this blog series example, it's assumed that each AMGW will be in a workgroup to minimize the footprint in Azure to only the two AMGW servers (versus adding a domain controller into Azure and configuring networking between Azure and an on premise environment). AMGW's can be installed on any supported configuration which is available as an option in Azure. For my example I installed the AMGW's on Windows Server 2012 but I could just have easily installed these on Windows Server 2012 R2.
Enabling an endpoint:
To allow inbound traffic to the AMGW servers on TCP port 5723 we need to configure an endpoint. This is done in the Azure Portal by opening Virtual Machines, opening the specific virtual machine and endpoints (shown below).
By default there are two endpoints defined (one for PowerShell and one for Remote Desktop), and the third was added for Operations Manager and is shown below as "OpsMgr".
To create an Endpoint you click Add (on the bottom of the screen).
Add it as a standalone endpoint:
And specify the details for the port.
Once the endpoint has been defined for Operations Manager you can test inbound traffic to the AMGW by using telnet to the FQDN of the AMGW on port 5723 from a system outside of Azure.
For Gateway servers outside of the forest certificates are the cause of almost every issue that I have had with Operations Manager Gateways. At the lowest level, Operations Manager certificates need to be unique to the server that they are installed on, private keys must be exportable and have both the client authentication and server authentication configured.
Since these AMGW servers are in a workgroup, we need to do one change to make their naming match the FQDN. To do this, open System Properties, click on change, click more and check the box to change the primary dns suffix. Add "cloudapp.net" to the DNS suffix as shown below.
For this example, the FQDN of the AMGW is "gw1.cloudapp.net". Use the processes documented at http://www.viacode.com/blog/2012/08/25/how-to-create-a-certificate-for-scom/ or http://marthijnvanrheenen.wordpress.com/2012/03/28/scom-2012-connecting-a-gateway-server-using-certificates/ to create a certificate (this process is basically the same as it has been since Operations Manager 2007).
Are you looking for a quick way to find out if the certificate that you added is configured correct and being used by Operations Manager? Stop the Microsoft Monitoring Agent service (in Operations Manager 2012 R2) or the System Center Monitoring service (In Operations Manager 2012). Clear the Operations Manager event log and then restart the service. Filter the Operations Manager event log to look for event number 20053 (the event source = "OpsMgr Connector"). This informational alert indicates that the certificate was accepted and used by Operations Manager on the system.
The AMGW systems need to be able to communicate with the FQDN for the management servers that they will be reporting to. For each of the AMGW's, configure hosts file with the FQDN for both management servers (stored in C:\Windows\System32\Drivers\etc by default). If your management servers are part of your on premise environment you will need to open a firewall port to allow communication from port 5723 to these systems from the AMGW servers.
Redundancy and Windows Updates:
Operations Manager Agents and Gateways have a built-in failover functionality where the agent/gateway can report to a primary and a failover system. The process to configure a Gateway to report to multiple management servers is discussed at http://technet.microsoft.com/en-us/library/hh212904.aspx.
Azure IaaS does not provide high without an availability set as virtual systems do need to be patched and are often rebooted during the patch process. One option would be to create an availability set for the AMGW's. For this example however I chose to configure the AMGW's so that one is located in an East-US datacenter and another is located in a West-US datacenter so that when one is patching the other should not be patching.
Discussions on availability groups and IaaS are available at http://blogs.msdn.com/b/windows_azure_technical_support_wats_team/archive/2013/11/27/windows-azure-iaas-host-os-update-demystified.aspx and http://weblogs.asp.net/scottgu/archive/2013/04/16/windows-azure-general-availability-of-infrastructure-as-a-service-iaas.aspx.
Management Server Configuration
It's important to note that the management servers will need to have the Gateway servers approved through the normal gateway approval process. For the process to be able to work, the AMGW's need to be able to name resolve the FQDN of the management servers and need to be able to communicate on port 5723.
Are you looking for a quick way to validate that communication can occur from the AMGW to the management servers? The easiest way to test this is to create the hosts file entry for each management server (discussed above), install the telnet client feature and test a telnet to the FQDN of the management server on port 5723.
Blog post series links:
The additional blog posts in the series include:
Installing a gateway within the domain: http://blogs.catapultsystems.com/cfuller/archive/2012/02/08/installation-of-an-opsmgr-scom-2012-gateway-within-the-domainforest.aspx
How to deploy a gateway server:
Certificate errors and what they mean:
Operations Manager supported configurations:
Configuring Gateway Server failover: http://technet.microsoft.com/en-us/library/hh212904.aspx