One of the common challenges when deploying OMS agents is the fact that agents need to connect to the OMS cloud. Even when connected through OpsMgr many data flows require a direct connection from the agent to the public cloud.
Fortune wants all the communication is https (we still have a noticeable exception for the hybrid worker role that I hope will soon be fixed), so the connection is http proxyb friendly and indeed the agent can be configured to use a proxy with optional authentication. So there are many options to let the agents communicate and if you don’t want to use the corporate web proxy nor want to let the agents directly through the firewall a simple (virtual) appliance can be used for the duty. A while ago I wrote about using Squid to control your OMS data flow.
Now we have a new option, the Microsoft supported OMS Gateway Server. Due to a strong demand from customers the OMS team, developed a simple OMS targeted gateway appliance that basically tasks care of everything you need to make the data flow to the cloud:
- it embeds the rules to the OMS endpoints
- it automatically (or manually) authorizes the OMS managed devices and only them to navigate through the gateway
- it funnels the traffic just to the proper workspace
- it is instrumented to log proper diagnostics (that obviously can be collected with Log Analytics)
- it is instrumented with appropriate performance counters to track the gateway behavior (these can again be collected with Log Analytics)
- it can even chain to an existing proxy if you don’t want the device to go directly to the cloud
So with this nice additions we now have the following option to regulate OMS agents traffic:
- direct NAT
- corporate https proxy (authenticated if needed)
- ad hoc appliance based on open source technologies (example Squid)
- OMS team supported Gateway server
All the above solutions can be set in an highly available configuration, if they don’t have something native, and for example the OMS Gateway don’t, a bunch of devices can be set in DNS round robin fashion, the agent is built to be resilient to connectivity issues and it can automatically move to another device without loosing data.
Also the gateway has been reviewed by my good friend @MrTaoYang on his blog.
Gateway server test drive
I tested the gateway on both Windows Server 2016 TP4 and Windows Server 2016 TP4 core edition. I wanted to try on the new platform even if the Gateway is obviously supported on Windows Server 2008 R2, Windows Server 2012 and 2012 R2. The gateway relays on .net framework 4.5 and thus won’t work on nano server. In my opinion it’s really important it can work con the core edition of the OS, this is a light weighted utility service you want to probably keep on dedicated systems treated as appliances, and core is the answer (waiting for nano support).
The installation is straightforward, it’s a windows installer based setup, with only three important choices:
1) the port used for the proxy service, by default 8080. The setup takes care of adding a windows firewall rule to allow the traffic.
2) the installation path
3) the configuration of a chained proxy, if needed
At the end of the setup you have a windows service under the name “Microsoft OMS Log Analytics Forwarder” and a directory with just a bunch of files, but some of them are really important. I really think the service name is short sighted, this service must become the OMS gateway not just the Log analytics gateway.
The entire service configuration is regulated by three files:
- allowedlist_clientcert.txt – used to specify the fqdn of the devices that can use the gateway
- allowedlist_servercert.txt – used to specify the workspace IDs the gateway can send the data to
- Microsoft.HttpForwarder.WindowsService.exe.config – use to configure the gateway post setup. Here the listening port, the chained proxy and the security mode can be configured
While the proxy configuration needs no comment, the security model is something specific worth a couple of words. It must be said that in a common deployment you want to install the OMS agent on the gateway, if you do so the deploytment is secure by default: only the devices enolled in the workspace are authorized to communicate with the gateway and the gateway will send data just to its own workspace. I really believe that in the future the team will give us a way to track gateways in the OMS console, so again having the OMS agent on board will be the common choice. But if you don’t want to use the builtin defualt security, then there’s a way to manually configure it:
- the list of the fqdn of the authorized servers must be specified in allowedlist_clientcert.txt
- the destination workspace ids must be specified in allowedlist_servercert.txt
- the default behavior must be turned off in the config file (this way even if you install the OMS agent on the gateway you maintain full control). Just change the following tag to “False”
<add key="IncorporateOMSSolution" value="False" />
Configuring the agents to use the gateway is just a matter of setting the agent proxy (without authentication). For Linug agent you must follow the instructions on GitHub
Also in this preview release to support Linux agents you need to manually add this endpoint [*.azure-automation.net] to the allowedlist_server.txt. If it doesn’t work just add the fqdn name of the oms endpoint scus-agentservice-prod-1.azure-automation.net.
Finally, waiting for a builtin solution you can use Log Analytics yiou can collect key gateway data, both events and performance counters can be added to the data collection in the workspace
Daniele
This posting is provided “AS IS” with no warranties, and confers no rights
Quae Nocent Docent 