Category: OMS

Connect Batch of Azure VMs to Log Analytics (OMS) via PowerShell

So, you have a bunch of Virtual Machines (VMs) in Azure, and didn’t used an ARM template, and now need to connect the VMs to Log Analytics (OMS). Earlier this month, I demonstrated on this can be done with the ARM portal, here’s that blog post. Of course, this has to be done individually and can be very tedious if you have 10’s or 100’s of machines to do this to… All I can think of is PowerShell!

Here is a script I tweaked that Microsoft has already provided but for a single VM. I have just tweaked it to automate and traverse through your entire resource group, and add ALL VMs within the RG to Log Analytics.

Here is the link to Microsoft TechNet for that script. Please test it out and let me know. And if it helped you out, please give it a 5 start rating.

Microsoft TechNet PowerShell Gallery

If all went well, your before and after should look similar to this. I had two test VMs in my Resource Group.

Before:

After:

(more…)

Advertisements

Connect Azure VMs to Log Analytics (OMS) via ARM Portal

Let’s say you have a bunch of machines in Azure, and want them communicating with Azure Log Analytics (aka OMS). Well, I am pretty sure that last thing you want to do is deploy the Microsoft Monitoring Agent to each machine, manually…

Well, now you can connect a VM to Log Analytics (OMS) with just a few clicks.

Go into the ARM (Azure Resource Manager) portal, and navigate to your “Log Analytics” blade, select your OMS workspace name, and within the Workspace Data Sources, select Virtual Machines.

Here you should have your machines that currently live within Azure. As you can see, there is one machine that is not connected to the OMS workspace. Let’s connect it now.

Select the VM in question, and you will now be presented with the following:

Make sure the VM is online/running, and select Connect. The VM must be online in order for the extensions to be passed through.

Give it a few moments, and there we go! No manual agent deployment.

 

We can also verify now in OMS, to see our new machine chatting with Log Analytics. (Go into the Agent Health solution/title)

ADFS Monitoring with Azure, OMS, SCOM 2016

ADFS (Active Directory Federation Services) has really taken flight since the inception of Office 365 and Azure Active Directory. Getting your on-premises environment configured with online identity services such as Azure, and having the SSO (Single Sign-On) abilities makes ADFS fundamental. Implementing ADFS is one thing, but what about monitoring your ADFS environment?

The following post is intended to illustrate the differences between ADFS monitoring by comparing the following monitoring tools: Azure AD Connect Health, OMS (Operations Management Suite) and SCOM 2016 (System Center Operations Manager).

SCOM (Operations Manager) 2016

First step is to deploy SCOM agents to your ADFS environment/servers along with the ADFS Management Pack install. Once that is complete, and discovery has run, we should start seeing data within the ADFS view(s).

Within the ADFS view, we can see some useful information such as Token requests. This data is represented in an hour fashion, and we can see the number of tokens being requested per hour over the given date range.

And good view is the Password Failed attempts. We can see how many bad password attempts were made over the various date range, but information such as which user, and when, could be useful.

This information is all good, however without doing some custom management pack work, it is impossible to get any additional data, ie. which users are requesting the token, which users are inputting bad passwords, and which users are connecting to which site/service offered by ADFS.

OMS (Operations Management Suite)

OMS does a nice job with dashboards, but unlike SCOM, we need to not only know which Event IDs we need to capture, we also need to build our dashboards out. This is not ideal, as it does require some custom work, and some investigation with regards to ADFS related Event IDs.

The query below, “EventID=4648 OR EventID4624 | measure count() by TargetAccount” shows us which target account/active directory user has requested the most ADFS tokens over the last 1 hour. Please note, this query is based on the OMS Log Analytics language version 1.

Since OMS does require a lot of ADFS knowledge, ie Event IDs, I decided not to proceed any further and build additional queries and dashboards.

Azure AD Connect Health

Lastly, Azure AD Connect is probably the most simple, and least technical configuration.

As a prerequisite, I enabled the all event types on the ADFS logs.

After running the AD Connect agent on the ADFS server(s).  And launching the Azure Resource Manager portal, we get some dashboards. Right off the bat, we can see some excellent information. Let’s take a deeper look.

If we click on the total request widget, this shows us similar data as we see in SCOM 2016, with some exceptions. Not only can we see the number of tokens being requested. We also can see which ADFS server within the farm is distributing the tokens. Since this is a highly-available and load-balanced configuration, it is comforting to know ADFS is distributing tokens as it is designed.

Secondly, we can also see which services within ADFS are generating the most hits. This is great to see which sites are the most busy. This something that lacks in SCOM and OMS, and I was unable to generate even after some custom MP work.

 

 

If we go into the Bad Password Attempts widget, we can see not only the number of bad password attempts, but also see which user and at what time and their source IP the attempt was generated from — very cool!

Overall, AD Connect Health does an excellent job and provides rich data and expands on what SCOM already does.

Verdict

After comparing SCOM 2016, OMS and Azure AD Connect Health, the clear winner is Azure AD Connect Health. Not only is the configuration straight forward, but provides more than enough information to monitor the ADFS environment. Azure AD Connect Health provides rich and very clear dashboards with almost no effect other than some log configuration on the ADFS server(s). The data is comparable to what SCOM presents, however much more richer and detailed. OMS and SCOM are still good tools, however does require some more technical knowledge and building the dashboards can be laboursome.

Dual-Homing OMS/Microsoft Monitoring Agent (MMA) — Questions

Earlier this week, I posted on how the OMS/Microsoft Monitoring Agent (MMA) can be dual-homed for multiple OMS Workspaces.

A good question from the community came up (thank you @ Manoj Mathew), “Have you noticed any performance impacts on the Agents when they are multi homed to OMS?

In the OMS Query below — making use of OMS’ Log Analytics, I checked the performance data in the last 48 hours. Unfortunately I cannot go any further, since the MMA was deployed earlier in that day, and the second OMS workspace was added later that afternoon.

There are a few spikes in the Memory and CPU, but this is also a result of a few factors:

  • Initially there is a high level of CPU/Memory usage as OMS did its stuff when the MMA/OMS made friends and synced up their data/solutions
  • There is a small spike when the second OMS workspace was added but this is minimal at best
  • This server was being patched with 90+ Windows Server OS patches around 8PM.

The query I used to collect the data is here,

perfover48hours

Computer="COMPUTERNAME.FQDN" Type=Perf (CounterName="Available MBytes" OR CounterName="% Processor Time") (ObjectName=Memory OR ObjectName=Processor)

A second question being asked here is, “how many OMS Workspace IDs can be added to “dual-home” the MMA agent?

Unfortunately I only have 3 OMS Workspace’s to work with at the moment in this environment, but with that said, I can surely say a minimum of 3. If you have the ability to test more than 3, I would love to find out!

Dual-Homing OMS/Microsoft Monitoring Agent (MMA)

Today I learned that the MMA (Microsoft Monitoring Agent) has the ability to be “dual-homed“. Similar to what we have seen in the past with the System Center Operations Manager (SCOM) agent and dual-homing it to multiple SCOM environments/Management Groups, the same can be said for the Operations Management Suite (OMS)/MMA agent. By going into the MMA properties, you can add multiple OMS Workspace IDs.  This is great if you want the Computer reporting to multiple OMS Workspaces and/or Azure Subscriptions, as was the case for me today.

Simply launch the MMA agent, and within the Azure Log Analytics (OMS), add your OMS Workspace ID here.

Note, this works for the MMA version, 8.0.11030.0 — Windows. Has not been tested against the Linux Agent.

1

2