One of the areas of technology that I find most interesting is when two different technologies combine to provide a better solution than either could alone. I see this occur regularly with Azure and System center and recently I started to see a combination of Azure and Operations Manager which had some significant benefits. The blog post is the first in a set of blog posts which will introduce the concepts, architecture, installation, configuration and functionality available when using Azure IaaS servers to provide Internet based server monitoring.


Background in Monitoring with Operations Manager

For background on why an Azure Monitoring Gateway is relevant, I will start by introducing five topics: Mutual authentication, monitoring outside of the forest, monitoring as a service provider, monitoring in a Hybrid world and Born-in-the-Cloud.

Mutual authentication: In Operations Manager, a server you want to monitor needs to be trusted and needs to trust the server that it is going to communicate with. Within a forest, this is done automatically by Kerberos for Windows servers so we get to ignore it most of the time. For servers outside of the forest we can use certificates to verify the server is who it says it is. Each step of the chain from the server which is monitored, through any gateways, to a management server needs to have this level of trust preserved. Back in the old-school MOM 2005 days we would disable mutual authentication but that’s not an option in Operations Manager 2007 and higher (nor would it be a good idea from a security perspective I expect).

Monitoring outside of the forest: For most environments, the only place where mutual authentication is challenging with servers in a non-trusted forest or servers in a workgroup. These often become one-off solutions where either a gateway server is installed within the forest or a certificate is installed on the individual servers which need to be monitored by Operations Manager.

Monitoring as a Service Provider: Service providers need to provide monitoring for multiple different organizations. I won’t delve into this concept in depth, but most commonly this is approached by placing a gateway in the forest of each of the organizations (potentially two for redundancy). This approach works well for situations where a gateway can be installed in the client forest, but if this isn’t an allowed configuring life gets more challenging.

Monitoring in a Hybrid world: Many organizations are moving to a model where some of their servers are in Azure and some are in an on-premise data center. Monitoring in Operations Manager can be designed so that the Azure servers report to an on-premise or Azure based Operations Manager environment.

Born-in-the-Cloud: With the flurry of activity around the cloud and how it impacts technical architecture there is an increased focus on new businesses designing their entire architecture to exist completely in the cloud. Monitoring is still required for these types of organizations, but it may or may not be viable to put a gateway in each new forest. In case of an company in the cloud with multiple separate forests, the overhead required to add a gateway server in Azure specifically to route monitoring traffic may not be cost effective.


The Azure Monitoring Gateway (AMGW)

The concept behind an Azure Monitoring Gateway is simple – install two Operations Manager 2012 R2 servers in IaaS in Azure in two different datacenter as Operations Manager gateways. These servers are configured with certificates, and they are configured to communicate with either a management server on-premise or in the case of a born-in-the-cloud configuration they report to a management server in the cloud.  Servers which you want to monitor have the Operations Manager agent installed with an appropriate certificate and they are configured to communicate with the AMGW’s and we’re good to go!

There are several benefits to this approach to providing monitoring:

  • AMGW’s provide a solution for monitoring systems which are outside of the forest regardless of what domain/forest they are a member of.
  • AMGW’s can benefit from Operations Manager’s ability to have a primary and secondary management server (gateway) that they report to so this becomes a highly available monitoring solution.
  • For Service Providers AMGW’s provide a way to decrease the hardware required by providing a single set of gateway servers that multiple clients can use for monitoring.
  • For organizations which are in a Hybrid world, the AMGW provides a consistent path to route monitoring information from the Azure cloud to an on-premise Operations Manager environment or from on-premise servers to an Azure based Operations Manager environment.
  • For organizations Born-in-the-Cloud, the AMGW approach provides a method to monitor many different domains and forest without trust relationships or the requirement to deploy one or two gateway servers per domain.


The benefit to a properly implemented AMGW became apparent during a client design session for a service provider and was backed up by discussions with a managed services organization and a client who is looking to be Born-in-the-Cloud. This has been a pet project of mine for a while now so I am looking forward to expounding on this concept in further detail in a series of blog posts. The next blog posts in the series include:


Additional Reference:

For thoughts around monitoring from a service provider perspective, see the System Center 2012 Operations Manager Unleashed book in Chapter 24. John Joyner wrote some great stuff in that chapter!

Kicking the tires on Windows Azure:

Monitoring and Windows Azure:

John Savill on Monitoring and Windows Azure: