Virtual Microsoft

Using Microsoft Operations Management Suite, Part 1

In the first installment of a new column, Paul Schnackenburg walks through the steps for setting up Microsoft's new management tool.

• By Paul Schnackenburg
• 03/15/2016

Once upon a time, there was a cloud service from Microsoft known as System Center Advisor, that no one had heard of. It collated information about common problems and misconfigurations in SQL Server, Exchange, Active Directory (AD) and the like (a bit like the Best Practices Analyzer tools). After some time, it integrated into the System Center Operations Management (SCOM) console, but it was still a fairly unknown service. When its name was changed to Azure Operational Insights, it received a little more attention; but it wasn't until it morphed into Operations Management Suite (OMS) last year that it really started to gain a following.

The name changes aren't totally random. Advisor did indeed only advise as to mistakes in setup or bugs that manifested in certain situations, Operational Insights added log analysis and provided real insight into your log files. OMS gives you more than insight; it lets you act on that insight. It's also gone beyond handling only Azure, and can now be used for on-premises infrastructure, Azure resources and resources in any other cloud.

Judging by the buzz I hear from fellow IT pros and the usefulness of the service in the real world, I think OMS has earned its place on the tool belt of most systems administrator and businesses. The screenshots and recommendations in this article come from live production systems for one of my clients. They're a typical SMB client with two Hyper-V hosts and three VMs (AD, file and Exchange).

Log Analysis For Dummies
OMS is a cloud service that's easy to set up and get going with. It ingests machine data such as Windows event logs, Linux syslogs, network traces and performance counter logs. The data is then crunched by "Solutions" (formerly known as Intelligence Packs) and actionable insights are presented in an easy-to-use way.

I suggest that you follow along with these instructions and set up a trial account for yourself. Getting started is easy: click the "Create a free account" link at www.microsoft.com/OMS. This free edition gives you 500MB of log uploads per day, with seven-day retention, 500 minutes of free Azure automation per month and the first month free backup of your VMs. That's not a time-limited trial; if you fit into those limits, it continues forever. In the case of my SMB client, they generate a lot less than 500MB of logs per day; and while it would be nice to go further back than seven days, it's still amazingly useful for the cost of free. Pricing information can be found here.

Log in using a Microsoft or Azure account, input some basic details about your new workspace (as shown in Figure 1), and optionally link the workspace to an Azure subscription and directory. That's all there is to it.

A workspace is a data retention boundary; you can have multiple workspaces for different departments, for instance, but be aware that the data won't be correlated between workspaces (see Figure 2). Linking a workspace to an Azure subscription has two benefits: If you have classic-based VMs (i.e., not Azure Resource Manager), they can easily be configured to send their log data to OMS, and new VMs will automatically do this (I've heard that support for ARM based VMs is coming shortly.) Second, OMS can also analyze logs stored by Azure Diagnostics, and generated by Web and worker roles in PaaS as well as Windows and Linux VMs in IaaS.

Connecting Data Sources
Once your workspace is up and running, your first stop should be the Settings tile (Figure 3). It's the bright blue one. This is where you connect your data sources. There are three ways of doing this.

1. If you've already deployed SCOM 2012 SP1 UR6 or later, or SCOM 2012 R2 UR2 or later, use the Operational Insights (the old name) node in the SCOM console to enable OMS. This means you don't have to deploy agents to your servers or desktops; the SCOM agent will gather the data for both SCOM and OMS. Note that you can pick computers or groups of computers where log data will be uploaded to OMS, so you can enable this in stages. The reverse is also possible (a quite recent addition to OMS); you can have alerts generated by OMS surface in the SCOM console.
2. If you don't have SCOM in your environment, you can use the Microsoft Monitoring Agent (MMA), which comes in 32- or 64-bit flavors for Windows, as well as a Linux version. The Windows version is an MSI file, so you can use any automated software distribution method to deploy it; the agent will send log data directly to OMS. There's no need to open incoming ports in any firewall for OMS; communications are always initiated from the client, but if you filter outgoing traffic at your edge firewall, see here for the list of required addresses and ports. There's also an option to configure a proxy server in the agent setup, which can be different from the system-defined proxy.
3. The third way to ingest logs into OMS is from an Azure storage account. As mentioned, support for AWS storage accounts are coming shortly.

Take OMS With You
There's a free app for Android, iOS and Windows phone. The app lets you see any custom dashboards you've created, along with the built-in ones. You can also access previous searches and change the time range for a particular search. The OMS portal is HTML 5, so it works great in all browsers and on the tablets I tested.

If you've been following along, you should now have your trial workspace up and running, and you've installed the MMA on at least one server (or desktop; OMS is great for monitoring point of sale systems, for instance). Next time I'll cover how to use different solutions to gain insight into your log data; Azure Backup and Azure Site Recovery; as well as Azure Automation (all are part of OMS). We'll also look at the search syntax to customize OMS so you can find exactly what you want, along with some resources to learn more about OMS.